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

[Benjy Grogan]

On 6/20/06, Paul Howarth <paul at city-fan.org> wrote:
> On Tue, 2006-06-20 at 01:46 -0400, Benjy Grogan wrote:
> > On 6/19/06, Daniel J Walsh <dwalsh at redhat.com> wrote:
> > > 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
> >
> > Okay, I created a policy from audit2allow and used as many macros as I
> > could where it made sense.  Below I have the TE file that I wrote.
> > This policy works fine with setenforce 0 and doesn't generate many
> > AVCs at all anymore, except when I navigate outside of the user's home
> > directory when saving or opening a jpeg, and I've auditdenied some of
> > that stuff.  But when I turn enforcing on, setenforce 1, I get this
> > error:
> >
> > $ googleearth
> > Xlib: connection to ":0.0" refused by server
> > Xlib: No protocol specified
> >
> > There are no AVCs to be found in /var/log/messages.
>
> It's possible that the AVCs are being dontaudit-ed. Try this:
>
> # semodule -b /usr/share/selinux/targeted/enableaudit.pp
>
> This is a version of the base policy without the dontaudit rules.
>
> To revert this change:
>
> # semodule -b /usr/share/selinux/targeted/base.pp

I think the problem could be some X server avcs that have been
auditdenied but this module didn't change anything.  Perhaps
enableaudit needs to be expanded to enable auditing of all X server
avcs?

Benjy


>
> Paul.
>
>
>