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.
Thanks, Benjy
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 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; ') domain_auto_trans(uncofined_t, googleearth_exec_t, googleearth_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
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
GOTO STEP 3
Thanks, Benjy
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
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) __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.
GOTO STEP 3
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.
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.
Is this possible? It might be a bit extreme 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?
Thanks, Benjy
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
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.
__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
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
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 :
- 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
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
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. I figured these lines should've handled any X server issues:
# XServer set-up
xserver_use_xdm_fds(googleearth_t) xserver_stream_connect_xdm(googleearth_t)
... but they don't.
So my Google Earth policy works in permissive mode but fails in enforcing mode without any AVCs to explain why not. Do you know how to fix this? Here's the TE I wrote:
policy_module(googleearth,1.0.7)
######################################## # # Declarations #
type googleearth_t; type googleearth_exec_t; domain_type(googleearth_t) init_daemon_domain(googleearth_t, googleearth_exec_t)
######################################## # # googleearth local policy # # Check in /etc/selinux/refpolicy/include for macros to use instead of allow rules.
# Some common macros (you might be able to remove some) files_read_etc_files(googleearth_t) libs_use_ld_so(googleearth_t) libs_use_shared_libs(googleearth_t) miscfiles_read_localization(googleearth_t) ## internal communication is often done using fifo and unix sockets. allow googleearth_t self:fifo_file { getattr read write }; allow googleearth_t self:unix_stream_socket create_stream_socket_perms;
allow googleearth_t self:tcp_socket { connect create getopt read write }; allow googleearth_t self:udp_socket { connect create getattr read write };
# Init script handling init_use_fds(googleearth_t) init_use_script_ptys(googleearth_t) domain_use_interactive_fds(googleearth_t)
gen_require(` type unconfined_t; ') domain_auto_trans(unconfined_t, googleearth_exec_t, googleearth_t)
# XServer set-up
xserver_use_xdm_fds(googleearth_t) xserver_stream_connect_xdm(googleearth_t)
# var_t stuff
gen_require(` type var_t; ')
allow googleearth_t var_t:file { getattr read };
# Connect to the unconfined domain using a unix domain stream socket. unconfined_stream_connect(googleearth_t)
# Send and receive messages from an unlabeled IPSEC association. kernel_sendrecv_unlabeled_association(googleearth_t)
allow googleearth_t devpts_t:chr_file { read write }; dev_rw_dri(googleearth_t)
# DISK ACCESS # allow reading of libcomponent.so et al in /usr/local/ allow googleearth_t usr_t:file { read execute getattr }; allow googleearth_t usr_t:lnk_file read;
# allow access to .googleearth in home directory
gen_require(` type user_home_dir_t; type user_home_t; type home_root_t; ') allow googleearth_t user_home_dir_t:dir { getattr search read write }; allow googleearth_t user_home_dir_t:file getattr; allow googleearth_t user_home_t:dir { add_name getattr remove_name search read write }; allow googleearth_t user_home_t:file { append getattr lock read write }; allow googleearth_t user_home_t:lnk_file { create read unlink };
# don't create AVCs outside of the user's home directory
auditdeny googleearth_t home_root_t:dir { getattr search };
# get extended attributes on files
fs_getattr_xattr_fs(googleearth_t)
# allow memory access
allow googleearth_t self:process { execmem execstack };
# kernel
gen_require(` type sysctl_kernel_t; type sysctl_t; ') allow googleearth_t sysctl_kernel_t:dir search; allow googleearth_t sysctl_kernel_t:file { getattr read };
allow googleearth_t sysctl_t:dir search;
# device proc
gen_require(` type proc_t; ') allow googleearth_t proc_t:dir search; allow googleearth_t proc_t:file { getattr read };
# temp dir
gen_require(` type tmp_t; ') allow googleearth_t tmp_t:file getattr; allow googleearth_t tmp_t:dir search; allow googleearth_t tmp_t:sock_file write;
# read fonts
miscfiles_read_fonts(googleearth_t)
# network stuff
corenet_tcp_sendrecv_all_if(googleearth_t) corenet_tcp_sendrecv_all_nodes(googleearth_t)
corenet_udp_sendrecv_all_if(googleearth_t) corenet_udp_sendrecv_all_nodes(googleearth_t)
corenet_tcp_connect_http_port(googleearth_t) corenet_tcp_sendrecv_http_port(googleearth_t)
corenet_udp_sendrecv_dns_port(googleearth_t)
sysnet_read_config(googleearth_t)
# unknown stuff
gen_require(` type ice_tmp_t; ') allow googleearth_t ice_tmp_t:dir search; allow googleearth_t ice_tmp_t:sock_file write;
gen_require(` type urandom_device_t; ') allow googleearth_t urandom_device_t:chr_file { getattr read };
Benjy
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
Paul.
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?
Benjy
Paul.
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.
On 6/20/06, Paul Howarth paul@city-fan.org wrote:
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.
How do you verify that you're using enableaudit.pp and not base.pp? I get these avcs after building and loading enableaudit but my Google Earth policy still gives off zero avcs after 20 minutes of use. Which would be great if it actually ran in enforcing mode.
Jun 20 15:18:03 localhost kernel: audit(1150831083.862:3836): avc: denied { siginh } for pid=7029 comm="setfiles" scontext=user_u:system_r:semanage_t:s0 tcontext=user_u:system_r:setfiles_t:s0 tclass=process Jun 20 15:18:03 localhost kernel: audit(1150831083.862:3837): avc: denied { rlimitinh } for pid=7029 comm="setfiles" scontext=user_u:system_r:semanage_t:s0 tcontext=user_u:system_r:setfiles_t:s0 tclass=process Jun 20 15:18:03 localhost kernel: audit(1150831083.862:3838): avc: denied { noatsecure } for pid=7029 comm="setfiles" scontext=user_u:system_r:semanage_t:s0 tcontext=user_u:system_r:setfiles_t:s0 tclass=process
Thanks for tips anyways. It should help narrow down the problem.
Benjy
On Tue, 2006-06-20 at 15:46 -0400, Benjy Grogan wrote:
How do you verify that you're using enableaudit.pp and not base.pp? I get these avcs after building and loading enableaudit but my Google Earth policy still gives off zero avcs after 20 minutes of use. Which would be great if it actually ran in enforcing mode.
Jun 20 15:18:03 localhost kernel: audit(1150831083.862:3836): avc: denied { siginh } for pid=7029 comm="setfiles" scontext=user_u:system_r:semanage_t:s0 tcontext=user_u:system_r:setfiles_t:s0 tclass=process Jun 20 15:18:03 localhost kernel: audit(1150831083.862:3837): avc: denied { rlimitinh } for pid=7029 comm="setfiles" scontext=user_u:system_r:semanage_t:s0 tcontext=user_u:system_r:setfiles_t:s0 tclass=process Jun 20 15:18:03 localhost kernel: audit(1150831083.862:3838): avc: denied { noatsecure } for pid=7029 comm="setfiles" scontext=user_u:system_r:semanage_t:s0 tcontext=user_u:system_r:setfiles_t:s0 tclass=process
Those avcs suggest that you are using enableaudit.pp, as they would normally be silenced by dontaudit rules. Try running the program under strace and checking the output to see precisely where it is failing. One case where we get no auditing at all is the net_admin capability check upon netlink recv; that will be fixed by a pending patch in the audit tree. Hopefully googleearth doesn't need that though ;)
On 6/20/06, Stephen Smalley sds@tycho.nsa.gov wrote:
On Tue, 2006-06-20 at 15:46 -0400, Benjy Grogan wrote:
How do you verify that you're using enableaudit.pp and not base.pp? I get these avcs after building and loading enableaudit but my Google Earth policy still gives off zero avcs after 20 minutes of use. Which would be great if it actually ran in enforcing mode.
Jun 20 15:18:03 localhost kernel: audit(1150831083.862:3836): avc: denied { siginh } for pid=7029 comm="setfiles" scontext=user_u:system_r:semanage_t:s0 tcontext=user_u:system_r:setfiles_t:s0 tclass=process Jun 20 15:18:03 localhost kernel: audit(1150831083.862:3837): avc: denied { rlimitinh } for pid=7029 comm="setfiles" scontext=user_u:system_r:semanage_t:s0 tcontext=user_u:system_r:setfiles_t:s0 tclass=process Jun 20 15:18:03 localhost kernel: audit(1150831083.862:3838): avc: denied { noatsecure } for pid=7029 comm="setfiles" scontext=user_u:system_r:semanage_t:s0 tcontext=user_u:system_r:setfiles_t:s0 tclass=process
Those avcs suggest that you are using enableaudit.pp, as they would normally be silenced by dontaudit rules. Try running the program under strace and checking the output to see precisely where it is failing. One case where we get no auditing at all is the net_admin capability check upon netlink recv; that will be fixed by a pending patch in the audit tree. Hopefully googleearth doesn't need that though ;)
Thanks. strace showed me that the problem was my own fault. I was incorrectly using auditdeny.
I'm currently trying to get my Google Earth selinux policy to allow CUPS. It's allowed but I find the cupsd_t domain's need to access the SElinux config and security file contexts strange. You can see below. Is this normal?
# Google Earth printing to CUPS
gen_require(` type cupsd_etc_t; type cupsd_rw_etc_t; type cupsd_var_run_t; type ipp_port_t; ') # how come cupsd_t has been denied these privileges and why would it need them? allow cupsd_t security_t:dir search; allow cupsd_t security_t:file read; allow cupsd_t selinux_config_t:dir search; allow cupsd_t selinux_config_t:file { getattr read };
# use CUPS service... cups_read_config(googleearth_t) allow googleearth_t cupsd_var_run_t:dir search; allow googleearth_t self:netlink_route_socket { r_netlink_socket_perms }; corenet_tcp_sendrecv_ipp_port(googleearth_t) corenet_tcp_connect_ipp_port(googleearth_t)
Benjy
-- Stephen Smalley National Security Agency
Benjy Grogan wrote:
On 6/20/06, Stephen Smalley sds@tycho.nsa.gov wrote:
On Tue, 2006-06-20 at 15:46 -0400, Benjy Grogan wrote:
How do you verify that you're using enableaudit.pp and not base.pp? I get these avcs after building and loading enableaudit but my Google Earth policy still gives off zero avcs after 20 minutes of use. Which would be great if it actually ran in enforcing mode.
Jun 20 15:18:03 localhost kernel: audit(1150831083.862:3836): avc: denied { siginh } for pid=7029 comm="setfiles" scontext=user_u:system_r:semanage_t:s0 tcontext=user_u:system_r:setfiles_t:s0 tclass=process Jun 20 15:18:03 localhost kernel: audit(1150831083.862:3837): avc: denied { rlimitinh } for pid=7029 comm="setfiles" scontext=user_u:system_r:semanage_t:s0 tcontext=user_u:system_r:setfiles_t:s0 tclass=process Jun 20 15:18:03 localhost kernel: audit(1150831083.862:3838): avc: denied { noatsecure } for pid=7029 comm="setfiles" scontext=user_u:system_r:semanage_t:s0 tcontext=user_u:system_r:setfiles_t:s0 tclass=process
Those avcs suggest that you are using enableaudit.pp, as they would normally be silenced by dontaudit rules. Try running the program under strace and checking the output to see precisely where it is failing. One case where we get no auditing at all is the net_admin capability check upon netlink recv; that will be fixed by a pending patch in the audit tree. Hopefully googleearth doesn't need that though ;)
Thanks. strace showed me that the problem was my own fault. I was incorrectly using auditdeny.
I'm currently trying to get my Google Earth selinux policy to allow CUPS. It's allowed but I find the cupsd_t domain's need to access the SElinux config and security file contexts strange. You can see below. Is this normal?
# Google Earth printing to CUPS is is gen_require(` type cupsd_etc_t; type cupsd_rw_etc_t; type cupsd_var_run_t; type ipp_port_t; ') # how come cupsd_t has been denied these privileges and why would it need them? allow cupsd_t security_t:dir search; allow cupsd_t security_t:file read; allow cupsd_t selinux_config_t:dir search; allow cupsd_t selinux_config_t:file { getattr read };
It does not need it. This is only because you are running in permissive mode. The first access would have been dontaudited and all of the other avc's would not been created.
# use CUPS service... cups_read_config(googleearth_t) allow googleearth_t cupsd_var_run_t:dir search; allow googleearth_t self:netlink_route_socket { r_netlink_socket_perms }; corenet_tcp_sendrecv_ipp_port(googleearth_t) corenet_tcp_connect_ipp_port(googleearth_t)
Benjy
-- Stephen Smalley National Security Agency
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
selinux@lists.fedoraproject.org
-
Benjy Grogan -
Daniel J Walsh -
Paul Howarth -
Stephen Smalley