selinux October 2010

selinux@lists.fedoraproject.org

16 participants
18 discussions

sandbox cleanup?
by Christoph A. 20 Jun '11

20 Jun '11

Hi, I just noticed that I have over 100 processes running in the sandbox_web_client_t domain, although I closed all my sandbox windows. ps auxZ|grep sandbox_web_client_t|grep -c /usr/libexec/gvfsd 52 ps auxZ|grep sandbox_web_client_t|grep -c '/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session' 51 Shouldn't they be killed after I closed all sandbox windows? Kind regards, Christoph

5 11

sandbox: open new firefox tab from outside
by Christoph A. 22 Apr '11

22 Apr '11

Hi, I was using firefox within sandboxes for a while without perm. home directory. To store bookmarks, addons and so on, I started to use perm. homedir (-H). Because firefox does not allow multiple concurrent sessions (lock on .mozilla) it is not possible to open multiple websites when specifying the same sandbox homedir, hence I'm looking for a possibility to open new websites within a running sandbox from outside. Without sandboxes everyone can open new websites in a running firefox instance using: firefox -remote "openurl(http://www.mozilla.org)" sandbox scenario: 1. step: start firefox: sandbox -X -H homedir -T tempdir -t sandbox_web_t -l s0:c100,c100 firefox 2. step: sandbox -H homedir -T tempdir -t sandbox_web_t -l s0:c100,c100 firefox -remote "openurl(http://www.mozilla.org)" My current attempts fail because I'm unable use the '-l' option (#632377) but would the policy allow the 'firefox -remote' command if type and security level matches with the already running sandbox? kind regards, Christoph

2 4

SELinux and Shorewall with IPSets
by Mr Dash Four 17 Jan '11

17 Jan '11

Problems combining these 2 to run while SELinux is in 'enforced' mode (policy running is the 'stock' targeted one supplied with FC13). I get 2 audit alerts when Shorewall starts (and fails!) - see logs below. I have x86_64 arch machine with FC13 running. Stock Shorewall is installed. IPSet (xtunnels) is compiled in (though with the 'stock' rpm I am getting the same errors). The problem seems to be caused by the Shorewall init script (see further below). The relevant part of my syslog when SELinux is in enforced mode is: =========SELinux=Enforcing================================ Jun 26 23:18:38 dev1 shorewall[2456]: Compiling... Jun 26 23:18:38 dev1 kernel: type=1400 audit(1277590718.634:29543): avc: denied { create } for pid=2577 comm="ipset" scontext=unconfined_u:system_r:shorewall_t:s0 tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket Jun 26 23:18:38 dev1 kernel: type=1400 audit(1277590718.637:29544): avc: denied { create } for pid=2579 comm="ipset" scontext=unconfined_u:system_r:shorewall_t:s0 tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket Jun 26 23:18:38 dev1 shorewall[2456]: Compiling /etc/shorewall/zones... Jun 26 23:18:38 dev1 shorewall[2456]: Compiling /etc/shorewall/interfaces... Jun 26 23:18:38 dev1 shorewall[2456]: Determining Hosts in Zones... Jun 26 23:18:38 dev1 shorewall[2456]: Preprocessing Action Files... Jun 26 23:18:38 dev1 shorewall[2456]: Pre-processing /usr/share/shorewall/action.Drop... Jun 26 23:18:38 dev1 shorewall[2456]: Pre-processing /usr/share/shorewall/action.Reject... Jun 26 23:18:38 dev1 shorewall[2456]: Compiling /etc/shorewall/policy... Jun 26 23:18:38 dev1 shorewall[2456]: Compiling /etc/shorewall/blacklist... Jun 26 23:18:38 dev1 shorewall[2456]: ERROR: ipset names in Shorewall configuration files require Ipset Match in your kernel and iptables : /etc/shorewall/blacklist (line 11) Jun 26 23:18:38 dev1 shorewall[2456]: ERROR: Shorewall start failed ========================================================== When I switch SELinux to Permissive I get two further errors: =========SELinux=Permissive=============================== Jun 26 23:32:45 dev1 kernel: type=1400 audit(1277591565.629:29551): avc: denied { create } for pid=3799 comm="ipset" scontext=unconfined_u:system_r:shorewall_t:s0 tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket Jun 26 23:32:45 dev1 kernel: type=1400 audit(1277591565.629:29552): avc: denied { getopt } for pid=3799 comm="ipset" lport=255 scontext=unconfined_u:system_r:shorewall_t:s0 tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket Jun 26 23:32:45 dev1 kernel: type=1400 audit(1277591565.629:29553): avc: denied { setopt } for pid=3799 comm="ipset" lport=255 scontext=unconfined_u:system_r:shorewall_t:s0 tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket Jun 26 23:32:45 dev1 shorewall[3678]: Compiling /etc/shorewall/zones... Jun 26 23:32:45 dev1 shorewall[3678]: Compiling /etc/shorewall/interfaces... Jun 26 23:32:45 dev1 shorewall[3678]: Determining Hosts in Zones... Jun 26 23:32:45 dev1 shorewall[3678]: Preprocessing Action Files... Jun 26 23:32:45 dev1 shorewall[3678]: Pre-processing /usr/share/shorewall/action.Drop... Jun 26 23:32:45 dev1 shorewall[3678]: Pre-processing /usr/share/shorewall/action.Reject... Jun 26 23:32:45 dev1 shorewall[3678]: Compiling /etc/shorewall/policy... Jun 26 23:32:45 dev1 shorewall[3678]: Compiling /etc/shorewall/blacklist... Jun 26 23:32:45 dev1 shorewall[3678]: Adding Anti-smurf Rules Jun 26 23:32:45 dev1 shorewall[3678]: Compiling TCP Flags filtering... Jun 26 23:32:45 dev1 shorewall[3678]: Compiling Kernel Route Filtering... Jun 26 23:32:45 dev1 shorewall[3678]: Compiling Martian Logging... Jun 26 23:32:45 dev1 shorewall[3678]: Compiling MAC Filtration -- Phase 1... Jun 26 23:32:45 dev1 shorewall[3678]: Compiling /etc/shorewall/rules... Jun 26 23:32:45 dev1 shorewall[3678]: Generating Transitive Closure of Used-action List... Jun 26 23:32:45 dev1 shorewall[3678]: Processing /usr/share/shorewall/action.Reject for chain Reject... Jun 26 23:32:45 dev1 shorewall[3678]: Processing /usr/share/shorewall/action.Drop for chain Drop... Jun 26 23:32:45 dev1 shorewall[3678]: Compiling MAC Filtration -- Phase 2... Jun 26 23:32:45 dev1 shorewall[3678]: Applying Policies... Jun 26 23:32:45 dev1 shorewall[3678]: Generating Rule Matrix... Jun 26 23:32:45 dev1 shorewall[3678]: Creating iptables-restore input... Jun 26 23:32:45 dev1 shorewall[3678]: Compiling iptables-restore input for chains blacklst mangle:... Jun 26 23:32:45 dev1 shorewall[3678]: Shorewall configuration compiled to /var/lib/shorewall/.start Jun 26 23:32:45 dev1 shorewall[3678]: Starting Shorewall.... Jun 26 23:32:45 dev1 shorewall[3678]: Initializing... Jun 26 23:32:46 dev1 kernel: u32 classifier Jun 26 23:32:46 dev1 kernel: Performance counters on Jun 26 23:32:46 dev1 kernel: input device check on Jun 26 23:32:46 dev1 kernel: Actions configured Jun 26 23:32:46 dev1 shorewall[3678]: Processing /etc/shorewall/init ... Jun 26 23:32:46 dev1 shorewall[3678]: loading /etc/shorewall/ips/blacklist-x1.ips Jun 26 23:32:46 dev1 shorewall[3678]: loading /etc/shorewall/ips/blacklist-x2.ips Jun 26 23:32:46 dev1 shorewall[3678]: loading /etc/shorewall/ips/blacklist-z1.ips Jun 26 23:32:47 dev1 shorewall[3678]: loading /etc/shorewall/ips/blacklist-z2.ips Jun 26 23:32:49 dev1 shorewall[3678]: Processing /etc/shorewall/tcclear ... Jun 26 23:32:49 dev1 shorewall[3678]: Setting up Route Filtering... Jun 26 23:32:49 dev1 shorewall[3678]: Setting up Martian Logging... Jun 26 23:32:49 dev1 shorewall[3678]: Setting up Proxy ARP... Jun 26 23:32:49 dev1 shorewall[3678]: Setting up Traffic Control... Jun 26 23:32:49 dev1 shorewall[3678]: Preparing iptables-restore input... Jun 26 23:32:49 dev1 shorewall[3678]: Running /sbin/iptables-restore... Jun 26 23:32:49 dev1 shorewall[3678]: IPv4 Forwarding Enabled Jun 26 23:32:49 dev1 shorewall[3678]: Processing /etc/shorewall/start ... Jun 26 23:32:49 dev1 shorewall[3678]: Processing /etc/shorewall/started ... Jun 26 23:32:49 dev1 shorewall[3678]: Shorewall started ========================================================== The problem seems to be caused by the shorewall init script, which is: ===========Shorewall init script========================== modprobe ifb numifbs=1 ip link set dev ifb0 up # configure the ipsets sw_ips_mask='/etc/shorewall/ips/*.ips' ipset_exec='/usr/sbin/ipset' if [ "$COMMAND" = start ]; then $ipset_exec -F $ipset_exec -X for c in `/bin/ls $sw_ips_mask 2>/dev/null`; do echo loading $c $ipset_exec -R < $c done fi ========================================================== The above script executes /usr/sbin/ipset to create my IP Sets needed for running Shorewall (all IP set commands are contained in those *.ips files). These IP sets comprise mainly of IP subnets which are part of my blacklists (banned IP subnets), though they also contain some IP Port sets as well. Don't know why SELinux denies "create" (and then "getopt" and "setopt") on a, what seems to be, raw ip socket (IPSet do not use/need one as far as I know!)? If I remove the IP Set part of the init script above and rearrange Shorewall to run without IPSets all is well, though its functionality is VERY limited and barely useful to me! Two questions to the SELinux gurus on here: 1) Why am I getting these alerts? and 2) How can I fix the problem so that I could run both Shorewall and IPSets with SELinux in Enforced mode? This is important for me as this is a production server and a lot of stuff runs on it and needs to be available 24/7. Many thanks in advance!

4 57

selinux policy UBAC question
by Roberto Sassu 03 Nov '10

03 Nov '10

Hi all i'm using the selinux policy shipped with Fedora 13 and UBAC turned on. I removed the unconfined package and i noted the unconfined_t domain with unconfined_u user is unable to access a file with another selinux user. I tried to build a custom module which contains the line: ubac_process_exempt(unconfined_t) but this does not solve the issue. How do i configure the policy to allow some domains to circumvent the UBAC enforcement? Thanks in advance for replies. Roberto Sassu

2 11

tzdata AVC
by Tony Molloy 27 Oct '10

27 Oct '10

Hi, I'm running SELinux in enforcing mode on fully updated CentOS-5 servers. selinux-policy-2.4.6-279.el5_5.1.noarch After the latest "possibly glibc" update I've seen the following AVC on several of my servers. Summary: SELinux is preventing tzdata-update (tzdata_t) "getattr" to / (fs_t). Detailed Description: SELinux denied access requested by tzdata-update. It is not expected that this access is required by tzdata-update and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context root:system_r:tzdata_t:SystemLow-SystemHigh Target Context system_u:object_r:fs_t Target Objects / [ filesystem ] Source tzdata-update Source Path <Unknown> Port <Unknown> Host remote-backup.x.y.z Source RPM Packages Target RPM Packages filesystem-2.4.0-3.el5 Policy RPM selinux-policy-2.4.6-279.el5_5.1 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name remote-backup.x.y.z Platform Linux remote-backup.x.y.z 2.6.18-194.17.1.el5 #1 SMP Wed Sep 29 12:50:31 EDT 2010 x86_64 x86_64 Alert Count 3 First Seen Fri Oct 22 06:31:14 2010 Last Seen Wed Oct 27 06:39:14 2010 Local ID ec15ac2d-b644-40fb-809a-2b3809b001e5 Line Numbers Raw Audit Messages host=remote-backup.csis.ul.ie type=AVC msg=audit(1288157954.817:16502): avc: denied { getattr } for pid=2135 comm="tzdata-update" name="/" dev=sda5 ino=2 scontext=root:system_r:tzdata_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem Regards, Tony

3 3

Transitions for files.
by Vadym Chepkov 25 Oct '10

25 Oct '10

Hi, I have an issue I would like to fix properly. I have a policy for mediawiki defined this way: apache_content_template(mediawiki) apache_search_sys_content(httpd_mediawiki_script_t) /var/www/mediawiki/bin(/.*)? gen_context(system_u:object_r:httpd_mediawiki_script_exec_t,s0) /var/www/mediawiki/images(/.*)? gen_context(system_u:object_r:httpd_mediawiki_script_rw_t,s0) /var/www/mediawiki/cache(/.*)? gen_context(system_u:object_r:httpd_mediawiki_script_rw_t,s0) And it works fine. The trouble occurs when you upload a new version of an existing file (any file goes under images, by the way) I assume mediawiki in this case creates a file in some temp directory, removes original file and then moves the file in place. This causes the context to be set like this: d/d6: -rw-r--r-- apache apache system_u:object_r:httpd_tmp_t:s0 Speedtest.png instead of "normal" d/d3: -rw-r--r-- apache apache system_u:object_r:httpd_mediawiki_script_rw_t:s0 PuTTY2.png Here are related AVCs: time->Mon Oct 18 13:45:03 2010 type=SYSCALL msg=audit(1287409503.893:6728): arch=c000003e syscall=4 success=no exit=-13 a0=7fff25eb8490 a1=7fff25eb53c0 a2=7fff25eb53c0 a3=0 items=0 ppid=14205 pid=14206 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) comm="convert" exe="/usr/bin/convert" subj=system_u:system_r:httpd_mediawiki_script_t:s0 key=(null) type=AVC msg=audit(1287409503.893:6728): avc: denied { getattr } for pid=14206 comm="convert" path="/var/www/mediawiki/images/d/d6/Speedtest.png" dev=sda1 ino=737287 scontext=system_u:system_r:httpd_mediawiki_script_t:s0 tcontext=system_u:object_r:httpd_tmp_t:s0 tclass=file ---- time->Mon Oct 18 13:45:03 2010 type=SYSCALL msg=audit(1287409503.893:6729): arch=c000003e syscall=2 success=no exit=-13 a0=7fff25eb8490 a1=0 a2=1b6 a3=0 items=0 ppid=14205 pid=14206 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) comm="convert" exe="/usr/bin/convert" subj=system_u:system_r:httpd_mediawiki_script_t:s0 key=(null) type=AVC msg=audit(1287409503.893:6729): avc: denied { read } for pid=14206 comm="convert" name="Speedtest.png" dev=sda1 ino=737287 scontext=system_u:system_r:httpd_mediawiki_script_t:s0 tcontext=system_u:object_r:httpd_tmp_t:s0 tclass=file I'd rather not allow mediawiki access to generic httpd_tmp_t, so I wonder if there is a way to enforce the proper context when file is being moved in place? Thank you, Vadym

