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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 6/20/06, Paul Howarth <paul@xxxxxxxxxxxx> wrote:
On Tue, 2006-06-20 at 02:18 -0400, Benjy Grogan wrote:
> On 6/20/06, Paul Howarth <paul@xxxxxxxxxxxx> wrote:
> > On Tue, 2006-06-20 at 01:46 -0400, Benjy Grogan wrote:
> > > On 6/19/06, Daniel J Walsh <dwalsh@xxxxxxxxxx> wrote:
> > > > Benjy Grogan wrote:
> > > > > On 6/17/06, Daniel J Walsh <dwalsh@xxxxxxxxxx> wrote:
> > > > >> Benjy Grogan wrote:
> > > > >> > Hello:
> > > > >> >
> > > > >> > On 6/15/06, Daniel J Walsh <dwalsh@xxxxxxxxxx> 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?

My understanding is that enableaudit.pp is the same as base.pp but with
all of the dontaudit rules removed, so if you're still not getting the
AVCs after loading enableaudit.pp, I'm a bit stuck.

How do you verify that you're using enableaudit.pp and not base.pp?  I
get these avcs after building and loading enableaudit but my Google
Earth policy still gives off zero avcs after 20 minutes of use.  Which
would be great if it actually ran in enforcing mode.

Jun 20 15:18:03 localhost kernel: audit(1150831083.862:3836): avc:
denied  { siginh } for
pid=7029 comm="setfiles" scontext=user_u:system_r:semanage_t:s0
tcontext=user_u:system_r:setfiles_t:s0 tclass=process
Jun 20 15:18:03 localhost kernel: audit(1150831083.862:3837): avc:
denied  { rlimitinh } for  pid=7029 comm="setfiles"
scontext=user_u:system_r:semanage_t:s0
tcontext=user_u:system_r:setfiles_t:s0 tclass=process
Jun 20 15:18:03 localhost kernel: audit(1150831083.862:3838): avc:
denied  { noatsecure } for  pid=7029 comm="setfiles"
scontext=user_u:system_r:semanage_t:s0
tcontext=user_u:system_r:setfiles_t:s0 tclass=process

Thanks for tips anyways.  It should help narrow down the problem.

Benjy

--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux