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.
__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
