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
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)
No you do not want to do this.
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 :
- 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.
- 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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list