Step-by-Step Guide To Creating SELinux Policy for Google Earth
Benjy Grogan
benjy.grogan at gmail.com
Mon Jun 19 03:14:01 UTC 2006
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
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)
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