Step-by-Step Guide To Creating SELinux Policy for Google Earth

[Benjy Grogan]

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
> >>
> >>
>
>