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