selinux May 2011

selinux@lists.fedoraproject.org

17 participants
15 discussions

[sandbox] modifying the Xephyr window title (patch)
by Christoph A. 25 Jun '12

25 Jun '12

Hi, If most of your windows are sandboxed applications, your bar looks like: [Sandbox sandbo..] [Sandbox sandbo..] [Sandbox sandbo..] and it is hard to find a specific application. example of a current Xephyr title: Sandbox sandbox_web_t:s0:c112,c991 -- /usr/bin/firefox with the modification in the attached patch titles will look like: /usr/bin/firefox (sandbox_web_t) and it should be easier to find a specific application. In addition to the type I would find it handy to also include the DISPLAY in the title (needed when using xsel for copy'n paste). The second patch only adds '-nolisten tcp' to Xephyr, but if there are use cases where one needs Xephyr to open a listener this patch will break thinks. regards, Christoph A. btw: secon's manpage doesn't contain the '-l' option.

2 10

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

Cannot disable SELinux
by Vratislav Podzimek 07 Jun '11

07 Jun '11

Hi, I have a question: What's the reason for the "Failed to load SELinux policy" displaying on my booting netbook with "selinux=0" as boot option and also SELinux disabled in /etc/selinux/config ? (running Fedora 15) Something doesn't realize that selinux is disabled. How can I prevent this? It's increasing boot time. Thanks a lot in advance Vratislav Podzimek

3 6

interesting group of AVCs
by Mr Dash Four 02 Jun '11

02 Jun '11

After routine check of my audit logs this morning I found this (capture with ausearch -i -m AVC): ---- type=SYSCALL msg=audit(30/05/11 01:42:21.687:173) : arch=i386 syscall=socketcall(connect) success=no exit=-115(Operation now in progress) a0=3 a1=b6dfeb40 a2=55ee30 a3=0 items=0 ppid=1 pid=4308 auid=root uid=_transmission gid=_transmission euid=_transmission suid=_transmission fsuid=_transmission egid=_transmission sgid=_transmission fsgid=_transmission tty=(none) ses=1 comm=transmission-da exe=/usr/bin/transmission-daemon subj=unconfined_u:system_r:transmissionbt_t:s0 key=(null) type=AVC msg=audit(30/05/11 01:42:21.687:173) : avc: denied { recv } for pid=4308 comm=transmission-da saddr=xx.xx.xx.xx src=80 daddr=10.x.x.x dest=39322 netif=lo scontext=unconfined_u:system_r:transmissionbt_t:s0 tcontext=system_u:object_r:unauthorised_packet_t:s0 tclass=packet ---- type=AVC msg=audit(30/05/11 01:42:24.697:174) : avc: denied { recv } for pid=5716 comm=sh saddr=xx.xx.xx.xx src=80 daddr=10.x.x.x dest=39322 netif=lo scontext=unconfined_u:system_r:transmissionbt_t:s0 tcontext=system_u:object_r:unauthorised_packet_t:s0 tclass=packet ---- type=AVC msg=audit(30/05/11 01:42:30.707:175) : avc: denied { recv } for pid=5820 comm=ipset saddr=xx.xx.xx.xx src=80 daddr=10.x.x.x dest=39322 netif=lo scontext=unconfined_u:system_r:transmissionbt_t:s0 tcontext=system_u:object_r:unauthorised_packet_t:s0 tclass=packet ---- type=AVC msg=audit(30/05/11 01:42:42.727:176) : avc: denied { recv } for pid=6068 comm=sh saddr=xx.xx.xx.xx src=80 daddr=10.x.x.x dest=39322 netif=lo scontext=unconfined_u:system_r:transmissionbt_t:s0 tcontext=system_u:object_r:unauthorised_packet_t:s0 tclass=packet ---- A couple of interesting things: 1. "saddr" is address outside any of my network, so I presume this is coming in (the avc is "recv"). The destination address, however, is on one of my interfaces (tun device). What baffles me is that "netif" field says "lo" which would suggest the loopback interface. How is that possible? 2. The first AVC (173) refers to an attempt at receiving a packet from outside and this was thwarted (success=no) by my iptables/selinux packing mechanism. The following 3 AVCs however, have more sinister look, I think, because they come from two *different* executables: "comm=sh" (which suggests the command shell?) and "comm=ipset" (suggesting the ipset command I have on the system). Does that mean an attempt was made at executing these programs as well as an attempt to receive packets using these? These 3 logs are a complete mystery to me as neither the shell (sh) nor ipset have capabilities of sending or receiving packets over the wire! 3. According to the last 3 logs (174-176), an attempt at receiving packet was made (and denied) by these executables ("sh" and "ipset") using destination address of my tun interface (10.x.x.x), but the interface indicated in those logs is "lo". How is that possible?

2 3

problem with likewise and audit messages
by Maria Iano 31 May '11

31 May '11

We use targeted SELinux and Likewise Open on our RHEL 5 and CentOS 5 servers, even though Likewise is currently not supported with SELinux in enforcing mode. Both of them together have been working reliably for us so far. The audit logs fill up with AVC messages like the ones I have pasted at the end of this message, which are all regarding /var/ lib/likewise/.lsassd and don't appear to matter from a functional point of view for the system. I have configured setroubleshoot to send emails to an internal mailing list when something is blocked, because apart from the likewise events anything else is really urgent. The problem is that the list receives so many messages about /var/lib/ likewise/.lsassd that the urgent ones get "lost". I have asked the folks at Likewise about this and their answer is always that SELinux should be permissive or disabled. Is there some way to prevent auditd from logging these AVC messages? type=AVC msg=audit(1306183684.644:121931): avc: denied { connectto } for pid=31266 comm="vsftpd" path="/var/lib/likewise/.lsassd" scontext=system_u:system_r:ftpd_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket type=AVC msg=audit(1306185430.740:122001): avc: denied { write } for pid=378 comm="pickup" name=".lsassd" dev=dm-1 ino=426071 scontext=system_u:system_r:postfix_pickup_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=sock_file type=AVC msg=audit(1306179615.139:121656): avc: denied { connectto } for pid=22431 comm="httpd" path="/var/lib/likewise/.lsassd" scontext=user_u:system_r:httpd_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket type=USER_AUTH msg=audit(1306265986.269:124088): user pid=25822 uid=0 auid=4294967295 subj=system_u:system_r:unconfined_t:s0-s0:c0.c1023 msg='PAM: authentication acct="layout" : exe="/usr/sbin/ sshd" (hostname=asb-sys61.us.ad.gannett.com, addr=10.0.65.242, terminal=ssh res=failed)' type=AVC msg=audit(1306853338.309:51215): avc: denied { write } for pid=5472 comm="genhomedircon" name=".lsassd" dev=dm-4 ino=32827 scontext=user_u:system_r:semanage_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=sock_file type=AVC msg=audit(1306853338.309:51215): avc: denied { connectto } for pid=5472 comm="genhomedircon" path="/var/lib/likewise/.lsassd" scontext=user_u:system_r:semanage_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket Thanks, Maria

2 4

excluding auditd events
by Mr Dash Four 25 May '11

25 May '11

I am having difficulty in trying to exclude a certain type of messages for certain SELinux types being reported to the auditd daemon. In particular, I would like to exclude the following from being reported (and thus filling up my audit logs unnecessarily): msgtype={USER_ACCT|CRED_ACQ|USER_START|CRED_DISP|USER_END} obj_type=crond_t success=0 When I try to add this as a rule with "auditctl -A exclude,never -F msgtype=USER_ACCT -F obj_type=crond_t -F success=0" I get "Only msgtype field can be used with exclude filter" which is a bit daft as I wish to exclude USER_ACCT message type from being reported *only* for the "crond_t" SELinux type. Is there any way I can do this?

5 15

[sandbox] non permanent '-H'
by Christoph A. 24 May '11

24 May '11

Hi, I like to run firefox instances where modifications to the profile are not permanent but with the feature of permanently installed addons, bookmarks, ... To accomplish that one can start firefox via sanbox -X -i ~/.mozilla .... and it will simply work. The problem arises if one would like to have different "templates" sandbox -X -i ~/sandboxes/fftemplate1/.mozilla ... sandbox -X -i ~/sandboxes/fftemplate2/.mozilla ... this wont work because the path within the sandbox will also be ~/sandboxes/fftemp.... instead of ~/.mozilla Is there a way to accomplish what I want? Or is there something like -H needed with the difference that it shouldn't store modifications? kind regards, Christoph A. btw: I didn't find a way to tell firefox to look for the profile folder at a different location.

4 12

nagios plugins with state files
by Vadym Chepkov 24 May '11

24 May '11

Hi, There is a series of nagios plugins which have to record previous call's status in a file. For example, check_snmp_uptime. It would record the previous uptime of a monitored server into a bdb file and will generate an ERROR state if during a next call uptime was lower then previous. Unfortunately, there is no suitable context for files like that. even nagios_system_plugin_tmp_t doesn't fit the bill. # ausearch -m avc -ts today ---- time->Thu May 26 07:13:23 2011 type=SYSCALL msg=audit(1306408403.157:422): arch=40000003 syscall=5 success=yes exit=3 a0=90368a8 a1=80c2 a2=1b6 a3=9026770 items=0 ppid=27717 pid=27718 auid=4294967295 uid=498 gid=493 euid=498 suid=498 fsuid=498 egid=493 sgid=493 fsgid=493 tty=(none) ses=4294967295 comm="check_snmp_upti" exe="/usr/bin/perl" subj=system_u:system_r:nagios_services_plugin_t:s0 key=(null) type=AVC msg=audit(1306408403.157:422): avc: denied { read write open } for pid=27718 comm="check_snmp_upti" name="__db.t100" dev=dm-2 ino=379 scontext=system_u:system_r:nagios_services_plugin_t:s0 tcontext=system_u:object_r:nagios_system_plugin_tmp_t:s0 tclass=file type=AVC msg=audit(1306408403.157:422): avc: denied { create } for pid=27718 comm="check_snmp_upti" name="__db.t100" scontext=system_u:system_r:nagios_services_plugin_t:s0 tcontext=system_u:object_r:nagios_system_plugin_tmp_t:s0 tclass=file type=AVC msg=audit(1306408403.157:422): avc: denied { add_name } for pid=27718 comm="check_snmp_upti" name="__db.t100" scontext=system_u:system_r:nagios_services_plugin_t:s0 tcontext=system_u:object_r:nagios_system_plugin_tmp_t:s0 tclass=dir type=AVC msg=audit(1306408403.157:422): avc: denied { write } for pid=27718 comm="check_snmp_upti" name="uptime" dev=dm-2 ino=208 scontext=system_u:system_r:nagios_services_plugin_t:s0 tcontext=system_u:object_r:nagios_system_plugin_tmp_t:s0 tclass=dir ---- time->Thu May 26 07:13:23 2011 type=SYSCALL msg=audit(1306408403.158:423): arch=40000003 syscall=197 success=yes exit=0 a0=3 a1=bfdab0b0 a2=541ff4 a3=64 items=0 ppid=27717 pid=27718 auid=4294967295 uid=498 gid=493 euid=498 suid=498 fsuid=498 egid=493 sgid=493 fsgid=493 tty=(none) ses=4294967295 comm="check_snmp_upti" exe="/usr/bin/perl" subj=system_u:system_r:nagios_services_plugin_t:s0 key=(null) type=AVC msg=audit(1306408403.158:423): avc: denied { getattr } for pid=27718 comm="check_snmp_upti" path="/var/spool/nagios/uptime/__db.t100" dev=dm-2 ino=379 scontext=system_u:system_r:nagios_services_plugin_t:s0 tcontext=system_u:object_r:nagios_system_plugin_tmp_t:s0 tclass=file ---- time->Thu May 26 07:13:23 2011 type=SYSCALL msg=audit(1306408403.168:424): arch=40000003 syscall=38 success=yes exit=0 a0=93ecf70 a1=90368a8 a2=91b048 a3=64 items=0 ppid=27717 pid=27718 auid=4294967295 uid=498 gid=493 euid=498 suid=498 fsuid=498 egid=493 sgid=493 fsgid=493 tty=(none) ses=4294967295 comm="check_snmp_upti" exe="/usr/bin/perl" subj=system_u:system_r:nagios_services_plugin_t:s0 key=(null) type=AVC msg=audit(1306408403.168:424): avc: denied { rename } for pid=27718 comm="check_snmp_upti" name="__db.t100" dev=dm-2 ino=379 scontext=system_u:system_r:nagios_services_plugin_t:s0 tcontext=system_u:object_r:nagios_system_plugin_tmp_t:s0 tclass=file type=AVC msg=audit(1306408403.168:424): avc: denied { remove_name } for pid=27718 comm="check_snmp_upti" name="__db.t100" dev=dm-2 ino=379 scontext=system_u:system_r:nagios_services_plugin_t:s0 tcontext=system_u:object_r:nagios_system_plugin_tmp_t:s0 tclass=dir ---- time->Thu May 26 07:31:48 2011 type=SYSCALL msg=audit(1306409508.204:434): arch=40000003 syscall=195 success=yes exit=0 a0=8cb7c68 a1=bfdf8030 a2=423ff4 a3=64 items=0 ppid=28479 pid=28480 auid=4294967295 uid=498 gid=493 euid=498 suid=498 fsuid=498 egid=493 sgid=493 fsgid=493 tty=(none) ses=4294967295 comm="check_snmp_upti" exe="/usr/bin/perl" subj=system_u:system_r:nagios_services_plugin_t:s0 key=(null) type=AVC msg=audit(1306409508.204:434): avc: denied { getattr } for pid=28480 comm="check_snmp_upti" path="/var/spool/nagios/uptime/t100" dev=dm-2 ino=379 scontext=system_u:system_r:nagios_services_plugin_t:s0 tcontext=system_u:object_r:nagios_system_plugin_tmp_t:s0 tclass=file ---- time->Thu May 26 07:31:48 2011 type=SYSCALL msg=audit(1306409508.205:435): arch=40000003 syscall=5 success=yes exit=3 a0=8cb7c68 a1=8002 a2=0 a3=88f5770 items=0 ppid=28479 pid=28480 auid=4294967295 uid=498 gid=493 euid=498 suid=498 fsuid=498 egid=493 sgid=493 fsgid=493 tty=(none) ses=4294967295 comm="check_snmp_upti" exe="/usr/bin/perl" subj=system_u:system_r:nagios_services_plugin_t:s0 key=(null) type=AVC msg=audit(1306409508.205:435): avc: denied { open } for pid=28480 comm="check_snmp_upti" name="t100" dev=dm-2 ino=379 scontext=system_u:system_r:nagios_services_plugin_t:s0 tcontext=system_u:object_r:nagios_system_plugin_tmp_t:s0 tclass=file type=AVC msg=audit(1306409508.205:435): avc: denied { read write } for pid=28480 comm="check_snmp_upti" name="t100" dev=dm-2 ino=379 scontext=system_u:system_r:nagios_services_plugin_t:s0 tcontext=system_u:object_r:nagios_system_plugin_tmp_t:s0 tclass=file Did I miss a proper context or I should create a new type? Thanks, Vadym

3 3

Upgrade F13 -> F14: gdm-session-wor / login denials
by Christoph A. 24 May '11

24 May '11

Hi, I did an upgrade from f13 to f14 (preupgrade method), after the reboot network was not working. My next step was: touch /.autorelabel reboot after the reboot, relabeling took place and after finishing the usual reboot occurred. Since the relabeling the machines gdm is not starting anymore. Logins on the tty (ctrl+alt+F2) are also not working. login attempts result in an immediate logout. Booting with selinux=0 as boot option works fine (gdm starts, login works). In the logfiles one can find these AVCs: [ 28.919108] type=1400 audit(1306418925.312:5): avc: denied { entrypoint } for pid=2067 comm="gdm-session-wor" path="/etc/X11/xinit/Xsession" dev=dm-1 ino=3539578 scontext=unconfined_u:system_r:abrt_helper_t:s0-s0:c0.c1023 tcontext=system_u:object_r:bin_t:s0 tclass=file gdm-binary[1875]: WARNING: GdmDisplay: display lasted 1.689620 seconds WARNING: GdmLocalDisplayFactory: maximum number of X display failures reached: check X server log for errors kernel: [ 53.017140] type=1400 audit(1306418949.453:11): avc: denied { entrypoint } for pid=2227 comm="login" path="/bin/bash" dev=dm-1 ino=262272 scontext=unconfined_u:system_r:abrt_helper_t:s0-s0:c0.c1023 tcontext=system_u:object_r:shell_exec_t:s0 tclass=filekernel: [ 53.020348] init: tty (/dev/tty2) main process ended, respawning Any hints how to fix this? thanks, Christoph A.

3 6

SELinux is preventing /usr/bin/skype from mmap_zero access on the memprotect Unknown.
by Francis Shim 17 May '11

17 May '11

SELinux is preventing /usr/bin/skype from mmap_zero access on the memprotect Unknown. ***** Plugin mmap_zero (53.1 confidence) suggests ************************** If you do not think /usr/bin/skype should need to mmap low memory in the kernel. Then you may be under attack by a hacker, this is a very dangerous access. Do contact your security administrator and report this issue. ***** Plugin catchall_boolean (42.6 confidence) suggests ******************* If you want to control the ability to mmap a low area of the address space, as configured by /proc/sys/kernel/mmap_min_addr. Then you must tell SELinux about this by enabling the 'mmap_low_allowed' boolean. Do setsebool -P mmap_low_allowed 1 ***** Plugin catchall (5.76 confidence) suggests *************************** If you believe that skype should be allowed mmap_zero access on the Unknown memprotect by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep skype /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context unconfined_u:unconfined_r:unconfined_execmem_t:s0- s0:c0.c1023 Target Context unconfined_u:unconfined_r:unconfined_execmem_t:s0- s0:c0.c1023 Target Objects Unknown [ memprotect ] Source skype Source Path /usr/bin/skype Port <Unknown> Host mobile-pc.localdomain Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.9.7-40.fc14 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name mobile-pc.localdomain Platform Linux mobile-pc.localdomain 2.6.35.13-91.fc14.i686.PAE #1 SMP Tue May 3 13:29:55 UTC 2011 i686 i686 Alert Count 100 First Seen Mon 16 May 2011 03:37:35 PM EDT Last Seen Mon 16 May 2011 03:37:35 PM EDT Local ID 162a1493-50dc-4231-ad0f-808d6fe5330b Raw Audit Messages type=AVC msg=audit(1305574655.789:127): avc: denied { mmap_zero } for pid=2784 comm="skype" scontext=unconfined_u:unconfined_r:unconfined_execmem_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_execmem_t:s0-s0:c0.c1023 tclass=memprotect Hash: skype,unconfined_execmem_t,unconfined_execmem_t,memprotect,mmap_zero audit2allow #============= unconfined_execmem_t ============== #!!!! This avc is allowed in the current policy allow unconfined_execmem_t self:memprotect mmap_zero; audit2allow -R #============= unconfined_execmem_t ============== #!!!! This avc is allowed in the current policy allow unconfined_execmem_t self:memprotect mmap_zero;

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux May 2011