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 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@xxxxxxxxxx >> > https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >>
-- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
