Step-by-Step Guide To Creating SELinux Policy for Google Earth
Daniel J Walsh
dwalsh at redhat.com
Mon Jun 19 14:06:01 UTC 2006
Benjy Grogan wrote:
> On 6/17/06, Daniel J Walsh <dwalsh at redhat.com> wrote:
>> Benjy Grogan wrote:
>> > Hello:
>> >
>> > On 6/15/06, Daniel J Walsh <dwalsh at redhat.com> wrote:
>> >> Benjy Grogan wrote:
>> >> > Hello:
>> >> >
>> >> > Would it be possible for the SELinux team at Red Hat to create an
>> >> > SELinux policy module for Google Earth and to show the step by step
>> >> > process for confining the application? I think these kind of
>> examples
>> >> > would be useful to developers attempting to create SELinux policies
>> >> > for other rpm packages out there. I'm not interested so much in
>> the
>> >> > actual policy module, but in creating it myself from step-by-step
>> >> > instructions. IMHO, that would be the best way to educate
>> developers
>> >> > on how to use SELinux.
>> >> >
>> >> Google-earth is not the best example of this but
>> >>
>> >> The way I would go about it would be to first use policygentool to
>> >> create my initial fc/if/te files
>> >>
>> >> #cd /tmp
>> >> #mkdir googlearth
>> >> #cd googleearth
>> >> STEP 1
>> >> #policygentool googlearth /usr/local/google-earth/googleearth-bin
>> >> answer some questions to the best of my ability
>> >
>> > I answered the questions, but I had little idea as to what pidfiles
>> > were. As for logs, Google Earth doesn't use /var/log but I know it
>> > must log something in ~/.googleearth. That would be a directory that
>> > depends on which user is at the moment using Google Earth. There's
>> > probably a better way of specifying this after running policygentool.
>> >
>> > I didn't know if there were any /var/lib files, so I left that alone.
>> > The module didn't have an init script, which is used by
>> > daemons/services, right? The module will be a heavy user of the
>> > network, so that was answered yes, but further restricting Google
>> > Earth's network access would be useful, such as no access 192.168.x.x.
>> >
>> >> STEP2
>> >> add the following lines to the te file to cause the transition form
>> >> uncofined_t to googleearth
>> >> cat >> googleearth.te << __EOF
>> >> gen_require(`
>> >> type unconfined_t;
>> >> ')
>> >
>> > First time I've seen ` and ' used.
>> >
>> >> domain_auto_trans(uncofined_t, googleearth_exec_t, googleearth_t)
>> This should be unconfined_t.
>
> I had made this change. I was avoiding the policy completely by using
> /usr/local/google-earth/googleearth instead of
> /usr/local/google-earth/googleearth-bin.
>
> When I do run googleearth-bin I get:
>
> $ /usr/local/google-earth/googleearth-bin
> /usr/local/google-earth/googleearth-bin: error while loading shared
> libraries: ./libcomponent.so: cannot open shared object file: No such
> file or directory
>
You should be running in permissive mode and translating avc messages to
allow rules via
audit2allow -R -i /var/log/messages
> There are currently these shared libraries to take care of:
>
> # ls /usr/local/google-earth/lib
> libauth.so libgooglesearch.so libmeasure.so
> libbase.so libgps.so libmng.so.1
> libbasicIngest.so libIGAttrs.so libnavigate.so
> libcollada.so libIGCollision.so libnet.so
> libcommon.so libIGCore.so libpng12.so.0
> libcomponent.so libIGDisplay.so libqt-mt.so.3
> libcrypto.so.0.9.8 libIGExportCommon.so libqui.so.1
> libcurl.so.3 libIGGfx.so librender.so
> libevll.so libIGGui.so libssl.so.0.9.8
> libframework.so libIGMath.so libstdc++.so.6
> libfreeimage.so.3 libIGOpt.so libtiff.so.3
> libfusion.so libIGSg.so libtweak.so
> libgcc_s.so.1 libIGUtils.so libwebbrowser.so
> libgeobase.so libjpeg.so.62 libwmsbase.so
> libGLU.so.1 liblayer.so libz.so.1
> libgoogleearth.so libmath.so
>
> I included libcomponent.so when policygentool asks for any /var/lib
> libraries, so it's listed in googleearth.fc as
>
> /usr/local/google-earth/libcomponent.so
> gen_context(system_u:object_r:googleearth_var_lib_t,s0)
>
No you do not want to do this.
> Not sure if this is the right way to go about it, because afterwards I
> get the exact same message about libcomponent.so, and I'm sure every
> other shared library is inaccessible too. How could I go about
> allowing access to these shared libraries?
>
> Benjy
>
>
>> >>
>> >> __EOF
>> >> STEP 3
>> >> # make -f /usr/share/selinux/devel/Makefile
>> >> # semodule -i googleearth.pp
>> >>
>> >> # setenforce 0
>> >> In a different window as a normal user
>> >> > googleearth
>> >> Test out lots of stuff
>> >
>> > There was a strange problem with Google Earth images not being able to
>> > be pasted into GIMP but able to to be pasted into KolourPaint. I
>> > removed the module using:
>> >
>> > # /usr/sbin/semodule --remove=googleearth
>> > libsepol.sepol_genbools_array: boolean googleearth_disable_trans no
>> > longer in policy
>> >
>> > ... and discovered the problem had nothing to do with SELinux.
>> >
>> >> Go back to the original root window
>> >>
>> >> grep googleearth /var/log/messages (or /var/log/audit/audit.log) |
>> >> audit2allow -R
>> >> Analyze these rules and macros to the best of my ability and add
>> them to
>> >> the te file
>> >
>> > The result from this was:
>> >
>> > # grep googleearth /var/log/messages | audit2allow -R
>> > /usr/bin/audit2allow: No AVC messages found.
>> >
>> I don't think you transitioned. You should check which context you ran
>> googleearth in with the ps command
>>
>> ps -eZ | grep google
>> >> GOTO STEP 3
>> > p
>> > So going back to step 3 wouldn't improve the policy. How could I
>> > further restrict the policy module so that I could perhaps generate
>> > some AVC messages? Two things I would like to do with the policy are
>> > :
>> >
>> > 1) Restrict Google Earth's file access, so that it can only read/write
>> > to .googleearth and read/write to ~/images (a directory available on
>> > my acccount, but maybe not others. if no /images directory available
>> > then do nothing). In fact all other user accounts do not have
>> > .googleearth or ~/images, so they would have to be created.
>> >
>> You can define file context for these directories. You could create a
>> googleearth_rw_t and define it to ~/images and .googlearth.
>> If you grab the policy src rpm and take a look at the mozilla context it
>> will give you an idea.
>>
>> > 2) Restrict Google Earth's network access, so that it can't access my
>> > local network at 192.168.x.x, or other local services.
>> >
>> I believe you can do this but it is fairly complicated, There is work
>> going on to tie SELinux and iptables closer together to make this
>> easier.
>> > me but I'm interested in
>> > restricting this proprietary application's access to the bare minimum.
>> > For fun mostly.
>> >
>> > Benjy
>> >
>> > PS: As I add or remove the googleearth policy module using semodule,
>> > is this affected by booting up and is it dependent on which kernel
>> > 2.6.16.x I'm using?
>> >
>> Independent. semodule recomposes the policy file on disk, and init just
>> reads the new policy file. So the change is permanent and
>> all SELinux kernels would use the policy
>> >
>> >
>> >>
>> >> > Thanks,
>> >> > Benjy
>> >> >
>> >> > --
>> >> > fedora-selinux-list mailing list
>> >> > fedora-selinux-list at redhat.com
>> >> > https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>> >>
>> >>
>>
>>
More information about the fedora-selinux-list
mailing list