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
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
> :
>
> 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