3 11

Come spy on me Facebook Port
by Rituraj Goswami 24 Oct '10

24 Oct '10

Ahoy Fedora, I sent ye a bottle to come aboard to Ye Olde Facebook many moons ago and want ye to know that once ye comes aboard, we'll be able to send bottles o' messages, rob glances at eachother's portriats, and set sail for grog fests, and more. Thank ye, Rituraj To join the Ye olde Facebook ship, climb aboard below deck: http://www.facebook.com/p.php?i=100000084056671&k=Z6E3Y5WSQ52AYEEJPB63RVSVP… Already have an account? Add this email address to your account: http://www.facebook.com/n/?merge_accounts.php&e=fedora-selinux-list%40redha… ======================================= fedora-selinux-list(a)redhat.com was shown aboard the jolly ship Facebook by Rituraj Goswami. If you do not wish to receive this type of email from Facebook in the future, please follow the link below to unsubscribe. http://www.facebook.com/o.php?k=fca54f&u=1000322530&mid=32e7675G3b9fb5e2G0G8 Facebook, Inc. P.O. Box 10005, Palo Alto, CA 94303

1 0

Addition of selinux users causes "Multiple same specifications" warnings during startup
by Radha Venkatesh (radvenka) 20 Oct '10

20 Oct '10

I have created SeLinux users using "semanage user" and tied the SeLinux users to Linux users using "semanage login". I find that on startup, there are several warnings thrown for "Multiple same specifications". Below is an example /etc/selinux/strict/contexts/files/file_contexts: Multiple same specifications for /dev/null/\.screenrc I then checked and found that file_contexts has file_contexts.homedirs:/dev/null/\.screenrc -- ccmusergrp_u:object_r:user_screen_ro_home_t:s0 file_contexts.homedirs:/dev/null/\.screenrc -- ccmusergrp_u:object_r:user_screen_ro_home_t:s0 file_contexts.homedirs:/dev/null/\.screenrc -- specialuser_u:object_r:user_screen_ro_home_t:s0 file_contexts.homedirs:/dev/null/\.screenrc -- ccmusergrp_u:object_r:user_screen_ro_home_t:s0 file_contexts.homedirs:/dev/null/\.screenrc -- ccmusergrp_u:object_r:user_screen_ro_home_t:s0 file_contexts.homedirs:/dev/null/\.screenrc -- specialuser_u:object_r:user_screen_ro_home_t:s0 Looks like there is an entry for every Linux user I tied to the SeLinux user. I am using libselinux-1.33.4-5.5.el5 libsemanage-1.9.1-4.4.el5 policycoreutils-1.33.12-14.8.el5 libsepol-1.15.2-3.el5 and do not have an option to move to later releases. Is there a way for me to get rid of these warnings or suppress them, without changing the source code provided by RedHat? Thanks, Radha.

3 15

Re: paths
by mark 18 Oct '10

18 Oct '10

John, Daniel, Thanks for the pointers. I'm trying to figure out if I dare run it on a production server.... mark

1 0

paths
by mark 18 Oct '10

18 Oct '10

Would it be a reasonable suggestiong for an enhancement to give full paths? I've been looking at AVC's and the o/p from sealert for days trying to figure out the path for various apparetnly temporary files ./<blah.blah> with a label of default_t. Of course, once I find it, then I have to figure out what to do with it, whether I need to set the context on the directories they're being created in, or if that has to do with the special perl that/s in a very nonstandard path that's running the .cgi that's creating them (and yes, I'm told it all does have to be there), so pointers to any threads or docs on that would be appreciated. mark

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux October 2010