From foreverterran at gmail.com Mon Sep 1 07:45:44 2008 From: foreverterran at gmail.com (foreverterran) Date: Mon, 1 Sep 2008 10:45:44 +0300 Subject: Linux/Unix system admin looking for job Message-ID: Hello, ABOUT ME: EXPERIENCE SUMMARY: Operating Systems: . FreeBSD . RHEL . Suse, SLES 9/10 . CentOS . Fedora . Ubuntu . Debian . Microsoft Windows 98/xp/2000/2003/NT Software and Networking: . Apache HTTP/HTTPS servers (versions 1.3.x/2.x ) . Mail (Sendmail, Postfix, Amavisd-new, ClamAV, Spamassassin, Courier IMAP) . MySQL, PostgreSQL, Sybase (backup, maintenance, tuning, replication) . Monitoring (MRTG, Zabbix, Munin) . Samba, NFS . NTP, ntpdate . Firewall (iptables, ipfw, ipfilter, shorewall) . LDAP (OpenLDAP) . Backup (Rsnapshot, Amanda) . Virtualisation (Qemu, Vmware, Xen) . High Availability (Hearbeat, load balancing) . TCP/IP, UDP, ICMP, DHCP, SNMP, NAT, VPN . Perl, bash scripting Working experience: . Administrated and configured more then 50 linux/unix servers. . Managing of the mail service using Sendmail and Postfix (virtual domains, MySQL, Antispam, Antivirus, SMTP authentication SASL). More then 5000 mailusers. . Managing, using Postfix and LDAP (Antispam, Antivirus, OpenLDAP, SMTP authentication SASL). More the 10 000 mailusers. . Tuning, maintained huge MySQL databases. . Apache (1.3.x / 2.x) tuning. Strong security experience . Implemented Rsnapshot, Amanda backup system. . Central monitoring system (Zabbix). . Software/hardware testing. . High Availability servers setup using Hearbeat. . Load balancing. WORK HISTORY: February 2002 - July 2003 System administration of UNIX Internet servers. Setup and support mail server with Sendmail and Postfix MTA (virtual domains, MySQL, Antispam, Antivirus, SMTP+Auth) more then 5000 mailusers, Apache, DNS(Bind), FTP, Samba. LAN/WAN security, VPN. Firewall tuning (shorewall, iptables). Juny 2003 - February 2005 Setup and support mail servers with Postfix MTA and LDAP (Spamassassin, ClamAV, OpenLDAP, SMTP auth). More the 10 000 mailusers. Huge MySQL database tuning, support. High raffic Apache web servers tuning. Network Security Auditing. Monitoring system (Munin). February 2005 - June 2006 Network management (packet analize, logs). Maintenance of security policies throughout the network. Design and implementation of a daily backup plan (rsnapshot). Sybase and PostgreSQL deployment/maintainence. Shell scripting (SED,AWK). June 2006 - August 2008 Responsible for network wide securit. Installed and maintained several load balancers. Wifi station and AP security. IBM Blade center virtualisation (Qemu, Vmware, Xen). Several DNS, LDAP, SMTP, SMTP-backup, POP3, Apache, High Availability (Hearbeat) servers setup, maintenance. Central monitoring system (Zabbix). CERTIFICATE: 1. Novell Certified Linux Professional 10 2. Linux technical specialist EDUCATION: 1.Informatics Bachelor's degree. Telecommute! mail: foreverterran at gmail.com From mmcallis at redhat.com Tue Sep 2 01:04:09 2008 From: mmcallis at redhat.com (Murray McAllister) Date: Tue, 02 Sep 2008 11:04:09 +1000 Subject: error when adding a translation with "semanage translation -a" Message-ID: <48BC9109.2030404@redhat.com> Hi, This is probably user error. I want to add a translation: 1. sudo cat /etc/selinux/targeted/setrans.conf s0= s0-s0:c0.c1023=SystemLow-SystemHigh s0:c0.c1023=SystemHigh 2. $ sudo semanage translation -l Level Translation s0 s0-s0:c0.c1023 SystemLow-SystemHigh s0:c0.c1023 SystemHigh 3. Attempt to add a new translation: $ sudo semanage translation -a -T NotSecret s0:c1 /etc/init.d/functions: line 19: /sbin/consoletype: Permission denied basename: write error: Permission denied basename: write error: Permission denied env: /etc/init.d/mcstrans: Permission denied 4. Translation appears to have been added: sudo semanage translation -l Level Translation s0 s0-s0:c0.c1023 SystemLow-SystemHigh s0:c0.c1023 SystemHigh s0:c1 NotSecret sudo cat /etc/selinux/targeted/setrans.conf s0= s0-s0:c0.c1023=SystemLow-SystemHigh s0:c0.c1023=SystemHigh s0:c1=NotSecret The following is logged to /var/log/messages: Aug 31 20:57:00 localhost setroubleshoot: SELinux is preventing service (semanage_t) "execute" to ./consoletype (consoletype_exec_t). For complete SELinux messages. run sealert -l 3a9da9b1-9310-492b-a4fd-3706d8d78259 Aug 31 20:57:00 localhost setroubleshoot: SELinux is preventing service (semanage_t) "execute" to ./consoletype (consoletype_exec_t). For complete SELinux messages. run sealert -l 3a9da9b1-9310-492b-a4fd-3706d8d78259 Aug 31 20:57:00 localhost setroubleshoot: SELinux is preventing service (semanage_t) "read" to pipe (semanage_t). For complete SELinux messages. run sealert -l 154967ff-45a0-4b8f-bf04-25546f129dd3 Aug 31 20:57:00 localhost setroubleshoot: SELinux is preventing service (semanage_t) "read" to pipe (semanage_t). For complete SELinux messages. run sealert -l 154967ff-45a0-4b8f-bf04-25546f129dd3 Aug 31 20:57:00 localhost setroubleshoot: SELinux is preventing basename (semanage_t) "getattr" to pipe (semanage_t). For complete SELinux messages. run sealert -l 641f7545-c40c-4d79-84c7-97e2b32d8c0a Aug 31 20:57:00 localhost setroubleshoot: SELinux is preventing basename (semanage_t) "write" to pipe (semanage_t). For complete SELinux messages. run sealert -l 2ab7598a-b0f7-4dec-a10d-cb4cfac057ee Aug 31 20:57:01 localhost setroubleshoot: SELinux is preventing basename (semanage_t) "getattr" to pipe (semanage_t). For complete SELinux messages. run sealert -l 641f7545-c40c-4d79-84c7-97e2b32d8c0a Aug 31 20:57:01 localhost setroubleshoot: SELinux is preventing basename (semanage_t) "write" to pipe (semanage_t). For complete SELinux messages. run sealert -l 2ab7598a-b0f7-4dec-a10d-cb4cfac057ee Aug 31 20:57:01 localhost setroubleshoot: SELinux is preventing service (semanage_t) "read" to pipe (semanage_t). For complete SELinux messages. run sealert -l 154967ff-45a0-4b8f-bf04-25546f129dd3 Aug 31 20:57:01 localhost setroubleshoot: SELinux is preventing env (semanage_t) "transition" to /etc/rc.d/init.d/mcstrans (semanage_t). For complete SELinux messages. run sealert -l ac0f934e-29dc-4702-a2f4-3a752150cb8f The following is logged to /var/log/audit/audit.log: type=AVC msg=audit(1220180220.598:367): avc: denied { execute } for pid=2118 comm="service" name="consoletype" dev=sda5 ino=73034 scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 tcontext=system_u:object_r:consoletype_exec_t:s0 tclass=file type=SYSCALL msg=audit(1220180220.598:367): arch=40000003 syscall=11 success=no exit=-13 a0=8d4c760 a1=8d4c7a8 a2=8d4c3b8 a3=0 items=0 ppid=2117 pid=2118 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="service" exe="/bin/bash" subj=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1220180220.599:368): avc: denied { execute } for pid=2118 comm="service" name="consoletype" dev=sda5 ino=73034 scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 tcontext=system_u:object_r:consoletype_exec_t:s0 tclass=file type=SYSCALL msg=audit(1220180220.599:368): arch=40000003 syscall=33 success=no exit=-13 a0=8d4c760 a1=1 a2=11 a3=8d4c760 items=0 ppid=2117 pid=2118 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="service" exe="/bin/bash" subj=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1220180220.637:369): avc: denied { read } for pid=2116 comm="service" path="pipe:[12134]" dev=pipefs ino=12134 scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 tclass=fifo_file type=SYSCALL msg=audit(1220180220.637:369): arch=40000003 syscall=3 success=no exit=-13 a0=3 a1=bfb075c8 a2=80 a3=80 items=0 ppid=2115 pid=2116 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="service" exe="/bin/bash" subj=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1220180220.679:370): avc: denied { read } for pid=2116 comm="service" path="pipe:[12135]" dev=pipefs ino=12135 scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 tclass=fifo_file type=SYSCALL msg=audit(1220180220.679:370): arch=40000003 syscall=3 success=no exit=-13 a0=3 a1=bfb079c8 a2=80 a3=80 items=0 ppid=2115 pid=2116 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="service" exe="/bin/bash" subj=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1220180220.694:371): avc: denied { getattr } for pid=2119 comm="basename" path="pipe:[12135]" dev=pipefs ino=12135 scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 tclass=fifo_file type=SYSCALL msg=audit(1220180220.694:371): arch=40000003 syscall=197 success=no exit=-13 a0=1 a1=bfd3e414 a2=960ff4 a3=9614c0 items=0 ppid=2116 pid=2119 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="basename" exe="/bin/basename" subj=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1220180220.708:372): avc: denied { write } for pid=2119 comm="basename" path="pipe:[12135]" dev=pipefs ino=12135 scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 tclass=fifo_file type=SYSCALL msg=audit(1220180220.708:372): arch=40000003 syscall=4 success=no exit=-13 a0=1 a1=b7f3d000 a2=8 a3=8 items=0 ppid=2116 pid=2119 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="basename" exe="/bin/basename" subj=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1220180220.727:373): avc: denied { getattr } for pid=2120 comm="basename" path="pipe:[12136]" dev=pipefs ino=12136 scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 tclass=fifo_file type=SYSCALL msg=audit(1220180220.727:373): arch=40000003 syscall=197 success=no exit=-13 a0=1 a1=bffb9684 a2=960ff4 a3=9614c0 items=0 ppid=2116 pid=2120 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="basename" exe="/bin/basename" subj=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1220180220.728:374): avc: denied { write } for pid=2120 comm="basename" path="pipe:[12136]" dev=pipefs ino=12136 scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 tclass=fifo_file type=SYSCALL msg=audit(1220180220.728:374): arch=40000003 syscall=4 success=no exit=-13 a0=1 a1=b80b8000 a2=8 a3=8 items=0 ppid=2116 pid=2120 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="basename" exe="/bin/basename" subj=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1220180220.749:375): avc: denied { read } for pid=2116 comm="service" path="pipe:[12136]" dev=pipefs ino=12136 scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 tclass=fifo_file type=SYSCALL msg=audit(1220180220.749:375): arch=40000003 syscall=3 success=no exit=-13 a0=3 a1=bfb079c8 a2=80 a3=80 items=0 ppid=2115 pid=2116 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="service" exe="/bin/bash" subj=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1220180220.760:376): avc: denied { transition } for pid=2121 comm="env" path="/etc/rc.d/init.d/mcstrans" dev=sda5 ino=222868 scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:semanage_t:s0 tclass=process type=SYSCALL msg=audit(1220180220.760:376): arch=40000003 syscall=11 success=no exit=-13 a0=bfd449ce a1=bfd435b8 a2=9922858 a3=5 items=0 ppid=2116 pid=2121 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="env" exe="/bin/env" subj=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 key=(null) The system: * Fedora release 9 (Sulphur) * kernel-2.6.25.14-108.fc9.i686 * kernel-headers-2.6.25.14-108.fc9.i386 * policycoreutils-2.0.52-5.fc9.i386 * mcstrans-0.2.11-1.fc9.i386 * selinux-policy-targeted-3.3.1-84.fc9.noarch * selinux-policy-3.3.1-84.fc9.noarch * selinux-policy-devel-3.3.1-84.fc9.noarch * libselinux-python-2.0.67-4.fc9.i386 * libselinux-2.0.67-4.fc9.i386 $ sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 22 Policy from config file: targeted ps -eZ | grep mcs system_u:system_r:setrans_t:SystemLow-SystemHigh 1262 ? 00:00:00 mcstransd Regards, Murray. From selinux at gmail.com Tue Sep 2 19:52:46 2008 From: selinux at gmail.com (Tom London) Date: Tue, 2 Sep 2008 12:52:46 -0700 Subject: AVCs generated by oom actions.... Message-ID: <4c4ba1530809021252t92e7694ra3b997207881e213@mail.gmail.com> I'm having some out-of-memory issues with latest kernels: https://bugzilla.redhat.com/show_bug.cgi?id=460848 I've noticed that when this happens, I get audit and AVC spew. Appears that I get 'sys_rawio', 'sys_admin', and 'sys_resource' AVCs for processes that are about to commit suicide. I have no idea what is causing these, and whether these are bugs (or features ;)). Any ideas/wisdom welcome! tom [root at tlondon ~]# audit2allow -i oom-audit.txt #============= NetworkManager_t ============== allow NetworkManager_t self:capability { sys_rawio sys_admin sys_resource }; #============= audisp_t ============== allow audisp_t self:capability { sys_rawio sys_admin sys_resource }; #============= auditd_t ============== allow auditd_t self:capability { sys_rawio sys_admin }; #============= bluetooth_t ============== allow bluetooth_t self:capability { sys_rawio sys_admin sys_resource }; #============= consolekit_t ============== allow consolekit_t self:capability { sys_rawio sys_admin sys_resource }; #============= dhcpc_t ============== allow dhcpc_t self:capability { sys_rawio sys_admin }; #============= getty_t ============== allow getty_t self:capability sys_rawio; #============= kerneloops_t ============== allow kerneloops_t self:capability { sys_rawio sys_admin sys_resource }; #============= restorecond_t ============== allow restorecond_t self:capability { sys_rawio sys_admin sys_resource }; #============= rpcd_t ============== allow rpcd_t self:capability { sys_rawio sys_admin sys_resource }; #============= sendmail_t ============== allow sendmail_t self:capability { sys_rawio sys_admin sys_resource }; #============= setroubleshootd_t ============== allow setroubleshootd_t self:capability { sys_rawio sys_admin sys_resource }; #============= sshd_t ============== allow sshd_t self:capability { sys_rawio sys_admin }; #============= syslogd_t ============== allow syslogd_t self:capability sys_rawio; #============= unconfined_mono_t ============== allow unconfined_mono_t self:process execstack; #============= xdm_t ============== allow xdm_t self:capability sys_admin; [root at tlondon ~]# -- Tom London From olivares14031 at yahoo.com Tue Sep 2 23:12:30 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Tue, 2 Sep 2008 16:12:30 -0700 (PDT) Subject: many avcs at startup, readahead and several others Message-ID: <941746.47387.qm@web52607.mail.re2.yahoo.com> Dear fellow selinux troubleshooters and testers, Using rawhide, I have seen several avcs at startup namely readahead and others, while I found out that the sound problem is due to selinux getting in the way of pulse. Here's a few avcs. Advise and/or workarounds appreciated, setroubleshoot has not kicked in, these are from dmesg | grep 'avcs' [root at localhost ~]# dmesg | grep 'avc' type=1400 audit(1220390408.063:4): avc: denied { read write } for pid=611 comm="readahead" path="/dev/console" dev=tmpfs ino=408 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file type=1400 audit(1220390408.064:5): avc: denied { read write } for pid=611 comm="readahead" path="/dev/console" dev=tmpfs ino=408 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file type=1400 audit(1220390408.064:6): avc: denied { read write } for pid=611 comm="readahead" path="/dev/console" dev=tmpfs ino=408 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file type=1400 audit(1220390408.788:7): avc: denied { fowner } for pid=611 comm="readahead" capability=3 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:system_r:readahead_t:s0 tclass=capability type=1400 audit(1220390408.837:8): avc: denied { fowner } for pid=611 comm="readahead" capability=3 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:system_r:readahead_t:s0 tclass=capability type=1400 audit(1220390408.838:9): avc: denied { fowner } for pid=611 comm="readahead" capability=3 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:system_r:readahead_t:s0 tclass=capability type=1400 audit(1220390409.131:10): avc: denied { fowner } for pid=611 comm="readahead" capability=3 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:system_r:readahead_t:s0 tclass=capability type=1400 audit(1220390433.392:11): avc: denied { write } for pid=1457 comm="ip6tables-resto" path="/0" dev=devpts ino=2 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:devpts_t:s0 tclass=chr_file type=1400 audit(1220390434.665:12): avc: denied { write } for pid=1679 comm="ip" path="/0" dev=devpts ino=2 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:devpts_t:s0 tclass=chr_file type=1400 audit(1220390483.087:13): avc: denied { search } for pid=1941 comm="pcscd" name="dbus" dev=dm-0 ino=3276848 scontext=system_u:system_r:pcscd_t:s0 tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=dir type=1400 audit(1220390498.350:14): avc: denied { execute } for pid=2393 comm="gdm" name="rpm" dev=dm-0 ino=24117303 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:rpm_exec_t:s0 tclass=file type=1400 audit(1220390498.351:15): avc: denied { getattr } for pid=2393 comm="gdm" path="/bin/rpm" dev=dm-0 ino=24117303 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:rpm_exec_t:s0 tclass=file type=1400 audit(1220390498.351:16): avc: denied { getattr } for pid=2393 comm="gdm" path="/bin/rpm" dev=dm-0 ino=24117303 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:rpm_exec_t:s0 tclass=file type=1400 audit(1220391361.963:17): avc: denied { setattr } for pid=3251 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220391361.965:18): avc: denied { setattr } for pid=3251 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220391361.965:19): avc: denied { setattr } for pid=3251 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220391361.966:20): avc: denied { setattr } for pid=3251 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220391361.966:21): avc: denied { write } for pid=3251 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220391480.205:22): avc: denied { setattr } for pid=3267 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220391480.206:23): avc: denied { setattr } for pid=3267 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220391480.206:24): avc: denied { setattr } for pid=3267 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220391480.206:25): avc: denied { setattr } for pid=3267 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220391480.206:26): avc: denied { write } for pid=3267 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220396664.211:27): avc: denied { setattr } for pid=3639 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220396664.211:28): avc: denied { setattr } for pid=3639 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220396664.212:29): avc: denied { setattr } for pid=3639 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220396664.212:30): avc: denied { setattr } for pid=3639 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220396664.212:31): avc: denied { write } for pid=3639 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220396675.758:32): avc: denied { setattr } for pid=3655 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220396675.759:33): avc: denied { setattr } for pid=3655 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220396675.759:34): avc: denied { setattr } for pid=3655 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220396675.760:35): avc: denied { setattr } for pid=3655 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220396675.760:36): avc: denied { write } for pid=3655 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220396688.315:37): avc: denied { setattr } for pid=3667 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220396688.316:38): avc: denied { setattr } for pid=3667 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220396688.317:39): avc: denied { setattr } for pid=3667 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220396688.317:40): avc: denied { setattr } for pid=3667 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220396688.318:41): avc: denied { write } for pid=3667 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220396800.645:42): avc: denied { setattr } for pid=3788 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220396800.645:43): avc: denied { setattr } for pid=3788 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220396800.646:44): avc: denied { setattr } for pid=3788 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220396800.646:45): avc: denied { setattr } for pid=3788 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220396800.647:46): avc: denied { write } for pid=3788 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220396814.195:47): avc: denied { setattr } for pid=3800 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220396814.196:48): avc: denied { setattr } for pid=3800 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220396814.196:49): avc: denied { setattr } for pid=3800 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220396814.197:50): avc: denied { setattr } for pid=3800 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=1400 audit(1220396814.197:51): avc: denied { write } for pid=3800 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir Thanks, Antonio From selinux at gmail.com Tue Sep 2 23:28:27 2008 From: selinux at gmail.com (Tom London) Date: Tue, 2 Sep 2008 16:28:27 -0700 Subject: many avcs at startup, readahead and several others In-Reply-To: <941746.47387.qm@web52607.mail.re2.yahoo.com> References: <941746.47387.qm@web52607.mail.re2.yahoo.com> Message-ID: <4c4ba1530809021628t78a6628l98d4f6a373051db4@mail.gmail.com> On Tue, Sep 2, 2008 at 4:12 PM, Antonio Olivares wrote: > Dear fellow selinux troubleshooters and testers, > > Using rawhide, I have seen several avcs at startup namely readahead and others, while I found out that the sound problem is due to selinux getting in the way of pulse. Here's a few avcs. Advise and/or workarounds appreciated, setroubleshoot has not kicked in, these are from dmesg | grep 'avcs' > > [root at localhost ~]# dmesg | grep 'avc' > type=1400 audit(1220390408.063:4): avc: denied { read write } for pid=611 comm="readahead" path="/dev/console" dev=tmpfs ino=408 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file > type=1400 audit(1220390408.064:5): avc: denied { read write } for pid=611 comm="readahead" path="/dev/console" dev=tmpfs ino=408 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file > type=1400 audit(1220390408.064:6): avc: denied { read write } for pid=611 comm="readahead" path="/dev/console" dev=tmpfs ino=408 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file > type=1400 audit(1220390408.788:7): avc: denied { fowner } for pid=611 comm="readahead" capability=3 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:system_r:readahead_t:s0 tclass=capability > type=1400 audit(1220390408.837:8): avc: denied { fowner } for pid=611 comm="readahead" capability=3 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:system_r:readahead_t:s0 tclass=capability > type=1400 audit(1220390408.838:9): avc: denied { fowner } for pid=611 comm="readahead" capability=3 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:system_r:readahead_t:s0 tclass=capability > type=1400 audit(1220390409.131:10): avc: denied { fowner } for pid=611 comm="readahead" capability=3 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:system_r:readahead_t:s0 tclass=capability > type=1400 audit(1220390433.392:11): avc: denied { write } for pid=1457 comm="ip6tables-resto" path="/0" dev=devpts ino=2 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:devpts_t:s0 tclass=chr_file > type=1400 audit(1220390434.665:12): avc: denied { write } for pid=1679 comm="ip" path="/0" dev=devpts ino=2 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:devpts_t:s0 tclass=chr_file > type=1400 audit(1220390483.087:13): avc: denied { search } for pid=1941 comm="pcscd" name="dbus" dev=dm-0 ino=3276848 scontext=system_u:system_r:pcscd_t:s0 tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=dir > type=1400 audit(1220390498.350:14): avc: denied { execute } for pid=2393 comm="gdm" name="rpm" dev=dm-0 ino=24117303 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:rpm_exec_t:s0 tclass=file > type=1400 audit(1220390498.351:15): avc: denied { getattr } for pid=2393 comm="gdm" path="/bin/rpm" dev=dm-0 ino=24117303 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:rpm_exec_t:s0 tclass=file > type=1400 audit(1220390498.351:16): avc: denied { getattr } for pid=2393 comm="gdm" path="/bin/rpm" dev=dm-0 ino=24117303 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:rpm_exec_t:s0 tclass=file > type=1400 audit(1220391361.963:17): avc: denied { setattr } for pid=3251 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220391361.965:18): avc: denied { setattr } for pid=3251 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220391361.965:19): avc: denied { setattr } for pid=3251 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220391361.966:20): avc: denied { setattr } for pid=3251 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220391361.966:21): avc: denied { write } for pid=3251 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220391480.205:22): avc: denied { setattr } for pid=3267 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220391480.206:23): avc: denied { setattr } for pid=3267 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220391480.206:24): avc: denied { setattr } for pid=3267 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220391480.206:25): avc: denied { setattr } for pid=3267 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220391480.206:26): avc: denied { write } for pid=3267 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220396664.211:27): avc: denied { setattr } for pid=3639 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220396664.211:28): avc: denied { setattr } for pid=3639 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220396664.212:29): avc: denied { setattr } for pid=3639 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220396664.212:30): avc: denied { setattr } for pid=3639 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220396664.212:31): avc: denied { write } for pid=3639 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220396675.758:32): avc: denied { setattr } for pid=3655 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220396675.759:33): avc: denied { setattr } for pid=3655 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220396675.759:34): avc: denied { setattr } for pid=3655 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220396675.760:35): avc: denied { setattr } for pid=3655 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220396675.760:36): avc: denied { write } for pid=3655 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220396688.315:37): avc: denied { setattr } for pid=3667 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220396688.316:38): avc: denied { setattr } for pid=3667 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220396688.317:39): avc: denied { setattr } for pid=3667 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220396688.317:40): avc: denied { setattr } for pid=3667 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220396688.318:41): avc: denied { write } for pid=3667 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220396800.645:42): avc: denied { setattr } for pid=3788 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220396800.645:43): avc: denied { setattr } for pid=3788 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220396800.646:44): avc: denied { setattr } for pid=3788 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220396800.646:45): avc: denied { setattr } for pid=3788 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220396800.647:46): avc: denied { write } for pid=3788 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220396814.195:47): avc: denied { setattr } for pid=3800 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220396814.196:48): avc: denied { setattr } for pid=3800 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220396814.196:49): avc: denied { setattr } for pid=3800 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220396814.197:50): avc: denied { setattr } for pid=3800 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=1400 audit(1220396814.197:51): avc: denied { write } for pid=3800 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > > > Thanks, > > Antonio > Try "restorecon -v -R ~" -- Tom London From mmcallis at redhat.com Wed Sep 3 00:29:13 2008 From: mmcallis at redhat.com (Murray McAllister) Date: Wed, 03 Sep 2008 10:29:13 +1000 Subject: changing categories with "semanage translation -m" Message-ID: <48BDDA59.40408@redhat.com> Hi, I added the following two translations using "semanage translation -a -T [name] level": s0:c1 NotSecret s0:c1.c2 Secret If I want to change the categories, say to have Secret as s0:c3, or only so:c2, can I use semanage? I tried "semanage translation -m -T Secret s0:c2": /usr/sbin/semanage: s0:c2 not defined in translations If I use "-a" instead of "-m", it adds another translation. Is the recommended way of changing categories adding a new one, and then 'semanage login -m -r s0:xy user', for any users using the old range? Cheers. I am using: * Fedora release 9 (Sulphur) * kernel-2.6.25.14-108.fc9.i686 * kernel-headers-2.6.25.14-108.fc9.i386 * policycoreutils-2.0.52-5.fc9.i386 * mcstrans-0.2.11-1.fc9.i386 * selinux-policy-targeted-3.3.1-84.fc9.noarch * selinux-policy-3.3.1-84.fc9.noarch * selinux-policy-devel-3.3.1-84.fc9.noarch * libselinux-python-2.0.67-4.fc9.i386 * libselinux-2.0.67-4.fc9.i386 $ sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 22 Policy from config file: targeted From olivares14031 at yahoo.com Wed Sep 3 01:19:33 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Tue, 2 Sep 2008 18:19:33 -0700 (PDT) Subject: many avcs at startup, readahead and several others In-Reply-To: <4c4ba1530809021628t78a6628l98d4f6a373051db4@mail.gmail.com> Message-ID: <136822.45881.qm@web52611.mail.re2.yahoo.com> --- On Tue, 9/2/08, Tom London wrote: > From: Tom London > Subject: Re: many avcs at startup, readahead and several others > To: olivares14031 at yahoo.com, "For testers of Fedora Core development releases" > Cc: fedora-selinux-list at redhat.com > Date: Tuesday, September 2, 2008, 4:28 PM > On Tue, Sep 2, 2008 at 4:12 PM, Antonio Olivares > wrote: > > Dear fellow selinux troubleshooters and testers, > > > > Using rawhide, I have seen several avcs at startup > namely readahead and others, while I found out that the > sound problem is due to selinux getting in the way of pulse. > Here's a few avcs. Advise and/or workarounds > appreciated, setroubleshoot has not kicked in, these are > from dmesg | grep 'avcs' > > > > [root at localhost ~]# dmesg | grep 'avc' > > type=1400 audit(1220390408.063:4): avc: denied { > read write } for pid=611 comm="readahead" > path="/dev/console" dev=tmpfs ino=408 > scontext=system_u:system_r:readahead_t:s0 .... removed to save BANDWITH ........ > > > > > > Thanks, > > > > Antonio > > > Try "restorecon -v -R ~" > > -- > Tom London It did not work. STILL I see the AVCS at startup :( Regards, Antonio From selinux at gmail.com Wed Sep 3 02:57:28 2008 From: selinux at gmail.com (Tom London) Date: Tue, 2 Sep 2008 19:57:28 -0700 Subject: many avcs at startup, readahead and several others In-Reply-To: <136822.45881.qm@web52611.mail.re2.yahoo.com> References: <4c4ba1530809021628t78a6628l98d4f6a373051db4@mail.gmail.com> <136822.45881.qm@web52611.mail.re2.yahoo.com> Message-ID: <4c4ba1530809021957s4fcc81a9lad5ef81b052ba7a@mail.gmail.com> On Tue, Sep 2, 2008 at 6:19 PM, Antonio Olivares wrote: > --- On Tue, 9/2/08, Tom London wrote: > >> From: Tom London >> Subject: Re: many avcs at startup, readahead and several others >> To: olivares14031 at yahoo.com, "For testers of Fedora Core development releases" >> Cc: fedora-selinux-list at redhat.com >> Date: Tuesday, September 2, 2008, 4:28 PM >> On Tue, Sep 2, 2008 at 4:12 PM, Antonio Olivares >> wrote: >> > Dear fellow selinux troubleshooters and testers, >> > >> > Using rawhide, I have seen several avcs at startup >> namely readahead and others, while I found out that the >> sound problem is due to selinux getting in the way of pulse. >> Here's a few avcs. Advise and/or workarounds >> appreciated, setroubleshoot has not kicked in, these are >> from dmesg | grep 'avcs' >> > >> > [root at localhost ~]# dmesg | grep 'avc' >> > type=1400 audit(1220390408.063:4): avc: denied { >> read write } for pid=611 comm="readahead" >> path="/dev/console" dev=tmpfs ino=408 >> scontext=system_u:system_r:readahead_t:s0 > .... removed to save BANDWITH ........ >> > >> > >> > Thanks, >> > >> > Antonio >> > >> Try "restorecon -v -R ~" >> >> -- >> Tom London > > It did not work. STILL I see the AVCS at startup :( > > > Regards, > > Antonio > I'm running selinux-policy-targeted-3.5.5-3.fc10.noarch and selinux-policy-3.5.5-3.fc10.noarch. and on my system ~/.pulse is: [tbl at tlondon ~]$ ls -ld .pulse drwx------ 2 tbl tbl 4096 2008-09-02 19:48 .pulse [tbl at tlondon ~]$ ls -ldZ .pulse drwx------ tbl tbl system_u:object_r:gnome_home_t:s0 .pulse [tbl at tlondon ~]$ On yours, it seems to be user_home_t. type=1400 audit(1220391480.206:24): avc: denied { setattr } for pid=3267 comm="npviewer.bin" name=".pulse" dev=dm-0 ino=7176200 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir You running the same policy? Did you update from F9? tom -- Tom London From olivares14031 at yahoo.com Wed Sep 3 04:05:27 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Tue, 2 Sep 2008 21:05:27 -0700 (PDT) Subject: many avcs at startup, readahead and several others In-Reply-To: <4c4ba1530809021957s4fcc81a9lad5ef81b052ba7a@mail.gmail.com> Message-ID: <599796.21379.qm@web52602.mail.re2.yahoo.com> --- On Tue, 9/2/08, Tom London wrote: > From: Tom London > Subject: Re: many avcs at startup, readahead and several others > To: olivares14031 at yahoo.com > Cc: fedora-test-list at redhat.com, fedora-selinux-list at redhat.com > Date: Tuesday, September 2, 2008, 7:57 PM > On Tue, Sep 2, 2008 at 6:19 PM, Antonio Olivares > wrote: > > --- On Tue, 9/2/08, Tom London > wrote: > > > >> From: Tom London > >> Subject: Re: many avcs at startup, readahead and > several others > >> To: olivares14031 at yahoo.com, "For testers of > Fedora Core development releases" > > >> Cc: fedora-selinux-list at redhat.com > >> Date: Tuesday, September 2, 2008, 4:28 PM > >> On Tue, Sep 2, 2008 at 4:12 PM, Antonio Olivares > >> wrote: > >> > Dear fellow selinux troubleshooters and > testers, > >> > > >> > Using rawhide, I have seen several avcs at > startup > >> namely readahead and others, while I found out > that the > >> sound problem is due to selinux getting in the way > of pulse. > >> Here's a few avcs. Advise and/or workarounds > >> appreciated, setroubleshoot has not kicked in, > these are > >> from dmesg | grep 'avcs' > >> > > >> > [root at localhost ~]# dmesg | grep > 'avc' > >> > type=1400 audit(1220390408.063:4): avc: > denied { > >> read write } for pid=611 > comm="readahead" > >> path="/dev/console" dev=tmpfs ino=408 > >> scontext=system_u:system_r:readahead_t:s0 > > .... removed to save BANDWITH ........ > >> > > >> > > >> > Thanks, > >> > > >> > Antonio > >> > > >> Try "restorecon -v -R ~" > >> > >> -- > >> Tom London > > > > It did not work. STILL I see the AVCS at startup :( > > > > > > Regards, > > > > Antonio > > > I'm running selinux-policy-targeted-3.5.5-3.fc10.noarch > and > selinux-policy-3.5.5-3.fc10.noarch. > > and on my system ~/.pulse is: > [tbl at tlondon ~]$ ls -ld .pulse > drwx------ 2 tbl tbl 4096 2008-09-02 19:48 .pulse > [tbl at tlondon ~]$ ls -ldZ .pulse > drwx------ tbl tbl system_u:object_r:gnome_home_t:s0 > .pulse > [tbl at tlondon ~]$ > > On yours, it seems to be user_home_t. > > type=1400 audit(1220391480.206:24): avc: denied { setattr > } for > pid=3267 comm="npviewer.bin" > name=".pulse" dev=dm-0 ino=7176200 > scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 > tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > > You running the same policy? Did you update from F9? Should be, I'll check tommorrow in the morning. I did a touch /. autorelabel; reboot and avc's appear to be gone :), however when I try to play an audio file, I get error(s) with pulse, so maybe pulse or the permissions are wrong :(. > tom > -- > Tom London Thanks for helping out. Regards, Antonio From jmorris at namei.org Wed Sep 3 11:09:47 2008 From: jmorris at namei.org (James Morris) Date: Wed, 3 Sep 2008 21:09:47 +1000 (EST) Subject: AVCs generated by oom actions.... In-Reply-To: <4c4ba1530809021252t92e7694ra3b997207881e213@mail.gmail.com> References: <4c4ba1530809021252t92e7694ra3b997207881e213@mail.gmail.com> Message-ID: On Tue, 2 Sep 2008, Tom London wrote: > I'm having some out-of-memory issues with latest kernels: > https://bugzilla.redhat.com/show_bug.cgi?id=460848 > > I've noticed that when this happens, I get audit and AVC spew. > > Appears that I get 'sys_rawio', 'sys_admin', and 'sys_resource' AVCs > for processes that are about to commit suicide. > > I have no idea what is causing these, and whether these are bugs (or > features ;)). > > Any ideas/wisdom welcome! This patch should fix it: http://marc.info/?l=selinux&m=122039060813510&w=2 -- James Morris From olivares14031 at yahoo.com Wed Sep 3 12:02:56 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Wed, 3 Sep 2008 05:02:56 -0700 (PDT) Subject: many avcs at startup, readahead and several others In-Reply-To: <4c4ba1530809021957s4fcc81a9lad5ef81b052ba7a@mail.gmail.com> Message-ID: <664028.7155.qm@web52610.mail.re2.yahoo.com> --- On Tue, 9/2/08, Tom London wrote: > I'm running selinux-policy-targeted-3.5.5-3.fc10.noarch > and > selinux-policy-3.5.5-3.fc10.noarch. > > and on my system ~/.pulse is: > [tbl at tlondon ~]$ ls -ld .pulse > drwx------ 2 tbl tbl 4096 2008-09-02 19:48 .pulse > [tbl at tlondon ~]$ ls -ldZ .pulse > drwx------ tbl tbl system_u:object_r:gnome_home_t:s0 > .pulse > [tbl at tlondon ~]$ > > On yours, it seems to be user_home_t. > > type=1400 audit(1220391480.206:24): avc: denied { setattr > } for > pid=3267 comm="npviewer.bin" > name=".pulse" dev=dm-0 ino=7176200 > scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 > tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > > You running the same policy? Did you update from F9? [olivares at localhost ~]$ cat .selinux-policy.txt selinux-policy-targeted-3.5.5-3.fc10.noarch selinux-policy-3.5.5-3.fc10.noarch [olivares at localhost ~]$ ls -ld .pulse drwx------ 2 olivares olivares 4096 2008-09-03 07:00 .pulse [olivares at localhost ~]$ ls -ldZ .pulse drwx------ olivares olivares system_u:object_r:gnome_home_t .pulse [olivares at localhost ~]$ I did a # touch ./autorelabel; reboot and the denied avcs still appear :(. Wonder what is happening? > > tom > -- > Tom London From selinux at gmail.com Wed Sep 3 13:40:25 2008 From: selinux at gmail.com (Tom London) Date: Wed, 3 Sep 2008 06:40:25 -0700 Subject: AVCs generated by oom actions.... In-Reply-To: References: <4c4ba1530809021252t92e7694ra3b997207881e213@mail.gmail.com> Message-ID: <4c4ba1530809030640u6cc2aa96p89cbe32033d4176c@mail.gmail.com> On Wed, Sep 3, 2008 at 4:09 AM, James Morris wrote: > On Tue, 2 Sep 2008, Tom London wrote: > >> I'm having some out-of-memory issues with latest kernels: >> https://bugzilla.redhat.com/show_bug.cgi?id=460848 >> >> I've noticed that when this happens, I get audit and AVC spew. >> >> Appears that I get 'sys_rawio', 'sys_admin', and 'sys_resource' AVCs >> for processes that are about to commit suicide. >> >> I have no idea what is causing these, and whether these are bugs (or >> features ;)). >> >> Any ideas/wisdom welcome! > > This patch should fix it: > http://marc.info/?l=selinux&m=122039060813510&w=2 > > -- > James Morris > > Thanks. I am already running (half of) that patch that fixes security_context_to_sid_core(), and it indeed seems to fix the random oom's. However, I was asking about the (corner?) case where the system legitimately needed to call the oom-killer. Do the above AVCs ('sys_rawio', 'sys_admin', and 'sys_resource') indicate an issue? They did not appear to interfere with the killing of the processes...... tom -- Tom London From sds at tycho.nsa.gov Wed Sep 3 13:53:01 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 03 Sep 2008 09:53:01 -0400 Subject: AVCs generated by oom actions.... In-Reply-To: <4c4ba1530809030640u6cc2aa96p89cbe32033d4176c@mail.gmail.com> References: <4c4ba1530809021252t92e7694ra3b997207881e213@mail.gmail.com> <4c4ba1530809030640u6cc2aa96p89cbe32033d4176c@mail.gmail.com> Message-ID: <1220449981.6034.59.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-09-03 at 06:40 -0700, Tom London wrote: > On Wed, Sep 3, 2008 at 4:09 AM, James Morris wrote: > > On Tue, 2 Sep 2008, Tom London wrote: > > > >> I'm having some out-of-memory issues with latest kernels: > >> https://bugzilla.redhat.com/show_bug.cgi?id=460848 > >> > >> I've noticed that when this happens, I get audit and AVC spew. > >> > >> Appears that I get 'sys_rawio', 'sys_admin', and 'sys_resource' AVCs > >> for processes that are about to commit suicide. > >> > >> I have no idea what is causing these, and whether these are bugs (or > >> features ;)). > >> > >> Any ideas/wisdom welcome! > > > > This patch should fix it: > > http://marc.info/?l=selinux&m=122039060813510&w=2 > > > > -- > > James Morris > > > > > Thanks. I am already running (half of) that patch that fixes > security_context_to_sid_core(), and it indeed seems to fix the random > oom's. > > However, I was asking about the (corner?) case where the system > legitimately needed to call the oom-killer. Do the above AVCs > ('sys_rawio', 'sys_admin', and 'sys_resource') indicate an issue? > They did not appear to interfere with the killing of the > processes...... The oom killer tests for those capabilities on potential target processes as part of selecting which process to kill (processes that have those capabilities are less likely to be killed by the oom killer). We should likely use a special hook for those tests that uses the _noaudit interfaces to avoid noise in the audit logs, similar to what was done for vm_enough_memory. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Wed Sep 3 14:55:58 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 03 Sep 2008 10:55:58 -0400 Subject: Samba Policy - Type Enforcement File In-Reply-To: <994219730808210611o588df335td0ce3cd4e6a937a5@mail.gmail.com> References: <994219730808210611o588df335td0ce3cd4e6a937a5@mail.gmail.com> Message-ID: <48BEA57E.2050407@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 prakash hallalli wrote: > Hi All > I have installed selinux on fedora 8, I was using targeted policy > which is the default policy in fedora. > I have searched the policy module file ( File Context (FC) Type Enforcement > (TE) and an Interface file (IF) ) Because i have configured samba server, > so i need to change some permissions in samba.te file, but i couldn't find > these file. Please help me where can i get these file and which package i > have to install. > > > Thanks > praksh,h,k > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list You can add rules by using loadable policy modules. You do not need the source. BTW have you read through samba_selinux man page? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAki+pX4ACgkQrlYvE4MpobMX5QCguwh+e7n0w5PScO71dhjIO9qe JlYAn3dZI5f9EejYO7D3+cnSrLpUI4MN =RYWU -----END PGP SIGNATURE----- From dwalsh at redhat.com Wed Sep 3 15:19:52 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 03 Sep 2008 11:19:52 -0400 Subject: selinux and readahead In-Reply-To: <14264.81745.qm@web52612.mail.re2.yahoo.com> References: <14264.81745.qm@web52612.mail.re2.yahoo.com> Message-ID: <48BEAB18.6070403@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Antonio Olivares wrote: > Dear all, > > I have encountered the following setroubleshoot warning: > > > Summary: > > SELinux is preventing readahead (readahead_t) "read" to inotify (inotifyfs_t). > > Detailed Description: > > SELinux denied access requested by readahead. It is not expected that this > access is required by readahead 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: > > Sometimes labeling problems can cause SELinux denials. You could try to restore > the default system file context for inotify, > > restorecon -v 'inotify' > > If this does not work, there is currently no automatic way to allow this access. > Instead, 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 system_u:system_r:readahead_t:SystemLow-SystemHigh > Target Context system_u:object_r:inotifyfs_t > Target Objects inotify [ dir ] > Source readahead > Source Path /usr/sbin/readahead > Port > Host localhost.localdomain > Source RPM Packages readahead-1.4.4-1.fc10 > Target RPM Packages > Policy RPM selinux-policy-3.5.1-4.fc10 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name catchall_file > Host Name localhost.localdomain > Platform Linux localhost.localdomain > 2.6.27-0.244.rc2.git1.fc10.i686 #1 SMP Fri Aug 8 > 13:26:20 EDT 2008 i686 i686 > Alert Count 2 > First Seen Thu 21 Aug 2008 04:04:26 AM CDT > Last Seen Thu 21 Aug 2008 04:04:28 AM CDT > Local ID c67dc8d2-0096-4510-9075-cbea7074ffa2 > Line Numbers > > Raw Audit Messages > > host=localhost.localdomain type=AVC msg=audit(1219309468.106:155): avc: denied { read } for pid=7574 comm="readahead" path="inotify" dev=inotifyfs ino=1 scontext=system_u:system_r:readahead_t:s0-s0:c0.c1023 tcontext=system_u:object_r:inotifyfs_t:s0 tclass=dir > > host=localhost.localdomain type=SYSCALL msg=audit(1219309468.106:155): arch=40000003 syscall=11 success=yes exit=0 a0=9f292d0 a1=9f29368 a2=9f295c0 a3=0 items=0 ppid=7564 pid=7574 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=24 comm="readahead" exe="/usr/sbin/readahead" subj=system_u:system_r:readahead_t:s0-s0:c0.c1023 key=(null) > > > > > I do not know if readahead should be denied or not? What do you recommend that I do? > > Regards, > > Antonio > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Fixed in selinux-policy-3.5.6-1.fc10 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAki+qxgACgkQrlYvE4MpobPFVQCfRkAZKXtrEoL62+Q1tbQZAj1R roYAmwRtzNJpWuGJaz0Wdf+juqPKqiwn =jjmC -----END PGP SIGNATURE----- From dwalsh at redhat.com Wed Sep 3 15:23:38 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 03 Sep 2008 11:23:38 -0400 Subject: rsync, xattrs, ntfs-3g and "selinux.selinux" In-Reply-To: <4c4ba1530808241420x70b65aafr9c206d8412fe4e97@mail.gmail.com> References: <4c4ba1530808241420x70b65aafr9c206d8412fe4e97@mail.gmail.com> Message-ID: <48BEABFA.1080604@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom London wrote: > Running rawhide. > > I use "rsync" to backup my system to a USB hard drive. > > I also ntfs-3g mount a WinXP partition to '/mnt/windows' on boot, and > I use the above rsync to back that up as well. > > Adding '-xattrs' to the argument list for rsync seems to produce scads > of the following (I'm guessing one for each file in the ntfs-3g file > system ): > > rsync: rsync_xal_clear: > lremovexattr("mnt/windows/WINDOWS/twain_32/wiatwain.ds","security.selinux") > failed: Permission denied (13) > rsync: rsync_xal_clear: > lremovexattr("mnt/windows/temp","security.selinux") failed: Permission > denied (13) > rsync: rsync_xal_clear: > lremovexattr("mnt/windows/temp/setup.log","security.selinux") failed: > Permission denied (13) > > Destination fs i ext4dev. > > When mounted, all the files in /mnt/windows have type: fusefs_t. When > rsych'ed, the type on the ext4 fs is file_t. > > Running 'getfatttr -d' on the source files produces, for example: > [root at localhost temp]# getfattr -d * > getfattr: setup.log: Operation not supported > [root at localhost temp]# > > On the destination fs, result is > [root at localhost temp]# getfattr -d * > [root at localhost temp]# > > This something due to the way I mounted the ntfs-3g fs? The way I run > rsync? Other? > > thanks, > tom Looks like an rsync bug? James did you work on rsync? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAki+q/oACgkQrlYvE4MpobP4SwCg2z+iKYk8e7Z43WFJhCAXccOI IRUAoN62L3+4eDi7Kf39M8URZCDHROQS =Zx2l -----END PGP SIGNATURE----- From jantill at redhat.com Wed Sep 3 15:55:41 2008 From: jantill at redhat.com (James Antill) Date: Wed, 03 Sep 2008 11:55:41 -0400 Subject: rsync, xattrs, ntfs-3g and "selinux.selinux" In-Reply-To: <48BEABFA.1080604@redhat.com> References: <4c4ba1530808241420x70b65aafr9c206d8412fe4e97@mail.gmail.com> <48BEABFA.1080604@redhat.com> Message-ID: <1220457341.3862.295.camel@code.and.org> On Wed, 2008-09-03 at 11:23 -0400, Daniel J Walsh wrote: > Looks like an rsync bug? > > James did you work on rsync? Nope, looking at the rpm changelog shows: * Mon Feb 19 2007 Simo Sorce - 2.6.9-2 - fix acl/xattr bug with --delete: (bz#229145) [...] * Fri Jun 09 2006 Jay Fenlason 2.6.8-3 - Add my xattrs_bug patch to fix a bug where xattrs don't get sent correctly. [...] * Mon May 08 2006 Jay Fenlason 2.6.8-2 - New upstream release - Use the upstream xattr patch instead of mine. This closes bz#190208 CVE-2006-2083 rsync buffer overflow issue [...] * Thu Feb 10 2005 Jay Fenlason 2.6.3-2 - Added my -xattr patch, which is based on the -acl patch. -- James Antill Red Hat From dwalsh at redhat.com Wed Sep 3 16:22:41 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 03 Sep 2008 12:22:41 -0400 Subject: policy rpm %post script encounters avc violations In-Reply-To: References: Message-ID: <48BEB9D1.1020000@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johnson, Richard wrote: > When installing a policy rpm, one cannot log the install activity w/o > generating avc errors. For example: > > rpm -i lsb-ft-asn-selinux > /var/log/rpm-update.log > > produces the following violation: > > type=SYSCALL msg=audit(1219774608.030:789): arch=c000003e syscall=59 > success=yes exit=0 a0=be952e0 a1=be93390 a2=be958f0 a3=8 items=0 > ppid=2848 pid=2875 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=ttyS1 ses=2 comm="restorecon" exe="/sbin/restorecon" > subj=root:system_r:restorecon_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1219774608.030:789): avc: denied { write } for > pid=2875 comm="restorecon" path="/var/log/rpm-update.log" dev=md2 > ino=2694055 scontext=root:system_r:restorecon_t:s0-s0:c0.c1023 > tcontext=root:object_r:var_log_t:s0 tclass=file > > The problems seems to stem from recording the %post script's attempts to > relabel files affected by the policy, specifically: > > /sbin/restorecon -F -R -v /opt/ft/sbin/sra_alarm; > /sbin/restorecon -F -R -v /etc/opt/ft/asn; > /sbin/restorecon -F -R -v /var/opt/ft/asn; > /sbin/restorecon -F -R -v /var/opt/ft/log; > > Is there any way to preserve the logging w/o disabling selinux for the > duration of the install? > > FWIW, the rpm commands are executed from a bash script. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Answered in http://danwalsh.livejournal.com/22860.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAki+udEACgkQrlYvE4MpobNuGwCgyTO3dySralLkMd+Xt71/IyPY Qg8AoK2w8AKq0JC+1Id1GXfhtGmzWTwn =PpRO -----END PGP SIGNATURE----- From dwalsh at redhat.com Wed Sep 3 16:53:44 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 03 Sep 2008 12:53:44 -0400 Subject: Bootable copy of an FC9 system. In-Reply-To: <8E00922D-4154-4451-BC37-33D29C6CE656@austin.rr.com> References: <8E00922D-4154-4451-BC37-33D29C6CE656@austin.rr.com> Message-ID: <48BEC118.1060705@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nickolas Gray wrote: > I am attempting to create a bootable copy of a running SELinux box on > FC9. I think I am close but I am coming up with a kernel panic (text at > end) Here are the steps and a brief reason. If anyone has any > suggestions where I might have made a mistake or left something out a > comment would be appreciated. The only requirement so far is that it has > to be a disk to disk copy with no CD/DVD rescue involved. > > The original looks like > > mbr on boot sector > /dev/sda1 ext3 /boot > /dev/sda2 LVM > > VolGroup00/LogVol00 is root > VolGroup00/LogVol01 is swap > > This is what I am doing. > > ? This seemed like an efficient way to dup the filesystems of the source > to the target. > sfdisk -d /dev/sda | sfdisk /dev/sdb > > ?Duplicate the MBR > dd if=/dev/sda1 of=/dev/sdb1 bs=512k > > ?Copy the entire /boot from a to b > dd if=/dev/sda of=/dev/sdb bs=664 count=1 > > ?Add the /dev/sdb2 to LVM > pvcreate /dev/sdb2 > > create the VolGroup for / > vgcreate -s 32m VolGroup01 /dev/sdb2 > > Create the logical volume for / and swap > lvcreate -l 1562 -n LogVol00 VolGroup01 > lvcreate -l 62 -n LogVol01 VolGroup01 > > Create the swap area > mkswap /dev/VolGroup01/LogVol01 > > Format the / filesystem > mkfs -t ext3 /dev/VolGroup01/LogVol00 > > Create the snapshot > lvcreate -L 20g -s -n snap /dev/VolGroup00/LogVol00 > > Mount the snapshot > mount /dev/VolGroup00/snap /snapshot > > Mount the target > mount /dev/VolGroup01/LogVol00 /target > > Rsync over the snapshot > rsync -vXxpr /snapshot/* /target > > Unmount the snapshot > umount /snapshot > > lvremove -f VolGroup00/snap > > At this point I fixed the initrd, the fstab and grub.conf on the target > to point to VolGroup01 instead of VolGroup00. > > I would think this should be it. > > What I get is. > > root (hd0,0) > Filesystem type is ..... > kerne /vmlinuz ...... > Linux bzimage..... > initrd / initrd .... > Linux initrd > > > Decompresing Linux ... Done > Booting the kernel > Red Hat nash version 6,0,52 starting > Reading all physical volumes this make take awhile .... > Found volume group VolGroup01 now active > ERROR: exec of init (/sbin/init) failed failed!!!! No such file or > directory > ERROR: failed in exec of /bin/echo: No such file or directory > a couple messages about not finding /bin/sleep > Kernel Panic > > I am not really sure where this is getting to. I thought it was getting > to the initrd but now I am not sure. > > Thanks Nick > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Why do you think this is an SELinux issue? If you boot enforcing=0 does it still blow up? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAki+wRgACgkQrlYvE4MpobM6JwCeNSPTbPYwT7RAgG03A8d+sDyv VOgAn1mQ6tSxVdKAN5XIEP295+oOpiXV =URlk -----END PGP SIGNATURE----- From dwalsh at redhat.com Wed Sep 3 16:56:06 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 03 Sep 2008 12:56:06 -0400 Subject: AVC denials when using RH Cluster Suite's qdiskd and ping heuristic In-Reply-To: <1219982333.3117.3.camel@sewt> References: <1219961124.3284.36.camel@sewt> <1219982333.3117.3.camel@sewt> Message-ID: <48BEC1A6.7030901@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sean E. Millichamp wrote: > On Thu, 2008-08-28 at 18:05 -0400, Sean E. Millichamp wrote: > >> When I configure a simple ping test with qdisk I get: >> >> type=AVC msg=audit(1219960233.627:4561): avc: denied { read write } for pid=23174 comm="ping" path="/dev/sda4" dev=tmpfs ino=1051 scontext=root:system_r:ping_t:s0 tcontext=system_u:object_ >> r:fixed_disk_device_t:s0 tclass=blk_file >> >> type=AVC msg=audit(1219960233.627:4561): avc: denied { read write } for pid=23174 comm="ping" path="/dev/sdb4" dev=tmpfs ino=985 scontext=root:system_r:ping_t:s0 tcontext=system_u:object_r >> :fixed_disk_device_t:s0 tclass=blk_file >> >> type=SYSCALL msg=audit(1219960233.627:4561): arch=c000003e syscall=59 success=yes exit=0 a0=1f3575a0 a1=1f357610 a2=1f356150 a3=3 items=0 ppid=23163 pid=23174 auid=0 uid=0 gid=0 euid=0 suid=0 >> fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=189 comm="ping" exe="/bin/ping" subj=root:system_r:ping_t:s0 key=(null) > > These messages are because qdiskd doesn't properly clean up its file > descriptors before forking and execing ping. I will clean up my > findings and submit a patch/open a bug report against qdisk. > > Thanks, > Sean > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Great, I was just about to suggest this. Whenever you see something bizarre like ping trying to read write raw disks, I think of leaked file descriptors. or redirection of stdout. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAki+waYACgkQrlYvE4MpobNRVQCbB8ZKR7N378P18cVG6eRHsY3H lqIAn0SQgiRvz400F0lvYABizPbatDAG =b8wE -----END PGP SIGNATURE----- From sean at bruenor.org Wed Sep 3 17:00:45 2008 From: sean at bruenor.org (Sean E. Millichamp) Date: Wed, 03 Sep 2008 13:00:45 -0400 Subject: AVC denials when using RH Cluster Suite's qdiskd and ping heuristic In-Reply-To: <48BEC1A6.7030901@redhat.com> References: <1219961124.3284.36.camel@sewt> <1219982333.3117.3.camel@sewt> <48BEC1A6.7030901@redhat.com> Message-ID: <1220461245.16258.41.camel@sewt> On Wed, 2008-09-03 at 12:56 -0400, Daniel J Walsh wrote: > Sean E. Millichamp wrote: > > These messages are because qdiskd doesn't properly clean up its file > > descriptors before forking and execing ping. I will clean up my > > findings and submit a patch/open a bug report against qdisk. > Great, I was just about to suggest this. Whenever you see something > bizarre like ping trying to read write raw disks, I think of leaked file > descriptors. or redirection of stdout. It turns out qdiskd was (is) leaking a number of file descriptors to its forked heuristics - and not always predictably because of the threading qdiskd uses. It would have been a very hard bug to spot if not for SELinux - mark a win for security! For those interested the qdisk bug report against RHEL 5 (with suggested patches) is here: https://bugzilla.redhat.com/show_bug.cgi?id=460645 Sean From dwalsh at redhat.com Wed Sep 3 17:02:24 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 03 Sep 2008 13:02:24 -0400 Subject: AVC Denial "services" In-Reply-To: References: Message-ID: <48BEC320.2040304@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Frank Murphy wrote: > su - root > chcon -t bin_t './system-config-services-mechanism.py' > chcon: cannot access `./system-config-services-mechanism.py': No such > file or directory > chcon -t bin_t \ /usr/share/system-config-services/system-config-services-mechanism.py The kernel could not reassemble the entire path. > > > Summary: > > SELinux is preventing the dbus-daemon-lau (system_dbusd_t) from executing > ./system-config-services-mechanism.py. > > Detailed Description: > > SELinux has denied the dbus-daemon-lau from executing > ./system-config-services-mechanism.py. If dbus-daemon-lau is supposed to be able > to execute ./system-config-services-mechanism.py, this could be a labeling > problem. Most confined domains are allowed to execute files labeled bin_t. So > you could change the labeling on this file to bin_t and retry the application. > If this dbus-daemon-lau is not supposed to execute > ./system-config-services-mechanism.py, this could signal a intrusion attempt. > > Allowing Access: > > If you want to allow dbus-daemon-lau to execute > ./system-config-services-mechanism.py: chcon -t bin_t > './system-config-services-mechanism.py' If this fix works, please update the > file context on disk, with the following command: semanage fcontext -a -t bin_t > './system-config-services-mechanism.py' Please specify the full path to the > executable, Please file a bug report > (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this selinux-policy > to make sure this becomes the default labeling. > > Additional Information: > > Source Context system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 > Target Context system_u:object_r:usr_t:s0 > Target Objects ./system-config-services-mechanism.py [ file ] > Source dbus-daemon-lau > Source Path /lib/dbus-1/dbus-daemon-launch-helper > Port > Host rawhide-02 > Source RPM Packages dbus-1.2.3-1.fc10 > Target RPM Packages > Policy RPM selinux-policy-3.5.1-4.fc10 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name execute > Host Name rawhide-02 > Platform Linux rawhide-02 2.6.27-0.238.rc2.fc10.i686 #1 SMP > Thu Aug 7 08:00:04 EDT 2008 i686 i686 > Alert Count 1 > First Seen Sat 30 Aug 2008 08:22:57 IST > Last Seen Sat 30 Aug 2008 08:22:57 IST > Local ID ffddfd97-63b1-4809-aee4-c10e29d86722 > Line Numbers > > Raw Audit Messages > > host=rawhide-02 type=AVC msg=audit(1220080977.294:17): avc: denied { > execute } for pid=3564 comm="dbus-daemon-lau" > name="system-config-services-mechanism.py" dev=dm-0 ino=2605067 > scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:usr_t:s0 tclass=file > > host=rawhide-02 type=SYSCALL msg=audit(1220080977.294:17): > arch=40000003 syscall=11 success=no exit=-13 a0=9774018 a1=9773d60 > a2=9773008 a3=b8d9bc items=0 ppid=3563 pid=3564 auid=4294967295 uid=0 > gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) > ses=4294967295 comm="dbus-daemon-lau" > exe="/lib/dbus-1/dbus-daemon-launch-helper" > subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null) > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAki+wyAACgkQrlYvE4MpobOFdACdHwTU9ha1XnsJ88NGq8s0orOj BqIAn0S9O64OVLp/fkiZCAKLyKVaTgs/ =Smmb -----END PGP SIGNATURE----- From dwalsh at redhat.com Wed Sep 3 17:14:38 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 03 Sep 2008 13:14:38 -0400 Subject: many avcs at startup, readahead and several others In-Reply-To: <664028.7155.qm@web52610.mail.re2.yahoo.com> References: <664028.7155.qm@web52610.mail.re2.yahoo.com> Message-ID: <48BEC5FE.8030002@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Antonio Olivares wrote: > > > --- On Tue, 9/2/08, Tom London wrote: > >> I'm running selinux-policy-targeted-3.5.5-3.fc10.noarch >> and >> selinux-policy-3.5.5-3.fc10.noarch. >> >> and on my system ~/.pulse is: >> [tbl at tlondon ~]$ ls -ld .pulse >> drwx------ 2 tbl tbl 4096 2008-09-02 19:48 .pulse >> [tbl at tlondon ~]$ ls -ldZ .pulse >> drwx------ tbl tbl system_u:object_r:gnome_home_t:s0 >> .pulse >> [tbl at tlondon ~]$ >> >> On yours, it seems to be user_home_t. >> >> type=1400 audit(1220391480.206:24): avc: denied { setattr >> } for >> pid=3267 comm="npviewer.bin" >> name=".pulse" dev=dm-0 ino=7176200 >> scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 >> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir >> >> You running the same policy? Did you update from F9? > > [olivares at localhost ~]$ cat .selinux-policy.txt > selinux-policy-targeted-3.5.5-3.fc10.noarch > selinux-policy-3.5.5-3.fc10.noarch > [olivares at localhost ~]$ ls -ld .pulse > drwx------ 2 olivares olivares 4096 2008-09-03 07:00 .pulse > [olivares at localhost ~]$ ls -ldZ .pulse > drwx------ olivares olivares system_u:object_r:gnome_home_t .pulse > [olivares at localhost ~]$ > > I did a > # touch ./autorelabel; reboot > > and the denied avcs still appear :(. Wonder what is happening? >> tom >> -- >> Tom London > > > > Which avc's still appear? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAki+xf4ACgkQrlYvE4MpobM6aACeNr5Hr+KQ88FmP1EKnJHALf25 TJMAnA6P4ORu8BJvSnKubjM7x+9oYvXy =lJ6A -----END PGP SIGNATURE----- From olivares14031 at yahoo.com Wed Sep 3 21:14:12 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Wed, 3 Sep 2008 14:14:12 -0700 (PDT) Subject: many avcs at startup, readahead and several others In-Reply-To: <48BEC5FE.8030002@redhat.com> Message-ID: <258028.19629.qm@web52601.mail.re2.yahoo.com> --- On Wed, 9/3/08, Daniel J Walsh wrote: > From: Daniel J Walsh > Subject: Re: many avcs at startup, readahead and several others > To: olivares14031 at yahoo.com, "For testers of Fedora Core development releases" > Cc: "Tom London" , fedora-selinux-list at redhat.com > Date: Wednesday, September 3, 2008, 10:14 AM > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Antonio Olivares wrote: > > > > > > --- On Tue, 9/2/08, Tom London > wrote: > > > >> I'm running > selinux-policy-targeted-3.5.5-3.fc10.noarch > >> and > >> selinux-policy-3.5.5-3.fc10.noarch. > >> > >> and on my system ~/.pulse is: > >> [tbl at tlondon ~]$ ls -ld .pulse > >> drwx------ 2 tbl tbl 4096 2008-09-02 19:48 .pulse > >> [tbl at tlondon ~]$ ls -ldZ .pulse > >> drwx------ tbl tbl > system_u:object_r:gnome_home_t:s0 > >> .pulse > >> [tbl at tlondon ~]$ > >> > >> On yours, it seems to be user_home_t. > >> > >> type=1400 audit(1220391480.206:24): avc: denied > { setattr > >> } for > >> pid=3267 comm="npviewer.bin" > >> name=".pulse" dev=dm-0 ino=7176200 > >> > scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 > >> tcontext=unconfined_u:object_r:user_home_t:s0 > tclass=dir > >> > >> You running the same policy? Did you update from > F9? > > > > [olivares at localhost ~]$ cat .selinux-policy.txt > > selinux-policy-targeted-3.5.5-3.fc10.noarch > > selinux-policy-3.5.5-3.fc10.noarch > > [olivares at localhost ~]$ ls -ld .pulse > > drwx------ 2 olivares olivares 4096 2008-09-03 07:00 > .pulse > > [olivares at localhost ~]$ ls -ldZ .pulse > > drwx------ olivares olivares > system_u:object_r:gnome_home_t .pulse > > [olivares at localhost ~]$ > > > > I did a > > # touch ./autorelabel; reboot > > > > and the denied avcs still appear :(. Wonder what is > happening? > >> tom > >> -- > >> Tom London > > > > > > > > > Which avc's still appear? After applying today's updates, [olivares at localhost ~]$ dmesg | grep 'avc' type=1400 audit(1220475941.234:4): avc: denied { read write } for pid=613 comm="readahead" path="/dev/console" dev=tmpfs ino=410 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file type=1400 audit(1220475941.235:5): avc: denied { read write } for pid=613 comm="readahead" path="/dev/console" dev=tmpfs ino=410 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file type=1400 audit(1220475941.235:6): avc: denied { read write } for pid=613 comm="readahead" path="/dev/console" dev=tmpfs ino=410 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file type=1400 audit(1220475942.150:7): avc: denied { fowner } for pid=613 comm="readahead" capability=3 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:system_r:readahead_t:s0 tclass=capability type=1400 audit(1220475942.150:8): avc: denied { fowner } for pid=613 comm="readahead" capability=3 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:system_r:readahead_t:s0 tclass=capability type=1400 audit(1220475942.155:9): avc: denied { fowner } for pid=613 comm="readahead" capability=3 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:system_r:readahead_t:s0 tclass=capability type=1400 audit(1220475942.651:10): avc: denied { fowner } for pid=613 comm="readahead" capability=3 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:system_r:readahead_t:s0 tclass=capability type=1400 audit(1220475968.477:11): avc: denied { write } for pid=1475 comm="ip6tables-resto" path="/0" dev=devpts ino=2 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:devpts_t:s0 tclass=chr_file type=1400 audit(1220475969.949:12): avc: denied { write } for pid=1697 comm="ip" path="/0" dev=devpts ino=2 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:devpts_t:s0 tclass=chr_file type=1400 audit(1220476005.919:13): avc: denied { search } for pid=1958 comm="pcscd" name="dbus" dev=dm-0 ino=3276848 scontext=system_u:system_r:pcscd_t:s0 tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=dir type=1400 audit(1220476026.870:14): avc: denied { search } for pid=2368 comm="python" name="hp" dev=dm-0 ino=28345940 scontext=system_u:system_r:cupsd_config_t:s0 tcontext=system_u:object_r:hplip_etc_t:s0 tclass=dir type=1400 audit(1220476026.972:15): avc: denied { execute } for pid=2417 comm="gdm" name="rpm" dev=dm-0 ino=24117291 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:rpm_exec_t:s0 tclass=file type=1400 audit(1220476026.973:16): avc: denied { getattr } for pid=2417 comm="gdm" path="/bin/rpm" dev=dm-0 ino=24117291 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:rpm_exec_t:s0 tclass=file type=1400 audit(1220476026.973:17): avc: denied { getattr } for pid=2417 comm="gdm" path="/bin/rpm" dev=dm-0 ino=24117291 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:rpm_exec_t:s0 tclass=file type=1400 audit(1220476028.580:18): avc: denied { search } for pid=2449 comm="python" name="hp" dev=dm-0 ino=28345940 scontext=system_u:system_r:cupsd_config_t:s0 tcontext=system_u:object_r:hplip_etc_t:s0 tclass=dir [olivares at localhost ~]$ [olivares at localhost ~]$ uname -a Linux localhost 2.6.27-0.297.rc5.git2.fc10.i686 #1 SMP Tue Sep 2 11:19:36 EDT 2008 i686 athlon i386 GNU/Linux From selinux at gmail.com Wed Sep 3 22:14:16 2008 From: selinux at gmail.com (Tom London) Date: Wed, 3 Sep 2008 15:14:16 -0700 Subject: many avcs at startup, readahead and several others In-Reply-To: <258028.19629.qm@web52601.mail.re2.yahoo.com> References: <48BEC5FE.8030002@redhat.com> <258028.19629.qm@web52601.mail.re2.yahoo.com> Message-ID: <4c4ba1530809031514x631bcd24l8b26d337aba8ceb3@mail.gmail.com> On Wed, Sep 3, 2008 at 2:14 PM, Antonio Olivares wrote: > > > > --- On Wed, 9/3/08, Daniel J Walsh wrote: > >> From: Daniel J Walsh >> Subject: Re: many avcs at startup, readahead and several others >> To: olivares14031 at yahoo.com, "For testers of Fedora Core development releases" >> Cc: "Tom London" , fedora-selinux-list at redhat.com >> Date: Wednesday, September 3, 2008, 10:14 AM >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Antonio Olivares wrote: >> > >> > >> > --- On Tue, 9/2/08, Tom London >> wrote: >> > >> >> I'm running >> selinux-policy-targeted-3.5.5-3.fc10.noarch >> >> and >> >> selinux-policy-3.5.5-3.fc10.noarch. >> >> >> >> and on my system ~/.pulse is: >> >> [tbl at tlondon ~]$ ls -ld .pulse >> >> drwx------ 2 tbl tbl 4096 2008-09-02 19:48 .pulse >> >> [tbl at tlondon ~]$ ls -ldZ .pulse >> >> drwx------ tbl tbl >> system_u:object_r:gnome_home_t:s0 >> >> .pulse >> >> [tbl at tlondon ~]$ >> >> >> >> On yours, it seems to be user_home_t. >> >> >> >> type=1400 audit(1220391480.206:24): avc: denied >> { setattr >> >> } for >> >> pid=3267 comm="npviewer.bin" >> >> name=".pulse" dev=dm-0 ino=7176200 >> >> >> scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 >> >> tcontext=unconfined_u:object_r:user_home_t:s0 >> tclass=dir >> >> >> >> You running the same policy? Did you update from >> F9? >> > >> > [olivares at localhost ~]$ cat .selinux-policy.txt >> > selinux-policy-targeted-3.5.5-3.fc10.noarch >> > selinux-policy-3.5.5-3.fc10.noarch >> > [olivares at localhost ~]$ ls -ld .pulse >> > drwx------ 2 olivares olivares 4096 2008-09-03 07:00 >> .pulse >> > [olivares at localhost ~]$ ls -ldZ .pulse >> > drwx------ olivares olivares >> system_u:object_r:gnome_home_t .pulse >> > [olivares at localhost ~]$ >> > >> > I did a >> > # touch ./autorelabel; reboot >> > >> > and the denied avcs still appear :(. Wonder what is >> happening? >> >> tom >> >> -- >> >> Tom London >> > >> > >> > >> > >> Which avc's still appear? > > > After applying today's updates, > > [olivares at localhost ~]$ dmesg | grep 'avc' > type=1400 audit(1220475941.234:4): avc: denied { read write } for pid=613 comm="readahead" path="/dev/console" dev=tmpfs ino=410 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file > type=1400 audit(1220475941.235:5): avc: denied { read write } for pid=613 comm="readahead" path="/dev/console" dev=tmpfs ino=410 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file > type=1400 audit(1220475941.235:6): avc: denied { read write } for pid=613 comm="readahead" path="/dev/console" dev=tmpfs ino=410 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file > type=1400 audit(1220475942.150:7): avc: denied { fowner } for pid=613 comm="readahead" capability=3 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:system_r:readahead_t:s0 tclass=capability > type=1400 audit(1220475942.150:8): avc: denied { fowner } for pid=613 comm="readahead" capability=3 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:system_r:readahead_t:s0 tclass=capability > type=1400 audit(1220475942.155:9): avc: denied { fowner } for pid=613 comm="readahead" capability=3 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:system_r:readahead_t:s0 tclass=capability > type=1400 audit(1220475942.651:10): avc: denied { fowner } for pid=613 comm="readahead" capability=3 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:system_r:readahead_t:s0 tclass=capability > type=1400 audit(1220475968.477:11): avc: denied { write } for pid=1475 comm="ip6tables-resto" path="/0" dev=devpts ino=2 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:devpts_t:s0 tclass=chr_file > type=1400 audit(1220475969.949:12): avc: denied { write } for pid=1697 comm="ip" path="/0" dev=devpts ino=2 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:devpts_t:s0 tclass=chr_file > type=1400 audit(1220476005.919:13): avc: denied { search } for pid=1958 comm="pcscd" name="dbus" dev=dm-0 ino=3276848 scontext=system_u:system_r:pcscd_t:s0 tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=dir > type=1400 audit(1220476026.870:14): avc: denied { search } for pid=2368 comm="python" name="hp" dev=dm-0 ino=28345940 scontext=system_u:system_r:cupsd_config_t:s0 tcontext=system_u:object_r:hplip_etc_t:s0 tclass=dir > type=1400 audit(1220476026.972:15): avc: denied { execute } for pid=2417 comm="gdm" name="rpm" dev=dm-0 ino=24117291 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:rpm_exec_t:s0 tclass=file > type=1400 audit(1220476026.973:16): avc: denied { getattr } for pid=2417 comm="gdm" path="/bin/rpm" dev=dm-0 ino=24117291 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:rpm_exec_t:s0 tclass=file > type=1400 audit(1220476026.973:17): avc: denied { getattr } for pid=2417 comm="gdm" path="/bin/rpm" dev=dm-0 ino=24117291 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:rpm_exec_t:s0 tclass=file > type=1400 audit(1220476028.580:18): avc: denied { search } for pid=2449 comm="python" name="hp" dev=dm-0 ino=28345940 scontext=system_u:system_r:cupsd_config_t:s0 tcontext=system_u:object_r:hplip_etc_t:s0 tclass=dir > [olivares at localhost ~]$ > [olivares at localhost ~]$ uname -a > Linux localhost 2.6.27-0.297.rc5.git2.fc10.i686 #1 SMP Tue Sep 2 11:19:36 EDT 2008 i686 athlon i386 GNU/Linux > > > OK, so running "restorecon" on your home directory got rid of the pulse related AVCs. Are you booting/running in enforcing or permissive mode? tom -- Tom London From olivares14031 at yahoo.com Wed Sep 3 22:51:23 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Wed, 3 Sep 2008 15:51:23 -0700 (PDT) Subject: many avcs at startup, readahead and several others In-Reply-To: <4c4ba1530809031514x631bcd24l8b26d337aba8ceb3@mail.gmail.com> Message-ID: <189657.20570.qm@web52611.mail.re2.yahoo.com> > >> Which avc's still appear? > > > > > > After applying today's updates, > > > > [olivares at localhost ~]$ dmesg | grep 'avc' > > type=1400 audit(1220475941.234:4): avc: denied { > read write } for pid=613 comm="readahead" > path="/dev/console" dev=tmpfs ino=410 > scontext=system_u:system_r:readahead_t:s0 > tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file > > type=1400 audit(1220475941.235:5): avc: denied { > read write } for pid=613 comm="readahead" > path="/dev/console" dev=tmpfs ino=410 > scontext=system_u:system_r:readahead_t:s0 > tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file > > type=1400 audit(1220475941.235:6): avc: denied { > read write } for pid=613 comm="readahead" > path="/dev/console" dev=tmpfs ino=410 > scontext=system_u:system_r:readahead_t:s0 > tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file > > type=1400 audit(1220475942.150:7): avc: denied { > fowner } for pid=613 comm="readahead" > capability=3 scontext=system_u:system_r:readahead_t:s0 > tcontext=system_u:system_r:readahead_t:s0 tclass=capability > > type=1400 audit(1220475942.150:8): avc: denied { > fowner } for pid=613 comm="readahead" > capability=3 scontext=system_u:system_r:readahead_t:s0 > tcontext=system_u:system_r:readahead_t:s0 tclass=capability > > type=1400 audit(1220475942.155:9): avc: denied { > fowner } for pid=613 comm="readahead" > capability=3 scontext=system_u:system_r:readahead_t:s0 > tcontext=system_u:system_r:readahead_t:s0 tclass=capability > > type=1400 audit(1220475942.651:10): avc: denied { > fowner } for pid=613 comm="readahead" > capability=3 scontext=system_u:system_r:readahead_t:s0 > tcontext=system_u:system_r:readahead_t:s0 tclass=capability > > type=1400 audit(1220475968.477:11): avc: denied { > write } for pid=1475 comm="ip6tables-resto" > path="/0" dev=devpts ino=2 > scontext=system_u:system_r:iptables_t:s0 > tcontext=system_u:object_r:devpts_t:s0 tclass=chr_file > > type=1400 audit(1220475969.949:12): avc: denied { > write } for pid=1697 comm="ip" > path="/0" dev=devpts ino=2 > scontext=system_u:system_r:ifconfig_t:s0 > tcontext=system_u:object_r:devpts_t:s0 tclass=chr_file > > type=1400 audit(1220476005.919:13): avc: denied { > search } for pid=1958 comm="pcscd" > name="dbus" dev=dm-0 ino=3276848 > scontext=system_u:system_r:pcscd_t:s0 > tcontext=system_u:object_r:system_dbusd_var_run_t:s0 > tclass=dir > > type=1400 audit(1220476026.870:14): avc: denied { > search } for pid=2368 comm="python" > name="hp" dev=dm-0 ino=28345940 > scontext=system_u:system_r:cupsd_config_t:s0 > tcontext=system_u:object_r:hplip_etc_t:s0 tclass=dir > > type=1400 audit(1220476026.972:15): avc: denied { > execute } for pid=2417 comm="gdm" > name="rpm" dev=dm-0 ino=24117291 > scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:rpm_exec_t:s0 tclass=file > > type=1400 audit(1220476026.973:16): avc: denied { > getattr } for pid=2417 comm="gdm" > path="/bin/rpm" dev=dm-0 ino=24117291 > scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:rpm_exec_t:s0 tclass=file > > type=1400 audit(1220476026.973:17): avc: denied { > getattr } for pid=2417 comm="gdm" > path="/bin/rpm" dev=dm-0 ino=24117291 > scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:rpm_exec_t:s0 tclass=file > > type=1400 audit(1220476028.580:18): avc: denied { > search } for pid=2449 comm="python" > name="hp" dev=dm-0 ino=28345940 > scontext=system_u:system_r:cupsd_config_t:s0 > tcontext=system_u:object_r:hplip_etc_t:s0 tclass=dir > > [olivares at localhost ~]$ > > [olivares at localhost ~]$ uname -a > > Linux localhost 2.6.27-0.297.rc5.git2.fc10.i686 #1 SMP > Tue Sep 2 11:19:36 EDT 2008 i686 athlon i386 GNU/Linux > > > > > > > OK, so running "restorecon" on your home > directory got rid of the > pulse related AVCs. > > Are you booting/running in enforcing or permissive mode? enforcing :) > > tom > -- > Tom London Thanks, Antonio From olivares14031 at yahoo.com Wed Sep 3 22:52:21 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Wed, 3 Sep 2008 15:52:21 -0700 (PDT) Subject: many avcs at startup, readahead and several others In-Reply-To: <4c4ba1530809031514x631bcd24l8b26d337aba8ceb3@mail.gmail.com> Message-ID: <146229.71378.qm@web52612.mail.re2.yahoo.com> > Are you booting/running in enforcing or permissive mode? enforcing :) > > tom > -- > Tom London BTW, I reran restorecon on my home directory not the root directory and I got [root at localhost ~]# restorecon -v -R /home/olivares/ restorecon: unable to stat file /home/olivares/.gvfs: Permission denied restorecon reset /home/olivares/.dmrc context system_u:object_r:xdm_home_t:s0->system_u:object_r:user_home_t:s0 Thanks, Antonio From olivares14031 at yahoo.com Thu Sep 4 12:10:53 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Thu, 4 Sep 2008 05:10:53 -0700 (PDT) Subject: problems with sound, cont'd - selinux is in the way Message-ID: <133872.43611.qm@web52605.mail.re2.yahoo.com> Dear fellow testers and selinux experts, In the other thread, I sent error messages like Audio file file format detected. ========================================================================== Opening audio decoder: [mp3lib] MPEG layer-2, layer-3 AUDIO: 44100 Hz, 2 ch, s16le, 128.0 kbit/9.07% (ratio: 16000->176400) Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3) ========================================================================== [AO_ALSA] alsa-lib: confmisc.c:768:(parse_card) cannot find card '0' [AO_ALSA] alsa-lib: conf.c:3513:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory [AO_ALSA] alsa-lib: confmisc.c:392:(snd_func_concat) error evaluating strings [AO_ALSA] alsa-lib: conf.c:3513:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory [AO_ALSA] alsa-lib: confmisc.c:1251:(snd_func_refer) error evaluating name [AO_ALSA] alsa-lib: conf.c:3513:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory [AO_ALSA] alsa-lib: conf.c:3985:(snd_config_expand) Evaluate error: No such file or directory [AO_ALSA] alsa-lib: pcm.c:2184:(snd_pcm_open_noupdate) Unknown PCM default [AO_ALSA] Playback open error: No such file or directory Could not open/initialize audio device -> no sound. Audio: no sound Video: no video without avcs, selinux is denying pulse: SELinux: initialized (dev fuse, type fuse), uses genfs_contexts type=1400 audit(1220529397.477:16): avc: denied { execstack } for pid=2945 comm="operapluginwrap" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process type=1400 audit(1220529397.482:17): avc: denied { execstack } for pid=2945 comm="operapluginwrap" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process type=1400 audit(1220529634.634:18): avc: denied { execstack } for pid=3088 comm="operapluginwrap" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process type=1400 audit(1220529634.643:19): avc: denied { execstack } for pid=3088 comm="operapluginwrap" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process type=1400 audit(1220529745.350:20): avc: denied { sys_tty_config } for pid=3224 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529745.389:21): avc: denied { sys_tty_config } for pid=3226 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529745.571:22): avc: denied { sys_tty_config } for pid=3228 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529745.611:23): avc: denied { sys_tty_config } for pid=3230 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529756.030:24): avc: denied { sys_tty_config } for pid=3233 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529756.095:25): avc: denied { sys_tty_config } for pid=3235 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529756.244:26): avc: denied { sys_tty_config } for pid=3237 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529756.283:27): avc: denied { sys_tty_config } for pid=3239 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529756.402:28): avc: denied { sys_tty_config } for pid=3241 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529756.442:29): avc: denied { sys_tty_config } for pid=3243 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529756.643:30): avc: denied { sys_tty_config } for pid=3245 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529756.683:31): avc: denied { sys_tty_config } for pid=3247 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529759.722:32): avc: denied { sys_tty_config } for pid=3249 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529759.763:33): avc: denied { sys_tty_config } for pid=3251 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability __ratelimit: 24 callbacks suppressed type=1400 audit(1220529767.214:42): avc: denied { sys_tty_config } for pid=3271 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529767.317:43): avc: denied { sys_tty_config } for pid=3273 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529767.714:44): avc: denied { sys_tty_config } for pid=3275 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529767.757:45): avc: denied { sys_tty_config } for pid=3277 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529768.485:46): avc: denied { sys_tty_config } for pid=3281 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529768.525:47): avc: denied { sys_tty_config } for pid=3283 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529770.778:48): avc: denied { sys_tty_config } for pid=3285 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529770.859:49): avc: denied { sys_tty_config } for pid=3287 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529772.510:50): avc: denied { sys_tty_config } for pid=3297 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529772.550:51): avc: denied { sys_tty_config } for pid=3299 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529775.226:52): avc: denied { sys_tty_config } for pid=3301 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529775.279:53): avc: denied { sys_tty_config } for pid=3303 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529775.453:54): avc: denied { sys_tty_config } for pid=3305 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529775.492:55): avc: denied { sys_tty_config } for pid=3307 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529777.577:56): avc: denied { sys_tty_config } for pid=3309 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529777.634:57): avc: denied { sys_tty_config } for pid=3311 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529777.769:58): avc: denied { sys_tty_config } for pid=3313 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529777.810:59): avc: denied { sys_tty_config } for pid=3315 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529780.434:60): avc: denied { sys_tty_config } for pid=3317 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529780.632:61): avc: denied { sys_tty_config } for pid=3319 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529781.084:62): avc: denied { sys_tty_config } for pid=3329 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529781.126:63): avc: denied { sys_tty_config } for pid=3331 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529784.000:64): avc: denied { sys_tty_config } for pid=3333 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529784.110:65): avc: denied { sys_tty_config } for pid=3335 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529784.430:66): avc: denied { sys_tty_config } for pid=3337 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529784.477:67): avc: denied { sys_tty_config } for pid=3339 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529784.823:68): avc: denied { sys_tty_config } for pid=3341 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529784.865:69): avc: denied { sys_tty_config } for pid=3343 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529788.255:70): avc: denied { sys_tty_config } for pid=3345 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529788.529:71): avc: denied { sys_tty_config } for pid=3347 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529788.655:72): avc: denied { sys_tty_config } for pid=3349 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529788.700:73): avc: denied { sys_tty_config } for pid=3351 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability __ratelimit: 6 callbacks suppressed type=1400 audit(1220529811.625:76): avc: denied { sys_tty_config } for pid=3357 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529811.686:77): avc: denied { sys_tty_config } for pid=3359 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529811.827:78): avc: denied { sys_tty_config } for pid=3361 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529811.869:79): avc: denied { sys_tty_config } for pid=3363 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529812.004:80): avc: denied { sys_tty_config } for pid=3365 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529812.072:81): avc: denied { sys_tty_config } for pid=3367 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529812.310:82): avc: denied { sys_tty_config } for pid=3369 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529812.352:83): avc: denied { sys_tty_config } for pid=3371 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529814.439:84): avc: denied { sys_tty_config } for pid=3373 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529814.487:85): avc: denied { sys_tty_config } for pid=3375 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability __ratelimit: 12 callbacks suppressed type=1400 audit(1220529818.528:90): avc: denied { sys_tty_config } for pid=3393 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529818.568:91): avc: denied { sys_tty_config } for pid=3395 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529820.169:92): avc: denied { sys_tty_config } for pid=3405 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529820.212:93): avc: denied { sys_tty_config } for pid=3407 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529820.505:94): avc: denied { sys_tty_config } for pid=3409 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529820.547:95): avc: denied { sys_tty_config } for pid=3411 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529822.767:96): avc: denied { sys_tty_config } for pid=3413 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529822.842:97): avc: denied { sys_tty_config } for pid=3415 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529822.960:98): avc: denied { sys_tty_config } for pid=3417 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529823.033:99): avc: denied { sys_tty_config } for pid=3419 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability __ratelimit: 12 callbacks suppressed type=1400 audit(1220529825.678:104): avc: denied { sys_tty_config } for pid=3429 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529825.724:105): avc: denied { sys_tty_config } for pid=3431 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529825.856:106): avc: denied { sys_tty_config } for pid=3433 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529825.897:107): avc: denied { sys_tty_config } for pid=3435 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529826.000:108): avc: denied { sys_tty_config } for pid=3437 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529826.041:109): avc: denied { sys_tty_config } for pid=3439 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529826.231:110): avc: denied { sys_tty_config } for pid=3441 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529826.271:111): avc: denied { sys_tty_config } for pid=3443 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529826.437:112): avc: denied { sys_tty_config } for pid=3445 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529826.478:113): avc: denied { sys_tty_config } for pid=3447 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529835.583:114): avc: denied { sys_tty_config } for pid=3451 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529835.634:115): avc: denied { sys_tty_config } for pid=3453 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529835.820:116): avc: denied { sys_tty_config } for pid=3455 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529835.861:117): avc: denied { sys_tty_config } for pid=3457 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529838.320:118): avc: denied { sys_tty_config } for pid=3459 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529838.360:119): avc: denied { sys_tty_config } for pid=3461 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529838.516:120): avc: denied { sys_tty_config } for pid=3463 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529838.561:121): avc: denied { sys_tty_config } for pid=3465 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529839.201:122): avc: denied { sys_tty_config } for pid=3467 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529839.242:123): avc: denied { sys_tty_config } for pid=3469 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529841.192:124): avc: denied { sys_tty_config } for pid=3471 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529841.321:125): avc: denied { sys_tty_config } for pid=3473 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529841.520:126): avc: denied { sys_tty_config } for pid=3476 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529841.637:127): avc: denied { sys_tty_config } for pid=3478 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529841.822:128): avc: denied { sys_tty_config } for pid=3480 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529841.862:129): avc: denied { sys_tty_config } for pid=3482 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529842.166:130): avc: denied { sys_tty_config } for pid=3484 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529842.210:131): avc: denied { sys_tty_config } for pid=3486 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529844.442:132): avc: denied { sys_tty_config } for pid=3488 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529844.506:133): avc: denied { sys_tty_config } for pid=3490 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability __ratelimit: 24 callbacks suppressed type=1400 audit(1220529848.095:142): avc: denied { sys_tty_config } for pid=3508 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529848.185:143): avc: denied { sys_tty_config } for pid=3510 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529848.859:144): avc: denied { sys_tty_config } for pid=3520 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529848.898:145): avc: denied { sys_tty_config } for pid=3522 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529849.137:146): avc: denied { sys_tty_config } for pid=3524 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529849.177:147): avc: denied { sys_tty_config } for pid=3526 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529852.584:148): avc: denied { sys_tty_config } for pid=3528 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529852.634:149): avc: denied { sys_tty_config } for pid=3530 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529852.754:150): avc: denied { sys_tty_config } for pid=3532 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529852.821:151): avc: denied { sys_tty_config } for pid=3534 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability __ratelimit: 6 callbacks suppressed type=1400 audit(1220529853.255:154): avc: denied { sys_tty_config } for pid=3540 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529853.299:155): avc: denied { sys_tty_config } for pid=3542 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529881.330:156): avc: denied { sys_tty_config } for pid=3545 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529881.399:157): avc: denied { sys_tty_config } for pid=3547 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529881.503:158): avc: denied { sys_tty_config } for pid=3549 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529881.544:159): avc: denied { sys_tty_config } for pid=3551 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529883.136:160): avc: denied { sys_tty_config } for pid=3561 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529883.175:161): avc: denied { sys_tty_config } for pid=3563 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529883.488:162): avc: denied { sys_tty_config } for pid=3565 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529883.527:163): avc: denied { sys_tty_config } for pid=3567 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529886.317:164): avc: denied { sys_tty_config } for pid=3569 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529886.358:165): avc: denied { sys_tty_config } for pid=3571 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529886.488:166): avc: denied { sys_tty_config } for pid=3573 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529886.526:167): avc: denied { sys_tty_config } for pid=3575 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529886.608:168): avc: denied { sys_tty_config } for pid=3577 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529886.648:169): avc: denied { sys_tty_config } for pid=3579 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529886.941:170): avc: denied { sys_tty_config } for pid=3581 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529886.980:171): avc: denied { sys_tty_config } for pid=3583 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529889.535:172): avc: denied { sys_tty_config } for pid=3585 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529889.595:173): avc: denied { sys_tty_config } for pid=3587 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529889.722:174): avc: denied { sys_tty_config } for pid=3589 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529889.769:175): avc: denied { sys_tty_config } for pid=3591 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability __ratelimit: 18 callbacks suppressed type=1400 audit(1220529892.600:182): avc: denied { sys_tty_config } for pid=3605 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529892.639:183): avc: denied { sys_tty_config } for pid=3607 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529892.801:184): avc: denied { sys_tty_config } for pid=3609 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529892.841:185): avc: denied { sys_tty_config } for pid=3611 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529893.125:186): avc: denied { sys_tty_config } for pid=3613 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529893.165:187): avc: denied { sys_tty_config } for pid=3615 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529895.584:188): avc: denied { sys_tty_config } for pid=3618 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529895.658:189): avc: denied { sys_tty_config } for pid=3620 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529895.814:190): avc: denied { sys_tty_config } for pid=3622 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529895.853:191): avc: denied { sys_tty_config } for pid=3624 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability __ratelimit: 6 callbacks suppressed type=1400 audit(1220529898.643:194): avc: denied { sys_tty_config } for pid=3630 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529898.686:195): avc: denied { sys_tty_config } for pid=3632 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529898.852:196): avc: denied { sys_tty_config } for pid=3634 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529898.892:197): avc: denied { sys_tty_config } for pid=3636 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529899.200:198): avc: denied { sys_tty_config } for pid=3638 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529899.242:199): avc: denied { sys_tty_config } for pid=3640 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529901.667:200): avc: denied { sys_tty_config } for pid=3642 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529901.756:201): avc: denied { sys_tty_config } for pid=3644 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529901.876:202): avc: denied { sys_tty_config } for pid=3646 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529901.926:203): avc: denied { sys_tty_config } for pid=3648 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability __ratelimit: 18 callbacks suppressed type=1400 audit(1220529904.636:210): avc: denied { sys_tty_config } for pid=3663 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529904.690:211): avc: denied { sys_tty_config } for pid=3665 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529904.850:212): avc: denied { sys_tty_config } for pid=3667 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529904.891:213): avc: denied { sys_tty_config } for pid=3669 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529907.399:214): avc: denied { sys_tty_config } for pid=3671 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529907.498:215): avc: denied { sys_tty_config } for pid=3673 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529907.794:216): avc: denied { sys_tty_config } for pid=3675 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529907.834:217): avc: denied { sys_tty_config } for pid=3677 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529908.700:218): avc: denied { sys_tty_config } for pid=3679 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529908.740:219): avc: denied { sys_tty_config } for pid=3681 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529913.685:220): avc: denied { sys_tty_config } for pid=3684 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529913.742:221): avc: denied { sys_tty_config } for pid=3686 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529913.879:222): avc: denied { sys_tty_config } for pid=3688 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529913.949:223): avc: denied { sys_tty_config } for pid=3690 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529914.276:224): avc: denied { sys_tty_config } for pid=3692 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529914.320:225): avc: denied { sys_tty_config } for pid=3694 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529914.738:226): avc: denied { sys_tty_config } for pid=3696 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529914.896:227): avc: denied { sys_tty_config } for pid=3698 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529935.547:228): avc: denied { sys_tty_config } for pid=3702 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529935.589:229): avc: denied { sys_tty_config } for pid=3704 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529936.070:230): avc: denied { sys_tty_config } for pid=3706 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529936.112:231): avc: denied { sys_tty_config } for pid=3708 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529939.916:232): avc: denied { sys_tty_config } for pid=3710 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529939.978:233): avc: denied { sys_tty_config } for pid=3712 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529940.548:234): avc: denied { sys_tty_config } for pid=3714 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220529940.610:235): avc: denied { sys_tty_config } for pid=3716 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220530068.807:236): avc: denied { sys_tty_config } for pid=3736 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability type=1400 audit(1220530068.856:237): avc: denied { sys_tty_config } for pid=3739 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability (TIA) Thanks in Advance, Antonio From dwalsh at redhat.com Thu Sep 4 12:58:24 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 04 Sep 2008 08:58:24 -0400 Subject: problems with sound, cont'd - selinux is in the way In-Reply-To: <133872.43611.qm@web52605.mail.re2.yahoo.com> References: <133872.43611.qm@web52605.mail.re2.yahoo.com> Message-ID: <48BFDB70.6050704@redhat.com> Antonio Olivares wrote: > Dear fellow testers and selinux experts, > > In the other thread, I sent error messages like > > Audio file file format detected. > ========================================================================== > Opening audio decoder: [mp3lib] MPEG layer-2, layer-3 > AUDIO: 44100 Hz, 2 ch, s16le, 128.0 kbit/9.07% (ratio: 16000->176400) > Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3) > ========================================================================== > [AO_ALSA] alsa-lib: confmisc.c:768:(parse_card) cannot find card '0' > [AO_ALSA] alsa-lib: conf.c:3513:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > [AO_ALSA] alsa-lib: confmisc.c:392:(snd_func_concat) error evaluating strings > [AO_ALSA] alsa-lib: conf.c:3513:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > [AO_ALSA] alsa-lib: confmisc.c:1251:(snd_func_refer) error evaluating name > [AO_ALSA] alsa-lib: conf.c:3513:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > [AO_ALSA] alsa-lib: conf.c:3985:(snd_config_expand) Evaluate error: No such file or directory > [AO_ALSA] alsa-lib: pcm.c:2184:(snd_pcm_open_noupdate) Unknown PCM default > [AO_ALSA] Playback open error: No such file or directory > Could not open/initialize audio device -> no sound. > Audio: no sound > Video: no video > > > without avcs, selinux is denying pulse: > > SELinux: initialized (dev fuse, type fuse), uses genfs_contexts > type=1400 audit(1220529397.477:16): avc: denied { execstack } for pid=2945 comm="operapluginwrap" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process > type=1400 audit(1220529397.482:17): avc: denied { execstack } for pid=2945 comm="operapluginwrap" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process > type=1400 audit(1220529634.634:18): avc: denied { execstack } for pid=3088 comm="operapluginwrap" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process > type=1400 audit(1220529634.643:19): avc: denied { execstack } for pid=3088 comm="operapluginwrap" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process > type=1400 audit(1220529745.350:20): avc: denied { sys_tty_config } for pid=3224 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529745.389:21): avc: denied { sys_tty_config } for pid=3226 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529745.571:22): avc: denied { sys_tty_config } for pid=3228 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529745.611:23): avc: denied { sys_tty_config } for pid=3230 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529756.030:24): avc: denied { sys_tty_config } for pid=3233 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529756.095:25): avc: denied { sys_tty_config } for pid=3235 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529756.244:26): avc: denied { sys_tty_config } for pid=3237 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529756.283:27): avc: denied { sys_tty_config } for pid=3239 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529756.402:28): avc: denied { sys_tty_config } for pid=3241 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529756.442:29): avc: denied { sys_tty_config } for pid=3243 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529756.643:30): avc: denied { sys_tty_config } for pid=3245 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529756.683:31): avc: denied { sys_tty_config } for pid=3247 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529759.722:32): avc: denied { sys_tty_config } for pid=3249 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529759.763:33): avc: denied { sys_tty_config } for pid=3251 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > __ratelimit: 24 callbacks suppressed > type=1400 audit(1220529767.214:42): avc: denied { sys_tty_config } for pid=3271 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529767.317:43): avc: denied { sys_tty_config } for pid=3273 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529767.714:44): avc: denied { sys_tty_config } for pid=3275 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529767.757:45): avc: denied { sys_tty_config } for pid=3277 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529768.485:46): avc: denied { sys_tty_config } for pid=3281 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529768.525:47): avc: denied { sys_tty_config } for pid=3283 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529770.778:48): avc: denied { sys_tty_config } for pid=3285 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529770.859:49): avc: denied { sys_tty_config } for pid=3287 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529772.510:50): avc: denied { sys_tty_config } for pid=3297 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529772.550:51): avc: denied { sys_tty_config } for pid=3299 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529775.226:52): avc: denied { sys_tty_config } for pid=3301 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529775.279:53): avc: denied { sys_tty_config } for pid=3303 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529775.453:54): avc: denied { sys_tty_config } for pid=3305 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529775.492:55): avc: denied { sys_tty_config } for pid=3307 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529777.577:56): avc: denied { sys_tty_config } for pid=3309 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529777.634:57): avc: denied { sys_tty_config } for pid=3311 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529777.769:58): avc: denied { sys_tty_config } for pid=3313 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529777.810:59): avc: denied { sys_tty_config } for pid=3315 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529780.434:60): avc: denied { sys_tty_config } for pid=3317 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529780.632:61): avc: denied { sys_tty_config } for pid=3319 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529781.084:62): avc: denied { sys_tty_config } for pid=3329 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529781.126:63): avc: denied { sys_tty_config } for pid=3331 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529784.000:64): avc: denied { sys_tty_config } for pid=3333 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529784.110:65): avc: denied { sys_tty_config } for pid=3335 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529784.430:66): avc: denied { sys_tty_config } for pid=3337 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529784.477:67): avc: denied { sys_tty_config } for pid=3339 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529784.823:68): avc: denied { sys_tty_config } for pid=3341 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529784.865:69): avc: denied { sys_tty_config } for pid=3343 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529788.255:70): avc: denied { sys_tty_config } for pid=3345 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529788.529:71): avc: denied { sys_tty_config } for pid=3347 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529788.655:72): avc: denied { sys_tty_config } for pid=3349 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529788.700:73): avc: denied { sys_tty_config } for pid=3351 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > __ratelimit: 6 callbacks suppressed > type=1400 audit(1220529811.625:76): avc: denied { sys_tty_config } for pid=3357 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529811.686:77): avc: denied { sys_tty_config } for pid=3359 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529811.827:78): avc: denied { sys_tty_config } for pid=3361 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529811.869:79): avc: denied { sys_tty_config } for pid=3363 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529812.004:80): avc: denied { sys_tty_config } for pid=3365 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529812.072:81): avc: denied { sys_tty_config } for pid=3367 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529812.310:82): avc: denied { sys_tty_config } for pid=3369 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529812.352:83): avc: denied { sys_tty_config } for pid=3371 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529814.439:84): avc: denied { sys_tty_config } for pid=3373 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529814.487:85): avc: denied { sys_tty_config } for pid=3375 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > __ratelimit: 12 callbacks suppressed > type=1400 audit(1220529818.528:90): avc: denied { sys_tty_config } for pid=3393 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529818.568:91): avc: denied { sys_tty_config } for pid=3395 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529820.169:92): avc: denied { sys_tty_config } for pid=3405 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529820.212:93): avc: denied { sys_tty_config } for pid=3407 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529820.505:94): avc: denied { sys_tty_config } for pid=3409 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529820.547:95): avc: denied { sys_tty_config } for pid=3411 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529822.767:96): avc: denied { sys_tty_config } for pid=3413 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529822.842:97): avc: denied { sys_tty_config } for pid=3415 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529822.960:98): avc: denied { sys_tty_config } for pid=3417 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529823.033:99): avc: denied { sys_tty_config } for pid=3419 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > __ratelimit: 12 callbacks suppressed > type=1400 audit(1220529825.678:104): avc: denied { sys_tty_config } for pid=3429 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529825.724:105): avc: denied { sys_tty_config } for pid=3431 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529825.856:106): avc: denied { sys_tty_config } for pid=3433 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529825.897:107): avc: denied { sys_tty_config } for pid=3435 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529826.000:108): avc: denied { sys_tty_config } for pid=3437 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529826.041:109): avc: denied { sys_tty_config } for pid=3439 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529826.231:110): avc: denied { sys_tty_config } for pid=3441 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529826.271:111): avc: denied { sys_tty_config } for pid=3443 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529826.437:112): avc: denied { sys_tty_config } for pid=3445 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529826.478:113): avc: denied { sys_tty_config } for pid=3447 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529835.583:114): avc: denied { sys_tty_config } for pid=3451 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529835.634:115): avc: denied { sys_tty_config } for pid=3453 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529835.820:116): avc: denied { sys_tty_config } for pid=3455 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529835.861:117): avc: denied { sys_tty_config } for pid=3457 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529838.320:118): avc: denied { sys_tty_config } for pid=3459 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529838.360:119): avc: denied { sys_tty_config } for pid=3461 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529838.516:120): avc: denied { sys_tty_config } for pid=3463 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529838.561:121): avc: denied { sys_tty_config } for pid=3465 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529839.201:122): avc: denied { sys_tty_config } for pid=3467 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529839.242:123): avc: denied { sys_tty_config } for pid=3469 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529841.192:124): avc: denied { sys_tty_config } for pid=3471 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529841.321:125): avc: denied { sys_tty_config } for pid=3473 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529841.520:126): avc: denied { sys_tty_config } for pid=3476 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529841.637:127): avc: denied { sys_tty_config } for pid=3478 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529841.822:128): avc: denied { sys_tty_config } for pid=3480 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529841.862:129): avc: denied { sys_tty_config } for pid=3482 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529842.166:130): avc: denied { sys_tty_config } for pid=3484 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529842.210:131): avc: denied { sys_tty_config } for pid=3486 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529844.442:132): avc: denied { sys_tty_config } for pid=3488 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529844.506:133): avc: denied { sys_tty_config } for pid=3490 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > __ratelimit: 24 callbacks suppressed > type=1400 audit(1220529848.095:142): avc: denied { sys_tty_config } for pid=3508 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529848.185:143): avc: denied { sys_tty_config } for pid=3510 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529848.859:144): avc: denied { sys_tty_config } for pid=3520 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529848.898:145): avc: denied { sys_tty_config } for pid=3522 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529849.137:146): avc: denied { sys_tty_config } for pid=3524 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529849.177:147): avc: denied { sys_tty_config } for pid=3526 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529852.584:148): avc: denied { sys_tty_config } for pid=3528 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529852.634:149): avc: denied { sys_tty_config } for pid=3530 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529852.754:150): avc: denied { sys_tty_config } for pid=3532 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529852.821:151): avc: denied { sys_tty_config } for pid=3534 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > __ratelimit: 6 callbacks suppressed > type=1400 audit(1220529853.255:154): avc: denied { sys_tty_config } for pid=3540 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529853.299:155): avc: denied { sys_tty_config } for pid=3542 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529881.330:156): avc: denied { sys_tty_config } for pid=3545 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529881.399:157): avc: denied { sys_tty_config } for pid=3547 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529881.503:158): avc: denied { sys_tty_config } for pid=3549 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529881.544:159): avc: denied { sys_tty_config } for pid=3551 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529883.136:160): avc: denied { sys_tty_config } for pid=3561 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529883.175:161): avc: denied { sys_tty_config } for pid=3563 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529883.488:162): avc: denied { sys_tty_config } for pid=3565 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529883.527:163): avc: denied { sys_tty_config } for pid=3567 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529886.317:164): avc: denied { sys_tty_config } for pid=3569 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529886.358:165): avc: denied { sys_tty_config } for pid=3571 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529886.488:166): avc: denied { sys_tty_config } for pid=3573 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529886.526:167): avc: denied { sys_tty_config } for pid=3575 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529886.608:168): avc: denied { sys_tty_config } for pid=3577 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529886.648:169): avc: denied { sys_tty_config } for pid=3579 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529886.941:170): avc: denied { sys_tty_config } for pid=3581 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529886.980:171): avc: denied { sys_tty_config } for pid=3583 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529889.535:172): avc: denied { sys_tty_config } for pid=3585 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529889.595:173): avc: denied { sys_tty_config } for pid=3587 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529889.722:174): avc: denied { sys_tty_config } for pid=3589 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529889.769:175): avc: denied { sys_tty_config } for pid=3591 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > __ratelimit: 18 callbacks suppressed > type=1400 audit(1220529892.600:182): avc: denied { sys_tty_config } for pid=3605 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529892.639:183): avc: denied { sys_tty_config } for pid=3607 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529892.801:184): avc: denied { sys_tty_config } for pid=3609 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529892.841:185): avc: denied { sys_tty_config } for pid=3611 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529893.125:186): avc: denied { sys_tty_config } for pid=3613 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529893.165:187): avc: denied { sys_tty_config } for pid=3615 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529895.584:188): avc: denied { sys_tty_config } for pid=3618 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529895.658:189): avc: denied { sys_tty_config } for pid=3620 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529895.814:190): avc: denied { sys_tty_config } for pid=3622 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529895.853:191): avc: denied { sys_tty_config } for pid=3624 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > __ratelimit: 6 callbacks suppressed > type=1400 audit(1220529898.643:194): avc: denied { sys_tty_config } for pid=3630 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529898.686:195): avc: denied { sys_tty_config } for pid=3632 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529898.852:196): avc: denied { sys_tty_config } for pid=3634 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529898.892:197): avc: denied { sys_tty_config } for pid=3636 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529899.200:198): avc: denied { sys_tty_config } for pid=3638 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529899.242:199): avc: denied { sys_tty_config } for pid=3640 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529901.667:200): avc: denied { sys_tty_config } for pid=3642 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529901.756:201): avc: denied { sys_tty_config } for pid=3644 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529901.876:202): avc: denied { sys_tty_config } for pid=3646 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529901.926:203): avc: denied { sys_tty_config } for pid=3648 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > __ratelimit: 18 callbacks suppressed > type=1400 audit(1220529904.636:210): avc: denied { sys_tty_config } for pid=3663 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529904.690:211): avc: denied { sys_tty_config } for pid=3665 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529904.850:212): avc: denied { sys_tty_config } for pid=3667 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529904.891:213): avc: denied { sys_tty_config } for pid=3669 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529907.399:214): avc: denied { sys_tty_config } for pid=3671 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529907.498:215): avc: denied { sys_tty_config } for pid=3673 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529907.794:216): avc: denied { sys_tty_config } for pid=3675 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529907.834:217): avc: denied { sys_tty_config } for pid=3677 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529908.700:218): avc: denied { sys_tty_config } for pid=3679 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529908.740:219): avc: denied { sys_tty_config } for pid=3681 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529913.685:220): avc: denied { sys_tty_config } for pid=3684 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529913.742:221): avc: denied { sys_tty_config } for pid=3686 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529913.879:222): avc: denied { sys_tty_config } for pid=3688 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529913.949:223): avc: denied { sys_tty_config } for pid=3690 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529914.276:224): avc: denied { sys_tty_config } for pid=3692 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529914.320:225): avc: denied { sys_tty_config } for pid=3694 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529914.738:226): avc: denied { sys_tty_config } for pid=3696 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529914.896:227): avc: denied { sys_tty_config } for pid=3698 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529935.547:228): avc: denied { sys_tty_config } for pid=3702 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529935.589:229): avc: denied { sys_tty_config } for pid=3704 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529936.070:230): avc: denied { sys_tty_config } for pid=3706 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529936.112:231): avc: denied { sys_tty_config } for pid=3708 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529939.916:232): avc: denied { sys_tty_config } for pid=3710 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529939.978:233): avc: denied { sys_tty_config } for pid=3712 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529940.548:234): avc: denied { sys_tty_config } for pid=3714 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220529940.610:235): avc: denied { sys_tty_config } for pid=3716 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220530068.807:236): avc: denied { sys_tty_config } for pid=3736 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > type=1400 audit(1220530068.856:237): avc: denied { sys_tty_config } for pid=3739 comm="pulseaudio" capability=26 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tclass=capability > > > (TIA) Thanks in Advance, > > > Antonio > > > > I will dontaudit the sys_tty_config for pulseaudio, but the execstack for operpluginwrap should be reported to whoever you got the package from. Why doesn't this get run by nsplugin? From dwalsh at redhat.com Thu Sep 4 13:08:33 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 04 Sep 2008 09:08:33 -0400 Subject: MLS enforcing and kerberos In-Reply-To: <20080822152149.0f5e7905@sparta.com> References: <20080822125102.447ca489@sparta.com> <1219424868.18600.97.camel@moss-spartans.epoch.ncsc.mil> <20080822152149.0f5e7905@sparta.com> Message-ID: <48BFDDD1.8080602@redhat.com> Robert Story wrote: > On Fri, 22 Aug 2008 13:07:48 -0400 Stephen wrote: > SS> > type=AVC msg=audit(1219421464.372:719): avc: denied { getattr } for > SS> > pid=2436 comm="kadmind" path="/var/tmp/kadmin_0" dev=dm-5 ino=82064 > SS> > scontext=system_u:system_r:kadmind_t:s0-s15:c0.c1023 > SS> > tcontext=system_u:object_r:unlabeled_t:s15:c0.c1023 tclass=file > SS> > SS> The real question there is why is that file labeled unlabeled_t? That > SS> usually indicates that its context was invalidated, e.g. you removed the > SS> type from the policy? > > I haven't touched policy... The file must be left over from when the box > was running in targeted mode... I did relabel, but then there's this: > > /etc/selinux/mls/contexts/files/file_contexts:/var/tmp/.* <> > > SS> BTW, aside from the wrong type on the file, the denial is clearly a MLS > SS> denial - look at the levels on the two contexts. You have a process > SS> whose current/low level is s0 (aka SystemLow) trying to getattr (read > SS> flow) a file at s15:c0.c1023 (aka SystemHigh). No surprises there. > SS> The high level of the process is only used as a ceiling for newrole -l > SS> or if the process' domain has certain MLS privileges allowing it to act > SS> up to its ceiling. > > I couldn't delete the file in enforcing mode, even after 'newrole -l > SystemHigh'. So I dropped to permissive and deleted the file. After > that, kadmin started fine and the file was recreated with SystemLow. > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Relabeling does not clean up /tmp files since we have no idea what to label these. So it is best when changing over if you remove all files from /tmp. Better yet use a tmpfs :^) From dwalsh at redhat.com Thu Sep 4 21:00:30 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 04 Sep 2008 17:00:30 -0400 Subject: error when adding a translation with "semanage translation -a" In-Reply-To: <48BC9109.2030404@redhat.com> References: <48BC9109.2030404@redhat.com> Message-ID: <48C04C6E.2080000@redhat.com> Murray McAllister wrote: > Hi, > > This is probably user error. I want to add a translation: > > 1. sudo cat /etc/selinux/targeted/setrans.conf > > s0= > s0-s0:c0.c1023=SystemLow-SystemHigh > s0:c0.c1023=SystemHigh > > 2. $ sudo semanage translation -l > > Level Translation > > s0 > s0-s0:c0.c1023 SystemLow-SystemHigh > s0:c0.c1023 SystemHigh > > 3. Attempt to add a new translation: > $ sudo semanage translation -a -T NotSecret s0:c1 > > /etc/init.d/functions: line 19: /sbin/consoletype: Permission denied > basename: write error: Permission denied > basename: write error: Permission denied > env: /etc/init.d/mcstrans: Permission denied > > 4. Translation appears to have been added: > > sudo semanage translation -l > > Level Translation > > s0 > s0-s0:c0.c1023 SystemLow-SystemHigh > s0:c0.c1023 SystemHigh > s0:c1 NotSecret > > sudo cat /etc/selinux/targeted/setrans.conf > > s0= > s0-s0:c0.c1023=SystemLow-SystemHigh > s0:c0.c1023=SystemHigh > s0:c1=NotSecret > > The following is logged to /var/log/messages: > > Aug 31 20:57:00 localhost setroubleshoot: SELinux is preventing service > (semanage_t) "execute" to ./consoletype (consoletype_exec_t). For > complete SELinux messages. run sealert -l > 3a9da9b1-9310-492b-a4fd-3706d8d78259 > Aug 31 20:57:00 localhost setroubleshoot: SELinux is preventing service > (semanage_t) "execute" to ./consoletype (consoletype_exec_t). For > complete SELinux messages. run sealert -l > 3a9da9b1-9310-492b-a4fd-3706d8d78259 > Aug 31 20:57:00 localhost setroubleshoot: SELinux is preventing service > (semanage_t) "read" to pipe (semanage_t). For complete SELinux messages. > run sealert -l 154967ff-45a0-4b8f-bf04-25546f129dd3 > Aug 31 20:57:00 localhost setroubleshoot: SELinux is preventing service > (semanage_t) "read" to pipe (semanage_t). For complete SELinux messages. > run sealert -l 154967ff-45a0-4b8f-bf04-25546f129dd3 > Aug 31 20:57:00 localhost setroubleshoot: SELinux is preventing basename > (semanage_t) "getattr" to pipe (semanage_t). For complete SELinux > messages. run sealert -l 641f7545-c40c-4d79-84c7-97e2b32d8c0a > Aug 31 20:57:00 localhost setroubleshoot: SELinux is preventing basename > (semanage_t) "write" to pipe (semanage_t). For complete SELinux > messages. run sealert -l 2ab7598a-b0f7-4dec-a10d-cb4cfac057ee > Aug 31 20:57:01 localhost setroubleshoot: SELinux is preventing basename > (semanage_t) "getattr" to pipe (semanage_t). For complete SELinux > messages. run sealert -l 641f7545-c40c-4d79-84c7-97e2b32d8c0a > Aug 31 20:57:01 localhost setroubleshoot: SELinux is preventing basename > (semanage_t) "write" to pipe (semanage_t). For complete SELinux > messages. run sealert -l 2ab7598a-b0f7-4dec-a10d-cb4cfac057ee > Aug 31 20:57:01 localhost setroubleshoot: SELinux is preventing service > (semanage_t) "read" to pipe (semanage_t). For complete SELinux messages. > run sealert -l 154967ff-45a0-4b8f-bf04-25546f129dd3 > Aug 31 20:57:01 localhost setroubleshoot: SELinux is preventing env > (semanage_t) "transition" to /etc/rc.d/init.d/mcstrans (semanage_t). For > complete SELinux messages. run sealert -l > ac0f934e-29dc-4702-a2f4-3a752150cb8f > > The following is logged to /var/log/audit/audit.log: > > type=AVC msg=audit(1220180220.598:367): avc: denied { execute } for > pid=2118 comm="service" name="consoletype" dev=sda5 ino=73034 > scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:consoletype_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1220180220.598:367): arch=40000003 syscall=11 > success=no exit=-13 a0=8d4c760 a1=8d4c7a8 a2=8d4c3b8 a3=0 items=0 > ppid=2117 pid=2118 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=pts0 ses=1 comm="service" exe="/bin/bash" > subj=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1220180220.599:368): avc: denied { execute } for > pid=2118 comm="service" name="consoletype" dev=sda5 ino=73034 > scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:consoletype_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1220180220.599:368): arch=40000003 syscall=33 > success=no exit=-13 a0=8d4c760 a1=1 a2=11 a3=8d4c760 items=0 ppid=2117 > pid=2118 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 tty=pts0 ses=1 comm="service" exe="/bin/bash" > subj=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1220180220.637:369): avc: denied { read } for > pid=2116 comm="service" path="pipe:[12134]" dev=pipefs ino=12134 > scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 > tcontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 > tclass=fifo_file > type=SYSCALL msg=audit(1220180220.637:369): arch=40000003 syscall=3 > success=no exit=-13 a0=3 a1=bfb075c8 a2=80 a3=80 items=0 ppid=2115 > pid=2116 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 tty=pts0 ses=1 comm="service" exe="/bin/bash" > subj=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1220180220.679:370): avc: denied { read } for > pid=2116 comm="service" path="pipe:[12135]" dev=pipefs ino=12135 > scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 > tcontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 > tclass=fifo_file > type=SYSCALL msg=audit(1220180220.679:370): arch=40000003 syscall=3 > success=no exit=-13 a0=3 a1=bfb079c8 a2=80 a3=80 items=0 ppid=2115 > pid=2116 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 tty=pts0 ses=1 comm="service" exe="/bin/bash" > subj=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1220180220.694:371): avc: denied { getattr } for > pid=2119 comm="basename" path="pipe:[12135]" dev=pipefs ino=12135 > scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 > tcontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 > tclass=fifo_file > type=SYSCALL msg=audit(1220180220.694:371): arch=40000003 syscall=197 > success=no exit=-13 a0=1 a1=bfd3e414 a2=960ff4 a3=9614c0 items=0 > ppid=2116 pid=2119 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=pts0 ses=1 comm="basename" exe="/bin/basename" > subj=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1220180220.708:372): avc: denied { write } for > pid=2119 comm="basename" path="pipe:[12135]" dev=pipefs ino=12135 > scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 > tcontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 > tclass=fifo_file > type=SYSCALL msg=audit(1220180220.708:372): arch=40000003 syscall=4 > success=no exit=-13 a0=1 a1=b7f3d000 a2=8 a3=8 items=0 ppid=2116 > pid=2119 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 tty=pts0 ses=1 comm="basename" exe="/bin/basename" > subj=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1220180220.727:373): avc: denied { getattr } for > pid=2120 comm="basename" path="pipe:[12136]" dev=pipefs ino=12136 > scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 > tcontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 > tclass=fifo_file > type=SYSCALL msg=audit(1220180220.727:373): arch=40000003 syscall=197 > success=no exit=-13 a0=1 a1=bffb9684 a2=960ff4 a3=9614c0 items=0 > ppid=2116 pid=2120 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=pts0 ses=1 comm="basename" exe="/bin/basename" > subj=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1220180220.728:374): avc: denied { write } for > pid=2120 comm="basename" path="pipe:[12136]" dev=pipefs ino=12136 > scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 > tcontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 > tclass=fifo_file > type=SYSCALL msg=audit(1220180220.728:374): arch=40000003 syscall=4 > success=no exit=-13 a0=1 a1=b80b8000 a2=8 a3=8 items=0 ppid=2116 > pid=2120 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 tty=pts0 ses=1 comm="basename" exe="/bin/basename" > subj=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1220180220.749:375): avc: denied { read } for > pid=2116 comm="service" path="pipe:[12136]" dev=pipefs ino=12136 > scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 > tcontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 > tclass=fifo_file > type=SYSCALL msg=audit(1220180220.749:375): arch=40000003 syscall=3 > success=no exit=-13 a0=3 a1=bfb079c8 a2=80 a3=80 items=0 ppid=2115 > pid=2116 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 tty=pts0 ses=1 comm="service" exe="/bin/bash" > subj=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1220180220.760:376): avc: denied { transition } for > pid=2121 comm="env" path="/etc/rc.d/init.d/mcstrans" dev=sda5 > ino=222868 scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 > tcontext=unconfined_u:system_r:semanage_t:s0 tclass=process > type=SYSCALL msg=audit(1220180220.760:376): arch=40000003 syscall=11 > success=no exit=-13 a0=bfd449ce a1=bfd435b8 a2=9922858 a3=5 items=0 > ppid=2116 pid=2121 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=pts0 ses=1 comm="env" exe="/bin/env" > subj=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 key=(null) > > The system: > > * Fedora release 9 (Sulphur) > * kernel-2.6.25.14-108.fc9.i686 > * kernel-headers-2.6.25.14-108.fc9.i386 > > * policycoreutils-2.0.52-5.fc9.i386 > * mcstrans-0.2.11-1.fc9.i386 > * selinux-policy-targeted-3.3.1-84.fc9.noarch > * selinux-policy-3.3.1-84.fc9.noarch > * selinux-policy-devel-3.3.1-84.fc9.noarch > * libselinux-python-2.0.67-4.fc9.i386 > * libselinux-2.0.67-4.fc9.i386 > > $ sestatus > SELinux status: enabled > SELinuxfs mount: /selinux > Current mode: enforcing > Mode from config file: enforcing > Policy version: 22 > Policy from config file: targeted > > ps -eZ | grep mcs > system_u:system_r:setrans_t:SystemLow-SystemHigh 1262 ? 00:00:00 mcstransd > > Regards, > > Murray. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Fixed in selinux-policy-3.5.6-2.fc10.noarch From dwalsh at redhat.com Thu Sep 4 21:01:43 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 04 Sep 2008 17:01:43 -0400 Subject: changing categories with "semanage translation -m" In-Reply-To: <48BDDA59.40408@redhat.com> References: <48BDDA59.40408@redhat.com> Message-ID: <48C04CB7.1000300@redhat.com> Murray McAllister wrote: > Hi, > > I added the following two translations using "semanage translation -a -T > [name] level": > > s0:c1 NotSecret > s0:c1.c2 Secret > > If I want to change the categories, say to have Secret as s0:c3, or only > so:c2, can I use semanage? I tried "semanage translation -m -T Secret > s0:c2": > The key is s0:c3 so you need to delete and add. > /usr/sbin/semanage: s0:c2 not defined in translations > > If I use "-a" instead of "-m", it adds another translation. > > Is the recommended way of changing categories adding a new one, and then > 'semanage login -m -r s0:xy user', for any users using the old range? > > Cheers. > > I am using: > > * Fedora release 9 (Sulphur) > * kernel-2.6.25.14-108.fc9.i686 > * kernel-headers-2.6.25.14-108.fc9.i386 > > * policycoreutils-2.0.52-5.fc9.i386 > * mcstrans-0.2.11-1.fc9.i386 > * selinux-policy-targeted-3.3.1-84.fc9.noarch > * selinux-policy-3.3.1-84.fc9.noarch > * selinux-policy-devel-3.3.1-84.fc9.noarch > * libselinux-python-2.0.67-4.fc9.i386 > * libselinux-2.0.67-4.fc9.i386 > > $ sestatus > SELinux status: enabled > SELinuxfs mount: /selinux > Current mode: enforcing > Mode from config file: enforcing > Policy version: 22 > Policy from config file: targeted > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From olivares14031 at yahoo.com Thu Sep 4 21:24:54 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Thu, 4 Sep 2008 14:24:54 -0700 (PDT) Subject: problems with sound, cont'd - selinux is in the way In-Reply-To: <48BFDB70.6050704@redhat.com> Message-ID: <50925.8306.qm@web52603.mail.re2.yahoo.com> --- On Thu, 9/4/08, Daniel J Walsh wrote: > I will dontaudit the sys_tty_config for pulseaudio, but the > execstack > for operpluginwrap should be reported to whoever you got > the package > from. Why doesn't this get run by nsplugin? I got the package(tar.gz) from Opera Download page. I was getting alot of freezes by both Seamonkey and Firefox that I went to get Opera. I got fed up with firefox and the Edit Preferences --> Tell Me that the s.... Anyhow, since opera is misbehaving, I am back with firefox for the meantime. I made a rule that setroubleshoot suggested and it was working up to now. I can't remember what it was. Thanks, Antonio From rjcarr at gmail.com Fri Sep 5 03:07:10 2008 From: rjcarr at gmail.com (Robert J. Carr) Date: Thu, 4 Sep 2008 20:07:10 -0700 Subject: changes from fedora 7 to 9 Message-ID: Hopefully this is a quick question to those that know SELinux more than I do, which wouldn't be very hard to accomplish. I'm migrating a (working) environment from one server running Fedora 7 to another running Fedora 9. After pulling my hair out for most of the day I've found out the problem is with SELinux because when I turned it off temporarily everything worked fine. Not to get into too much detail, but my problem came from apache not being able to access a file (although the error isn't quite that clear). Between the working environment and the non-working environment I can only see a couple differences in the selinux config files in /etc, but these have never been touched in either instance. The context labels are a bit different too. The working environment has these selinux context labels: user_u:object_r:httpd_sys_content_t But the non-working environment has these context labels: unconfined_u:object_r:httpd_sys_content_t:s0 It seems to get an extra field and the user changes to unconfined. Is this relevant? There is nothing else that I can find different, is there anything else that could be the problem? Any advice would be greatly appreciated. From paul at city-fan.org Fri Sep 5 06:34:22 2008 From: paul at city-fan.org (Paul Howarth) Date: Fri, 5 Sep 2008 07:34:22 +0100 Subject: changes from fedora 7 to 9 In-Reply-To: References: Message-ID: <20080905073422.1e8ac3e7@metropolis.intra.city-fan.org> On Thu, 4 Sep 2008 20:07:10 -0700 "Robert J. Carr" wrote: > Hopefully this is a quick question to those that know SELinux more > than I do, which wouldn't be very hard to accomplish. > > I'm migrating a (working) environment from one server running Fedora 7 > to another running Fedora 9. After pulling my hair out for most of > the day I've found out the problem is with SELinux because when I > turned it off temporarily everything worked fine. > > Not to get into too much detail, but my problem came from apache not > being able to access a file (although the error isn't quite that > clear). Between the working environment and the non-working > environment I can only see a couple differences in the selinux config > files in /etc, but these have never been touched in either instance. > > The context labels are a bit different too. The working environment > has these selinux context labels: > > user_u:object_r:httpd_sys_content_t > > But the non-working environment has these context labels: > > unconfined_u:object_r:httpd_sys_content_t:s0 > > It seems to get an extra field and the user changes to unconfined. Is > this relevant? > > There is nothing else that I can find different, is there anything > else that could be the problem? > > Any advice would be greatly appreciated. You need to find the actual SELinux denials that are happening and post them. They'll be in /var/log/audit/audit.log if you're running the audit daemon, and /var/log/messages of you're not. Paul. From dwalsh at redhat.com Fri Sep 5 14:19:08 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 05 Sep 2008 10:19:08 -0400 Subject: changes from fedora 7 to 9 In-Reply-To: References: Message-ID: <48C13FDC.9050008@redhat.com> Robert J. Carr wrote: > Hopefully this is a quick question to those that know SELinux more > than I do, which wouldn't be very hard to accomplish. > > I'm migrating a (working) environment from one server running Fedora 7 > to another running Fedora 9. After pulling my hair out for most of > the day I've found out the problem is with SELinux because when I > turned it off temporarily everything worked fine. > > Not to get into too much detail, but my problem came from apache not > being able to access a file (although the error isn't quite that > clear). Between the working environment and the non-working > environment I can only see a couple differences in the selinux config > files in /etc, but these have never been touched in either instance. > > The context labels are a bit different too. The working environment > has these selinux context labels: > > user_u:object_r:httpd_sys_content_t > > But the non-working environment has these context labels: > > unconfined_u:object_r:httpd_sys_content_t:s0 > > It seems to get an extra field and the user changes to unconfined. Is > this relevant? > > There is nothing else that I can find different, is there anything > else that could be the problem? > > Any advice would be greatly appreciated. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Also pipe them through audit2why it might tell you you need to turn on a boolean. grep http /var/log/audit/audit.log | audit2allow -w From rjcarr at gmail.com Fri Sep 5 16:16:11 2008 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 5 Sep 2008 09:16:11 -0700 Subject: changes from fedora 7 to 9 In-Reply-To: <48C13FDC.9050008@redhat.com> References: <48C13FDC.9050008@redhat.com> Message-ID: Thanks Paul and Daniel- I piped the logs through audit2why and here's what it is saying: ---- type=AVC msg=audit(1220631048.301:1541): avc: denied { write } for pid=8572 comm="httpd" name="trac.db" dev=dm-0 ino=2148813854 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=file Was caused by: Missing type enforcement (TE) allow rule. You can use audit2allow to generate a loadable module to allow this access. ---- As I said previously I know almost nothing about selinux, so if this means anything help is appreciated, otherwise I'm going to see what I can find out. Thanks for the guidance. On Fri, Sep 5, 2008 at 7:19 AM, Daniel J Walsh wrote: > Robert J. Carr wrote: >> Hopefully this is a quick question to those that know SELinux more >> than I do, which wouldn't be very hard to accomplish. >> >> I'm migrating a (working) environment from one server running Fedora 7 >> to another running Fedora 9. After pulling my hair out for most of >> the day I've found out the problem is with SELinux because when I >> turned it off temporarily everything worked fine. >> >> Not to get into too much detail, but my problem came from apache not >> being able to access a file (although the error isn't quite that >> clear). Between the working environment and the non-working >> environment I can only see a couple differences in the selinux config >> files in /etc, but these have never been touched in either instance. >> >> The context labels are a bit different too. The working environment >> has these selinux context labels: >> >> user_u:object_r:httpd_sys_content_t >> >> But the non-working environment has these context labels: >> >> unconfined_u:object_r:httpd_sys_content_t:s0 >> >> It seems to get an extra field and the user changes to unconfined. Is >> this relevant? >> >> There is nothing else that I can find different, is there anything >> else that could be the problem? >> >> Any advice would be greatly appreciated. >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Also pipe them through audit2why it might tell you you need to turn on a > boolean. > > grep http /var/log/audit/audit.log | audit2allow -w > > From paul at city-fan.org Fri Sep 5 17:35:48 2008 From: paul at city-fan.org (Paul Howarth) Date: Fri, 5 Sep 2008 18:35:48 +0100 Subject: changes from fedora 7 to 9 In-Reply-To: References: <48C13FDC.9050008@redhat.com> Message-ID: <20080905183548.4c60ea6b@metropolis.intra.city-fan.org> On Fri, 5 Sep 2008 09:16:11 -0700 "Robert J. Carr" wrote: > Thanks Paul and Daniel- > > I piped the logs through audit2why and here's what it is saying: > > ---- > > type=AVC msg=audit(1220631048.301:1541): avc: denied { write } for > pid=8572 comm="httpd" name="trac.db" dev=dm-0 ino=2148813854 > scontext=unconfined_u:system_r:httpd_t:s0 > tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=file > > Was caused by: > Missing type enforcement (TE) allow rule. > > You can use audit2allow to generate a loadable module to allow this > access. > > ---- > > As I said previously I know almost nothing about selinux, so if this > means anything help is appreciated, otherwise I'm going to see what I > can find out. > > Thanks for the guidance. > > On Fri, Sep 5, 2008 at 7:19 AM, Daniel J Walsh > wrote: > > Robert J. Carr wrote: > >> Hopefully this is a quick question to those that know SELinux more > >> than I do, which wouldn't be very hard to accomplish. > >> > >> I'm migrating a (working) environment from one server running > >> Fedora 7 to another running Fedora 9. After pulling my hair out > >> for most of the day I've found out the problem is with SELinux > >> because when I turned it off temporarily everything worked fine. > >> > >> Not to get into too much detail, but my problem came from apache > >> not being able to access a file (although the error isn't quite > >> that clear). Between the working environment and the non-working > >> environment I can only see a couple differences in the selinux > >> config files in /etc, but these have never been touched in either > >> instance. > >> > >> The context labels are a bit different too. The working > >> environment has these selinux context labels: > >> > >> user_u:object_r:httpd_sys_content_t > >> > >> But the non-working environment has these context labels: > >> > >> unconfined_u:object_r:httpd_sys_content_t:s0 > >> > >> It seems to get an extra field and the user changes to > >> unconfined. Is this relevant? > >> > >> There is nothing else that I can find different, is there anything > >> else that could be the problem? > >> > >> Any advice would be greatly appreciated. > >> > >> -- > >> fedora-selinux-list mailing list > >> fedora-selinux-list at redhat.com > >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Also pipe them through audit2why it might tell you you need to turn > > on a boolean. > > > > grep http /var/log/audit/audit.log | audit2allow -w OK, I don't know where your trac.db file is, so let's say it's /srv/www/trac/db/trac.db See if this helps: # chcon -R -t httpd_sys_script_rw_t /srv/www/trac/ Cheers, Paul. From rjcarr at gmail.com Fri Sep 5 17:50:35 2008 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 5 Sep 2008 10:50:35 -0700 Subject: changes from fedora 7 to 9 In-Reply-To: <20080905183548.4c60ea6b@metropolis.intra.city-fan.org> References: <48C13FDC.9050008@redhat.com> <20080905183548.4c60ea6b@metropolis.intra.city-fan.org> Message-ID: Thanks Paul! I put that label (httpd_sys_script_rw_t) on the trac.db file itself (not using -R as you suggested) and it worked. So now for the whole teach a guy how to fish part. Is this a new label for selinux in Fedora 9? In my other working environment in Fedora 7 all files (including trac.db) are labeled with httpd_sys_content_t. What's different? Is there some guide that tells you the labels you should be using for specific types of httpd files? Thanks again for the help ... it is greatly appreciated. On Fri, Sep 5, 2008 at 10:35 AM, Paul Howarth wrote: > On Fri, 5 Sep 2008 09:16:11 -0700 > "Robert J. Carr" wrote: > >> Thanks Paul and Daniel- >> >> I piped the logs through audit2why and here's what it is saying: >> >> ---- >> >> type=AVC msg=audit(1220631048.301:1541): avc: denied { write } for >> pid=8572 comm="httpd" name="trac.db" dev=dm-0 ino=2148813854 >> scontext=unconfined_u:system_r:httpd_t:s0 >> tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=file >> >> Was caused by: >> Missing type enforcement (TE) allow rule. >> >> You can use audit2allow to generate a loadable module to allow this >> access. >> >> ---- >> >> As I said previously I know almost nothing about selinux, so if this >> means anything help is appreciated, otherwise I'm going to see what I >> can find out. >> >> Thanks for the guidance. >> >> On Fri, Sep 5, 2008 at 7:19 AM, Daniel J Walsh >> wrote: >> > Robert J. Carr wrote: >> >> Hopefully this is a quick question to those that know SELinux more >> >> than I do, which wouldn't be very hard to accomplish. >> >> >> >> I'm migrating a (working) environment from one server running >> >> Fedora 7 to another running Fedora 9. After pulling my hair out >> >> for most of the day I've found out the problem is with SELinux >> >> because when I turned it off temporarily everything worked fine. >> >> >> >> Not to get into too much detail, but my problem came from apache >> >> not being able to access a file (although the error isn't quite >> >> that clear). Between the working environment and the non-working >> >> environment I can only see a couple differences in the selinux >> >> config files in /etc, but these have never been touched in either >> >> instance. >> >> >> >> The context labels are a bit different too. The working >> >> environment has these selinux context labels: >> >> >> >> user_u:object_r:httpd_sys_content_t >> >> >> >> But the non-working environment has these context labels: >> >> >> >> unconfined_u:object_r:httpd_sys_content_t:s0 >> >> >> >> It seems to get an extra field and the user changes to >> >> unconfined. Is this relevant? >> >> >> >> There is nothing else that I can find different, is there anything >> >> else that could be the problem? >> >> >> >> Any advice would be greatly appreciated. >> >> >> >> -- >> >> fedora-selinux-list mailing list >> >> fedora-selinux-list at redhat.com >> >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> > Also pipe them through audit2why it might tell you you need to turn >> > on a boolean. >> > >> > grep http /var/log/audit/audit.log | audit2allow -w > > OK, I don't know where your trac.db file is, so let's say > it's /srv/www/trac/db/trac.db > > See if this helps: > # chcon -R -t httpd_sys_script_rw_t /srv/www/trac/ > > Cheers, Paul. > > From dwalsh at redhat.com Fri Sep 5 18:30:33 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 05 Sep 2008 14:30:33 -0400 Subject: changes from fedora 7 to 9 In-Reply-To: References: <48C13FDC.9050008@redhat.com> <20080905183548.4c60ea6b@metropolis.intra.city-fan.org> Message-ID: <48C17AC9.5050109@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert J. Carr wrote: > Thanks Paul! I put that label (httpd_sys_script_rw_t) on the trac.db > file itself (not using -R as you suggested) and it worked. > > So now for the whole teach a guy how to fish part. Is this a new > label for selinux in Fedora 9? In my other working environment in > Fedora 7 all files (including trac.db) are labeled with > httpd_sys_content_t. What's different? > > Is there some guide that tells you the labels you should be using for > specific types of httpd files? > > Thanks again for the help ... it is greatly appreciated. > > > On Fri, Sep 5, 2008 at 10:35 AM, Paul Howarth wrote: >> On Fri, 5 Sep 2008 09:16:11 -0700 >> "Robert J. Carr" wrote: >> >>> Thanks Paul and Daniel- >>> >>> I piped the logs through audit2why and here's what it is saying: >>> >>> ---- >>> >>> type=AVC msg=audit(1220631048.301:1541): avc: denied { write } for >>> pid=8572 comm="httpd" name="trac.db" dev=dm-0 ino=2148813854 >>> scontext=unconfined_u:system_r:httpd_t:s0 >>> tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=file >>> >>> Was caused by: >>> Missing type enforcement (TE) allow rule. >>> >>> You can use audit2allow to generate a loadable module to allow this >>> access. >>> >>> ---- >>> >>> As I said previously I know almost nothing about selinux, so if this >>> means anything help is appreciated, otherwise I'm going to see what I >>> can find out. >>> >>> Thanks for the guidance. >>> >>> On Fri, Sep 5, 2008 at 7:19 AM, Daniel J Walsh >>> wrote: >>>> Robert J. Carr wrote: >>>>> Hopefully this is a quick question to those that know SELinux more >>>>> than I do, which wouldn't be very hard to accomplish. >>>>> >>>>> I'm migrating a (working) environment from one server running >>>>> Fedora 7 to another running Fedora 9. After pulling my hair out >>>>> for most of the day I've found out the problem is with SELinux >>>>> because when I turned it off temporarily everything worked fine. >>>>> >>>>> Not to get into too much detail, but my problem came from apache >>>>> not being able to access a file (although the error isn't quite >>>>> that clear). Between the working environment and the non-working >>>>> environment I can only see a couple differences in the selinux >>>>> config files in /etc, but these have never been touched in either >>>>> instance. >>>>> >>>>> The context labels are a bit different too. The working >>>>> environment has these selinux context labels: >>>>> >>>>> user_u:object_r:httpd_sys_content_t >>>>> >>>>> But the non-working environment has these context labels: >>>>> >>>>> unconfined_u:object_r:httpd_sys_content_t:s0 >>>>> >>>>> It seems to get an extra field and the user changes to >>>>> unconfined. Is this relevant? >>>>> >>>>> There is nothing else that I can find different, is there anything >>>>> else that could be the problem? >>>>> >>>>> Any advice would be greatly appreciated. >>>>> >>>>> -- >>>>> fedora-selinux-list mailing list >>>>> fedora-selinux-list at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>>> Also pipe them through audit2why it might tell you you need to turn >>>> on a boolean. >>>> >>>> grep http /var/log/audit/audit.log | audit2allow -w >> OK, I don't know where your trac.db file is, so let's say >> it's /srv/www/trac/db/trac.db >> >> See if this helps: >> # chcon -R -t httpd_sys_script_rw_t /srv/www/trac/ >> >> Cheers, Paul. >> >> > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list man httpd_selinux Explains a lot of it. # semanage fcontext -a -t httpd_sys_script_rw_t '/srv/www/trac(/.*)?' But this is revealing a bug in policy. This is supposed to work out of the box with the httpd_unified boolean turned on. But the policy to do this was accidently removed. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjBeskACgkQrlYvE4MpobN9TwCfad+fPalb5egzj/Mnq0OYvBGb Nr0AoI1xWlN4z5n4Q4/9RwQ5jh4oz4CQ =VxgT -----END PGP SIGNATURE----- From dwalsh at redhat.com Fri Sep 5 18:32:55 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 05 Sep 2008 14:32:55 -0400 Subject: changes from fedora 7 to 9 In-Reply-To: <48C17AC9.5050109@redhat.com> References: <48C13FDC.9050008@redhat.com> <20080905183548.4c60ea6b@metropolis.intra.city-fan.org> <48C17AC9.5050109@redhat.com> Message-ID: <48C17B57.7060801@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel J Walsh wrote: > Robert J. Carr wrote: >> Thanks Paul! I put that label (httpd_sys_script_rw_t) on the trac.db >> file itself (not using -R as you suggested) and it worked. > >> So now for the whole teach a guy how to fish part. Is this a new >> label for selinux in Fedora 9? In my other working environment in >> Fedora 7 all files (including trac.db) are labeled with >> httpd_sys_content_t. What's different? > >> Is there some guide that tells you the labels you should be using for >> specific types of httpd files? > >> Thanks again for the help ... it is greatly appreciated. > > >> On Fri, Sep 5, 2008 at 10:35 AM, Paul Howarth wrote: >>> On Fri, 5 Sep 2008 09:16:11 -0700 >>> "Robert J. Carr" wrote: >>> >>>> Thanks Paul and Daniel- >>>> >>>> I piped the logs through audit2why and here's what it is saying: >>>> >>>> ---- >>>> >>>> type=AVC msg=audit(1220631048.301:1541): avc: denied { write } for >>>> pid=8572 comm="httpd" name="trac.db" dev=dm-0 ino=2148813854 >>>> scontext=unconfined_u:system_r:httpd_t:s0 >>>> tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=file >>>> >>>> Was caused by: >>>> Missing type enforcement (TE) allow rule. >>>> >>>> You can use audit2allow to generate a loadable module to allow this >>>> access. >>>> >>>> ---- >>>> >>>> As I said previously I know almost nothing about selinux, so if this >>>> means anything help is appreciated, otherwise I'm going to see what I >>>> can find out. >>>> >>>> Thanks for the guidance. >>>> >>>> On Fri, Sep 5, 2008 at 7:19 AM, Daniel J Walsh >>>> wrote: >>>>> Robert J. Carr wrote: >>>>>> Hopefully this is a quick question to those that know SELinux more >>>>>> than I do, which wouldn't be very hard to accomplish. >>>>>> >>>>>> I'm migrating a (working) environment from one server running >>>>>> Fedora 7 to another running Fedora 9. After pulling my hair out >>>>>> for most of the day I've found out the problem is with SELinux >>>>>> because when I turned it off temporarily everything worked fine. >>>>>> >>>>>> Not to get into too much detail, but my problem came from apache >>>>>> not being able to access a file (although the error isn't quite >>>>>> that clear). Between the working environment and the non-working >>>>>> environment I can only see a couple differences in the selinux >>>>>> config files in /etc, but these have never been touched in either >>>>>> instance. >>>>>> >>>>>> The context labels are a bit different too. The working >>>>>> environment has these selinux context labels: >>>>>> >>>>>> user_u:object_r:httpd_sys_content_t >>>>>> >>>>>> But the non-working environment has these context labels: >>>>>> >>>>>> unconfined_u:object_r:httpd_sys_content_t:s0 >>>>>> >>>>>> It seems to get an extra field and the user changes to >>>>>> unconfined. Is this relevant? >>>>>> >>>>>> There is nothing else that I can find different, is there anything >>>>>> else that could be the problem? >>>>>> >>>>>> Any advice would be greatly appreciated. >>>>>> >>>>>> -- >>>>>> fedora-selinux-list mailing list >>>>>> fedora-selinux-list at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>>>> Also pipe them through audit2why it might tell you you need to turn >>>>> on a boolean. >>>>> >>>>> grep http /var/log/audit/audit.log | audit2allow -w >>> OK, I don't know where your trac.db file is, so let's say >>> it's /srv/www/trac/db/trac.db >>> >>> See if this helps: >>> # chcon -R -t httpd_sys_script_rw_t /srv/www/trac/ >>> >>> Cheers, Paul. >>> >>> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list Resending with fixed text. man httpd_selinux Explains a lot of it. # semanage fcontext -a -t httpd_sys_script_rw_t '/srv/www/trac(/.*)?' # restorecon -R -v /srv/www Is better then chcon since it will survive a relebel. But this is revealing a bug in policy. This is supposed to work out of the box with the httpd_unified boolean turned on. But the policy to do this was accidently removed. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjBe1YACgkQrlYvE4MpobOMdACfc4FxXzfSjhxCTaMsMv/KIYKa pgkAn0rvEjLA/dYEmpm/BEXHvRxTk//r =5c1o -----END PGP SIGNATURE----- From selinux at gmail.com Sat Sep 6 18:17:42 2008 From: selinux at gmail.com (Tom London) Date: Sat, 6 Sep 2008 11:17:42 -0700 Subject: rsync, xattrs, ntfs-3g and "selinux.selinux" In-Reply-To: <1220457341.3862.295.camel@code.and.org> References: <4c4ba1530808241420x70b65aafr9c206d8412fe4e97@mail.gmail.com> <48BEABFA.1080604@redhat.com> <1220457341.3862.295.camel@code.and.org> Message-ID: <4c4ba1530809061117m2ba83e41m7f43065029830016@mail.gmail.com> On Wed, Sep 3, 2008 at 8:55 AM, James Antill wrote: > On Wed, 2008-09-03 at 11:23 -0400, Daniel J Walsh wrote: > >> Looks like an rsync bug? >> >> James did you work on rsync? > > Nope, looking at the rpm changelog shows: > > > * Mon Feb 19 2007 Simo Sorce - 2.6.9-2 > - fix acl/xattr bug with --delete: (bz#229145) > > [...] > > * Fri Jun 09 2006 Jay Fenlason 2.6.8-3 > - Add my xattrs_bug patch to fix a bug where xattrs don't get sent > correctly. > [...] > > * Mon May 08 2006 Jay Fenlason 2.6.8-2 > - New upstream release > - Use the upstream xattr patch instead of mine. This closes > bz#190208 CVE-2006-2083 rsync buffer overflow issue > > [...] > > * Thu Feb 10 2005 Jay Fenlason 2.6.3-2 > - Added my -xattr patch, which is based on the -acl patch. > > > -- > James Antill > Red Hat > I looked into this a bit..... The upstream source for rsync-3.0.3 shows this in xattr.c: <<<>>>> static int rsync_xal_set(const char *fname, item_list *xalp, const char *fnamecmp, stat_x *sxp) { <<<<>>>> /* Remove any extraneous names. */ for (name = namebuf; list_len > 0; name += name_len) { name_len = strlen(name) + 1; list_len -= name_len; #ifdef HAVE_LINUX_XATTRS /* We always ignore the system namespace, and non-root * ignores everything but the user namespace. */ if (am_root ? HAS_PREFIX(name, SYSTEM_PREFIX) : !HAS_PREFIX(name, USER_PREFIX)) continue; #endif I think this says: if running as root, don't remove attributes in the system namespace (but remove everything else); if running as non-root, remove all attributes but those in the user namespace. If so, when running as root, the code will attempt to remove attributes from the security namespace (e.g., 'security.selinux'). In my case, I'm rsync-ing to an ext4 fs that supports SELinux labels/etc., but copying from an NTFS-3g fs (mounted as /mnt/XXXXX) that shows fusefs_t as labels. "getfattr" on files in these mounted filesystems fail: [root at tlondon ~]# getfattr /mnt/music getfattr: /mnt/music: Operation not supported [root at tlondon ~]# My (first?) guess is that rsync is trying to remove the security attributes from target files to match the source file attributes (none). Is this logic wrong? Should rsync try to remove the security (e.g., selinux) attributes from the target? It would be straightforward to patch the above code to 'continue' on both system and security attributes. Something like: --- xattrs.c 2008-09-06 11:12:50.000000000 -0700 +++ xattrs.c.orig 2008-09-06 11:09:08.000000000 -0700 @@ -818,10 +818,9 @@ list_len -= name_len; #ifdef HAVE_LINUX_XATTRS - /* We always ignore the system and security namespaces, - * and non-root ignores everything but the user namespace. */ - if (am_root ? ( HAS_PREFIX(name, SYSTEM_PREFIX) - || HAS_PREFIX(name, SECURITY_PREFIX) ) + /* We always ignore the system namespace, and non-root + * ignores everything but the user namespace. */ + if (am_root ? HAS_PREFIX(name, SYSTEM_PREFIX) : !HAS_PREFIX(name, USER_PREFIX)) continue; #endif But is this the right way to handle attributes in the security namespace? What about "Trusted extended attributes"? If the above is "the right way", I can create a working patch and test. If not, I could use some "enlightenment"..... ;) tom -- Tom London From sdcroll at verizon.net Sun Sep 7 22:10:52 2008 From: sdcroll at verizon.net (Stephen Croll) Date: Sun, 07 Sep 2008 17:10:52 -0500 Subject: SELinux kerneloops and dhclient issues Message-ID: <48C4516C.1080805@verizon.net> Note: Originally posted to fedora-list. The "setroubleshoot browser" is reporting the following issues on Fedora 9: SELinux is preventing kerneloops (kerneloops_t) "signal" to (kerneloops_t). SELinux is preventing dhclient (dhcpc_t) "read write" to socket (unconfined_t). The first issue occurred on boot, but no longer seems to be happening. The second issue occurs when I bring up eth0. Should I file a bug report, or might there be something more sinister going on? For reference, the complete reports are as follows: Summary: SELinux is preventing kerneloops (kerneloops_t) "signal" to (kerneloops_t). Detailed Description: SELinux denied access requested by kerneloops. It is not expected that this access is required by kerneloops 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 system_u:system_r:kerneloops_t:s0 Target Context system_u:system_r:kerneloops_t:s0 Target Objects None [ process ] Source kerneloops Source Path /usr/sbin/kerneloops Port Host gerbil Source RPM Packages kerneloops-0.11-1.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-84.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name gerbil Platform Linux gerbil 2.6.25.14-108.fc9.x86_64 #1 SMP Mon Aug 4 13:46:35 EDT 2008 x86_64 x86_64 Alert Count 2 First Seen Sun 07 Sep 2008 03:21:55 AM CDT Last Seen Sun 07 Sep 2008 03:21:55 AM CDT Local ID fa4c1bd0-faf1-48ba-ba55-74285538ef90 Line Numbers Raw Audit Messages host=gerbil type=AVC msg=audit(1220775715.59:8): avc: denied { signal } for pid=2363 comm="kerneloops" scontext=system_u:system_r:kerneloops_t:s0 tcontext=system_u:system_r:kerneloops_t:s0 tclass=process host=gerbil type=SYSCALL msg=audit(1220775715.59:8): arch=c000003e syscall=234 success=no exit=-13 a0=93b a1=93b a2=6 a3=8 items=0 ppid=1 pid=2363 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="kerneloops" exe="/usr/sbin/kerneloops" subj=system_u:system_r:kerneloops_t:s0 key=(null) -and- Summary: SELinux is preventing dhclient (dhcpc_t) "read write" to socket (unconfined_t). Detailed Description: SELinux denied access requested by dhclient. It is not expected that this access is required by dhclient 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 unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 Target Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 023 Target Objects socket [ unix_stream_socket ] Source dhclient Source Path /sbin/dhclient Port Host gerbil Source RPM Packages dhclient-4.0.0-14.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-84.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name gerbil Platform Linux gerbil 2.6.25.14-108.fc9.x86_64 #1 SMP Mon Aug 4 13:46:35 EDT 2008 x86_64 x86_64 Alert Count 16 First Seen Sun 07 Sep 2008 12:56:48 AM CDT Last Seen Sun 07 Sep 2008 03:23:07 AM CDT Local ID a3b5492a-0ef2-4cc3-bdd0-4c06696bae70 Line Numbers Raw Audit Messages host=gerbil type=AVC msg=audit(1220775787.407:21): avc: denied { read write } for pid=3069 comm="dhclient" path="socket:[68728]" dev=sockfs ino=68728 scontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket host=gerbil type=SYSCALL msg=audit(1220775787.407:21): arch=c000003e syscall=59 success=yes exit=0 a0=948530 a1=94ad90 a2=8f0d70 a3=3f48f67a70 items=0 ppid=2970 pid=3069 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="dhclient" exe="/sbin/dhclient" subj=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 key=(null) -- Steve Croll From paul at city-fan.org Mon Sep 8 08:55:28 2008 From: paul at city-fan.org (Paul Howarth) Date: Mon, 08 Sep 2008 09:55:28 +0100 Subject: changes from fedora 7 to 9 In-Reply-To: References: <48C13FDC.9050008@redhat.com> <20080905183548.4c60ea6b@metropolis.intra.city-fan.org> Message-ID: <48C4E880.9020005@city-fan.org> Robert J. Carr wrote: > Thanks Paul! I put that label (httpd_sys_script_rw_t) on the trac.db > file itself (not using -R as you suggested) and it worked. > > So now for the whole teach a guy how to fish part. Is this a new > label for selinux in Fedora 9? In my other working environment in > Fedora 7 all files (including trac.db) are labeled with > httpd_sys_content_t. What's different? > > Is there some guide that tells you the labels you should be using for > specific types of httpd files? > > Thanks again for the help ... it is greatly appreciated. > > > On Fri, Sep 5, 2008 at 10:35 AM, Paul Howarth wrote: >> On Fri, 5 Sep 2008 09:16:11 -0700 >> "Robert J. Carr" wrote: >> >>> Thanks Paul and Daniel- >>> >>> I piped the logs through audit2why and here's what it is saying: >>> >>> ---- >>> >>> type=AVC msg=audit(1220631048.301:1541): avc: denied { write } for >>> pid=8572 comm="httpd" name="trac.db" dev=dm-0 ino=2148813854 >>> scontext=unconfined_u:system_r:httpd_t:s0 >>> tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=file >>> >>> Was caused by: >>> Missing type enforcement (TE) allow rule. >>> >>> You can use audit2allow to generate a loadable module to allow this >>> access. >>> >>> ---- >>> >>> As I said previously I know almost nothing about selinux, so if this >>> means anything help is appreciated, otherwise I'm going to see what I >>> can find out. >>> >>> Thanks for the guidance. As Dan suggested, "man httpd_selinux" lists the available context types for web applications that don't have their own specific types (bugzilla is an example of an app that has its own types). I find a reasonable rule of thumb is: * CGI scripts need to be httpd_script_exec_t * Files/directories that needs to be writeable by the apache user or group should be httpd_sys_script_rw_t * Everything else should be httpd_sys_content_t In your case, you may find that just setting the context of trac.db fixes the immediate problem but you may have issues e.g. with adding attachments to trac wiki pages, hence the suggestion to do all of /srv/www/trac Paul. From dwalsh at redhat.com Mon Sep 8 12:45:59 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 08 Sep 2008 08:45:59 -0400 Subject: SELinux kerneloops and dhclient issues In-Reply-To: <48C4516C.1080805@verizon.net> References: <48C4516C.1080805@verizon.net> Message-ID: <48C51E87.5040000@redhat.com> Stephen Croll wrote: > Note: Originally posted to fedora-list. > > The "setroubleshoot browser" is reporting the following issues on Fedora 9: > > SELinux is preventing kerneloops (kerneloops_t) "signal" to > (kerneloops_t). > SELinux is preventing dhclient (dhcpc_t) "read write" to socket > (unconfined_t). > > The first issue occurred on boot, but no longer seems to be happening. > The second > issue occurs when I bring up eth0. > > Should I file a bug report, or might there be something more sinister > going on? > > For reference, the complete reports are as follows: > > Summary: > > SELinux is preventing kerneloops (kerneloops_t) "signal" to > (kerneloops_t). > > Detailed Description: > > SELinux denied access requested by kerneloops. It is not expected that this > access is required by kerneloops 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 system_u:system_r:kerneloops_t:s0 > Target Context system_u:system_r:kerneloops_t:s0 > Target Objects None [ process ] > Source kerneloops > Source Path /usr/sbin/kerneloops > Port > Host gerbil > Source RPM Packages kerneloops-0.11-1.fc9 > Target RPM Packages Policy RPM > selinux-policy-3.3.1-84.fc9 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name catchall > Host Name gerbil > Platform Linux gerbil 2.6.25.14-108.fc9.x86_64 #1 > SMP Mon > Aug 4 13:46:35 EDT 2008 x86_64 x86_64 > Alert Count 2 > First Seen Sun 07 Sep 2008 03:21:55 AM CDT > Last Seen Sun 07 Sep 2008 03:21:55 AM CDT > Local ID fa4c1bd0-faf1-48ba-ba55-74285538ef90 > Line Numbers Raw Audit Messages > host=gerbil type=AVC msg=audit(1220775715.59:8): avc: denied { signal > } for pid=2363 comm="kerneloops" > scontext=system_u:system_r:kerneloops_t:s0 > tcontext=system_u:system_r:kerneloops_t:s0 tclass=process > > host=gerbil type=SYSCALL msg=audit(1220775715.59:8): arch=c000003e > syscall=234 success=no exit=-13 a0=93b a1=93b a2=6 a3=8 items=0 ppid=1 > pid=2363 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 tty=(none) ses=4294967295 comm="kerneloops" > exe="/usr/sbin/kerneloops" subj=system_u:system_r:kerneloops_t:s0 > key=(null) > > -and- > > Summary: > > SELinux is preventing dhclient (dhcpc_t) "read write" to socket > (unconfined_t). > > Detailed Description: > > SELinux denied access requested by dhclient. It is not expected that > this access > is required by dhclient 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 unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 > Target Context > unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 > 023 > Target Objects socket [ unix_stream_socket ] > Source dhclient > Source Path /sbin/dhclient > Port > Host gerbil > Source RPM Packages dhclient-4.0.0-14.fc9 > Target RPM Packages Policy RPM > selinux-policy-3.3.1-84.fc9 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name catchall > Host Name gerbil > Platform Linux gerbil 2.6.25.14-108.fc9.x86_64 #1 > SMP Mon > Aug 4 13:46:35 EDT 2008 x86_64 x86_64 > Alert Count 16 > First Seen Sun 07 Sep 2008 12:56:48 AM CDT > Last Seen Sun 07 Sep 2008 03:23:07 AM CDT > Local ID a3b5492a-0ef2-4cc3-bdd0-4c06696bae70 > Line Numbers Raw Audit Messages > host=gerbil type=AVC msg=audit(1220775787.407:21): avc: denied { read > write } for pid=3069 comm="dhclient" path="socket:[68728]" dev=sockfs > ino=68728 scontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 > tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > tclass=unix_stream_socket > > host=gerbil type=SYSCALL msg=audit(1220775787.407:21): arch=c000003e > syscall=59 success=yes exit=0 a0=948530 a1=94ad90 a2=8f0d70 > a3=3f48f67a70 items=0 ppid=2970 pid=3069 auid=500 uid=0 gid=0 euid=0 > suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="dhclient" > exe="/sbin/dhclient" subj=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 > key=(null) > kerneloops needing signal is a bug in selinux-policy. You can allow this for now. # audit2allow -M mypol -l -i /var/log/audit/audit.log # semodule -i mypol.pp Fixed in selinux-policy-3.3.1-89.fc9.noarch The dhcp_t (/sbin/dhclient) trying to read/write an unconfined_t unix_stream_socket, is a leaked file descriptor. So it is a bug in some application that you are using to bring up your network. What app are you using for this? From dwalsh at redhat.com Mon Sep 8 12:46:46 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 08 Sep 2008 08:46:46 -0400 Subject: rsync, xattrs, ntfs-3g and "selinux.selinux" In-Reply-To: <4c4ba1530809061117m2ba83e41m7f43065029830016@mail.gmail.com> References: <4c4ba1530808241420x70b65aafr9c206d8412fe4e97@mail.gmail.com> <48BEABFA.1080604@redhat.com> <1220457341.3862.295.camel@code.and.org> <4c4ba1530809061117m2ba83e41m7f43065029830016@mail.gmail.com> Message-ID: <48C51EB6.5070201@redhat.com> Tom London wrote: > On Wed, Sep 3, 2008 at 8:55 AM, James Antill wrote: >> On Wed, 2008-09-03 at 11:23 -0400, Daniel J Walsh wrote: >> >>> Looks like an rsync bug? >>> >>> James did you work on rsync? >> Nope, looking at the rpm changelog shows: >> >> >> * Mon Feb 19 2007 Simo Sorce - 2.6.9-2 >> - fix acl/xattr bug with --delete: (bz#229145) >> >> [...] >> >> * Fri Jun 09 2006 Jay Fenlason 2.6.8-3 >> - Add my xattrs_bug patch to fix a bug where xattrs don't get sent >> correctly. >> [...] >> >> * Mon May 08 2006 Jay Fenlason 2.6.8-2 >> - New upstream release >> - Use the upstream xattr patch instead of mine. This closes >> bz#190208 CVE-2006-2083 rsync buffer overflow issue >> >> [...] >> >> * Thu Feb 10 2005 Jay Fenlason 2.6.3-2 >> - Added my -xattr patch, which is based on the -acl patch. >> >> >> -- >> James Antill >> Red Hat >> > I looked into this a bit..... > > The upstream source for rsync-3.0.3 shows this in xattr.c: > <<<>>>> > static int rsync_xal_set(const char *fname, item_list *xalp, > const char *fnamecmp, stat_x *sxp) > { > <<<<>>>> > /* Remove any extraneous names. */ > for (name = namebuf; list_len > 0; name += name_len) { > name_len = strlen(name) + 1; > list_len -= name_len; > > #ifdef HAVE_LINUX_XATTRS > /* We always ignore the system namespace, and non-root > * ignores everything but the user namespace. */ > if (am_root ? HAS_PREFIX(name, SYSTEM_PREFIX) > : !HAS_PREFIX(name, USER_PREFIX)) > continue; > #endif > > I think this says: if running as root, don't remove attributes in the > system namespace (but remove everything else); if running as non-root, > remove all attributes but those in the user namespace. > > If so, when running as root, the code will attempt to remove > attributes from the security namespace (e.g., 'security.selinux'). > > In my case, I'm rsync-ing to an ext4 fs that supports SELinux > labels/etc., but copying from an NTFS-3g fs (mounted as /mnt/XXXXX) > that shows fusefs_t as labels. "getfattr" on files in these mounted > filesystems fail: > > [root at tlondon ~]# getfattr /mnt/music > getfattr: /mnt/music: Operation not supported > [root at tlondon ~]# > > My (first?) guess is that rsync is trying to remove the security > attributes from target files to match the source file attributes > (none). > > Is this logic wrong? Should rsync try to remove the security (e.g., > selinux) attributes from the target? > > It would be straightforward to patch the above code to 'continue' on > both system and security attributes. Something like: > > --- xattrs.c 2008-09-06 11:12:50.000000000 -0700 > +++ xattrs.c.orig 2008-09-06 11:09:08.000000000 -0700 > @@ -818,10 +818,9 @@ > list_len -= name_len; > > #ifdef HAVE_LINUX_XATTRS > - /* We always ignore the system and security namespaces, > - * and non-root ignores everything but the user namespace. */ > - if (am_root ? ( HAS_PREFIX(name, SYSTEM_PREFIX) > - || HAS_PREFIX(name, SECURITY_PREFIX) ) > + /* We always ignore the system namespace, and non-root > + * ignores everything but the user namespace. */ > + if (am_root ? HAS_PREFIX(name, SYSTEM_PREFIX) > : !HAS_PREFIX(name, USER_PREFIX)) > continue; > #endif > > But is this the right way to handle attributes in the security > namespace? What about "Trusted extended attributes"? > > If the above is "the right way", I can create a working patch and test. > > If not, I could use some "enlightenment"..... ;) > > tom We should bring this conversation into a bugzilla. Maybe discuss on main selinux list also. From selinux at gmail.com Mon Sep 8 14:24:07 2008 From: selinux at gmail.com (Tom London) Date: Mon, 8 Sep 2008 07:24:07 -0700 Subject: rsync, xattrs, ntfs-3g and "selinux.selinux" In-Reply-To: <48C51EB6.5070201@redhat.com> References: <4c4ba1530808241420x70b65aafr9c206d8412fe4e97@mail.gmail.com> <48BEABFA.1080604@redhat.com> <1220457341.3862.295.camel@code.and.org> <4c4ba1530809061117m2ba83e41m7f43065029830016@mail.gmail.com> <48C51EB6.5070201@redhat.com> Message-ID: <4c4ba1530809080724m3070c913n33986e8b619ec409@mail.gmail.com> On Mon, Sep 8, 2008 at 5:46 AM, Daniel J Walsh wrote: > Tom London wrote: >> On Wed, Sep 3, 2008 at 8:55 AM, James Antill wrote: >>> On Wed, 2008-09-03 at 11:23 -0400, Daniel J Walsh wrote: >>> >>>> Looks like an rsync bug? >>>> >>>> James did you work on rsync? >>> Nope, looking at the rpm changelog shows: >>> >>> >>> * Mon Feb 19 2007 Simo Sorce - 2.6.9-2 >>> - fix acl/xattr bug with --delete: (bz#229145) >>> >>> [...] >>> >>> * Fri Jun 09 2006 Jay Fenlason 2.6.8-3 >>> - Add my xattrs_bug patch to fix a bug where xattrs don't get sent >>> correctly. >>> [...] >>> >>> * Mon May 08 2006 Jay Fenlason 2.6.8-2 >>> - New upstream release >>> - Use the upstream xattr patch instead of mine. This closes >>> bz#190208 CVE-2006-2083 rsync buffer overflow issue >>> >>> [...] >>> >>> * Thu Feb 10 2005 Jay Fenlason 2.6.3-2 >>> - Added my -xattr patch, which is based on the -acl patch. >>> >>> >>> -- >>> James Antill >>> Red Hat >>> >> I looked into this a bit..... >> >> The upstream source for rsync-3.0.3 shows this in xattr.c: >> <<<>>>> >> static int rsync_xal_set(const char *fname, item_list *xalp, >> const char *fnamecmp, stat_x *sxp) >> { >> <<<<>>>> >> /* Remove any extraneous names. */ >> for (name = namebuf; list_len > 0; name += name_len) { >> name_len = strlen(name) + 1; >> list_len -= name_len; >> >> #ifdef HAVE_LINUX_XATTRS >> /* We always ignore the system namespace, and non-root >> * ignores everything but the user namespace. */ >> if (am_root ? HAS_PREFIX(name, SYSTEM_PREFIX) >> : !HAS_PREFIX(name, USER_PREFIX)) >> continue; >> #endif >> >> I think this says: if running as root, don't remove attributes in the >> system namespace (but remove everything else); if running as non-root, >> remove all attributes but those in the user namespace. >> >> If so, when running as root, the code will attempt to remove >> attributes from the security namespace (e.g., 'security.selinux'). >> >> In my case, I'm rsync-ing to an ext4 fs that supports SELinux >> labels/etc., but copying from an NTFS-3g fs (mounted as /mnt/XXXXX) >> that shows fusefs_t as labels. "getfattr" on files in these mounted >> filesystems fail: >> >> [root at tlondon ~]# getfattr /mnt/music >> getfattr: /mnt/music: Operation not supported >> [root at tlondon ~]# >> >> My (first?) guess is that rsync is trying to remove the security >> attributes from target files to match the source file attributes >> (none). >> >> Is this logic wrong? Should rsync try to remove the security (e.g., >> selinux) attributes from the target? >> >> It would be straightforward to patch the above code to 'continue' on >> both system and security attributes. Something like: >> >> --- xattrs.c 2008-09-06 11:12:50.000000000 -0700 >> +++ xattrs.c.orig 2008-09-06 11:09:08.000000000 -0700 >> @@ -818,10 +818,9 @@ >> list_len -= name_len; >> >> #ifdef HAVE_LINUX_XATTRS >> - /* We always ignore the system and security namespaces, >> - * and non-root ignores everything but the user namespace. */ >> - if (am_root ? ( HAS_PREFIX(name, SYSTEM_PREFIX) >> - || HAS_PREFIX(name, SECURITY_PREFIX) ) >> + /* We always ignore the system namespace, and non-root >> + * ignores everything but the user namespace. */ >> + if (am_root ? HAS_PREFIX(name, SYSTEM_PREFIX) >> : !HAS_PREFIX(name, USER_PREFIX)) >> continue; >> #endif >> >> But is this the right way to handle attributes in the security >> namespace? What about "Trusted extended attributes"? >> >> If the above is "the right way", I can create a working patch and test. >> >> If not, I could use some "enlightenment"..... ;) >> >> tom > We should bring this conversation into a bugzilla. Maybe discuss on > main selinux list also. > BZ'ed (Fedora) here: https://bugzilla.redhat.com/show_bug.cgi?id=461486 I'll post something on tycho list too.... tom -- Tom London From Richard.Johnson at stratus.com Mon Sep 8 22:23:05 2008 From: Richard.Johnson at stratus.com (Johnson, Richard) Date: Mon, 8 Sep 2008 18:23:05 -0400 Subject: Naive Qs about selinux modules Message-ID: Q: Can any SELinux directive be put into a policy smodule, or are there restrictions? For example: suppose I wanted to: allow snmpd_t apmd_t:process ptrace; allow snmpd_t auditd_t:process ptrace; allow snmpd_t automount_t:process ptrace; [ ...and so on ] so that snmpd could access mib .1.3.6.1.2.1.6. (advisability notwithstanding) Could these directives be put into a policy module even though the base policy already has an snmpd i/f? Q. Can a module define new booleans? If so are they persistent if the module is unloaded and reloaded? For example; an snmpd policy module with an snmpd_can_ptrace boolean. Are there namespace conventions? Q. What happens if the base policy (or another policy modules) is updated with overlapping statements. Am I correct in believing that the set of allows is the union of the base allows + all module allows? --rich -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdcroll at verizon.net Tue Sep 9 05:14:47 2008 From: sdcroll at verizon.net (Stephen Croll) Date: Tue, 09 Sep 2008 00:14:47 -0500 Subject: SELinux kerneloops and dhclient issues In-Reply-To: <48C51E87.5040000@redhat.com> References: <48C4516C.1080805@verizon.net> <48C51E87.5040000@redhat.com> Message-ID: <48C60647.4080300@verizon.net> Daniel J Walsh wrote: > The dhcp_t (/sbin/dhclient) trying to read/write an unconfined_t > unix_stream_socket, is a leaked file descriptor. So it is a bug in some > application that you are using to bring up your network. What app are > you using for this? > The following apps produce the issue: /sbin/ifup, /sbin/ifdown, and /sbin/dhclient. Sample usage: [root at gerbil ~]# /sbin/ifconfig lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:3776 errors:0 dropped:0 overruns:0 frame:0 TX packets:3776 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:188960 (184.5 KiB) TX bytes:188960 (184.5 KiB) [root at gerbil ~]# /sbin/ifup eth0 <---------------------- AVC Denial Determining IP information for eth0... done. [root at gerbil ~]# /sbin/ifconfig eth0 Link encap:Ethernet HWaddr 00:15:C5:3E:AC:A7 inet addr:192.168.2.4 Bcast:192.168.2.255 Mask:255.255.255.0 inet6 addr: fe80::215:c5ff:fe3e:aca7/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:15 errors:0 dropped:0 overruns:0 frame:0 TX packets:152 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3507 (3.4 KiB) TX bytes:34235 (33.4 KiB) Interrupt:17 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:3776 errors:0 dropped:0 overruns:0 frame:0 TX packets:3776 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:188960 (184.5 KiB) TX bytes:188960 (184.5 KiB) [root at gerbil ~]# /sbin/ifdown eth0 <---------------------- AVC Denial [root at gerbil ~]# /sbin/ifconfig lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:3776 errors:0 dropped:0 overruns:0 frame:0 TX packets:3776 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:188960 (184.5 KiB) TX bytes:188960 (184.5 KiB) [root at gerbil ~]# /sbin/ifconfig eth0 up [root at gerbil ~]# /sbin/ifconfig eth0 Link encap:Ethernet HWaddr 00:15:C5:3E:AC:A7 inet6 addr: fe80::215:c5ff:fe3e:aca7/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:16 errors:0 dropped:0 overruns:0 frame:0 TX packets:164 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3571 (3.4 KiB) TX bytes:36889 (36.0 KiB) Interrupt:17 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:3776 errors:0 dropped:0 overruns:0 frame:0 TX packets:3776 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:188960 (184.5 KiB) TX bytes:188960 (184.5 KiB) [root at gerbil ~]# /sbin/dhclient eth0 <---------------------- AVC Denial [root at gerbil ~]# /sbin/ifconfig eth0 Link encap:Ethernet HWaddr 00:15:C5:3E:AC:A7 inet addr:192.168.2.4 Bcast:192.168.2.255 Mask:255.255.255.0 inet6 addr: fe80::215:c5ff:fe3e:aca7/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:17 errors:0 dropped:0 overruns:0 frame:0 TX packets:182 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3918 (3.8 KiB) TX bytes:41608 (40.6 KiB) Interrupt:17 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:3776 errors:0 dropped:0 overruns:0 frame:0 TX packets:3776 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:188960 (184.5 KiB) TX bytes:188960 (184.5 KiB) -- Steve Croll From dwalsh at redhat.com Tue Sep 9 12:46:10 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 09 Sep 2008 08:46:10 -0400 Subject: Naive Qs about selinux modules In-Reply-To: References: Message-ID: <48C67012.8090001@redhat.com> Johnson, Richard wrote: > Q: Can any SELinux directive be put into a policy smodule, or are there > restrictions? > > > > For example: suppose I wanted to: > > allow snmpd_t apmd_t:process ptrace; > > allow snmpd_t auditd_t:process ptrace; > > allow snmpd_t automount_t:process ptrace; > > [ ...and so on ] > > > > so that snmpd could access mib .1.3.6.1.2.1.6. (advisability > notwithstanding) Could these directives be put into a policy module even > though the base policy already has an snmpd i/f? > Yes although watch out for name conflicts, IE Don't name your module the same as an existing module or you will replace it. BTW the interface domain_read_all_domains_state(snmpd_t) Is probably what you want. > > > Q. Can a module define new booleans? If so are they persistent if the > module is unloaded and reloaded? > Yes and the booleans will be removed if you unload the policy. > > > For example; an snmpd policy module with an snmpd_can_ptrace boolean. > Are there namespace conventions? > > Well we would prefer all booleans to be named with the name of the module. Although there are a lot of booleans that do not follow that standard. I would love to have aliasing for booleans so we could rename them. > > Q. What happens if the base policy (or another policy modules) is > updated with overlapping statements. > > They are additive. > > Am I correct in believing that the set of allows is the union of the > base allows + all module allows? > > Yes > > --rich > > > > > > > > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From dwalsh at redhat.com Tue Sep 9 12:49:08 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 09 Sep 2008 08:49:08 -0400 Subject: SELinux kerneloops and dhclient issues In-Reply-To: <48C60647.4080300@verizon.net> References: <48C4516C.1080805@verizon.net> <48C51E87.5040000@redhat.com> <48C60647.4080300@verizon.net> Message-ID: <48C670C4.9060109@redhat.com> Stephen Croll wrote: > Daniel J Walsh wrote: >> The dhcp_t (/sbin/dhclient) trying to read/write an unconfined_t >> unix_stream_socket, is a leaked file descriptor. So it is a bug in some >> application that you are using to bring up your network. What app are >> you using for this? >> > > The following apps produce the issue: /sbin/ifup, /sbin/ifdown, and > /sbin/dhclient. Sample usage: > > [root at gerbil ~]# /sbin/ifconfig > lo Link encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:3776 errors:0 dropped:0 overruns:0 frame:0 > TX packets:3776 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:188960 (184.5 KiB) TX bytes:188960 (184.5 KiB) > > [root at gerbil ~]# /sbin/ifup eth0 <---------------------- AVC Denial > > Determining IP information for eth0... done. > [root at gerbil ~]# /sbin/ifconfig > eth0 Link encap:Ethernet HWaddr 00:15:C5:3E:AC:A7 > inet addr:192.168.2.4 Bcast:192.168.2.255 Mask:255.255.255.0 > inet6 addr: fe80::215:c5ff:fe3e:aca7/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:15 errors:0 dropped:0 overruns:0 frame:0 > TX packets:152 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:3507 (3.4 KiB) TX bytes:34235 (33.4 KiB) > Interrupt:17 > > lo Link encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:3776 errors:0 dropped:0 overruns:0 frame:0 > TX packets:3776 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:188960 (184.5 KiB) TX bytes:188960 (184.5 KiB) > > [root at gerbil ~]# /sbin/ifdown eth0 <---------------------- AVC Denial > [root at gerbil ~]# /sbin/ifconfig > lo Link encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:3776 errors:0 dropped:0 overruns:0 frame:0 > TX packets:3776 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:188960 (184.5 KiB) TX bytes:188960 (184.5 KiB) > > [root at gerbil ~]# /sbin/ifconfig eth0 up > [root at gerbil ~]# /sbin/ifconfig > eth0 Link encap:Ethernet HWaddr 00:15:C5:3E:AC:A7 > inet6 addr: fe80::215:c5ff:fe3e:aca7/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:16 errors:0 dropped:0 overruns:0 frame:0 > TX packets:164 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:3571 (3.4 KiB) TX bytes:36889 (36.0 KiB) > Interrupt:17 > > lo Link encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:3776 errors:0 dropped:0 overruns:0 frame:0 > TX packets:3776 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:188960 (184.5 KiB) TX bytes:188960 (184.5 KiB) > > [root at gerbil ~]# /sbin/dhclient eth0 <---------------------- AVC Denial > [root at gerbil ~]# /sbin/ifconfig > eth0 Link encap:Ethernet HWaddr 00:15:C5:3E:AC:A7 > inet addr:192.168.2.4 Bcast:192.168.2.255 Mask:255.255.255.0 > inet6 addr: fe80::215:c5ff:fe3e:aca7/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:17 errors:0 dropped:0 overruns:0 frame:0 > TX packets:182 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:3918 (3.8 KiB) TX bytes:41608 (40.6 KiB) > Interrupt:17 > > lo Link encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:3776 errors:0 dropped:0 overruns:0 frame:0 > TX packets:3776 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:188960 (184.5 KiB) TX bytes:188960 (184.5 KiB) > -- > Steve Croll > So it looks like you already have a leaked file descriptor in the shell that you are running these commands from Does ls -lZ /proc/self/fd show anything stange? From dwalsh at redhat.com Tue Sep 9 13:11:29 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 09 Sep 2008 09:11:29 -0400 Subject: Naive Qs about selinux modules In-Reply-To: <48C67012.8090001@redhat.com> References: <48C67012.8090001@redhat.com> Message-ID: <48C67601.6060801@redhat.com> Daniel J Walsh wrote: > Johnson, Richard wrote: >> Q: Can any SELinux directive be put into a policy smodule, or are there >> restrictions? >> >> >> >> For example: suppose I wanted to: >> >> allow snmpd_t apmd_t:process ptrace; >> >> allow snmpd_t auditd_t:process ptrace; >> >> allow snmpd_t automount_t:process ptrace; >> >> [ ...and so on ] >> >> >> >> so that snmpd could access mib .1.3.6.1.2.1.6. (advisability >> notwithstanding) Could these directives be put into a policy module even >> though the base policy already has an snmpd i/f? >> > Yes although watch out for name conflicts, IE Don't name your module > the same as an existing module or you will replace it. > > BTW the interface > domain_read_all_domains_state(snmpd_t) > > Is probably what you want. >> >> >> Q. Can a module define new booleans? If so are they persistent if the >> module is unloaded and reloaded? >> > Yes and the booleans will be removed if you unload the policy. > >> >> >> For example; an snmpd policy module with an snmpd_can_ptrace boolean. >> Are there namespace conventions? >> >> > Well we would prefer all booleans to be named with the name of the > module. Although there are a lot of booleans that do not follow that > standard. I would love to have aliasing for booleans so we could rename > them. >> Q. What happens if the base policy (or another policy modules) is >> updated with overlapping statements. >> >> > They are additive. >> Am I correct in believing that the set of allows is the union of the >> base allows + all module allows? >> >> > Yes >> --rich >> >> >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Futher answered on http://danwalsh.livejournal.com/23710.html From Richard.Johnson at stratus.com Tue Sep 9 13:14:57 2008 From: Richard.Johnson at stratus.com (Johnson, Richard) Date: Tue, 9 Sep 2008 09:14:57 -0400 Subject: Naive Qs about selinux modules In-Reply-To: 48C67012.8090001@redhat.com References: 48C67012.8090001@redhat.com Message-ID: Daniel J Walsh wrote: Johnson, Richard wrote: >> Q: Can any SELinux directive be put into a policy smodule, or are there >> restrictions? >> >> >> >> For example: suppose I wanted to: >> >> allow snmpd_t apmd_t:process ptrace; >> allow snmpd_t auditd_t:process ptrace; >> allow snmpd_t automount_t:process ptrace; >> [ ...and so on ] >> >> so that snmpd could access mib .1.3.6.1.2.1.6. (advisability >> notwithstanding) Could these directives be put into a policy module even >> though the base policy already has an snmpd i/f? >> >Yes although watch out for name conflicts, IE Don't name your module >the same as an existing module or you will replace it. > >BTW the interface >domain_read_all_domains_state(snmpd_t) > >Is probably what you want. >> >> Q. Can a module define new booleans? If so are they persistent if the >> module is unloaded and reloaded? >> >Yes and the booleans will be removed if you unload the policy. > >> For example; an snmpd policy module with an snmpd_can_ptrace boolean. >> Are there namespace conventions? > >Well we would prefer all booleans to be named with the name of the >module. Although there are a lot of booleans that do not follow that >standard. I would love to have aliasing for booleans so we could rename >them. >> >> Q. What happens if the base policy (or another policy modules) is >> updated with overlapping statements. > >They are additive. >> >> Am I correct in believing that the set of allows is the union of the >> base allows + all module allows? > >Yes Thanks. And thanks for the hint about domain_read_all_domains_state(). From sdcroll at verizon.net Wed Sep 10 01:20:36 2008 From: sdcroll at verizon.net (Stephen Croll) Date: Tue, 09 Sep 2008 20:20:36 -0500 Subject: SELinux kerneloops and dhclient issues In-Reply-To: <48C670C4.9060109@redhat.com> References: <48C4516C.1080805@verizon.net> <48C51E87.5040000@redhat.com> <48C60647.4080300@verizon.net> <48C670C4.9060109@redhat.com> Message-ID: <48C720E4.2090407@verizon.net> Daniel J Walsh wrote: > So it looks like you already have a leaked file descriptor in the shell > that you are running these commands from > > Does ls -lZ /proc/self/fd show anything stange? Yes it does, fd 25: [root at gerbil ~]# ls -lZ /proc/self/fd lrwx------ root root unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 0 -> /dev/pts/0 lrwx------ root root unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 1 -> /dev/pts/0 lrwx------ root root unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 2 -> /dev/pts/0 lrwx------ root root unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 25 -> socket:[18571] lr-x------ root root unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 3 -> /proc/3446/fd It would appear fd 3 is what ls is using to read the entries in /proc/self/fd (also verified with strace): [root at gerbil ~]# ls -lZ /proc/self/fd & lrwx------ root root unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 0 -> /dev/pts/0 lrwx------ root root unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 1 -> /dev/pts/0 lrwx------ root root unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 2 -> /dev/pts/0 lrwx------ root root unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 25 -> socket:[18571] lr-x------ root root unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 3 -> /proc/3463/fd [1] 3463 [1]+ Done ls --color=auto -lZ /proc/self/fd I've been trying to figure out the mysteries of NetworkManager and mixing wired and wireless connections. I just noticed that if I don't have NetworkManager configured at boot, I don't get the AVC denial nor do I see the socket on fd 25. Additionally, I noticed that even if NetworkManager is configured at boot, I don't see the AVC denial/fd 25 issue when running in a virtual terminal. Upon further investigation, this issue only seems to occur when running KDE+konsole, but not KDE+gnome-terminal, nor GNOME+konsole, nor GNOME+gnome-terminal. Also, I don't see fd 25 when connecting remotely (over SSH) and running the above ls command. -- Steve Croll From kris_s at atmyhome.org Wed Sep 10 22:15:50 2008 From: kris_s at atmyhome.org (Kristen R) Date: Wed, 10 Sep 2008 14:15:50 -0800 Subject: Help with AVC messages Message-ID: <200809101415.51091.kris_s@atmyhome.org> Last night I had a users website hacked. The hacker then tried to use httpd to access /etc files and directorys, as well as the root directory. SELinux saved my system. I need to make a complaint to the ISP who is providing for this offender. I have http access logs and error logs but they don't show very much. Other then access which was valid (well, not valid) and 2 entries in the error log. Is there a way I can correlate the AVC denials with the malious attacker? The AVC messages do not have time stamps or IP addresses attached to them. Thank you for your assistance, and for SELinux! Kristen From cra at WPI.EDU Wed Sep 10 22:31:08 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 10 Sep 2008 18:31:08 -0400 Subject: Help with AVC messages In-Reply-To: <200809101415.51091.kris_s@atmyhome.org> References: <200809101415.51091.kris_s@atmyhome.org> Message-ID: <20080910223108.GB15457@angus.ind.WPI.EDU> On Wed, Sep 10, 2008 at 02:15:50PM -0800, Kristen R wrote: > Last night I had a users website hacked. The hacker then tried to use httpd to > access /etc files and directorys, as well as the root directory. SELinux > saved my system. Excellent! > I need to make a complaint to the ISP who is providing for this offender. I > have http access logs and error logs but they don't show very much. Other > then access which was valid (well, not valid) and 2 entries in the error log. > Is there a way I can correlate the AVC denials with the malious attacker? The > AVC messages do not have time stamps or IP addresses attached to them. There are timestamps on the AVCs, but they are encoded as time-since-UNIX-epoch in seconds. You can convert them to human readble and also narrow down the results with ausearch. All results, human readable: ausearch -i Other options are documented in ausearch(8) From jmorris at namei.org Wed Sep 10 23:31:42 2008 From: jmorris at namei.org (James Morris) Date: Thu, 11 Sep 2008 09:31:42 +1000 (EST) Subject: Help with AVC messages In-Reply-To: <200809101415.51091.kris_s@atmyhome.org> References: <200809101415.51091.kris_s@atmyhome.org> Message-ID: On Wed, 10 Sep 2008, Kristen R wrote: > Last night I had a users website hacked. The hacker then tried to use httpd to > access /etc files and directorys, as well as the root directory. SELinux > saved my system. > > I need to make a complaint to the ISP who is providing for this offender. I > have http access logs and error logs but they don't show very much. Other > then access which was valid (well, not valid) and 2 entries in the error log. > Is there a way I can correlate the AVC denials with the malious attacker? The > AVC messages do not have time stamps or IP addresses attached to them. > > Thank you for your assistance, and for SELinux! You should be able to find more detailed information in the audit log. Try "ausearch -x httpd" Any idea how they attacked the web server? - James -- James Morris From rom at twister.dyndns.org Wed Sep 10 23:47:22 2008 From: rom at twister.dyndns.org (Fred Wittekind) Date: Wed, 10 Sep 2008 19:47:22 -0400 Subject: Need some help with a new policy module Message-ID: <48C85C8A.8070008@twister.dyndns.org> I'm trying to write a new policy for PvPGN. When I try to start the service via the init script I get: Starting PvPGN game server: /usr/sbin/bnetd: error while loading shared libraries: libm.so.6: cannot open shared object file: Permission denied [FAILED] And: host=twister.dragon type=AVC msg=audit(1221090145.148:30403): avc: denied { search } for pid=3526 comm="bnetd" name="usr" dev=dm-0 ino=3284993 scontext=unconfined_u:system_r:pvpgn_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=dir host=twister.dragon type=SYSCALL msg=audit(1221090145.148:30403): arch=40000003 syscall=195 success=no exit=-13 a0=bfaad190 a1=bfaad1f0 a2=ca3fc0 a3=8 items=0 ppid=3525 pid=3526 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=151 comm="bnetd" exe="/usr/sbin/bnetd" subj=unconfined_u:system_r:pvpgn_t:s0 key=(null) Policy RPM selinux-policy-3.3.1-84.fc9 If I run the service from the command line without the init script, it works. I'm sure I'm missing something stuipid, just can't figure out what it is. Can't figure out why it works without the initscript, and throws selinux errors when run from the init script. Thanks in advance for any help. Fred Wittekind IV -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pvpgn.fc URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pvpgn.te URL: From paul at city-fan.org Thu Sep 11 06:09:53 2008 From: paul at city-fan.org (Paul Howarth) Date: Thu, 11 Sep 2008 07:09:53 +0100 Subject: Need some help with a new policy module In-Reply-To: <48C85C8A.8070008@twister.dyndns.org> References: <48C85C8A.8070008@twister.dyndns.org> Message-ID: <20080911070953.2adb47bb@metropolis.intra.city-fan.org> On Wed, 10 Sep 2008 19:47:22 -0400 Fred Wittekind wrote: > I'm trying to write a new policy for PvPGN. > > When I try to start the service via the init script I get: > Starting PvPGN game server: /usr/sbin/bnetd: error while loading > shared libraries: libm.so.6: cannot open shared object file: > Permission denied [FAILED] > > And: > host=twister.dragon type=AVC msg=audit(1221090145.148:30403): avc: > denied { search } for pid=3526 comm="bnetd" name="usr" dev=dm-0 > ino=3284993 scontext=unconfined_u:system_r:pvpgn_t:s0 > tcontext=system_u:object_r:usr_t:s0 tclass=dir > > host=twister.dragon type=SYSCALL msg=audit(1221090145.148:30403): > arch=40000003 syscall=195 success=no exit=-13 a0=bfaad190 a1=bfaad1f0 > a2=ca3fc0 a3=8 items=0 ppid=3525 pid=3526 auid=500 uid=0 gid=0 euid=0 > suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=151 comm="bnetd" > exe="/usr/sbin/bnetd" subj=unconfined_u:system_r:pvpgn_t:s0 key=(null) Add to your policy: libs_use_shared_libs(pvpgn_t) > Policy RPM selinux-policy-3.3.1-84.fc9 > > > If I run the service from the command line without the init script, > it works. I'm sure I'm missing something stuipid, just can't figure > out what it is. Can't figure out why it works without the > initscript, and throws selinux errors when run from the init script. When you run the service directly from the command line, it doesn't transition to pvpgn_t, running unconfined instead, hence no SELinux issues. Paul. From dwalsh at redhat.com Thu Sep 11 12:57:34 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 11 Sep 2008 08:57:34 -0400 Subject: Need some help with a new policy module In-Reply-To: <48C85C8A.8070008@twister.dyndns.org> References: <48C85C8A.8070008@twister.dyndns.org> Message-ID: <48C915BE.9030705@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fred Wittekind wrote: > I'm trying to write a new policy for PvPGN. > > When I try to start the service via the init script I get: > Starting PvPGN game server: /usr/sbin/bnetd: error while loading shared > libraries: libm.so.6: cannot open shared object file: Permission denied > [FAILED] > > And: > host=twister.dragon type=AVC msg=audit(1221090145.148:30403): avc: > denied { search } for pid=3526 comm="bnetd" name="usr" dev=dm-0 > ino=3284993 scontext=unconfined_u:system_r:pvpgn_t:s0 > tcontext=system_u:object_r:usr_t:s0 tclass=dir > > host=twister.dragon type=SYSCALL msg=audit(1221090145.148:30403): > arch=40000003 syscall=195 success=no exit=-13 a0=bfaad190 a1=bfaad1f0 > a2=ca3fc0 a3=8 items=0 ppid=3525 pid=3526 auid=500 uid=0 gid=0 euid=0 > suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=151 comm="bnetd" > exe="/usr/sbin/bnetd" subj=unconfined_u:system_r:pvpgn_t:s0 key=(null) > > Policy RPM selinux-policy-3.3.1-84.fc9 > > > If I run the service from the command line without the init script, it > works. I'm sure I'm missing something stuipid, just can't figure out > what it is. Can't figure out why it works without the initscript, and > throws selinux errors when run from the init script. > > Thanks in advance for any help. > > Fred Wittekind IV > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Fred if you use policy_module(pvpgn, 1.0.0) You will get all of the gen_require stuff for free. corenet_udp_bind_generic_port(pvpgn_t) corenet_tcp_bind_generic_port(pvpgn_t) You really should define a port and then allow pvpgn bind to the specific port. (Unless pvpgn binds to random ports?) If this is on Fedora 10 you might want to add permissive pvpgn_t; Which will allow the daemon to run in permissive mode while you are testing. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjJFb4ACgkQrlYvE4MpobP73gCdF0SzLu6vwQKvlxlzZpisGmcp uS0An3qN7yVmjTrhtaKxytQKICcP9oQQ =dg/y -----END PGP SIGNATURE----- From rom at twister.dyndns.org Thu Sep 11 13:06:53 2008 From: rom at twister.dyndns.org (Fred Wittekind) Date: Thu, 11 Sep 2008 09:06:53 -0400 Subject: Need some help with a new policy module In-Reply-To: <20080911070953.2adb47bb@metropolis.intra.city-fan.org> References: <48C85C8A.8070008@twister.dyndns.org> <20080911070953.2adb47bb@metropolis.intra.city-fan.org> Message-ID: <48C917ED.6050407@twister.dyndns.org> Paul Howarth wrote: > On Wed, 10 Sep 2008 19:47:22 -0400 > Fred Wittekind wrote: > > >> I'm trying to write a new policy for PvPGN. >> >> When I try to start the service via the init script I get: >> Starting PvPGN game server: /usr/sbin/bnetd: error while loading >> shared libraries: libm.so.6: cannot open shared object file: >> Permission denied [FAILED] >> >> And: >> host=twister.dragon type=AVC msg=audit(1221090145.148:30403): avc: >> denied { search } for pid=3526 comm="bnetd" name="usr" dev=dm-0 >> ino=3284993 scontext=unconfined_u:system_r:pvpgn_t:s0 >> tcontext=system_u:object_r:usr_t:s0 tclass=dir >> >> host=twister.dragon type=SYSCALL msg=audit(1221090145.148:30403): >> arch=40000003 syscall=195 success=no exit=-13 a0=bfaad190 a1=bfaad1f0 >> a2=ca3fc0 a3=8 items=0 ppid=3525 pid=3526 auid=500 uid=0 gid=0 euid=0 >> suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=151 comm="bnetd" >> exe="/usr/sbin/bnetd" subj=unconfined_u:system_r:pvpgn_t:s0 key=(null) >> > > Add to your policy: > > libs_use_shared_libs(pvpgn_t) > Thanks, that got me pointed in the right direction, I was sure there was a simple way to do it, I just wasn't seeing it. > >> Policy RPM selinux-policy-3.3.1-84.fc9 >> >> >> If I run the service from the command line without the init script, >> it works. I'm sure I'm missing something stuipid, just can't figure >> out what it is. Can't figure out why it works without the >> initscript, and throws selinux errors when run from the init script. >> > > When you run the service directly from the command line, it doesn't > transition to pvpgn_t, running unconfined instead, hence no SELinux > issues. > That explains it. Just because I like to know how things work, what makes the initscript different? Is it something in the policy, or something in the functions file? > Paul. > > From rom at twister.dyndns.org Thu Sep 11 13:17:00 2008 From: rom at twister.dyndns.org (Fred Wittekind) Date: Thu, 11 Sep 2008 09:17:00 -0400 Subject: Need some help with a new policy module In-Reply-To: <48C915BE.9030705@redhat.com> References: <48C85C8A.8070008@twister.dyndns.org> <48C915BE.9030705@redhat.com> Message-ID: <48C91A4C.5060802@twister.dyndns.org> Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Fred Wittekind wrote: > >> I'm trying to write a new policy for PvPGN. >> >> When I try to start the service via the init script I get: >> Starting PvPGN game server: /usr/sbin/bnetd: error while loading shared >> libraries: libm.so.6: cannot open shared object file: Permission denied >> [FAILED] >> >> And: >> host=twister.dragon type=AVC msg=audit(1221090145.148:30403): avc: >> denied { search } for pid=3526 comm="bnetd" name="usr" dev=dm-0 >> ino=3284993 scontext=unconfined_u:system_r:pvpgn_t:s0 >> tcontext=system_u:object_r:usr_t:s0 tclass=dir >> >> host=twister.dragon type=SYSCALL msg=audit(1221090145.148:30403): >> arch=40000003 syscall=195 success=no exit=-13 a0=bfaad190 a1=bfaad1f0 >> a2=ca3fc0 a3=8 items=0 ppid=3525 pid=3526 auid=500 uid=0 gid=0 euid=0 >> suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=151 comm="bnetd" >> exe="/usr/sbin/bnetd" subj=unconfined_u:system_r:pvpgn_t:s0 key=(null) >> >> Policy RPM selinux-policy-3.3.1-84.fc9 >> >> >> If I run the service from the command line without the init script, it >> works. I'm sure I'm missing something stuipid, just can't figure out >> what it is. Can't figure out why it works without the initscript, and >> throws selinux errors when run from the init script. >> >> Thanks in advance for any help. >> >> Fred Wittekind IV >> >> >> ------------------------------------------------------------------------ >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> > > Fred if you use policy_module(pvpgn, 1.0.0) > You will get all of the gen_require stuff for free. > Quite helpful, thanks. > corenet_udp_bind_generic_port(pvpgn_t) > corenet_tcp_bind_generic_port(pvpgn_t) > > You really should define a port and then allow pvpgn bind to the > specific port. (Unless pvpgn binds to random ports?) > Wanted to, but couldn't quite figure out how to define a specific port. Using source rpm for policy as a reference, but, it appears to use macros for all the ports it needs. > If this is on Fedora 10 you might want to add > > permissive pvpgn_t; > > Which will allow the daemon to run in permissive mode while you are testing. > It's Fedora 9, thanks though. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkjJFb4ACgkQrlYvE4MpobP73gCdF0SzLu6vwQKvlxlzZpisGmcp > uS0An3qN7yVmjTrhtaKxytQKICcP9oQQ > =dg/y > -----END PGP SIGNATURE----- > > From dwalsh at redhat.com Thu Sep 11 13:42:54 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 11 Sep 2008 09:42:54 -0400 Subject: Need some help with a new policy module In-Reply-To: <48C91A4C.5060802@twister.dyndns.org> References: <48C85C8A.8070008@twister.dyndns.org> <48C915BE.9030705@redhat.com> <48C91A4C.5060802@twister.dyndns.org> Message-ID: <48C9205E.9000503@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fred Wittekind wrote: > Daniel J Walsh wrote: > Fred Wittekind wrote: > >>>> I'm trying to write a new policy for PvPGN. >>>> >>>> When I try to start the service via the init script I get: >>>> Starting PvPGN game server: /usr/sbin/bnetd: error while loading shared >>>> libraries: libm.so.6: cannot open shared object file: Permission denied >>>> [FAILED] >>>> >>>> And: >>>> host=twister.dragon type=AVC msg=audit(1221090145.148:30403): avc: >>>> denied { search } for pid=3526 comm="bnetd" name="usr" dev=dm-0 >>>> ino=3284993 scontext=unconfined_u:system_r:pvpgn_t:s0 >>>> tcontext=system_u:object_r:usr_t:s0 tclass=dir >>>> >>>> host=twister.dragon type=SYSCALL msg=audit(1221090145.148:30403): >>>> arch=40000003 syscall=195 success=no exit=-13 a0=bfaad190 a1=bfaad1f0 >>>> a2=ca3fc0 a3=8 items=0 ppid=3525 pid=3526 auid=500 uid=0 gid=0 euid=0 >>>> suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=151 comm="bnetd" >>>> exe="/usr/sbin/bnetd" subj=unconfined_u:system_r:pvpgn_t:s0 key=(null) >>>> >>>> Policy RPM selinux-policy-3.3.1-84.fc9 >>>> >>>> >>>> If I run the service from the command line without the init script, it >>>> works. I'm sure I'm missing something stuipid, just can't figure out >>>> what it is. Can't figure out why it works without the initscript, and >>>> throws selinux errors when run from the init script. >>>> >>>> Thanks in advance for any help. >>>> >>>> Fred Wittekind IV >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> -- >>>> fedora-selinux-list mailing list >>>> fedora-selinux-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>>> > > Fred if you use policy_module(pvpgn, 1.0.0) > You will get all of the gen_require stuff for free. > >> Quite helpful, thanks. > corenet_udp_bind_generic_port(pvpgn_t) > corenet_tcp_bind_generic_port(pvpgn_t) > type pvpgn_port_t; ports_type(pvpgn_port_t) allow pvpgn_t pbpgn_port_t:tcp_socket name_bind; allow pvpgn_t pbpgn_port_t:udp_socket name_bind; Then you need to add the ports definition using semanage port -a -t pvpgn_port_t -Ptcp PORTNUM > You really should define a port and then allow pvpgn bind to the > specific port. (Unless pvpgn binds to random ports?) > >> Wanted to, but couldn't quite figure out how to define a specific port. >> Using source rpm for policy as a reference, but, it appears to use >> macros for all the ports it needs. > If this is on Fedora 10 you might want to add > > permissive pvpgn_t; > > Which will allow the daemon to run in permissive mode while you are > testing. > >> It's Fedora 9, thanks though. >> Well that should show up in Fedora 9 whenever they move to the kernel-2.6.27 kernel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjJIF4ACgkQrlYvE4MpobOXcACg5nX3J9InfRUZ+bWK3ECMqkBw l6QAn2JO8BOwXMzxLE570FxoqT7B5k10 =Sedm -----END PGP SIGNATURE----- From dwalsh at redhat.com Thu Sep 11 13:54:35 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 11 Sep 2008 09:54:35 -0400 Subject: Need some help with a new policy module In-Reply-To: <48C917ED.6050407@twister.dyndns.org> References: <48C85C8A.8070008@twister.dyndns.org> <20080911070953.2adb47bb@metropolis.intra.city-fan.org> <48C917ED.6050407@twister.dyndns.org> Message-ID: <48C9231B.9010601@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fred Wittekind wrote: > Paul Howarth wrote: >> On Wed, 10 Sep 2008 19:47:22 -0400 >> Fred Wittekind wrote: >> >> >>> I'm trying to write a new policy for PvPGN. >>> >>> When I try to start the service via the init script I get: >>> Starting PvPGN game server: /usr/sbin/bnetd: error while loading >>> shared libraries: libm.so.6: cannot open shared object file: >>> Permission denied [FAILED] >>> >>> And: >>> host=twister.dragon type=AVC msg=audit(1221090145.148:30403): avc: >>> denied { search } for pid=3526 comm="bnetd" name="usr" dev=dm-0 >>> ino=3284993 scontext=unconfined_u:system_r:pvpgn_t:s0 >>> tcontext=system_u:object_r:usr_t:s0 tclass=dir >>> >>> host=twister.dragon type=SYSCALL msg=audit(1221090145.148:30403): >>> arch=40000003 syscall=195 success=no exit=-13 a0=bfaad190 a1=bfaad1f0 >>> a2=ca3fc0 a3=8 items=0 ppid=3525 pid=3526 auid=500 uid=0 gid=0 euid=0 >>> suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=151 comm="bnetd" >>> exe="/usr/sbin/bnetd" subj=unconfined_u:system_r:pvpgn_t:s0 key=(null) >>> >> >> Add to your policy: >> >> libs_use_shared_libs(pvpgn_t) >> > Thanks, that got me pointed in the right direction, I was sure there was > a simple way to do it, I just wasn't seeing it. >> >>> Policy RPM selinux-policy-3.3.1-84.fc9 >>> >>> >>> If I run the service from the command line without the init script, >>> it works. I'm sure I'm missing something stuipid, just can't figure >>> out what it is. Can't figure out why it works without the >>> initscript, and throws selinux errors when run from the init script. >>> >> >> When you run the service directly from the command line, it doesn't >> transition to pvpgn_t, running unconfined instead, hence no SELinux >> issues. >> > That explains it. Just because I like to know how things work, what > makes the initscript different? Is it something in the policy, or > something in the functions file? >> Paul. >> >> > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list The interface init_daemon_domain(pvpgn_t, pvpgn_exec_t) Defines a transition rule that says Init Scripts executing apps labeled pvbpgn_exec_t should transition to pvpgn_t. initrc_t -> pvpgn_exec_t -> pvpgn_t If an unconfined_t user executes these same applications it will stay in the context of the user account, since there is no transition defined for unconfined_t -> pvpgn_exec_t -> pvpgn_t. I don't want to have that many transitions from the unconfined user, since this would tend to surprise the user. We tell the user SELinux will not blocked unconfined users and then they run one app and suddenly it is confined. One transition that for the unconfined user is over init scripts. unconfined_t -> initrc_exec_t -> initrc_t All scripts in /etc/init.d/ are defined with an initscript context (initrc_exec_t) and allow this transition. So an unconfined user executing system pvpvn restart would execute the init script and the init script would finally start pvpvn running in the correct context. unconfined_t -> initrc_exec_t -> initrc_t -> pvpgn_exec_t -> pvpgn_t -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjJIxsACgkQrlYvE4MpobMAKwCbBPVT+Lo+05t7WL1uCgcxdnEt wrcAnAjZmiFbdW6SUHEBHN8AmK9Tv3Vi =GN3X -----END PGP SIGNATURE----- From rom at twister.dyndns.org Thu Sep 11 13:57:15 2008 From: rom at twister.dyndns.org (Fred Wittekind) Date: Thu, 11 Sep 2008 09:57:15 -0400 Subject: Need some help with a new policy module In-Reply-To: <48C9205E.9000503@redhat.com> References: <48C85C8A.8070008@twister.dyndns.org> <48C915BE.9030705@redhat.com> <48C91A4C.5060802@twister.dyndns.org> <48C9205E.9000503@redhat.com> Message-ID: <48C923BB.9030105@twister.dyndns.org> Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Fred Wittekind wrote: > >> Daniel J Walsh wrote: >> Fred Wittekind wrote: >> >> >>>>> I'm trying to write a new policy for PvPGN. >>>>> >>>>> When I try to start the service via the init script I get: >>>>> Starting PvPGN game server: /usr/sbin/bnetd: error while loading shared >>>>> libraries: libm.so.6: cannot open shared object file: Permission denied >>>>> [FAILED] >>>>> >>>>> And: >>>>> host=twister.dragon type=AVC msg=audit(1221090145.148:30403): avc: >>>>> denied { search } for pid=3526 comm="bnetd" name="usr" dev=dm-0 >>>>> ino=3284993 scontext=unconfined_u:system_r:pvpgn_t:s0 >>>>> tcontext=system_u:object_r:usr_t:s0 tclass=dir >>>>> >>>>> host=twister.dragon type=SYSCALL msg=audit(1221090145.148:30403): >>>>> arch=40000003 syscall=195 success=no exit=-13 a0=bfaad190 a1=bfaad1f0 >>>>> a2=ca3fc0 a3=8 items=0 ppid=3525 pid=3526 auid=500 uid=0 gid=0 euid=0 >>>>> suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=151 comm="bnetd" >>>>> exe="/usr/sbin/bnetd" subj=unconfined_u:system_r:pvpgn_t:s0 key=(null) >>>>> >>>>> Policy RPM selinux-policy-3.3.1-84.fc9 >>>>> >>>>> >>>>> If I run the service from the command line without the init script, it >>>>> works. I'm sure I'm missing something stuipid, just can't figure out >>>>> what it is. Can't figure out why it works without the initscript, and >>>>> throws selinux errors when run from the init script. >>>>> >>>>> Thanks in advance for any help. >>>>> >>>>> Fred Wittekind IV >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> -- >>>>> fedora-selinux-list mailing list >>>>> fedora-selinux-list at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>>>> >>>>> >> Fred if you use policy_module(pvpgn, 1.0.0) >> You will get all of the gen_require stuff for free. >> >> >>> Quite helpful, thanks. >>> >> corenet_udp_bind_generic_port(pvpgn_t) >> corenet_tcp_bind_generic_port(pvpgn_t) >> >> > type pvpgn_port_t; > ports_type(pvpgn_port_t) > > allow pvpgn_t pbpgn_port_t:tcp_socket name_bind; > allow pvpgn_t pbpgn_port_t:udp_socket name_bind; > > Then you need to add the ports definition using > semanage port -a -t pvpgn_port_t -Ptcp PORTNUM > Assuming this policy files is going to be included into a rpm I'm making for pvpgn, what's best practice for handling adding the port numbers. Add semanage statements for the port numbers to the %post section? Or is there a way to encode the port numbers into the policy file? > >> You really should define a port and then allow pvpgn bind to the >> specific port. (Unless pvpgn binds to random ports?) >> >> >>> Wanted to, but couldn't quite figure out how to define a specific port. >>> Using source rpm for policy as a reference, but, it appears to use >>> macros for all the ports it needs. >>> >> If this is on Fedora 10 you might want to add >> >> permissive pvpgn_t; >> >> Which will allow the daemon to run in permissive mode while you are >> testing. >> >> >>> It's Fedora 9, thanks though. >>> >>> > Well that should show up in Fedora 9 whenever they move to the > kernel-2.6.27 kernel > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkjJIF4ACgkQrlYvE4MpobOXcACg5nX3J9InfRUZ+bWK3ECMqkBw > l6QAn2JO8BOwXMzxLE570FxoqT7B5k10 > =Sedm > -----END PGP SIGNATURE----- > > From dwalsh at redhat.com Thu Sep 11 14:50:28 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 11 Sep 2008 10:50:28 -0400 Subject: Need some help with a new policy module In-Reply-To: <48C923BB.9030105@twister.dyndns.org> References: <48C85C8A.8070008@twister.dyndns.org> <48C915BE.9030705@redhat.com> <48C91A4C.5060802@twister.dyndns.org> <48C9205E.9000503@redhat.com> <48C923BB.9030105@twister.dyndns.org> Message-ID: <48C93034.7000709@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fred Wittekind wrote: > Daniel J Walsh wrote: > Fred Wittekind wrote: > >>>> Daniel J Walsh wrote: >>>> Fred Wittekind wrote: >>>> >>>> >>>>>>> I'm trying to write a new policy for PvPGN. >>>>>>> >>>>>>> When I try to start the service via the init script I get: >>>>>>> Starting PvPGN game server: /usr/sbin/bnetd: error while loading >>>>>>> shared >>>>>>> libraries: libm.so.6: cannot open shared object file: Permission >>>>>>> denied >>>>>>> [FAILED] >>>>>>> >>>>>>> And: >>>>>>> host=twister.dragon type=AVC msg=audit(1221090145.148:30403): avc: >>>>>>> denied { search } for pid=3526 comm="bnetd" name="usr" dev=dm-0 >>>>>>> ino=3284993 scontext=unconfined_u:system_r:pvpgn_t:s0 >>>>>>> tcontext=system_u:object_r:usr_t:s0 tclass=dir >>>>>>> >>>>>>> host=twister.dragon type=SYSCALL msg=audit(1221090145.148:30403): >>>>>>> arch=40000003 syscall=195 success=no exit=-13 a0=bfaad190 a1=bfaad1f0 >>>>>>> a2=ca3fc0 a3=8 items=0 ppid=3525 pid=3526 auid=500 uid=0 gid=0 euid=0 >>>>>>> suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=151 comm="bnetd" >>>>>>> exe="/usr/sbin/bnetd" subj=unconfined_u:system_r:pvpgn_t:s0 >>>>>>> key=(null) >>>>>>> >>>>>>> Policy RPM selinux-policy-3.3.1-84.fc9 >>>>>>> >>>>>>> >>>>>>> If I run the service from the command line without the init >>>>>>> script, it >>>>>>> works. I'm sure I'm missing something stuipid, just can't figure out >>>>>>> what it is. Can't figure out why it works without the initscript, >>>>>>> and >>>>>>> throws selinux errors when run from the init script. >>>>>>> >>>>>>> Thanks in advance for any help. >>>>>>> >>>>>>> Fred Wittekind IV >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> fedora-selinux-list mailing list >>>>>>> fedora-selinux-list at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>>>>>> >>>> Fred if you use policy_module(pvpgn, 1.0.0) >>>> You will get all of the gen_require stuff for free. >>>> >>>>> Quite helpful, thanks. >>>>> >>>> corenet_udp_bind_generic_port(pvpgn_t) >>>> corenet_tcp_bind_generic_port(pvpgn_t) >>>> >>>> > type pvpgn_port_t; > ports_type(pvpgn_port_t) > > allow pvpgn_t pbpgn_port_t:tcp_socket name_bind; > allow pvpgn_t pbpgn_port_t:udp_socket name_bind; > > Then you need to add the ports definition using > semanage port -a -t pvpgn_port_t -Ptcp PORTNUM > >> Assuming this policy files is going to be included into a rpm I'm making >> for pvpgn, what's best practice for handling adding the port numbers. >> Add semanage statements for the port numbers to the %post section? Or >> is there a way to encode the port numbers into the policy file? > Yes I would execute the something like the following in your post # semodule -i pvpgn.pp # restorecon -R -v PGPGNPATHS ... # semanage port -a -t pvpgn_port_t -Ptcp PORTNUM You can not define a port in a module currently. >>>> You really should define a port and then allow pvpgn bind to the >>>> specific port. (Unless pvpgn binds to random ports?) >>>> >>>>> Wanted to, but couldn't quite figure out how to define a specific >>>>> port. Using source rpm for policy as a reference, but, it appears to >>>>> use >>>>> macros for all the ports it needs. >>>>> >>>> If this is on Fedora 10 you might want to add >>>> >>>> permissive pvpgn_t; >>>> >>>> Which will allow the daemon to run in permissive mode while you are >>>> testing. >>>> >>>>> It's Fedora 9, thanks though. >>>>> >>>>> > Well that should show up in Fedora 9 whenever they move to the > kernel-2.6.27 kernel >> Your question this morning has triggered me to write a blog entry. http://danwalsh.livejournal.com/23944.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjJMDQACgkQrlYvE4MpobNHuwCgquwqLy3OaLPm8OR1Wduuq294 u14AoJIW2CDtNQXo6CUCq+ICDkIPMNCT =q33W -----END PGP SIGNATURE----- From dpquigl at tycho.nsa.gov Thu Sep 11 17:44:01 2008 From: dpquigl at tycho.nsa.gov (David P. Quigley) Date: Thu, 11 Sep 2008 13:44:01 -0400 Subject: udp bind() fails with EACCESS when selinux enforcing, but no audit messages In-Reply-To: <1221147280.16999.45.camel@alabast.home.lan> References: <1221147280.16999.45.camel@alabast.home.lan> Message-ID: <1221155041.5347.35.camel@moss-terrapins.epoch.ncsc.mil> I'm pretty sure this doesn't have anything to do with the kernel end but is probably some sort of policy issue instead. I've CCed the fedora-selinux list for an answer. The CC to linux-kernel should probably be dropped from the reply there. Dave On Thu, 2008-09-11 at 17:34 +0200, Enrique Perez-Terron wrote: > Fedora core 9 stock kernel 2.6.25.108 i586 > > Udp bind() fails with EACCESS when selinux enforcing, but no audit > messages. > > How to reproduce: > > In startup scripts, configure rpc.statd to use the fixed port 34. > This port does not occur in /etc/services > (In /etc/sysconfig/nfs, STATD_PORT=34) > > Write the following script, run it with bash -x. > > #!/bin/bash > > TESTDIR=/var/tmp/se-bind-test-$$ > mkdir $TESTDIR # to hold about 50 files > cd $TESTDIR > > # Stop NFS: > service nfs stop > service nfslock stop > > # Gather some baseline data for easy comparison > echo 1 /selinux/enforce # just in case > dmesg > dmesg-enforc-before > wc /var/log/audit/audit.log > audit-enforc-before > > # This fails > strace -o enforc -ff service nfslock start > > # But no new messages in logs > dmesg > dmesg-enforc-after > wc /var/log/audit/audit.log > audit-enforc-after > > # Try again in permissive mode > echo 0 /selinux/enforce > dmesg > dmesg-nonenf-before > wc /var/log/audit/audit.log > audit-nonenf-before > > # Since this works, daemon starts, and strace hangs on > # Need sigkill; sigint does not work. Why? > (sleep 5; killall -9 strace) & > strace -o nonenf -ff service nfslock start > > # Just for symmetry > dmesg > dmesg-nonenf-after > wc /var/log/audit/audit.log > audit-nonenf-after > > # Check that there are no audits. > diff dmesg-enforc-before dmesg-enforc-after > diff audit-enforc-before audit-enforc-after > > # There are several other calls to bind() that are not prevented > grep -E '^bind|^socket' enforc.* > grep -E '^bind|^socket' nonenf.* > > Regards > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ From dwalsh at redhat.com Thu Sep 11 18:20:22 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 11 Sep 2008 14:20:22 -0400 Subject: udp bind() fails with EACCESS when selinux enforcing, but no audit messages In-Reply-To: <1221155041.5347.35.camel@moss-terrapins.epoch.ncsc.mil> References: <1221147280.16999.45.camel@alabast.home.lan> <1221155041.5347.35.camel@moss-terrapins.epoch.ncsc.mil> Message-ID: <48C96166.5040709@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David P. Quigley wrote: > I'm pretty sure this doesn't have anything to do with the kernel end but > is probably some sort of policy issue instead. I've CCed the > fedora-selinux list for an answer. The CC to linux-kernel should > probably be dropped from the reply there. > > Dave > > On Thu, 2008-09-11 at 17:34 +0200, Enrique Perez-Terron wrote: >> Fedora core 9 stock kernel 2.6.25.108 i586 >> >> Udp bind() fails with EACCESS when selinux enforcing, but no audit >> messages. >> >> How to reproduce: >> >> In startup scripts, configure rpc.statd to use the fixed port 34. >> This port does not occur in /etc/services >> (In /etc/sysconfig/nfs, STATD_PORT=34) >> >> Write the following script, run it with bash -x. >> >> #!/bin/bash >> >> TESTDIR=/var/tmp/se-bind-test-$$ >> mkdir $TESTDIR # to hold about 50 files >> cd $TESTDIR >> >> # Stop NFS: >> service nfs stop >> service nfslock stop >> >> # Gather some baseline data for easy comparison >> echo 1 /selinux/enforce # just in case >> dmesg > dmesg-enforc-before >> wc /var/log/audit/audit.log > audit-enforc-before >> >> # This fails >> strace -o enforc -ff service nfslock start >> >> # But no new messages in logs >> dmesg > dmesg-enforc-after >> wc /var/log/audit/audit.log > audit-enforc-after >> >> # Try again in permissive mode >> echo 0 /selinux/enforce >> dmesg > dmesg-nonenf-before >> wc /var/log/audit/audit.log > audit-nonenf-before >> >> # Since this works, daemon starts, and strace hangs on >> # Need sigkill; sigint does not work. Why? >> (sleep 5; killall -9 strace) & >> strace -o nonenf -ff service nfslock start >> >> # Just for symmetry >> dmesg > dmesg-nonenf-after >> wc /var/log/audit/audit.log > audit-nonenf-after >> >> # Check that there are no audits. >> diff dmesg-enforc-before dmesg-enforc-after >> diff audit-enforc-before audit-enforc-after >> >> # There are several other calls to bind() that are not prevented >> grep -E '^bind|^socket' enforc.* >> grep -E '^bind|^socket' nonenf.* >> >> Regards >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majordomo at vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list semodule -DB Will remove all dontaudit rules. Then run your service script. semodule -B Will put them back. You have yum -y upgrade selinux-policy\* -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjJYWYACgkQrlYvE4MpobMzAACfVTPibwI01dcnZAc+R8mB1bAE XNMAn00pwIPWDJ8o5THRmPY4AHhbsmhS =Jtrn -----END PGP SIGNATURE----- From kris_s at atmyhome.org Thu Sep 11 20:20:55 2008 From: kris_s at atmyhome.org (Kristen R) Date: Thu, 11 Sep 2008 12:20:55 -0800 Subject: Help with AVC messages In-Reply-To: References: <200809101415.51091.kris_s@atmyhome.org> Message-ID: <97A73517-A574-4C3E-A7DD-425AEC6E6E36@atmyhome.org> On Sep 10, 2008, at 3:31 PM, James Morris wrote: > On Wed, 10 Sep 2008, Kristen R wrote: > >> Last night I had a users website hacked. The hacker then tried to >> use httpd to >> access /etc files and directorys, as well as the root directory. >> SELinux >> saved my system. >> >> I need to make a complaint to the ISP who is providing for this >> offender. I >> have http access logs and error logs but they don't show very much. >> Other >> then access which was valid (well, not valid) and 2 entries in the >> error log. >> Is there a way I can correlate the AVC denials with the malious >> attacker? The >> AVC messages do not have time stamps or IP addresses attached to >> them. >> >> Thank you for your assistance, and for SELinux! > > You should be able to find more detailed information in the audit log. > > Try "ausearch -x httpd" > > Any idea how they attacked the web server? > > > - James > -- > James Morris > I do know how they got in to the website. The user is running a Joomla! CMS website (ver 1.5). There is a vulnerability in sanitizing the input on the screen where a user request their password. That vulnerability was exploited which allowed the attacker to gain access to the administration side of the software. Once there he installed his own software, a java script version. I can see in the URL's sent to the webserver where queries for /etc and / were sent. The AVC messages stated that httpd was attempting to gain read access to the / etc directory. Also the root directory. This involved several hours of research using find and a rootkit hunter, along with deleting MySQL databases and directories. I didn't appreciate it at all. So, I have decided to block the entire Turkish network this attacker came from since this network is notorious for spam anyhow. Kristen From init at kth.se Fri Sep 12 12:08:02 2008 From: init at kth.se (Ingemar Nilsson) Date: Fri, 12 Sep 2008 14:08:02 +0200 Subject: Need some help with a new policy module In-Reply-To: <48C9205E.9000503@redhat.com> References: <48C85C8A.8070008@twister.dyndns.org> <48C915BE.9030705@redhat.com> <48C91A4C.5060802@twister.dyndns.org> <48C9205E.9000503@redhat.com> Message-ID: <48CA5BA2.2000905@kth.se> Daniel J Walsh wrote: > Then you need to add the ports definition using > semanage port -a -t pvpgn_port_t -Ptcp PORTNUM It would be nice if someone could explain what this actually does, so that I (and others) can figure out what implications it has. E.g. is it persistent? Where is the information stored? Etc, etc. I'm not very fond of magic. :) Regards Ingemar From gp at dipohl.com Fri Sep 12 12:35:28 2008 From: gp at dipohl.com (Gabriele Pohl) Date: Fri, 12 Sep 2008 14:35:28 +0200 Subject: Hello world and first question concerning Munin Message-ID: <1221222928.3231.129.camel@calex.dipohl.com> Hi all, my name is Gabriele Pohl. I live in Bonn, Germany and use Fedora for a few years (starting with Core 4 and upgraded to 9 some months ago) I use Munin (http://munin.projects.linpro.no/) to monitor my computers hardware and services. After upgrading to Fedora 9 I decided to use SELinux in mode *enforce* and run into lots of problems concerning SELinux and Munin-Plugins, that need high system privileges to access block devices a.s.o. I would like to solve this issues in a good manner and therefore subscribed to this list to ask the experts, how to do it. Now my first question: Plugin smart_ is written in Python. It calls "smartctl" from the smartmontools package (http://smartmontools.sourceforge.net/) to read the values of the SMART-Attributes from the harddisks. To activate the plugin, one has to create a link within the service directory. Actually the link looks like this: lrwxrwxrwx root root unconfined_u:object_r:munin_etc_t:s0 smart_sda -> /usr/share/munin/plugins/smart_ The plugins file looks like this: -rwxr-xr-x root root system_u:object_r:munin_exec_t:s0 /usr/share/munin/plugins/smart_ Executable smartctl looks like this: -rwxr-xr-x root root system_u:object_r:fsadm_exec_t:s0 /usr/sbin/smartctl It needs access to the disks block device /dev/sda that looks like this: brw-rw---- root disk system_u:object_r:fixed_disk_device_t:s0 /dev/sda I have policy type targeted active and policy module munin 1.4.0 installed. I get the following raw audit messages, when calling smart_sda: host=calex.dipohl.com type=AVC msg=audit(1221221404.542:709): avc: denied { getattr } for pid=18327 comm="python" path="/dev/sda" dev=tmpfs ino=298 scontext=unconfined_u:system_r:munin_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file host=calex.dipohl.com type=SYSCALL msg=audit(1221221404.542:709): arch=40000003 syscall=195 success=no exit=-13 a0=8fbe278 a1=bfcdf038 a2=3e8ff4 a3=8f481b8 items=0 ppid=18220 pid=18327 auid=500 uid=0 gid=491 euid=0 suid=0 fsuid=0 egid=491 sgid=491 fsgid=491 tty=(none) ses=1 comm="python" exe="/usr/bin/python" subj=unconfined_u:system_r:munin_t:s0 key=(null) As the FAQ said, I fed these messages into audit2allow: audit2allow -M mine < avcs and get the following mine.te: ------------------------------- module mine 1.0; require { type munin_t; type fixed_disk_device_t; class blk_file getattr; } require { type munin_t; type fixed_disk_device_t; class blk_file getattr; } #============= munin_t ============== allow munin_t fixed_disk_device_t:blk_file getattr; ------------------------------- and a mine.pp Will it be ok to load that into the kernel using semodule -i mine.pp ? And why are there two identical *require* structs? Can / Should I delete one of them? What shall I do with the message of type "SYSCALL" if it were wrong to put it into the avcs-File? Should I make adjustments to the files above (service-link, plugin-file) Anything else, that you can advise? So far for now & cheers, Gabriele From sean at bruenor.org Fri Sep 12 13:24:36 2008 From: sean at bruenor.org (Sean E. Millichamp) Date: Fri, 12 Sep 2008 09:24:36 -0400 Subject: Puppet's use of tempfiles for capturing use of subprocess I/O Message-ID: <1221225876.3483.22.camel@sewt> I know this is long, please be patient as I detail the situation. There is a lot of Puppet-stuff initially to frame the question, but I promise there is an SELinux question at the end :) A common use-case in Puppet is for it to manage your system services, restarting services as needed. I noticed that when Puppet did this I got SELinux violations. Since we are trying to embrace SELinux (and noisy logs don't help in that goal) I dug a bit deeper. It turns out that Puppet creates a temp file in /tmp and sets the file descriptor for that tempfile to the stdout/stderr of the process before it exec()s (say) "/etc/init.d/setroubleshoot" (I've seen this happen with a number of different services). audit log messages: type=AVC msg=audit(1220897810.383:141): avc: denied { read write } for pid=3452 comm="setroubleshootd" path="/tmp/puppet.3059.7" dev=md3 ino=6036 scontext=root:system_r:setroubleshootd_t:s0 tcontext=root:object_r:tmp_t:s0 tclass=file type=AVC msg=audit(1220897810.383:141): avc: denied { read write } for pid=3452 comm="setroubleshootd" path="/tmp/puppet.3059.7" dev=md3 ino=6036 scontext=root:system_r:setroubleshootd_t:s0 tcontext=root:object_r:tmp_t:s0 tclass=file type=AVC msg=audit(1220897810.383:141): avc: denied { read write } for pid=3452 comm="setroubleshootd" path="/tmp/puppet.3059.7" dev=md3 ino=6036 scontext=root:system_r:setroubleshootd_t:s0 tcontext=root:object_r:tmp_t:s0 tclass=file Now, it seems that the domain that the init scripts transition to (rightly) doesn't have access to the tmp_t domain of Puppet's temporary file. It seems that the two results of this are a) audit log noise and b) If Puppet were to want to use the output it captures then there wouldn't be any for confined services. I created and submitted a patch to use Unix pipes instead of a temporary file for capturing the output - figuring that this was the only way sure to be SELinux-safe. (See my bug report at http://projects.reductivelabs.com/issues/show/1563 for a link to the original bug, the patch, and more details.) They told me that Puppet used to use pipes about a year ago but that there were occasionally weird hanging problems where Puppet would block on IO reads forever so the temporary file method was adopted and they didn't want to just go back to a situation where Puppet might end up hanging forever on an IO read. Fair enough, I can't object to that. I downloaded Debian Etch and successfully reproduced the originally reported problem with the pipes method. Bottom line is that during the package install a process is started, daemonizes, but not correctly and never detaches from/closes stdout/stderr, causing the pipe to not close and flush, resulting in Puppet blocking forever on the IO read. I have now worked out another patch to Puppet which uses non-blocking I/O. This works but causes problems where the package doesn't finish installing properly because Puppet can't know when to finish trying to read from the pipe and if it closes the pipe before the package is finished installing then the install doesn't complete. At this point I would say this is squarely a problem with the package containing the poorly written daemon BUT, before I make that case on the bug report with my new patch I want to know: Is there a clean way of doing this using temporary files that will be safe for all SELinux domain transition possibilities? Perhaps a label I could apply to the temporary file after creation but before the fork()/exec() that would be permissible in any SELinux context current or future? Or some other deep Unix magic I don't know about? I suspect the answer is "no", but I figure I had to ask the experts before declaring there was no other way in the Puppet bug report. Thanks for sticking through reading all of this :) Sean From sds at tycho.nsa.gov Fri Sep 12 13:43:25 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 12 Sep 2008 09:43:25 -0400 Subject: Puppet's use of tempfiles for capturing use of subprocess I/O In-Reply-To: <1221225876.3483.22.camel@sewt> References: <1221225876.3483.22.camel@sewt> Message-ID: <1221227005.4712.15.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2008-09-12 at 09:24 -0400, Sean E. Millichamp wrote: > I know this is long, please be patient as I detail the situation. There > is a lot of Puppet-stuff initially to frame the question, but I promise > there is an SELinux question at the end :) > > A common use-case in Puppet is for it to manage your system services, > restarting services as needed. I noticed that when Puppet did this I > got SELinux violations. Since we are trying to embrace SELinux (and > noisy logs don't help in that goal) I dug a bit deeper. > > It turns out that Puppet creates a temp file in /tmp and sets the file > descriptor for that tempfile to the stdout/stderr of the process before > it exec()s (say) "/etc/init.d/setroubleshoot" (I've seen this happen > with a number of different services). > > audit log messages: > type=AVC msg=audit(1220897810.383:141): avc: denied { read write } for pid=3452 comm="setroubleshootd" path="/tmp/puppet.3059.7" dev=md3 ino=6036 scontext=root:system_r:setroubleshootd_t:s0 tcontext=root:object_r:tmp_t:s0 tclass=file > type=AVC msg=audit(1220897810.383:141): avc: denied { read write } for pid=3452 comm="setroubleshootd" path="/tmp/puppet.3059.7" dev=md3 ino=6036 scontext=root:system_r:setroubleshootd_t:s0 tcontext=root:object_r:tmp_t:s0 tclass=file > type=AVC msg=audit(1220897810.383:141): avc: denied { read write } for pid=3452 comm="setroubleshootd" path="/tmp/puppet.3059.7" dev=md3 ino=6036 scontext=root:system_r:setroubleshootd_t:s0 tcontext=root:object_r:tmp_t:s0 tclass=file > > Now, it seems that the domain that the init scripts transition to > (rightly) doesn't have access to the tmp_t domain of Puppet's temporary > file. It seems that the two results of this are a) audit log noise and > b) If Puppet were to want to use the output it captures then there > wouldn't be any for confined services. > > I created and submitted a patch to use Unix pipes instead of a temporary > file for capturing the output - figuring that this was the only way sure > to be SELinux-safe. (See my bug report at > http://projects.reductivelabs.com/issues/show/1563 for a link to the > original bug, the patch, and more details.) They told me that Puppet > used to use pipes about a year ago but that there were occasionally > weird hanging problems where Puppet would block on IO reads forever so > the temporary file method was adopted and they didn't want to just go > back to a situation where Puppet might end up hanging forever on an IO > read. Fair enough, I can't object to that. > > I downloaded Debian Etch and successfully reproduced the originally > reported problem with the pipes method. Bottom line is that during the > package install a process is started, daemonizes, but not correctly and > never detaches from/closes stdout/stderr, causing the pipe to not close > and flush, resulting in Puppet blocking forever on the IO read. > > I have now worked out another patch to Puppet which uses non-blocking > I/O. This works but causes problems where the package doesn't finish > installing properly because Puppet can't know when to finish trying to > read from the pipe and if it closes the pipe before the package is > finished installing then the install doesn't complete. At this point I > would say this is squarely a problem with the package containing the > poorly written daemon BUT, before I make that case on the bug report > with my new patch I want to know: > > Is there a clean way of doing this using temporary files that will be > safe for all SELinux domain transition possibilities? Perhaps a label I > could apply to the temporary file after creation but before the > fork()/exec() that would be permissible in any SELinux context current > or future? Or some other deep Unix magic I don't know about? I suspect > the answer is "no", but I figure I had to ask the experts before > declaring there was no other way in the Puppet bug report. > > Thanks for sticking through reading all of this :) puppet should run in its own domain, and the files created for output should have their own distinct type devoted to this purpose, so that you don't open up access to other files in /tmp unwittingly. That can be done via policy rules for all files created by puppet in /tmp or via explicit calls to setfscreatecon(3) or setfilecon(3) by puppet for only the specific output files. With a recent kernel and a policy that enables the open_perms capability (which I believe will be used in Fedora 10, but isn't on presently in rawhide AFAICS), you can allow domains to inherit and use an open file descriptor provided by the caller without allowing them to directly open the file. Then policy could allow all of the service domains to inherit and use the open file descriptors to the output files while still preventing them from opening any other output file created in /tmp by puppet. That is done by way of introducing an "open" permission check on direct opens of files separate from the existing "read" and "write" checks applied on any access of the file. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Fri Sep 12 13:49:07 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 12 Sep 2008 09:49:07 -0400 Subject: Hello world and first question concerning Munin In-Reply-To: <1221222928.3231.129.camel@calex.dipohl.com> References: <1221222928.3231.129.camel@calex.dipohl.com> Message-ID: <1221227347.4712.19.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2008-09-12 at 14:35 +0200, Gabriele Pohl wrote: > Hi all, > > my name is Gabriele Pohl. I live in Bonn, Germany > and use Fedora for a few years (starting with > Core 4 and upgraded to 9 some months ago) > > I use Munin (http://munin.projects.linpro.no/) > to monitor my computers hardware and services. > After upgrading to Fedora 9 I decided to use SELinux > in mode *enforce* and run into lots of problems > concerning SELinux and Munin-Plugins, that need > high system privileges to access block devices a.s.o. > > I would like to solve this issues in a good > manner and therefore subscribed to this list > to ask the experts, how to do it. > > Now my first question: > > Plugin smart_ is written in Python. > It calls "smartctl" from the smartmontools package > (http://smartmontools.sourceforge.net/) to read the > values of the SMART-Attributes from the harddisks. > > To activate the plugin, one has to create a link > within the service directory. > > Actually the link looks like this: > lrwxrwxrwx root root unconfined_u:object_r:munin_etc_t:s0 smart_sda > -> /usr/share/munin/plugins/smart_ > > The plugins file looks like this: > -rwxr-xr-x root root > system_u:object_r:munin_exec_t:s0 /usr/share/munin/plugins/smart_ > > Executable smartctl looks like this: > -rwxr-xr-x root root > system_u:object_r:fsadm_exec_t:s0 /usr/sbin/smartctl > > It needs access to the disks block device /dev/sda > that looks like this: > brw-rw---- root disk system_u:object_r:fixed_disk_device_t:s0 /dev/sda > > I have policy type targeted active and > policy module munin 1.4.0 installed. > > I get the following raw audit messages, when > calling smart_sda: > > host=calex.dipohl.com type=AVC msg=audit(1221221404.542:709): avc: > denied { getattr } for pid=18327 comm="python" path="/dev/sda" dev=tmpfs > ino=298 scontext=unconfined_u:system_r:munin_t:s0 > tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file > > host=calex.dipohl.com type=SYSCALL msg=audit(1221221404.542:709): > arch=40000003 syscall=195 success=no exit=-13 a0=8fbe278 a1=bfcdf038 > a2=3e8ff4 a3=8f481b8 items=0 ppid=18220 pid=18327 auid=500 uid=0 gid=491 > euid=0 suid=0 fsuid=0 egid=491 sgid=491 fsgid=491 tty=(none) ses=1 > comm="python" exe="/usr/bin/python" > subj=unconfined_u:system_r:munin_t:s0 key=(null) > > As the FAQ said, I fed these messages into audit2allow: > audit2allow -M mine < avcs > > and get the following mine.te: > ------------------------------- > module mine 1.0; > > require { > type munin_t; > type fixed_disk_device_t; > class blk_file getattr; > } > require { > type munin_t; > type fixed_disk_device_t; > class blk_file getattr; > } > > #============= munin_t ============== > allow munin_t fixed_disk_device_t:blk_file getattr; > ------------------------------- > > and a mine.pp > > Will it be ok to load that into the kernel using > semodule -i mine.pp ? > > And why are there two identical *require* structs? > Can / Should I delete one of them? > What shall I do with the message of type "SYSCALL" > if it were wrong to put it into the avcs-File? > > Should I make adjustments to the files above > (service-link, plugin-file) > > Anything else, that you can advise? Ideally the munin_t domain itself shouldn't need any access to the raw device - it should transition into the existing domain for smartd (fsdaemon_t) upon executing the smartctl program. I don't know offhand if the existing munin policy module has such a domain transition rule. However, mere getattr access (i.e. the ability to stat the file) isn't a big deal, so you could likely grant that one w/o difficulty. What would be more problematic is allowing read or write access to the raw device. The duplicate require blocks look like a bug in audit2allow. -- Stephen Smalley National Security Agency From sean at bruenor.org Fri Sep 12 15:58:39 2008 From: sean at bruenor.org (Sean E. Millichamp) Date: Fri, 12 Sep 2008 11:58:39 -0400 Subject: Puppet's use of tempfiles for capturing use of subprocess I/O In-Reply-To: <1221227005.4712.15.camel@moss-spartans.epoch.ncsc.mil> References: <1221225876.3483.22.camel@sewt> <1221227005.4712.15.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1221235119.11325.20.camel@sewt> On Fri, 2008-09-12 at 09:43 -0400, Stephen Smalley wrote: > puppet should run in its own domain, and the files created for output > should have their own distinct type devoted to this purpose, so that you > don't open up access to other files in /tmp unwittingly. That can be > done via policy rules for all files created by puppet in /tmp or via > explicit calls to setfscreatecon(3) or setfilecon(3) by puppet for only > the specific output files. Hi Stephen, thanks for your reply. Well, as I understand it, putting Puppet in its own domain and labeling the /tmp files so Puppet can only read them and not other files in /tmp would certainly be a good thing, but doesn't address my problem. I'm just starting to spend time interacting with SELinux so if I am completely misunderstanding something please be patient. My problem (in this case) isn't that I want to confine Puppet (that is a different project for a different day - maybe), it is that those /tmp files Puppet creates and attaches to arbitrary process STDOUT/STDERR streams have to be writable by any process in any domain. Any service/command you would run on the command line should be available to an admin via Puppet, but in this case instead of sending their output to a tty they are sending it to a file. Basically, I want to be able to do this: - create the temporary file - chcon the temporary file to allow_all_domains_to_write_to_me_t - attach the files to stdout/stderr and exec whatever the command is - regardless of any policy on the command, it should be able to write to allow_all_domains_to_write_to_me_t I know that having a context like "allow_all_domains_to_write_to_me_t" is probably against the spirit of SELinux, but if such a file context exists it would solve my problem. > With a recent kernel and a policy that enables the open_perms capability > (which I believe will be used in Fedora 10, but isn't on presently in > rawhide AFAICS), you can allow domains to inherit and use an open file > descriptor provided by the caller without allowing them to directly open > the file. Then policy could allow all of the service domains to inherit > and use the open file descriptors to the output files while still > preventing them from opening any other output file created in /tmp by > puppet. That is done by way of introducing an "open" permission check > on direct opens of files separate from the existing "read" and "write" > checks applied on any access of the file. This sounds like exactly what I need, except unfortunately I need something that will work on existing and older distributions. Is there anyway I can simulate that behavior now with existing SELinux implementations? Sean From sds at tycho.nsa.gov Fri Sep 12 17:33:03 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 12 Sep 2008 13:33:03 -0400 Subject: Puppet's use of tempfiles for capturing use of subprocess I/O In-Reply-To: <1221235119.11325.20.camel@sewt> References: <1221225876.3483.22.camel@sewt> <1221227005.4712.15.camel@moss-spartans.epoch.ncsc.mil> <1221235119.11325.20.camel@sewt> Message-ID: <1221240783.4712.86.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2008-09-12 at 11:58 -0400, Sean E. Millichamp wrote: > On Fri, 2008-09-12 at 09:43 -0400, Stephen Smalley wrote: > > > puppet should run in its own domain, and the files created for output > > should have their own distinct type devoted to this purpose, so that you > > don't open up access to other files in /tmp unwittingly. That can be > > done via policy rules for all files created by puppet in /tmp or via > > explicit calls to setfscreatecon(3) or setfilecon(3) by puppet for only > > the specific output files. > > Hi Stephen, thanks for your reply. > > Well, as I understand it, putting Puppet in its own domain and labeling > the /tmp files so Puppet can only read them and not other files in /tmp > would certainly be a good thing, but doesn't address my problem. That isn't what I meant. I said to put puppet in its domain so that the policy rules can define a type for files it creates in /tmp that are different than the type used by any other process, and then we can allow all service domains to read that new type created only by puppet w/o exposing the temporary files of any other process to such access. See the difference? What domain does puppet run in presently, initrc_t? > I'm > just starting to spend time interacting with SELinux so if I am > completely misunderstanding something please be patient. > > My problem (in this case) isn't that I want to confine Puppet (that is a > different project for a different day - maybe), it is that those /tmp > files Puppet creates and attaches to arbitrary process STDOUT/STDERR > streams have to be writable by any process in any domain. Precisely - which means they need their own type. And the easiest way to ensure that goal is to put puppet into its own domain and define a file type transition from that domain on tmp_t:dir such that any /tmp files created by puppet get that type automatically. > Any > service/command you would run on the command line should be available to > an admin via Puppet, but in this case instead of sending their output to > a tty they are sending it to a file. > > Basically, I want to be able to do this: > - create the temporary file > - chcon the temporary file to allow_all_domains_to_write_to_me_t This step becomes unnecessary if we put puppet into its own domain and define a file type transition to a new type, say puppet_tmp_t when creating files in /tmp, and then the puppet policy can say "allow domain puppet_tmp_t:file { read write getattr append };" > This sounds like exactly what I need, except unfortunately I need > something that will work on existing and older distributions. Is there > anyway I can simulate that behavior now with existing SELinux > implementations? The approach above will work for existing distributions but will allow the service domains to potentially open other files created by puppet in /tmp as well (but not open arbitrary /tmp files created by other processes). Then in newer distributions where the new open permission is enabled in policy, the service domains will not be able to open other files created by puppet in /tmp other than the one handed to them due to the checking of the new open permission. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Fri Sep 12 17:35:29 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 12 Sep 2008 13:35:29 -0400 Subject: Puppet's use of tempfiles for capturing use of subprocess I/O In-Reply-To: <1221235119.11325.20.camel@sewt> References: <1221225876.3483.22.camel@sewt> <1221227005.4712.15.camel@moss-spartans.epoch.ncsc.mil> <1221235119.11325.20.camel@sewt> Message-ID: <48CAA861.60509@redhat.com> Sean E. Millichamp wrote: > On Fri, 2008-09-12 at 09:43 -0400, Stephen Smalley wrote: > >> puppet should run in its own domain, and the files created for output >> should have their own distinct type devoted to this purpose, so that you >> don't open up access to other files in /tmp unwittingly. That can be >> done via policy rules for all files created by puppet in /tmp or via >> explicit calls to setfscreatecon(3) or setfilecon(3) by puppet for only >> the specific output files. > > Hi Stephen, thanks for your reply. > > Well, as I understand it, putting Puppet in its own domain and labeling > the /tmp files so Puppet can only read them and not other files in /tmp > would certainly be a good thing, but doesn't address my problem. I'm > just starting to spend time interacting with SELinux so if I am > completely misunderstanding something please be patient. > > My problem (in this case) isn't that I want to confine Puppet (that is a > different project for a different day - maybe), it is that those /tmp > files Puppet creates and attaches to arbitrary process STDOUT/STDERR > streams have to be writable by any process in any domain. Any > service/command you would run on the command line should be available to > an admin via Puppet, but in this case instead of sending their output to > a tty they are sending it to a file. > > Basically, I want to be able to do this: > - create the temporary file > - chcon the temporary file to allow_all_domains_to_write_to_me_t > - attach the files to stdout/stderr and exec whatever the command is > - regardless of any policy on the command, it should be able to write > to allow_all_domains_to_write_to_me_t > > I know that having a context like "allow_all_domains_to_write_to_me_t" > is probably against the spirit of SELinux, but if such a file context > exists it would solve my problem. > >> With a recent kernel and a policy that enables the open_perms capability >> (which I believe will be used in Fedora 10, but isn't on presently in >> rawhide AFAICS), you can allow domains to inherit and use an open file >> descriptor provided by the caller without allowing them to directly open >> the file. Then policy could allow all of the service domains to inherit >> and use the open file descriptors to the output files while still >> preventing them from opening any other output file created in /tmp by >> puppet. That is done by way of introducing an "open" permission check >> on direct opens of files separate from the existing "read" and "write" >> checks applied on any access of the file. > > This sounds like exactly what I need, except unfortunately I need > something that will work on existing and older distributions. Is there > anyway I can simulate that behavior now with existing SELinux > implementations? > > Sean > > Right and you would allow domain puppet_tmp_t:file rw_file_perms; Which would allow every process on the system to read/write these files. Of course I would suggest that you not use /tmp for this activity since /tmp is really a USER resource and not a System resource. You should never create files by privileged processes in /tmp/ they should be created in /var/run/puppet or /var/log/puppet. http://danwalsh.livejournal.com/11467.html You can generate a policy # cat puppetout.te policy_module(puppetout, 1.0) gen_require(` attribute domain; ') type puppet_log_t; files_type(puppet_log_t) allow domain puppet_log_t:file rw_file_perms; # make -f /usr/share/selinux/devel/Makefile # semodule -i puppet.pp # touch /var/run/puppet.log # chcon -t puppet_log_t /var/log/puppet.log Go to town. From sean at bruenor.org Fri Sep 12 18:16:06 2008 From: sean at bruenor.org (Sean E. Millichamp) Date: Fri, 12 Sep 2008 14:16:06 -0400 Subject: Puppet's use of tempfiles for capturing use of subprocess I/O In-Reply-To: <1221240783.4712.86.camel@moss-spartans.epoch.ncsc.mil> References: <1221225876.3483.22.camel@sewt> <1221227005.4712.15.camel@moss-spartans.epoch.ncsc.mil> <1221235119.11325.20.camel@sewt> <1221240783.4712.86.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1221243366.11325.37.camel@sewt> On Fri, 2008-09-12 at 13:33 -0400, Stephen Smalley wrote: > That isn't what I meant. I said to put puppet in its domain so that the > policy rules can define a type for files it creates in /tmp that are > different than the type used by any other process, and then we can allow > all service domains to read that new type created only by puppet w/o > exposing the temporary files of any other process to such access. See > the difference? What domain does puppet run in presently, initrc_t? Ah, okay. Now I get it. I didn't realize/understand that putting it in its own domain would provide a route to do that. Puppet runs in initrc_t if started via /etc/init.d/puppet and in unconfined_t if run as puppetd from the command line (which I frequently do for testing new configs). > This step becomes unnecessary if we put puppet into its own domain and > define a file type transition to a new type, say puppet_tmp_t when > creating files in /tmp, and then the puppet policy can say "allow domain > puppet_tmp_t:file { read write getattr append };" Okay, I think it starting to make sense to me now. Between your explanation and Dan's sample policy and explanation I think I am starting to understand what is needed. So, to clarify, if I create the new puppet domain definition and policy correctly I theoretically won't even need to modify a line of Puppet code itself? It seems I have some more learning to do :) I think I am going to try this approach and see if I can come up with a policy that will cover a domain transition and the required labeling. > The approach above will work for existing distributions but will allow > the service domains to potentially open other files created by puppet > in /tmp as well (but not open arbitrary /tmp files created by other > processes). Then in newer distributions where the new open permission > is enabled in policy, the service domains will not be able to open > other files created by puppet in /tmp other than the one handed to > them due to the checking of the new open permission. Good point. Thanks! Sean From sean at bruenor.org Fri Sep 12 18:23:50 2008 From: sean at bruenor.org (Sean E. Millichamp) Date: Fri, 12 Sep 2008 14:23:50 -0400 Subject: Puppet's use of tempfiles for capturing use of subprocess I/O In-Reply-To: <48CAA861.60509@redhat.com> References: <1221225876.3483.22.camel@sewt> <1221227005.4712.15.camel@moss-spartans.epoch.ncsc.mil> <1221235119.11325.20.camel@sewt> <48CAA861.60509@redhat.com> Message-ID: <1221243830.11325.45.camel@sewt> On Fri, 2008-09-12 at 13:35 -0400, Daniel J Walsh wrote: > Of course I would suggest that you not use /tmp for this activity since > /tmp is really a USER resource and not a System resource. You should > never create files by privileged processes in /tmp/ they should be > created in /var/run/puppet or /var/log/puppet. > > http://danwalsh.livejournal.com/11467.html Hi Dan, Thanks for chiming in and providing the example policy. I have been so focused on the file labeling and errors I hadn't even stopped to consider the location :). Puppet currently uses the Ruby Tempfile class without specifying a tmpdir and defaults to /tmp as the Ruby built-in default. I might take a stab at adding a configuration setting for that and defaulting it someplace else. Excellent idea, thanks! Sean From sds at tycho.nsa.gov Fri Sep 12 18:28:34 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 12 Sep 2008 14:28:34 -0400 Subject: Puppet's use of tempfiles for capturing use of subprocess I/O In-Reply-To: <1221243366.11325.37.camel@sewt> References: <1221225876.3483.22.camel@sewt> <1221227005.4712.15.camel@moss-spartans.epoch.ncsc.mil> <1221235119.11325.20.camel@sewt> <1221240783.4712.86.camel@moss-spartans.epoch.ncsc.mil> <1221243366.11325.37.camel@sewt> Message-ID: <1221244114.4712.97.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2008-09-12 at 14:16 -0400, Sean E. Millichamp wrote: > Between your explanation and Dan's sample policy and explanation I think > I am starting to understand what is needed. > > So, to clarify, if I create the new puppet domain definition and policy > correctly I theoretically won't even need to modify a line of Puppet > code itself? It seems I have some more learning to do :) Yes. Something along the lines of: policy_module(puppet, 1.0) type puppet_t; type puppet_exec_t; domain_type(puppet_t) init_daemon_domain(puppet_t, puppet_exec_t) role system_r types puppet_t; type puppet_tmp_t; files_tmp_file(puppet_tmp_t) files_tmp_filetrans(puppet_t, puppet_tmp_t, file) should get you started. And if your goal is to leave puppet completely unrestricted, you can always add a: optional_policy(` unconfined_domain(puppet_t) ') to leave it unrestricted in its own actions by SELinux. > I think I am going to try this approach and see if I can come up with a > policy that will cover a domain transition and the required labeling. -- Stephen Smalley National Security Agency From frankly3d at gmail.com Sun Sep 14 10:44:27 2008 From: frankly3d at gmail.com (Frank Murphy) Date: Sun, 14 Sep 2008 11:44:27 +0100 Subject: AVC Denials x2 - No Network Connection Long-Post Message-ID: Basically this is F9 on a USB-Stick, installed as "install to hd" upgraded full to newkey status. restorecon -v '/var/lib/dhclient/dhclient-eth0.leases' -:- No change to avc(s) Summary: SELinux is preventing consoletype (consoletype_t) "read" to /var/lib/dhclient/dhclient-eth0.leases (dhcpc_state_t). Detailed Description: SELinux denied access requested by consoletype. It is not expected that this access is required by consoletype 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: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /var/lib/dhclient/dhclient-eth0.leases, restorecon -v '/var/lib/dhclient/dhclient-eth0.leases' If this does not work, there is currently no automatic way to allow this access. Instead, 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 unconfined_u:system_r:consoletype_t:s0 Target Context unconfined_u:object_r:dhcpc_state_t:s0 Target Objects /var/lib/dhclient/dhclient-eth0.leases [ file ] Source consoletype Source Path /sbin/consoletype Port Host usbstick-01 Source RPM Packages initscripts-8.76-1 Target RPM Packages Policy RPM selinux-policy-3.3.1-42.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name usbstick-01 Platform Linux usbstick-01 2.6.25-14.fc9.i686 #1 SMP Thu May 1 06:28:41 EDT 2008 i686 i686 Alert Count 3 First Seen Sat 13 Sep 2008 17:54:44 IST Last Seen Sun 14 Sep 2008 10:48:26 IST Local ID d216653d-c0e7-4df0-81bd-c9ee3c1d542b Line Numbers Raw Audit Messages host=usbstick-01 type=AVC msg=audit(1221385706.55:48): avc: denied { read } for pid=4706 comm="consoletype" path="/var/lib/dhclient/dhclient-eth0.leases" dev=dm-0 ino=47658 scontext=unconfined_u:system_r:consoletype_t:s0 tcontext=unconfined_u:object_r:dhcpc_state_t:s0 tclass=file host=usbstick-01 type=SYSCALL msg=audit(1221385706.55:48): arch=40000003 syscall=11 success=yes exit=0 a0=844fcb8 a1=844f738 a2=844f958 a3=0 items=0 ppid=4705 pid=4706 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="consoletype" exe="/sbin/consoletype" subj=unconfined_u:system_r:consoletype_t:s0 key=(null) Summary: SELinux is preventing ifconfig (ifconfig_t) "read" to /var/lib/dhclient/dhclient-eth0.leases (dhcpc_state_t). Detailed Description: SELinux denied access requested by ifconfig. It is not expected that this access is required by ifconfig 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: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /var/lib/dhclient/dhclient-eth0.leases, restorecon -v '/var/lib/dhclient/dhclient-eth0.leases' If this does not work, there is currently no automatic way to allow this access. Instead, 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 unconfined_u:system_r:ifconfig_t:s0 Target Context unconfined_u:object_r:dhcpc_state_t:s0 Target Objects /var/lib/dhclient/dhclient-eth0.leases [ file ] Source ifconfig Source Path /sbin/ifconfig Port Host usbstick-01 Source RPM Packages net-tools-1.60-87.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-42.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name usbstick-01 Platform Linux usbstick-01 2.6.25-14.fc9.i686 #1 SMP Thu May 1 06:28:41 EDT 2008 i686 i686 Alert Count 4 First Seen Sat 13 Sep 2008 17:54:44 IST Last Seen Sun 14 Sep 2008 10:48:26 IST Local ID c7b6f250-55d9-4401-97db-6503d3d2db46 Line Numbers Raw Audit Messages host=usbstick-01 type=AVC msg=audit(1221385706.103:49): avc: denied { read } for pid=4726 comm="ifconfig" path="/var/lib/dhclient/dhclient-eth0.leases" dev=dm-0 ino=47658 scontext=unconfined_u:system_r:ifconfig_t:s0 tcontext=unconfined_u:object_r:dhcpc_state_t:s0 tclass=file host=usbstick-01 type=SYSCALL msg=audit(1221385706.103:49): arch=40000003 syscall=11 success=yes exit=0 a0=8490b40 a1=8490960 a2=8477018 a3=0 items=0 ppid=4704 pid=4726 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="ifconfig" exe="/sbin/ifconfig" subj=unconfined_u:system_r:ifconfig_t:s0 key=(null) audit2allow -M lease < /var/lib/dhclient/dhclient-eth0.leases compilation failed: lease.te:6:ERROR 'syntax error' at token '' on line 6: /usr/bin/checkmodule: error(s) encountered while parsing configuration /usr/bin/checkmodule: loading policy configuration from lease.te [root at usbstick-01 ~]# audit2allow -M local < '/var/lib/dhclient/dhclient-eth0.leases' compilation failed: local.te:6:ERROR 'syntax error' at token '' on line 6: /usr/bin/checkmodule: error(s) encountered while parsing configuration /usr/bin/checkmodule: loading policy configuration from local.te Frank -- aMSN: Frankly3D From frankly3d at gmail.com Sun Sep 14 15:30:46 2008 From: frankly3d at gmail.com (Frank Murphy) Date: Sun, 14 Sep 2008 16:30:46 +0100 Subject: AVC Denials x2 - No Network Connection Long-Post In-Reply-To: References: Message-ID: <1221406246.24915.3.camel@frank-01> On Sun, 2008-09-14 at 11:44 +0100, Frank Murphy wrote: Sorry for self-reply, got around it by disabling selinx, then updated to newer policies.Now re enabled without eth errors. Frank From usenet at laliluna.de Sun Sep 14 21:15:20 2008 From: usenet at laliluna.de (Sebastian Hennebrueder) Date: Sun, 14 Sep 2008 23:15:20 +0200 Subject: question on new filecontext type and documentation issues Message-ID: <48CD7EE8.6090307@laliluna.de> Hello, thank you for the nice solution you provided with Selinux. I have two issues: 1) I use Centos 5.2 which clones Redhat Enterprise Linux. I use the targeted policy. Postfix and dovecot shares the certicates. I solved the problem in a way that I copied the certificates and set the corresponding context. I don't like this approach. Alternatively I can use the normal audit2allow approach to allow postfix access to dovecot or vice versa but I would like not to give them this right. The best solution is to create a new context which can be accessed by both domains. With the new module approach, how do I start to write a new context type? It is probably simple but I don't find the way to start by reading the documentation on the net. 2) I am actually a Java developer running my own Linux server, so I am far away from being a Linux expert. My feeling is that the documentation is really hard to follow. It was hard to find out how to interpret the audit.log. The only location to explain the different attributes seams to be > http://seedit.sourceforge.net/doc/access_vectors/ > But still some documented log entries would be fine, e.g. what does a socket connect require, what does a search for the config file in /etc require, ... I found the tip to use sealert -a on the http://wiki.centos.org/HowTos/SELinux I found the statement do 'cat audit.log | audit2allow ...' but don't trust the result somewhere. But well, if I shouldn't trust, I would appreciate to analyse as well. Your wiki does note http://people.redhat.com/dwalsh/SELinux/Presentations/ManageRHEL5.pdf which is a good resource after having understood the basics The next page told me about sesearch, which is a very important tool IMHO. http://www.durchmesser.ch/wiki/SELinux I still have no idea how to find information on the different macros which where noted somewhere. From my beginner point of view, I noted my steps and resources on my blog at http://www.laliluna.de/blog/ To summarize, I would appreciate a somehow more centralized complete documentation, much more oriented to practical use cases. Best Regards Sebastian From dwalsh at redhat.com Mon Sep 15 13:17:11 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 15 Sep 2008 09:17:11 -0400 Subject: Puppet's use of tempfiles for capturing use of subprocess I/O In-Reply-To: <1221243366.11325.37.camel@sewt> References: <1221225876.3483.22.camel@sewt> <1221227005.4712.15.camel@moss-spartans.epoch.ncsc.mil> <1221235119.11325.20.camel@sewt> <1221240783.4712.86.camel@moss-spartans.epoch.ncsc.mil> <1221243366.11325.37.camel@sewt> Message-ID: <48CE6057.90202@redhat.com> Sean E. Millichamp wrote: > On Fri, 2008-09-12 at 13:33 -0400, Stephen Smalley wrote: > >> That isn't what I meant. I said to put puppet in its domain so that the >> policy rules can define a type for files it creates in /tmp that are >> different than the type used by any other process, and then we can allow >> all service domains to read that new type created only by puppet w/o >> exposing the temporary files of any other process to such access. See >> the difference? What domain does puppet run in presently, initrc_t? > > Ah, okay. Now I get it. I didn't realize/understand that putting it in > its own domain would provide a route to do that. Puppet runs in > initrc_t if started via /etc/init.d/puppet and in unconfined_t if run as > puppetd from the command line (which I frequently do for testing new > configs). > >> This step becomes unnecessary if we put puppet into its own domain and >> define a file type transition to a new type, say puppet_tmp_t when >> creating files in /tmp, and then the puppet policy can say "allow domain >> puppet_tmp_t:file { read write getattr append };" > > Okay, I think it starting to make sense to me now. > > Between your explanation and Dan's sample policy and explanation I think > I am starting to understand what is needed. > > So, to clarify, if I create the new puppet domain definition and policy > correctly I theoretically won't even need to modify a line of Puppet > code itself? It seems I have some more learning to do :) > > I think I am going to try this approach and see if I can come up with a > policy that will cover a domain transition and the required labeling. > >> The approach above will work for existing distributions but will allow >> the service domains to potentially open other files created by puppet >> in /tmp as well (but not open arbitrary /tmp files created by other >> processes). Then in newer distributions where the new open permission >> is enabled in policy, the service domains will not be able to open >> other files created by puppet in /tmp other than the one handed to >> them due to the checking of the new open permission. > > Good point. > > Thanks! > > Sean > Well puppet has problems when it installs files, that have been reported upstream. Basically it needs to ask the system what the label of a file it puts on disk and make sure it is correct. I wrote ruby bindings during the summer for this purpose and hopefully an updated version of puppet will be available soon. Currently Fedora Infrastructure team is using restorecond to try to maintain the labels of files provided via puppet. From dwalsh at redhat.com Mon Sep 15 13:25:43 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 15 Sep 2008 09:25:43 -0400 Subject: AVC Denials x2 - No Network Connection Long-Post In-Reply-To: References: Message-ID: <48CE6257.1050005@redhat.com> Frank Murphy wrote: > Basically this is F9 on a USB-Stick, installed as "install to hd" > upgraded full to newkey status. > restorecon -v '/var/lib/dhclient/dhclient-eth0.leases' -:- No change to avc(s) > > Summary: > > SELinux is preventing consoletype (consoletype_t) "read" to > /var/lib/dhclient/dhclient-eth0.leases (dhcpc_state_t). > > Detailed Description: > > SELinux denied access requested by consoletype. It is not expected that this > access is required by consoletype 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: > > Sometimes labeling problems can cause SELinux denials. You could try to restore > the default system file context for /var/lib/dhclient/dhclient-eth0.leases, > > restorecon -v '/var/lib/dhclient/dhclient-eth0.leases' > > If this does not work, there is currently no automatic way to allow this access. > Instead, 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 unconfined_u:system_r:consoletype_t:s0 > Target Context unconfined_u:object_r:dhcpc_state_t:s0 > Target Objects /var/lib/dhclient/dhclient-eth0.leases [ file ] > Source consoletype > Source Path /sbin/consoletype > Port > Host usbstick-01 > Source RPM Packages initscripts-8.76-1 > Target RPM Packages > Policy RPM selinux-policy-3.3.1-42.fc9 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name catchall_file > Host Name usbstick-01 > Platform Linux usbstick-01 2.6.25-14.fc9.i686 #1 SMP Thu > May 1 06:28:41 EDT 2008 i686 i686 > Alert Count 3 > First Seen Sat 13 Sep 2008 17:54:44 IST > Last Seen Sun 14 Sep 2008 10:48:26 IST > Local ID d216653d-c0e7-4df0-81bd-c9ee3c1d542b > Line Numbers > > Raw Audit Messages > > host=usbstick-01 type=AVC msg=audit(1221385706.55:48): avc: denied { > read } for pid=4706 comm="consoletype" > path="/var/lib/dhclient/dhclient-eth0.leases" dev=dm-0 ino=47658 > scontext=unconfined_u:system_r:consoletype_t:s0 > tcontext=unconfined_u:object_r:dhcpc_state_t:s0 tclass=file > > host=usbstick-01 type=SYSCALL msg=audit(1221385706.55:48): > arch=40000003 syscall=11 success=yes exit=0 a0=844fcb8 a1=844f738 > a2=844f958 a3=0 items=0 ppid=4705 pid=4706 auid=500 uid=0 gid=0 euid=0 > suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="consoletype" > exe="/sbin/consoletype" subj=unconfined_u:system_r:consoletype_t:s0 > key=(null) > > > > > > Summary: > > SELinux is preventing ifconfig (ifconfig_t) "read" to > /var/lib/dhclient/dhclient-eth0.leases (dhcpc_state_t). > > Detailed Description: > > SELinux denied access requested by ifconfig. It is not expected that this access > is required by ifconfig 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: > > Sometimes labeling problems can cause SELinux denials. You could try to restore > the default system file context for /var/lib/dhclient/dhclient-eth0.leases, > > restorecon -v '/var/lib/dhclient/dhclient-eth0.leases' > > If this does not work, there is currently no automatic way to allow this access. > Instead, 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 unconfined_u:system_r:ifconfig_t:s0 > Target Context unconfined_u:object_r:dhcpc_state_t:s0 > Target Objects /var/lib/dhclient/dhclient-eth0.leases [ file ] > Source ifconfig > Source Path /sbin/ifconfig > Port > Host usbstick-01 > Source RPM Packages net-tools-1.60-87.fc9 > Target RPM Packages > Policy RPM selinux-policy-3.3.1-42.fc9 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name catchall_file > Host Name usbstick-01 > Platform Linux usbstick-01 2.6.25-14.fc9.i686 #1 SMP Thu > May 1 06:28:41 EDT 2008 i686 i686 > Alert Count 4 > First Seen Sat 13 Sep 2008 17:54:44 IST > Last Seen Sun 14 Sep 2008 10:48:26 IST > Local ID c7b6f250-55d9-4401-97db-6503d3d2db46 > Line Numbers > > Raw Audit Messages > > host=usbstick-01 type=AVC msg=audit(1221385706.103:49): avc: denied > { read } for pid=4726 comm="ifconfig" > path="/var/lib/dhclient/dhclient-eth0.leases" dev=dm-0 ino=47658 > scontext=unconfined_u:system_r:ifconfig_t:s0 > tcontext=unconfined_u:object_r:dhcpc_state_t:s0 tclass=file > > host=usbstick-01 type=SYSCALL msg=audit(1221385706.103:49): > arch=40000003 syscall=11 success=yes exit=0 a0=8490b40 a1=8490960 > a2=8477018 a3=0 items=0 ppid=4704 pid=4726 auid=500 uid=0 gid=0 euid=0 > suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="ifconfig" > exe="/sbin/ifconfig" subj=unconfined_u:system_r:ifconfig_t:s0 > key=(null) > > > > audit2allow -M lease < /var/lib/dhclient/dhclient-eth0.leases > compilation failed: > lease.te:6:ERROR 'syntax error' at token '' on line 6: > This should have been audit2allow -M lease < /var/log/audit/audit.log > > /usr/bin/checkmodule: error(s) encountered while parsing configuration > /usr/bin/checkmodule: loading policy configuration from lease.te > [root at usbstick-01 ~]# audit2allow -M local < > '/var/lib/dhclient/dhclient-eth0.leases' > compilation failed: > local.te:6:ERROR 'syntax error' at token '' on line 6: > > > /usr/bin/checkmodule: error(s) encountered while parsing configuration > /usr/bin/checkmodule: loading policy configuration from local.te > > > Frank If you take a look at what these AVC's are saying, you should realize they make no sense. The AVC's are reporting that consoletype and application for looking at the current terminal wants to read a file created by dhclient? Not likely. When I see a avc like this that makes no sense, my mind instantly thinks leaked file descriptors. When you see the second avc saying ifconfig_t also wants to read the same file, I have a pretty good idea this is a leak. SELinux is just reporting that the dhclient program passed an open file descriptor that confined domains that it is execing do not have access to. SELinux is closing the file descriptors and consoletype and ifconfig are working fine, but SELinux complains about the descriptors. The dhclient program should get a bugzilla telling them to close the desctiptors on exec. fcntl(fd, F_SETFD, FD_CLOEXEC); This would eliminate a potential security hole and get SELinux to be quiet. From dwalsh at redhat.com Mon Sep 15 13:43:36 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 15 Sep 2008 09:43:36 -0400 Subject: question on new filecontext type and documentation issues In-Reply-To: <48CD7EE8.6090307@laliluna.de> References: <48CD7EE8.6090307@laliluna.de> Message-ID: <48CE6688.4020202@redhat.com> Sebastian Hennebrueder wrote: > Hello, > thank you for the nice solution you provided with Selinux. > > I have two issues: > > 1) > I use Centos 5.2 which clones Redhat Enterprise Linux. I use the > targeted policy. > > Postfix and dovecot shares the certicates. I solved the problem in a > way that I copied the certificates and set the corresponding context. > I don't like this approach. Alternatively I can use the normal > audit2allow approach to allow postfix access to dovecot or vice versa > but I would like not to give them this right. > The best solution is to create a new context which can be accessed by > both domains. > With the new module approach, how do I start to write a new context > type? It is probably simple but I don't find the way to start by reading > the documentation on the net. > > 2) > I am actually a Java developer running my own Linux server, so I am far > away from being a Linux expert. > My feeling is that the documentation is really hard to follow. > > It was hard to find out how to interpret the audit.log. The only > location to explain the different attributes seams to be >> http://seedit.sourceforge.net/doc/access_vectors/ >> > But still some documented log entries would be fine, e.g. what does a > socket connect require, what does a search for the config file in /etc > require, ... > > I found the tip to use sealert -a on the > http://wiki.centos.org/HowTos/SELinux > > > I found the statement do 'cat audit.log | audit2allow ...' but don't > trust the result somewhere. But well, if I shouldn't trust, I would > appreciate to analyse as well. > > Your wiki does note > http://people.redhat.com/dwalsh/SELinux/Presentations/ManageRHEL5.pdf > which is a good resource after > having understood the basics > > The next page told me about sesearch, which is a very important tool IMHO. > http://www.durchmesser.ch/wiki/SELinux > > > I still have no idea how to find information on the different macros > which where noted somewhere. > > From my beginner point of view, I noted my steps and resources on my > blog at http://www.laliluna.de/blog/ > > To summarize, I would appreciate a somehow more centralized complete > documentation, much more oriented to practical use cases. > > Best Regards > > Sebastian > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Sebastian, I answered in my blog: http://danwalsh.livejournal.com/24147.html From mmcallis at redhat.com Wed Sep 17 06:56:35 2008 From: mmcallis at redhat.com (Murray McAllister) Date: Wed, 17 Sep 2008 16:56:35 +1000 Subject: restoring default selinux policy configuration Message-ID: <48D0AA23.1040702@redhat.com> Hi, If I change a lot of booleans, or install a lot of custom policies, is there any way to restore selinux policy (targeted) to its default configuration? Thanks. From dwalsh at redhat.com Wed Sep 17 12:10:34 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 17 Sep 2008 08:10:34 -0400 Subject: restoring default selinux policy configuration In-Reply-To: <48D0AA23.1040702@redhat.com> References: <48D0AA23.1040702@redhat.com> Message-ID: <48D0F3BA.1020300@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Murray McAllister wrote: > Hi, > > If I change a lot of booleans, or install a lot of custom policies, is > there any way to restore selinux policy (targeted) to its default > configuration? > > Thanks. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Well semanage does have a -D option to remove all local customizations for the object man semanage ... -D, --deleteall Remove all OBJECTS local customizations Example: semanage ports -D Would remove all port changes. There is no way to do this with modules currently. You could look at the modules in /usr/share/selinux/targeted/*.pp and compare them to semodule -l to see any modules that were different and use semodule -r MODNAME to remove them. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjQ87gACgkQrlYvE4MpobMHigCfXrph1KpagtXk2EbwYrsGTrjb c3YAn04JaTzLSTanFK5irxBC1mBKlmAh =wNCb -----END PGP SIGNATURE----- From eparis at redhat.com Wed Sep 17 12:16:39 2008 From: eparis at redhat.com (Eric Paris) Date: Wed, 17 Sep 2008 08:16:39 -0400 Subject: restoring default selinux policy configuration In-Reply-To: <48D0F3BA.1020300@redhat.com> References: <48D0AA23.1040702@redhat.com> <48D0F3BA.1020300@redhat.com> Message-ID: <1221653799.15373.2.camel@localhost.localdomain> On Wed, 2008-09-17 at 08:10 -0400, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Murray McAllister wrote: > > Hi, > > > > If I change a lot of booleans, or install a lot of custom policies, is > > there any way to restore selinux policy (targeted) to its default > > configuration? > > > > Thanks. > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Well semanage does have a -D option to remove all local customizations > for the object > > man semanage > .. > > -D, --deleteall > Remove all OBJECTS local customizations > > > > Example: > > semanage ports -D > > Would remove all port changes. > > There is no way to do this with modules currently. > > You could look at the modules in /usr/share/selinux/targeted/*.pp > and compare them to semodule -l to see any modules that were different > and use semodule -r MODNAME to remove them. Gross horrible dangerous hack, be VERY careful, might eat your first born, kidnap your grandmother, and blow your house down... rpm -e --nodeps --justdb selinux-policy-targeted rm -rf /etc/selinux/targeted yum install selinux-policy-targeted touch /.autorelabel reboot yes? no? From fs at WPI.EDU Wed Sep 17 15:52:32 2008 From: fs at WPI.EDU (Frank Sweetser) Date: Wed, 17 Sep 2008 11:52:32 -0400 Subject: Backing up and restoring SELinux file contexts Message-ID: <48D127C0.4040705@wpi.edu> I'm looking at helping to extend the Bacula backup system to handle SELinux file contexts, and I wanted to make sure I'm going down the right path. Now as I understand it, the context associated with a file on disk can be retrieved via getfilecon, and set via setfilecon. However, on disk, the context is stored as an extended attribute, which are handled via getxattr and setxattr. So my question is, is it practical to just use the *xattr functions to backup and restore the file contexts, or do I need to perform an explicit check to see if I'm running on an SELinux system and, if so, use the *filecon functions instead? I'd prefer to use the *xattr functions if at all possible, since that would simplify a lot of cases, such as restoring an SELinux system from a non SELinux aware rescue disk, but want to make sure there aren't any gotchas I'm missing. -- Frank Sweetser fs at wpi.edu | For every problem, there is a solution that WPI Senior Network Engineer | is simple, elegant, and wrong. - HL Mencken GPG fingerprint = 6174 1257 129E 0D21 D8D4 E8A3 8E39 29E3 E2E8 8CEC From dwalsh at redhat.com Wed Sep 17 20:41:29 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 17 Sep 2008 16:41:29 -0400 Subject: restoring default selinux policy configuration In-Reply-To: <1221653799.15373.2.camel@localhost.localdomain> References: <48D0AA23.1040702@redhat.com> <48D0F3BA.1020300@redhat.com> <1221653799.15373.2.camel@localhost.localdomain> Message-ID: <48D16B79.5080100@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Paris wrote: > On Wed, 2008-09-17 at 08:10 -0400, Daniel J Walsh wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Murray McAllister wrote: >>> Hi, >>> >>> If I change a lot of booleans, or install a lot of custom policies, is >>> there any way to restore selinux policy (targeted) to its default >>> configuration? >>> >>> Thanks. >>> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> Well semanage does have a -D option to remove all local customizations >> for the object >> >> man semanage >> .. >> >> -D, --deleteall >> Remove all OBJECTS local customizations >> >> >> >> Example: >> >> semanage ports -D >> >> Would remove all port changes. >> >> There is no way to do this with modules currently. >> >> You could look at the modules in /usr/share/selinux/targeted/*.pp >> and compare them to semodule -l to see any modules that were different >> and use semodule -r MODNAME to remove them. > > Gross horrible dangerous hack, be VERY careful, might eat your first > born, kidnap your grandmother, and blow your house down... > > rpm -e --nodeps --justdb selinux-policy-targeted > rm -rf /etc/selinux/targeted > yum install selinux-policy-targeted > touch /.autorelabel > reboot > > yes? no? > I would put the machine in permissive before doing this. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjRa3kACgkQrlYvE4MpobNB+QCfWVCQQ+BceAXpRLMHl78wlyao 59wAoIXrGXp1u928nxPC1GzCH2HwOVsW =n7BG -----END PGP SIGNATURE----- From dwalsh at redhat.com Wed Sep 17 20:43:04 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 17 Sep 2008 16:43:04 -0400 Subject: Backing up and restoring SELinux file contexts In-Reply-To: <48D127C0.4040705@wpi.edu> References: <48D127C0.4040705@wpi.edu> Message-ID: <48D16BD8.1080909@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Frank Sweetser wrote: > I'm looking at helping to extend the Bacula backup system to handle SELinux > file contexts, and I wanted to make sure I'm going down the right path. > > Now as I understand it, the context associated with a file on disk can be > retrieved via getfilecon, and set via setfilecon. > > However, on disk, the context is stored as an extended attribute, which are > handled via getxattr and setxattr. > > So my question is, is it practical to just use the *xattr functions to backup > and restore the file contexts, or do I need to perform an explicit check to > see if I'm running on an SELinux system and, if so, use the *filecon functions > instead? I'd prefer to use the *xattr functions if at all possible, since > that would simplify a lot of cases, such as restoring an SELinux system from a > non SELinux aware rescue disk, but want to make sure there aren't any gotchas > I'm missing. > I would not make your tool know anything about SELinux. It should just back up and restore all extended attributes. SELinux is not the only user of xattrs and more tools in the future might use it. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjRa9cACgkQrlYvE4MpobOvCQCdG/u3ZxR/mpJ+IrDfFDRoYnfo QqUAn3ZKCy/tE47c1cqFoHYnz5JVPieH =bL8J -----END PGP SIGNATURE----- From mmcallis at redhat.com Wed Sep 17 23:17:40 2008 From: mmcallis at redhat.com (Murray McAllister) Date: Thu, 18 Sep 2008 09:17:40 +1000 Subject: restoring default selinux policy configuration In-Reply-To: <48D16B79.5080100@redhat.com> References: <48D0AA23.1040702@redhat.com> <48D0F3BA.1020300@redhat.com> <1221653799.15373.2.camel@localhost.localdomain> <48D16B79.5080100@redhat.com> Message-ID: <48D19014.1080709@redhat.com> Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Eric Paris wrote: >> On Wed, 2008-09-17 at 08:10 -0400, Daniel J Walsh wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Murray McAllister wrote: >>>> Hi, >>>> >>>> If I change a lot of booleans, or install a lot of custom policies, is >>>> there any way to restore selinux policy (targeted) to its default >>>> configuration? >>>> >>>> Thanks. >>>> >>>> -- >>>> fedora-selinux-list mailing list >>>> fedora-selinux-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>> Well semanage does have a -D option to remove all local customizations >>> for the object >>> >>> man semanage >>> .. >>> >>> -D, --deleteall >>> Remove all OBJECTS local customizations >>> >>> >>> >>> Example: >>> >>> semanage ports -D >>> >>> Would remove all port changes. >>> >>> There is no way to do this with modules currently. >>> >>> You could look at the modules in /usr/share/selinux/targeted/*.pp >>> and compare them to semodule -l to see any modules that were different >>> and use semodule -r MODNAME to remove them. >> Gross horrible dangerous hack, be VERY careful, might eat your first >> born, kidnap your grandmother, and blow your house down... >> >> rpm -e --nodeps --justdb selinux-policy-targeted >> rm -rf /etc/selinux/targeted >> yum install selinux-policy-targeted >> touch /.autorelabel >> reboot >> >> yes? no? >> > I would put the machine in permissive before doing this. Thanks. Should something like this be in the selinux user guide? The commands above look safe to me - what's the worse that can happen? Do problems occur if you don't relabel after the above steps? > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkjRa3kACgkQrlYvE4MpobNB+QCfWVCQQ+BceAXpRLMHl78wlyao > 59wAoIXrGXp1u928nxPC1GzCH2HwOVsW > =n7BG > -----END PGP SIGNATURE----- From paul at city-fan.org Wed Sep 17 23:29:27 2008 From: paul at city-fan.org (Paul Howarth) Date: Thu, 18 Sep 2008 00:29:27 +0100 Subject: restoring default selinux policy configuration In-Reply-To: <48D19014.1080709@redhat.com> References: <48D0AA23.1040702@redhat.com> <48D0F3BA.1020300@redhat.com> <1221653799.15373.2.camel@localhost.localdomain> <48D16B79.5080100@redhat.com> <48D19014.1080709@redhat.com> Message-ID: <20080918002927.08cad18d@metropolis.intra.city-fan.org> On Thu, 18 Sep 2008 09:17:40 +1000 Murray McAllister wrote: > Daniel J Walsh wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Eric Paris wrote: > >> On Wed, 2008-09-17 at 08:10 -0400, Daniel J Walsh wrote: > >>> -----BEGIN PGP SIGNED MESSAGE----- > >>> Hash: SHA1 > >>> > >>> Murray McAllister wrote: > >>>> Hi, > >>>> > >>>> If I change a lot of booleans, or install a lot of custom > >>>> policies, is there any way to restore selinux policy (targeted) > >>>> to its default configuration? > >>>> > >>>> Thanks. > >>>> > >>>> -- > >>>> fedora-selinux-list mailing list > >>>> fedora-selinux-list at redhat.com > >>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > >>> Well semanage does have a -D option to remove all local > >>> customizations for the object > >>> > >>> man semanage > >>> .. > >>> > >>> -D, --deleteall > >>> Remove all OBJECTS local customizations > >>> > >>> > >>> > >>> Example: > >>> > >>> semanage ports -D > >>> > >>> Would remove all port changes. > >>> > >>> There is no way to do this with modules currently. > >>> > >>> You could look at the modules in /usr/share/selinux/targeted/*.pp > >>> and compare them to semodule -l to see any modules that were > >>> different and use semodule -r MODNAME to remove them. > >> Gross horrible dangerous hack, be VERY careful, might eat your > >> first born, kidnap your grandmother, and blow your house down... > >> > >> rpm -e --nodeps --justdb selinux-policy-targeted > >> rm -rf /etc/selinux/targeted > >> yum install selinux-policy-targeted > >> touch /.autorelabel > >> reboot > >> > >> yes? no? > >> > > I would put the machine in permissive before doing this. > > Thanks. Should something like this be in the selinux user guide? The > commands above look safe to me - what's the worse that can happen? > > Do problems occur if you don't relabel after the above steps? You may have removed policy modules that included new file context types that were in use on the system. Files originally labelled with those types will be unlabelled after removing the modules, hence the need to relabel. Paul. From fs at WPI.EDU Thu Sep 18 02:06:34 2008 From: fs at WPI.EDU (Frank Sweetser) Date: Wed, 17 Sep 2008 22:06:34 -0400 Subject: Backing up and restoring SELinux file contexts In-Reply-To: <48D16BD8.1080909@redhat.com> References: <48D127C0.4040705@wpi.edu> <48D16BD8.1080909@redhat.com> Message-ID: <48D1B7AA.6000308@wpi.edu> Daniel J Walsh wrote: > Frank Sweetser wrote: >> I'm looking at helping to extend the Bacula backup system to handle SELinux >> file contexts, and I wanted to make sure I'm going down the right path. > >> Now as I understand it, the context associated with a file on disk can be >> retrieved via getfilecon, and set via setfilecon. > >> However, on disk, the context is stored as an extended attribute, which are >> handled via getxattr and setxattr. > >> So my question is, is it practical to just use the *xattr functions to backup >> and restore the file contexts, or do I need to perform an explicit check to >> see if I'm running on an SELinux system and, if so, use the *filecon functions >> instead? I'd prefer to use the *xattr functions if at all possible, since >> that would simplify a lot of cases, such as restoring an SELinux system from a >> non SELinux aware rescue disk, but want to make sure there aren't any gotchas >> I'm missing. > > I would not make your tool know anything about SELinux. It should just > back up and restore all extended attributes. SELinux is not the only > user of xattrs and more tools in the future might use it. Thanks - that's exactly the answer I was hoping for. -- Frank Sweetser fs at wpi.edu | For every problem, there is a solution that WPI Senior Network Engineer | is simple, elegant, and wrong. - HL Mencken GPG fingerprint = 6174 1257 129E 0D21 D8D4 E8A3 8E39 29E3 E2E8 8CEC From eparis at redhat.com Thu Sep 18 13:53:16 2008 From: eparis at redhat.com (Eric Paris) Date: Thu, 18 Sep 2008 09:53:16 -0400 Subject: restoring default selinux policy configuration In-Reply-To: <48D19014.1080709@redhat.com> References: <48D0AA23.1040702@redhat.com> <48D0F3BA.1020300@redhat.com> <1221653799.15373.2.camel@localhost.localdomain> <48D16B79.5080100@redhat.com> <48D19014.1080709@redhat.com> Message-ID: <1221745996.15373.194.camel@localhost.localdomain> On Thu, 2008-09-18 at 09:17 +1000, Murray McAllister wrote: > Thanks. Should something like this be in the selinux user guide? The > commands above look safe to me - what's the worse that can happen? > > Do problems occur if you don't relabel after the above steps? It could be in the guide, but it better be prefaced with something like I gave it :) The worst that happens is your system completely dies and locks you out the instant you start to install selinux-policy-targeted. If your local customizations caused your shell process to run as a type or user or whatever that isn't defined when you start loading the new policy things could esplode (permissive is a must and should stop you from locking yourself out/failing to actually install the original policy, I'm glad dan remembered) You need to autorelabel because you have no idea what types were valid that are not longer valid (all of those in custom modules you just removed are now invalid) Labeling could be so different that you need to reboot in permissive to even get it boot to the point where it can autorelabel. Perfect steps would be setenforce 0 [run my steps] stop grub and add enforcing=0 finish boot setenforce 1 Do all that and you should be safe :) -Eric From dwalsh at redhat.com Thu Sep 18 18:18:22 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 18 Sep 2008 14:18:22 -0400 Subject: restoring default selinux policy configuration In-Reply-To: <48D19014.1080709@redhat.com> References: <48D0AA23.1040702@redhat.com> <48D0F3BA.1020300@redhat.com> <1221653799.15373.2.camel@localhost.localdomain> <48D16B79.5080100@redhat.com> <48D19014.1080709@redhat.com> Message-ID: <48D29B6E.2090606@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Murray McAllister wrote: > Daniel J Walsh wrote: > Eric Paris wrote: >>>> On Wed, 2008-09-17 at 08:10 -0400, Daniel J Walsh wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> Murray McAllister wrote: >>>>>> Hi, >>>>>> >>>>>> If I change a lot of booleans, or install a lot of custom policies, is >>>>>> there any way to restore selinux policy (targeted) to its default >>>>>> configuration? >>>>>> >>>>>> Thanks. >>>>>> >>>>>> -- >>>>>> fedora-selinux-list mailing list >>>>>> fedora-selinux-list at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>>>> Well semanage does have a -D option to remove all local customizations >>>>> for the object >>>>> >>>>> man semanage >>>>> .. >>>>> >>>>> -D, --deleteall >>>>> Remove all OBJECTS local customizations >>>>> >>>>> >>>>> >>>>> Example: >>>>> >>>>> semanage ports -D >>>>> >>>>> Would remove all port changes. >>>>> >>>>> There is no way to do this with modules currently. >>>>> >>>>> You could look at the modules in /usr/share/selinux/targeted/*.pp >>>>> and compare them to semodule -l to see any modules that were different >>>>> and use semodule -r MODNAME to remove them. >>>> Gross horrible dangerous hack, be VERY careful, might eat your first >>>> born, kidnap your grandmother, and blow your house down... >>>> >>>> rpm -e --nodeps --justdb selinux-policy-targeted >>>> rm -rf /etc/selinux/targeted >>>> yum install selinux-policy-targeted >>>> touch /.autorelabel >>>> reboot >>>> >>>> yes? no? >>>> > I would put the machine in permissive before doing this. > >> Thanks. Should something like this be in the selinux user guide? The >> commands above look safe to me - what's the worse that can happen? > >> Do problems occur if you don't relabel after the above steps? > > > No I believe a better solution would be # setenforce 0 # yum remove selinux-policy\* # rm -rf /etc/selinux/targeted /etc/selinux/config # yum install selinux-policy-targeted # yum install selinux-policy-devel policycoreutils-gui *** Only if these were removed byt the yum remove. touch /.autorelabel; reboot Which will get the postinstall scripts to run properly. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjSm2oACgkQrlYvE4MpobPB7wCfU7jyn9S2OITIVqqj9urtWIvr zpcAoKfCIRR2oEVTcmxwBHqSzRCg8Xrr =aRvi -----END PGP SIGNATURE----- From fedora02 at grifent.com Fri Sep 19 16:11:56 2008 From: fedora02 at grifent.com (John Griffiths) Date: Fri, 19 Sep 2008 12:11:56 -0400 Subject: sealert won't erase some entries In-Reply-To: <20080919160025.73EFE8E0326@hormel.redhat.com> References: <20080919160025.73EFE8E0326@hormel.redhat.com> Message-ID: <48D3CF4C.8000908@grifent.com> I need some guidance. I have four entries that show up in sealert browser mode that will not erase. I select them, delete them, and remove those that are marked deleted and nothing happens. There are only four entries that do this. The other log entires can be deleted just fine. The four entries don't seem to cause any problems; they are just an annoyance. Any help would be appreciated. Thanks, John From jdennis at redhat.com Fri Sep 19 16:32:21 2008 From: jdennis at redhat.com (John Dennis) Date: Fri, 19 Sep 2008 12:32:21 -0400 Subject: sealert won't erase some entries In-Reply-To: <48D3CF4C.8000908@grifent.com> References: <20080919160025.73EFE8E0326@hormel.redhat.com> <48D3CF4C.8000908@grifent.com> Message-ID: <48D3D415.30203@redhat.com> John Griffiths wrote: > I need some guidance. > > I have four entries that show up in sealert browser mode that will not > erase. I select them, delete them, and remove those that are marked > deleted and nothing happens. There are only four entries that do this. > The other log entires can be deleted just fine. > > The four entries don't seem to cause any problems; they are just an > annoyance. Any help would be appreciated. Are you seeing a message complaining you're not the owner of those alerts? If memory serves me correctly the message will appear in the status bar at the bottom of the window. If so you'll have to either su to the owner of the alerts or login in as them in order to delete them. If that's not the case then: Please open a bug report (https://bugzilla.redhat.com) using the component "setroubleshoot" Add the description from above and then attach to the bug report this file: /var/lib/setroubleshoot/audit_listener_database.xml Don't forget to specify the rpm version of setroubleshoot you're using: rpm -q setroubleshoot -- John Dennis From dcarter at entertain-me.com Fri Sep 19 17:09:30 2008 From: dcarter at entertain-me.com (David Carter) Date: Fri, 19 Sep 2008 14:39:30 -0230 Subject: Advice needed designing packages for selinux Message-ID: Hey folks! Here's some architectural background on my application. I have two pieces: an agent and a library that links with an application. The library communicates with the agent via semaphores, message queues, and shared memory. The files corresponding to these IPC mechanisms had been stored in /tmp. But here's the rub. The agent could run in root space as a system wide agent, but also in user space as a development and debugging tool. To facilitate this, each instance creates it's own subdirectory to hold the IPC files. Since they'll need to clean this up when they're done, I'd set the sticky bit on the directory. So know, if I move the system queues to /var/lib as I should, I have to have the sticky but set there, which is bad. Alternatively, if I leave it in the /tmp directory, I don't see how I can set the ACL's that selinux requires. The third option is to give any applications requiring access permissions so broad as to defeat the purpose of selinux. And the fourth is to disable selinux entirely, which is also not good. Advice? TIA, Dave From fedora02 at grifent.com Fri Sep 19 17:16:15 2008 From: fedora02 at grifent.com (John Griffiths) Date: Fri, 19 Sep 2008 13:16:15 -0400 Subject: sealert won't erase some entries In-Reply-To: <48D3D415.30203@redhat.com> References: <20080919160025.73EFE8E0326@hormel.redhat.com> <48D3CF4C.8000908@grifent.com> <48D3D415.30203@redhat.com> Message-ID: <48D3DE5F.7080707@grifent.com> John Dennis wrote: > John Griffiths wrote: >> I need some guidance. >> >> I have four entries that show up in sealert browser mode that will >> not erase. I select them, delete them, and remove those that are >> marked deleted and nothing happens. There are only four entries that >> do this. The other log entires can be deleted just fine. >> >> The four entries don't seem to cause any problems; they are just an >> annoyance. Any help would be appreciated. > > Are you seeing a message complaining you're not the owner of those > alerts? If memory serves me correctly the message will appear in the > status bar at the bottom of the window. If so you'll have to either su > to the owner of the alerts or login in as them in order to delete them. No. > > If that's not the case then: > > Please open a bug report (https://bugzilla.redhat.com) using the > component "setroubleshoot" done https://bugzilla.redhat.com/show_bug.cgi?id=462913 > > Add the description from above and then attach to the bug report this > file: > /var/lib/setroubleshoot/audit_listener_database.xml and done > > Don't forget to specify the rpm version of setroubleshoot you're using: > rpm -q setroubleshoot > and done setroubleshoot-2.0.5-2.fc8 Thanks, John From yiruli at ccsl.carleton.ca Sat Sep 20 19:14:55 2008 From: yiruli at ccsl.carleton.ca (yiruli at ccsl.carleton.ca) Date: Sat, 20 Sep 2008 15:14:55 -0400 Subject: where can I find source policy for Mozilla Browser (Firefox) Message-ID: <20080920151455.xung98y1ogk08owk@www.ccsl.carleton.ca> Hi, Where can I find the source policy for Mozilla Firefox? From the SELinux administration tool, I see that Mozilla module has been loaded? But I find the following through the command "ps -Z": unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 2600 ? 00:17:34 firefox Can I say that the policy for Firefox in my machine is not enforced yet? How can I make the policy be enforced? What is the status of the policy writing for Firefox? In one web article, Dan said that the policy writing for Firefox has little success due to its variant behaviour. I am a beginner of SELinux. Thanks a lot. Yiru From jason at rampaginggeek.com Sat Sep 20 20:27:43 2008 From: jason at rampaginggeek.com (Jason Edgecombe) Date: Sat, 20 Sep 2008 16:27:43 -0400 Subject: where can I find source policy for Mozilla Browser (Firefox) In-Reply-To: <20080920151455.xung98y1ogk08owk@www.ccsl.carleton.ca> References: <20080920151455.xung98y1ogk08owk@www.ccsl.carleton.ca> Message-ID: <48D55CBF.9080907@rampaginggeek.com> yiruli at ccsl.carleton.ca wrote: > Hi, > Where can I find the source policy for Mozilla Firefox? > > From the SELinux administration tool, I see that Mozilla module has > been loaded? > > But I find the following through the command "ps -Z": > unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 2600 ? 00:17:34 > firefox > > Can I say that the policy for Firefox in my machine is not enforced yet? > > How can I make the policy be enforced? > > What is the status of the policy writing for Firefox? > In one web article, Dan said that the policy writing for Firefox has > little success due to its variant behaviour. What about changing the root password, then giving the customer (and other internal people) access vis sudo with an auditing shell like eash. They still have a root shell, it's just audited now. See http://www.rootprompt.org/article.php3?article=10015 If you don't have selinux, then you can also write library that logs the system calls that you want and load it with LD_PRELOAD in a script that is run via sudo. Jason From Valdis.Kletnieks at vt.edu Sun Sep 21 04:25:41 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 21 Sep 2008 00:25:41 -0400 Subject: where can I find source policy for Mozilla Browser (Firefox) In-Reply-To: Your message of "Sat, 20 Sep 2008 16:27:43 EDT." <48D55CBF.9080907@rampaginggeek.com> References: <20080920151455.xung98y1ogk08owk@www.ccsl.carleton.ca> <48D55CBF.9080907@rampaginggeek.com> Message-ID: <26923.1221971141@turing-police.cc.vt.edu> On Sat, 20 Sep 2008 16:27:43 EDT, Jason Edgecombe said: > yiruli at ccsl.carleton.ca wrote: > > Hi, > > Where can I find the source policy for Mozilla Firefox? > > > > From the SELinux administration tool, I see that Mozilla module has > > been loaded? > > > > But I find the following through the command "ps -Z": > > unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 2600 ? 00:17:34 > > firefox > > > > Can I say that the policy for Firefox in my machine is not enforced yet? > > > > How can I make the policy be enforced? > > > > What is the status of the policy writing for Firefox? > > In one web article, Dan said that the policy writing for Firefox has > > little success due to its variant behaviour. > What about changing the root password, then giving the customer (and > other internal people) access vis sudo with an auditing shell like eash. > They still have a root shell, it's just audited now. That's not addressing the *big* problem with things like Firefox. The original poster probably wants Firefox policy enforced so that if an exploit is found in Firefox, the damage is basically contained to the user's ~/.mozilla directory (where Firefox reads/writes it files), and the now-rogue Firefox process can't go snooping around in other sensitive files (like the ones in your .ssh or .gpg directories). I don't see where the root password even enters into it - does *anybody* run a browser as root? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From mmcallis at redhat.com Mon Sep 22 04:05:34 2008 From: mmcallis at redhat.com (Murray McAllister) Date: Mon, 22 Sep 2008 14:05:34 +1000 Subject: was selinux-policy-devel merged into selinux-policy Message-ID: <48D7198E.3070409@redhat.com> Hi, Sorry for the silly question. On Fedora 9, "rpm -qf /usr/share/selinux/devel/policygentool" says that it belongs to selinux-policy-devel-3.3.1-87.fc9. On rawhide, "rpm -qf /usr/share/selinux/devel/policygentool" says that it belongs to selinux-policy-3.5.7-1.fc10.noarch. When I try "yum install selinux-policy-devel", it says that selinux-policy-3.5.7-1.fc10.noarch is already installed. Was selinux-policy-devel merged into selinux-policy? (I looked in the selinux-policy changelog but wasn't sure) Thanks. From joe at nall.com Mon Sep 22 04:44:23 2008 From: joe at nall.com (Joe Nall) Date: Sun, 21 Sep 2008 23:44:23 -0500 Subject: was selinux-policy-devel merged into selinux-policy In-Reply-To: <48D7198E.3070409@redhat.com> References: <48D7198E.3070409@redhat.com> Message-ID: On Sep 21, 2008, at 11:05 PM, Murray McAllister wrote: > Hi, > > Sorry for the silly question. On Fedora 9, "rpm -qf /usr/share/ > selinux/devel/policygentool" says that it belongs to selinux-policy- > devel-3.3.1-87.fc9. > > On rawhide, "rpm -qf /usr/share/selinux/devel/policygentool" says > that it belongs to selinux-policy-3.5.7-1.fc10.noarch. > > When I try "yum install selinux-policy-devel", it says that selinux- > policy-3.5.7-1.fc10.noarch is already installed. > > Was selinux-policy-devel merged into selinux-policy? (I looked in > the selinux-policy changelog but wasn't sure) Yes rpm -q -provides selinux-policy joe From sds at tycho.nsa.gov Mon Sep 22 14:42:28 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 22 Sep 2008 10:42:28 -0400 Subject: where can I find source policy for Mozilla Browser (Firefox) In-Reply-To: <20080920151455.xung98y1ogk08owk@www.ccsl.carleton.ca> References: <20080920151455.xung98y1ogk08owk@www.ccsl.carleton.ca> Message-ID: <1222094548.18735.3.camel@moss-spartans.epoch.ncsc.mil> On Sat, 2008-09-20 at 15:14 -0400, yiruli at ccsl.carleton.ca wrote: > Hi, > Where can I find the source policy for Mozilla Firefox? > > From the SELinux administration tool, I see that Mozilla module has > been loaded? > > But I find the following through the command "ps -Z": > unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 2600 ? 00:17:34 firefox > > Can I say that the policy for Firefox in my machine is not enforced yet? > > How can I make the policy be enforced? > > What is the status of the policy writing for Firefox? > In one web article, Dan said that the policy writing for Firefox has > little success due to its variant behaviour. Try mapping your user identity to a confined user (e.g user_u or staff_u) via semanage login or system-config-selinux, and see if that yields firefox running in its own domain. Fedora policy likely only defines transition from the confined user domains to the browser domain. Or you could add a local policy module that defines a transition from unconfined_t to mozilla_t. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Mon Sep 22 15:19:26 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 22 Sep 2008 11:19:26 -0400 Subject: Advice needed designing packages for selinux In-Reply-To: References: Message-ID: <48D7B77E.2050805@redhat.com> David Carter wrote: > Hey folks! > > Here's some architectural background on my application. I have two > pieces: an agent and a library that links with an application. The > library communicates with the agent via semaphores, message queues, and > shared memory. The files corresponding to these IPC mechanisms had been > stored in /tmp. But here's the rub. The agent could run in root space as > a system wide agent, but also in user space as a development and > debugging tool. To facilitate this, each instance creates it's own > subdirectory to hold the IPC files. Since they'll need to clean this up > when they're done, I'd set the sticky bit on the directory. > > So know, if I move the system queues to /var/lib as I should, I have to > have the sticky but set there, which is bad. Alternatively, if I leave > it in the /tmp directory, I don't see how I can set the ACL's that > selinux requires. The third option is to give any applications requiring > access permissions so broad as to defeat the purpose of selinux. And the > fourth is to disable selinux entirely, which is also not good. > > Advice? > Why not use communication via /var/run? Which is cleaned up automatically? Also have it attempt /var/run when you start and fall back to /tmp so if you are working in development, you would use /tmp and in productions /var/run. You should also potentially look at the abstract namespace for socket communication (X Windows now uses this). > TIA, > Dave > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From dwalsh at redhat.com Mon Sep 22 15:28:36 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 22 Sep 2008 11:28:36 -0400 Subject: where can I find source policy for Mozilla Browser (Firefox) In-Reply-To: <20080920151455.xung98y1ogk08owk@www.ccsl.carleton.ca> References: <20080920151455.xung98y1ogk08owk@www.ccsl.carleton.ca> Message-ID: <48D7B9A4.50909@redhat.com> yiruli at ccsl.carleton.ca wrote: > Hi, > Where can I find the source policy for Mozilla Firefox? > > From the SELinux administration tool, I see that Mozilla module has been > loaded? > > But I find the following through the command "ps -Z": > unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 2600 ? 00:17:34 > firefox > > Can I say that the policy for Firefox in my machine is not enforced yet? > > How can I make the policy be enforced? > > What is the status of the policy writing for Firefox? > In one web article, Dan said that the policy writing for Firefox has > little success due to its variant behaviour. > > I am a beginner of SELinux. > Thanks a lot. > Yiru > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list In the Fedora the only transition domain that transitions to firefox policy is xguest. Every other user type including unconfined_t above runs firefox without transition. So if ps -eZ | grep firefox shows unconfined_t firefox, it means it has the privs of the unconfined_t domain. It can do everything the users shell can do. There is policy to confine mozilla, but usually this ends up breaking more things then users are willing to put up with. So we have decided to concentrate on confining the users (staff_t, user_t, xguest_t, guest_t) and the plugins. So firefox might run in staff_t but the plugin it execs will run in staff_nsplugin_t. Plugins have a very confined domain. The real problem with confining firefox is the number of applications that it launches (openoffice, evince, acroread, email...) And writing policy for the confinement of all of these, plus the interaction with users launching the same apps from the toolbar is just not manageable. So what does the mozilla policy do that is loaded on my machine, well it defined file context for directories like .mozilla. It also is used for the transition from xguest_t to xguest_mozilla_t. From mike.clarkson at baesystems.com Mon Sep 22 19:42:20 2008 From: mike.clarkson at baesystems.com (Clarkson, Mike R (US SSA)) Date: Mon, 22 Sep 2008 12:42:20 -0700 Subject: giving ftp access to specif files and directories Message-ID: <738lm5$i52id@dmzms99801.na.baesystems.com> In RHEL5.1, I don't see an interface allowing the policy writer to give the ftp daemon access to specific file and directory types. This would be nice to have. From joe at nall.com Tue Sep 23 13:16:21 2008 From: joe at nall.com (Joe Nall) Date: Tue, 23 Sep 2008 08:16:21 -0500 Subject: openoffice_plugin_per_role_template Message-ID: <2882576A-C80A-4AF7-8EFF-430597C9B691@nall.com> Is this misnamed? It has a per_role_template name but is an interface in policy 3.5.6-4. joe From dwalsh at redhat.com Tue Sep 23 16:16:27 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 23 Sep 2008 12:16:27 -0400 Subject: giving ftp access to specif files and directories In-Reply-To: <738lm5$i52id@dmzms99801.na.baesystems.com> References: <738lm5$i52id@dmzms99801.na.baesystems.com> Message-ID: <48D9165B.9070601@redhat.com> Clarkson, Mike R (US SSA) wrote: > In RHEL5.1, I don't see an interface allowing the policy writer to give > the ftp daemon access to specific file and directory types. This would > be nice to have. > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Not sure what you are after here. Do you want to label a directory or file with public_content_t will allow ftp to gain access. If the files are labeled something non default you could add allow rules using audit2allow -M myftp. If you want to add a type specific to ftp that other daemons would not have access to IE Not public_content_t, you could define a module type ftp_content_t; files_type(ftp_content_t) ... Then allow access. And set the labeling correct From mike.clarkson at baesystems.com Tue Sep 23 20:58:22 2008 From: mike.clarkson at baesystems.com (Clarkson, Mike R (US SSA)) Date: Tue, 23 Sep 2008 13:58:22 -0700 Subject: giving ftp access to specif files and directories Message-ID: <737og9$4hkjo@dmzms99902.na.baesystems.com> OK, I'll get more specific. Let's say I've got some_program that I've created a policy module for so that it runs in the some_program_t domain. Suppose some_program uses files for various purposes and the module has labeled them, such that all the files under the /local/some_dir directory are labeled some_file_t. Further suppose that some_program uses ftp to transfer one or more of the files labeled some_file_t, and that the policy writer does not want to label these files public_content_t. The policy writer can do something like this: require {type ftpd_t;} allow ftpd_t some_file_t:file ; Rules giving ftpt_t access to other objects belong in the ftp module, but the policy writer really doesn't want to modify the ftp module for obvious reasons. This is where it would be nice to have interfaces in the ftp module that allowed policy writers to give the ftpd_t domain access to files and directories of specific types. There could either be a series of interfaces giving different permissions to choose from or it could be handled by a generic interface such as this: ################################################ ## ## Give the ftpd_t access to specified file type. ## ## ## ## File type to which ftpd_t needs access ## ## Type of object (i.e. file or dir) ## ## ## Permission needed by ftpd_t(i.e. read, write, etc.) ## interface(`give_ftp_access',` gen_require(` type ftpd_t; ') allow ftpd_t $1:$2 $3; ') > -----Original Message----- > From: Daniel J Walsh [mailto:dwalsh at redhat.com] > Sent: Tuesday, September 23, 2008 9:16 AM > To: Clarkson, Mike R (US SSA) > Cc: fedora-selinux-list at redhat.com > Subject: Re: giving ftp access to specif files and directories > > Clarkson, Mike R (US SSA) wrote: > > In RHEL5.1, I don't see an interface allowing the policy writer to give > > the ftp daemon access to specific file and directory types. This would > > be nice to have. > > > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Not sure what you are after here. Do you want to label a directory or > file with public_content_t will allow ftp to gain access. > > If the files are labeled something non default you could add allow rules > using audit2allow -M myftp. > > If you want to add a type specific to ftp that other daemons would not > have access to IE Not public_content_t, you could define a module > > type ftp_content_t; > files_type(ftp_content_t) > > ... > > Then allow access. And set the labeling correct From yiruli at ccsl.carleton.ca Wed Sep 24 18:51:25 2008 From: yiruli at ccsl.carleton.ca (yiruli at ccsl.carleton.ca) Date: Wed, 24 Sep 2008 14:51:25 -0400 Subject: nsplugin module files are not in / Message-ID: <20080924145125.qg8n5kp5ogk8sg4k@www.ccsl.carleton.ca> nsplugin.pp is loaded in my machines. But I can not find the three module files--nsplugin.if, nsplugin.te, and nsplugin.fc? Should not they be in the directory /serefpolicy-3.3.1/policy/modules/apps of the src.rpm package? thanks a lot. Yiru From paul at city-fan.org Wed Sep 24 22:01:48 2008 From: paul at city-fan.org (Paul Howarth) Date: Wed, 24 Sep 2008 23:01:48 +0100 Subject: nsplugin module files are not in / In-Reply-To: <20080924145125.qg8n5kp5ogk8sg4k@www.ccsl.carleton.ca> References: <20080924145125.qg8n5kp5ogk8sg4k@www.ccsl.carleton.ca> Message-ID: <20080924230148.5a6982c6@metropolis.intra.city-fan.org> On Wed, 24 Sep 2008 14:51:25 -0400 yiruli at ccsl.carleton.ca wrote: > > nsplugin.pp is loaded in my machines. > > But I can not find the three module files--nsplugin.if, nsplugin.te, > and nsplugin.fc? > > Should not they be in the directory > /serefpolicy-3.3.1/policy/modules/apps of the src.rpm package? It is, if you "prep" the SRPM (unpack the tarball, apply patches, etc.). The nsplugin module comes from policy-20071130.patch. Paul. From belfrancis2001 at yahoo.ca Wed Sep 24 23:00:13 2008 From: belfrancis2001 at yahoo.ca (Francis K Shim) Date: Wed, 24 Sep 2008 19:00:13 -0400 Subject: SELinux detects problem with proprietary binary fglrx driver; however, AMD/ATI will not help Message-ID: <1222297213.11556.18.camel@mobile-pc.localdomain> I am submitting this report to this list for documentation, perspectives and, hopefully, helpful assistance towards resolving this issue. Sorry in advance for the length of this post. First reported to the Unofficial Wiki + Bugzilla of the ATI fglrx binary, then to AMD/ATI technical support was the following issue: I have the following configuration: * Lenovo Thinkpad T60p * ATI Mobility FireGL V5250 graphics card * version 8.52.3 of the fglrx module * Fedora 8 running version 2.6.25.14-69.fc8 of the GNU/Linux kernel *NOTE: I have upgraded the kernel and driver from the first indications of the problem; hence, older versions are in the bug report below. However, the same bug persists according to both symptoms and to the security log. At intermittent start-ups of the X server using the fglrx driver the X server does not display due to a security compatibility problem between the fglrx driver and the secure SELinux module of the GNU/linux kernel. The following is the report from the system log outlining the problem: SELinux: out of range capability -157851600 ------------[ cut here ]------------ kernel BUG at security/selinux/hooks.c:1332! invalid opcode: 0000 [#1] SMP Modules linked in: ipv6 snd_hda_intel snd_seq_dummy snd_seq_oss arc4 snd_seq_midi_event snd_seq ecb snd_seq_device crypto_blkcipher snd_pcm_oss snd_mixer_oss snd_pcm i2c_i801 iwl3945 iTCO_wdt battery iTCO_vendor_support snd_timer i2c_core ac mac80211 video thinkpad_acpi bay snd_page_alloc irda output snd_hwdep e1000e button snd cfg80211 crc_ccitt fglrx(P)(U) pcspkr hwmon soundcore sr_mod cdrom sg usb_storage ata_piix dm_snapshot dm_zero dm_mirror dm_mod ahci libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: scsi_wait_scan] Pid: 1488, comm: Xorg Tainted: P (2.6.25.6-27.fc8 #1) EIP: 0060:[] EFLAGS: 00213246 CPU: 1 EIP is at task_has_capability+0x46/0x79 EAX: 00000030 EBX: f6976030 ECX: 00203046 EDX: 00203046 ESI: f685f200 EDI: f6959eb0 EBP: f6959ebc ESP: f6959e6c DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process Xorg (pid: 1488, ti=f6959000 task=f6f98000 task.ti=f6959000) Stack: c06d780d f6976030 f6f98000 00000003 f6f98000 f6976030 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 f6976030 f6f98000 f69ca000 f6959ecc c04cd37a f6f98000 f9678400 Call Trace: [] ? selinux_capable+0x1f/0x23 [] ? security_capable+0xc/0xe [] ? __capable+0xb/0x1f [] ? firegl_version+0x0/0x1b0 [fglrx] [] ? capable+0x10/0x12 [] ? firegl_ioctl+0xe7/0x220 [fglrx] [] ? handle_mm_fault+0x64f/0x6ef [] ? ip_firegl_ioctl+0xe/0x10 [fglrx] [] ? vfs_ioctl+0x4e/0x67 [] ? do_vfs_ioctl+0x262/0x279 [] ? selinux_file_ioctl+0xa8/0xab [] ? sys_ioctl+0x40/0x5c [] ? syscall_call+0x7/0xb ======================= Code: 05 00 00 89 d0 f3 ab 8b 4d b8 89 d8 b2 04 c1 f8 05 c6 45 bc 03 89 5d c4 89 4d c0 74 19 48 74 11 53 68 0d 78 6d c0 e8 6d 9e f5 ff <0f> 0b 58 5a eb fe ba 45 00 00 00 8b 46 08 83 e3 1f 0f b7 f2 8d EIP: [] task_has_capability+0x46/0x79 SS:ESP 0068:f6959e6c ---[ end trace 93d33da5bd859df0 ]--- [fglrx:firegl_release] *ERROR* device busy: 1 0 [fglrx] release failed with code -EBUSY -------------------- End of report ------------------- AMD/ATI's response is as follows: I regret there is no support for Linux at this time. Please see the following 737-28027: LINUX support for ATI Video cards LINUX support for ATI Video cards: Although we have drivers for Linux posted on the ATI website, we do not provide technical support for driver or multimedia issues in Linux directly. The Linux drivers available (For laptops, RADEON and All in wonder Products) from AMD are provided are "as is". If you are looking for drivers then go to: http://ati.amd.com/support/driver.html For information regarding the ATI Proprietary Linux Driver visit: http://www.ati.com/products/catalyst/linux.html Our web site offers several links to Linux support websites that may help you. The link below has information that might be helpful to your case. http://wiki.cchtml.com/index.php/Main_Page\ There are also very good articles from third parties: 1. http://www.rage3d.com/content/articles/atilinuxhowto/Linux_ATI.html#SECTION000140000000000000000 2. http://www.linux.org/help/index.html 3. http://www.linuxdoc.org/ 4. http://www.xfree86.org/ To report issues with Linux drivers you can submit an online ticket using the ?Linux Driver Feedback? category, and your report will be received and reviewed/tested by our driver team. Please note that your report will only be responded to if we require additional information. We do not respond to all support inquires. For the Linux Driver Feedback submission page, visit. http://support.ati.com/ics/survey/survey.asp?deptID=894&surveyID=508&type=web ---------------- End of response ----------------- I could disable SELinux and I would not have this problem; however, I was hoping that there was a much secure or safer work-around to this problem. Peace, Frank From jmorris at namei.org Thu Sep 25 04:15:16 2008 From: jmorris at namei.org (James Morris) Date: Thu, 25 Sep 2008 14:15:16 +1000 (EST) Subject: SELinux detects problem with proprietary binary fglrx driver; however, AMD/ATI will not help In-Reply-To: <1222297213.11556.18.camel@mobile-pc.localdomain> References: <1222297213.11556.18.camel@mobile-pc.localdomain> Message-ID: On Wed, 24 Sep 2008, Francis K Shim wrote: > > I could disable SELinux and I would not have this problem; however, I > was hoping that there was a much secure or safer work-around to this > problem. The video driver is inherently dangerous, so the safe approach is not to use it. - James -- James Morris From sundaram at fedoraproject.org Thu Sep 25 10:32:23 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 25 Sep 2008 16:02:23 +0530 Subject: Xfce Live CD and SELinux Message-ID: <48DB68B7.8040203@fedoraproject.org> Hi, While building a live cd in a SELinux enabled system, I get this. Should I still be building live images with SELinux in permissive mode? " Installing: selinux-policy-targeted ##################### [685/918] SELinux: Could not downgrade policy file /etc/selinux/targeted/policy/policy.23, searching for an older version. SELinux: Could not open policy file <= /etc/selinux/targeted/policy/policy.23: No such file or directory /usr/sbin/load_policy: Can't load policy: No such file or directory libsemanage.semanage_reload_policy: load_policy returned error code 2. libsemanage.semanage_install_active: Could not copy /etc/selinux/targeted/modules/active/policy.kern to /etc/selinux/targeted/policy/policy.23. (No such file or directory). semodule: Failed! libsemanage.semanage_link_sandbox: Could not access sandbox base file /etc/selinux/targeted/modules/tmp/base.pp. (No such file or directory). /usr/sbin/semanage: Could not commit semanage transaction /usr/sbin/semanage: Login mapping for __default__ is not defined Installing: authconfig-gtk ##################### [686/918] " Rahul From eparis at redhat.com Thu Sep 25 13:04:45 2008 From: eparis at redhat.com (Eric Paris) Date: Thu, 25 Sep 2008 09:04:45 -0400 Subject: Xfce Live CD and SELinux In-Reply-To: <48DB68B7.8040203@fedoraproject.org> References: <48DB68B7.8040203@fedoraproject.org> Message-ID: <1222347885.2872.78.camel@localhost.localdomain> On Thu, 2008-09-25 at 16:02 +0530, Rahul Sundaram wrote: > Hi, > > While building a live cd in a SELinux enabled system, I get this. Should > I still be building live images with SELinux in permissive mode? I believe everything should be working as long as both the host and the image are updated F9 or rawhide (ok at least libselinux and livecd-creator needs to be updated, and I don't remember what else). F9 GA and earlier is known to have some problems. My guess is that you have a rawhide/updated host and are building a GA image? There might be an issue I didn't originally think about.... Hopefully early next week I'll have time to look at things and if you give me a kickstart file I can help run down problems.... -Eric From eparis at redhat.com Thu Sep 25 13:13:34 2008 From: eparis at redhat.com (Eric Paris) Date: Thu, 25 Sep 2008 09:13:34 -0400 Subject: SELinux detects problem with proprietary binary fglrx driver; however, AMD/ATI will not help In-Reply-To: References: <1222297213.11556.18.camel@mobile-pc.localdomain> Message-ID: <1222348415.2872.87.camel@localhost.localdomain> On Thu, 2008-09-25 at 14:15 +1000, James Morris wrote: > On Wed, 24 Sep 2008, Francis K Shim wrote: > > > > > I could disable SELinux and I would not have this problem; however, I > > was hoping that there was a much secure or safer work-around to this > > problem. > > The video driver is inherently dangerous, so the safe approach is not to > use it. James isn't exactly being helpful, but the reason is because as you guessed the problem lies squarely and obviously with AMD/ATI and there isn't much we can do to help with closed source proprietary software. AMD/ATI is obviously doing it wrong and when it comes to security doing it wrong is never a good idea. Sadly we don't have their source so I can't show you the line of code (or do anything to fix it), but your backtrace should make it pretty obvious if anyone inside ATI decides to care. Stephen James, what do the two of you think about something like this? Maybe a WARN_ONCE() ? security/selinux/hooks.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 03fc6a8..14f1242 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -1385,7 +1385,8 @@ static int task_has_capability(struct task_struct *tsk, default: printk(KERN_ERR "SELinux: out of range capability %d\n", cap); - BUG(); + WARN(); + return -EPERM; } return avc_has_perm(tsec->sid, tsec->sid, sclass, av, &ad); } From cpebenito at tresys.com Thu Sep 25 14:28:27 2008 From: cpebenito at tresys.com (Christopher J. PeBenito) Date: Thu, 25 Sep 2008 10:28:27 -0400 Subject: SELinux detects problem with proprietary binary fglrx driver; however, AMD/ATI will not help In-Reply-To: <1222348415.2872.87.camel@localhost.localdomain> References: <1222297213.11556.18.camel@mobile-pc.localdomain> <1222348415.2872.87.camel@localhost.localdomain> Message-ID: <1222352907.4240.35.camel@gorn.columbia.tresys.com> On Thu, 2008-09-25 at 09:13 -0400, Eric Paris wrote: > On Thu, 2008-09-25 at 14:15 +1000, James Morris wrote: > > On Wed, 24 Sep 2008, Francis K Shim wrote: > > > > > > > > I could disable SELinux and I would not have this problem; however, I > > > was hoping that there was a much secure or safer work-around to this > > > problem. > > > > The video driver is inherently dangerous, so the safe approach is not to > > use it. > > James isn't exactly being helpful, but the reason is because as you > guessed the problem lies squarely and obviously with AMD/ATI and there > isn't much we can do to help with closed source proprietary software. > AMD/ATI is obviously doing it wrong and when it comes to security doing > it wrong is never a good idea. Sadly we don't have their source so I > can't show you the line of code (or do anything to fix it), but your > backtrace should make it pretty obvious if anyone inside ATI decides to > care. > > Stephen James, what do the two of you think about something like this? > Maybe a WARN_ONCE() ? Maybe instead of returning -EPERM unconditionally, returning based on the unknown_perms setting? Of course what to do if its set to reject would be a question (my suggestion would be deny on that too). > security/selinux/hooks.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c > index 03fc6a8..14f1242 100644 > --- a/security/selinux/hooks.c > +++ b/security/selinux/hooks.c > @@ -1385,7 +1385,8 @@ static int task_has_capability(struct task_struct *tsk, > default: > printk(KERN_ERR > "SELinux: out of range capability %d\n", cap); > - BUG(); > + WARN(); > + return -EPERM; > } > return avc_has_perm(tsec->sid, tsec->sid, sclass, av, &ad); > } > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 From jmorris at namei.org Thu Sep 25 14:31:09 2008 From: jmorris at namei.org (James Morris) Date: Fri, 26 Sep 2008 00:31:09 +1000 (EST) Subject: SELinux detects problem with proprietary binary fglrx driver; however, AMD/ATI will not help In-Reply-To: <1222348415.2872.87.camel@localhost.localdomain> References: <1222297213.11556.18.camel@mobile-pc.localdomain> <1222348415.2872.87.camel@localhost.localdomain> Message-ID: On Thu, 25 Sep 2008, Eric Paris wrote: > Stephen James, what do the two of you think about something like this? > Maybe a WARN_ONCE() ? > There are several issues here: - Does this actually solve the problem for the user? What happens when the driver gets an -EPERM there? - Should we be littering the kernel code with workarounds for bugs in proprietary drivers? - Should we be encouraging vendors to not support Linux users, especially when other vendors are offering support (who we would then also be discouraging). - Francis asked for a much-secure or safer workaround to the issue. Given that the driver is messing with kernel security, is also broken in its use of a security API, and not maintained, I'm certainly not going to recommend its continued use in this context. - James -- James Morris From sundaram at fedoraproject.org Thu Sep 25 16:14:51 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 25 Sep 2008 21:44:51 +0530 Subject: Xfce Live CD and SELinux In-Reply-To: <1222347885.2872.78.camel@localhost.localdomain> References: <48DB68B7.8040203@fedoraproject.org> <1222347885.2872.78.camel@localhost.localdomain> Message-ID: <48DBB8FB.2050400@fedoraproject.org> Eric Paris wrote: > On Thu, 2008-09-25 at 16:02 +0530, Rahul Sundaram wrote: >> Hi, >> >> While building a live cd in a SELinux enabled system, I get this. Should >> I still be building live images with SELinux in permissive mode? > > I believe everything should be working as long as both the host and the > image are updated F9 or rawhide (ok at least libselinux and > livecd-creator needs to be updated, and I don't remember what else). F9 > GA and earlier is known to have some problems. My guess is that you > have a rawhide/updated host and are building a GA image? No. A rawhide image on a rawhide host. Rahul From dwalsh at redhat.com Thu Sep 25 17:14:50 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 25 Sep 2008 13:14:50 -0400 Subject: giving ftp access to specif files and directories In-Reply-To: <737og9$4hkjo@dmzms99902.na.baesystems.com> References: <737og9$4hkjo@dmzms99902.na.baesystems.com> Message-ID: <48DBC70A.5090200@redhat.com> Clarkson, Mike R (US SSA) wrote: > OK, I'll get more specific. > > Let's say I've got some_program that I've created a policy module for so > that it runs in the some_program_t domain. Suppose some_program uses > files for various purposes and the module has labeled them, such that > all the files under the /local/some_dir directory are labeled > some_file_t. Further suppose that some_program uses ftp to transfer one > or more of the files labeled some_file_t, and that the policy writer > does not want to label these files public_content_t. The policy writer > can do something like this: > > require {type ftpd_t;} > allow ftpd_t some_file_t:file ; > > Rules giving ftpt_t access to other objects belong in the ftp module, > but the policy writer really doesn't want to modify the ftp module for > obvious reasons. This is where it would be nice to have interfaces in > the ftp module that allowed policy writers to give the ftpd_t domain > access to files and directories of specific types. There could either be > a series of interfaces giving different permissions to choose from or it > could be handled by a generic interface such as this: > > ################################################ > ## > ## Give the ftpd_t access to specified file type. > ## > ## > ## > ## File type to which ftpd_t needs access > ## ## > ## Type of object (i.e. file or dir) > ## > ## > ## Permission needed by ftpd_t(i.e. read, write, etc.) > ## > interface(`give_ftp_access',` > gen_require(` > type ftpd_t; > ') > > allow ftpd_t $1:$2 $3; > ') > I don't see where this is any easier then just using the code you wrote above. Other then you don't need the gen_require. >> -----Original Message----- >> From: Daniel J Walsh [mailto:dwalsh at redhat.com] >> Sent: Tuesday, September 23, 2008 9:16 AM >> To: Clarkson, Mike R (US SSA) >> Cc: fedora-selinux-list at redhat.com >> Subject: Re: giving ftp access to specif files and directories >> >> Clarkson, Mike R (US SSA) wrote: >>> In RHEL5.1, I don't see an interface allowing the policy writer to > give >>> the ftp daemon access to specific file and directory types. This > would >>> be nice to have. >>> >>> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> Not sure what you are after here. Do you want to label a directory or >> file with public_content_t will allow ftp to gain access. >> >> If the files are labeled something non default you could add allow > rules >> using audit2allow -M myftp. >> >> If you want to add a type specific to ftp that other daemons would not >> have access to IE Not public_content_t, you could define a module >> >> type ftp_content_t; >> files_type(ftp_content_t) >> >> ... >> >> Then allow access. And set the labeling correct > From mike.clarkson at baesystems.com Thu Sep 25 17:36:08 2008 From: mike.clarkson at baesystems.com (Clarkson, Mike R (US SSA)) Date: Thu, 25 Sep 2008 10:36:08 -0700 Subject: giving ftp access to specif files and directories Message-ID: <738m08$i5m3d@dmzms99802.na.baesystems.com> I'll grant that the difference is fairly subtle, but it gets into the software design principles of the reference policy. Chiefly, attempting to keep modules loosely coupled by using interfaces rather than global use of type identifiers. With the interface approach, all uses of the ftpd_t type are kept within the ftp module. > -----Original Message----- > From: Daniel J Walsh [mailto:dwalsh at redhat.com] > Sent: Thursday, September 25, 2008 10:15 AM > To: Clarkson, Mike R (US SSA) > Cc: fedora-selinux-list at redhat.com > Subject: Re: giving ftp access to specif files and directories > > Clarkson, Mike R (US SSA) wrote: > > OK, I'll get more specific. > > > > Let's say I've got some_program that I've created a policy module for so > > that it runs in the some_program_t domain. Suppose some_program uses > > files for various purposes and the module has labeled them, such that > > all the files under the /local/some_dir directory are labeled > > some_file_t. Further suppose that some_program uses ftp to transfer one > > or more of the files labeled some_file_t, and that the policy writer > > does not want to label these files public_content_t. The policy writer > > can do something like this: > > > > require {type ftpd_t;} > > allow ftpd_t some_file_t:file ; > > > > Rules giving ftpt_t access to other objects belong in the ftp module, > > but the policy writer really doesn't want to modify the ftp module for > > obvious reasons. This is where it would be nice to have interfaces in > > the ftp module that allowed policy writers to give the ftpd_t domain > > access to files and directories of specific types. There could either be > > a series of interfaces giving different permissions to choose from or it > > could be handled by a generic interface such as this: > > > > ################################################ > > ## > > ## Give the ftpd_t access to specified file type. > > ## > > ## > > ## > > ## File type to which ftpd_t needs access > > ## > ## > > ## Type of object (i.e. file or dir) > > ## > > ## > > ## Permission needed by ftpd_t(i.e. read, write, etc.) > > ## > > interface(`give_ftp_access',` > > gen_require(` > > type ftpd_t; > > ') > > > > allow ftpd_t $1:$2 $3; > > ') > > > I don't see where this is any easier then just using the code you wrote > above. > > Other then you don't need the gen_require. > > >> -----Original Message----- > >> From: Daniel J Walsh [mailto:dwalsh at redhat.com] > >> Sent: Tuesday, September 23, 2008 9:16 AM > >> To: Clarkson, Mike R (US SSA) > >> Cc: fedora-selinux-list at redhat.com > >> Subject: Re: giving ftp access to specif files and directories > >> > >> Clarkson, Mike R (US SSA) wrote: > >>> In RHEL5.1, I don't see an interface allowing the policy writer to > > give > >>> the ftp daemon access to specific file and directory types. This > > would > >>> be nice to have. > >>> > >>> > >>> -- > >>> fedora-selinux-list mailing list > >>> fedora-selinux-list at redhat.com > >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > >> Not sure what you are after here. Do you want to label a directory or > >> file with public_content_t will allow ftp to gain access. > >> > >> If the files are labeled something non default you could add allow > > rules > >> using audit2allow -M myftp. > >> > >> If you want to add a type specific to ftp that other daemons would not > >> have access to IE Not public_content_t, you could define a module > >> > >> type ftp_content_t; > >> files_type(ftp_content_t) > >> > >> ... > >> > >> Then allow access. And set the labeling correct > > From dwalsh at redhat.com Thu Sep 25 18:40:14 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 25 Sep 2008 14:40:14 -0400 Subject: giving ftp access to specif files and directories In-Reply-To: <738m08$i5m3d@dmzms99802.na.baesystems.com> References: <738m08$i5m3d@dmzms99802.na.baesystems.com> Message-ID: <48DBDB0E.9030900@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Clarkson, Mike R (US SSA) wrote: > I'll grant that the difference is fairly subtle, but it gets into the > software design principles of the reference policy. Chiefly, attempting > to keep modules loosely coupled by using interfaces rather than global > use of type identifiers. With the interface approach, all uses of the > ftpd_t type are kept within the ftp module. > Well submit it upstream and see what Chris thinks. >> -----Original Message----- >> From: Daniel J Walsh [mailto:dwalsh at redhat.com] >> Sent: Thursday, September 25, 2008 10:15 AM >> To: Clarkson, Mike R (US SSA) >> Cc: fedora-selinux-list at redhat.com >> Subject: Re: giving ftp access to specif files and directories >> >> Clarkson, Mike R (US SSA) wrote: >>> OK, I'll get more specific. >>> >>> Let's say I've got some_program that I've created a policy module > for so >>> that it runs in the some_program_t domain. Suppose some_program uses >>> files for various purposes and the module has labeled them, such > that >>> all the files under the /local/some_dir directory are labeled >>> some_file_t. Further suppose that some_program uses ftp to transfer > one >>> or more of the files labeled some_file_t, and that the policy writer >>> does not want to label these files public_content_t. The policy > writer >>> can do something like this: >>> >>> require {type ftpd_t;} >>> allow ftpd_t some_file_t:file ; >>> >>> Rules giving ftpt_t access to other objects belong in the ftp > module, >>> but the policy writer really doesn't want to modify the ftp module > for >>> obvious reasons. This is where it would be nice to have interfaces > in >>> the ftp module that allowed policy writers to give the ftpd_t domain >>> access to files and directories of specific types. There could > either be >>> a series of interfaces giving different permissions to choose from > or it >>> could be handled by a generic interface such as this: >>> >>> ################################################ >>> ## >>> ## Give the ftpd_t access to specified file type. >>> ## >>> ## >>> ## >>> ## File type to which ftpd_t needs access >>> ## >> ## >>> ## Type of object (i.e. file or dir) >>> ## >>> ## >>> ## Permission needed by ftpd_t(i.e. read, write, etc.) >>> ## >>> interface(`give_ftp_access',` >>> gen_require(` >>> type ftpd_t; >>> ') >>> >>> allow ftpd_t $1:$2 $3; >>> ') >>> >> I don't see where this is any easier then just using the code you > wrote >> above. >> >> Other then you don't need the gen_require. >> >>>> -----Original Message----- >>>> From: Daniel J Walsh [mailto:dwalsh at redhat.com] >>>> Sent: Tuesday, September 23, 2008 9:16 AM >>>> To: Clarkson, Mike R (US SSA) >>>> Cc: fedora-selinux-list at redhat.com >>>> Subject: Re: giving ftp access to specif files and directories >>>> >>>> Clarkson, Mike R (US SSA) wrote: >>>>> In RHEL5.1, I don't see an interface allowing the policy writer to >>> give >>>>> the ftp daemon access to specific file and directory types. This >>> would >>>>> be nice to have. >>>>> >>>>> >>>>> -- >>>>> fedora-selinux-list mailing list >>>>> fedora-selinux-list at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>>> Not sure what you are after here. Do you want to label a directory > or >>>> file with public_content_t will allow ftp to gain access. >>>> >>>> If the files are labeled something non default you could add allow >>> rules >>>> using audit2allow -M myftp. >>>> >>>> If you want to add a type specific to ftp that other daemons would > not >>>> have access to IE Not public_content_t, you could define a module >>>> >>>> type ftp_content_t; >>>> files_type(ftp_content_t) >>>> >>>> ... >>>> >>>> Then allow access. And set the labeling correct > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjb2w4ACgkQrlYvE4MpobNFAwCgkJ5B5icfolq3AZiaU1eHlkzA oDoAniz36nB7GPGuJS8PYM9GJg+QhmuV =5Qv5 -----END PGP SIGNATURE----- From Valdis.Kletnieks at vt.edu Fri Sep 26 03:38:39 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 25 Sep 2008 23:38:39 -0400 Subject: SELinux detects problem with proprietary binary fglrx driver; however, AMD/ATI will not help In-Reply-To: Your message of "Fri, 26 Sep 2008 00:31:09 +1000." References: <1222297213.11556.18.camel@mobile-pc.localdomain> <1222348415.2872.87.camel@localhost.localdomain> Message-ID: <9730.1222400319@turing-police.cc.vt.edu> On Fri, 26 Sep 2008 00:31:09 +1000, James Morris said: > - Francis asked for a much-secure or safer workaround to the issue. > Given that the driver is messing with kernel security, is also broken in > its use of a security API, and not maintained, I'm certainly not going to > recommend its continued use in this context. Given the fact it's a kernel BUG, I wonder if the *real* issue isn't that the driver doesn't support SELinux, but that it doesn't understand the expanded more-than-32-bits capabilities in recent kernels, causing something to overlay something it shouldn't have... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From belfrancis2001 at yahoo.ca Fri Sep 26 20:00:54 2008 From: belfrancis2001 at yahoo.ca (Francis K Shim) Date: Fri, 26 Sep 2008 16:00:54 -0400 Subject: SELinux detects problem with proprietary binary fglrx driver; however, AMD/ATI will not help In-Reply-To: <9730.1222400319@turing-police.cc.vt.edu> References: <1222297213.11556.18.camel@mobile-pc.localdomain> <1222348415.2872.87.camel@localhost.localdomain> <9730.1222400319@turing-police.cc.vt.edu> Message-ID: <1222459254.8969.1.camel@mobile-pc.localdomain> On Thu, 2008-09-25 at 23:38 -0400, Valdis.Kletnieks at vt.edu wrote: > On Fri, 26 Sep 2008 00:31:09 +1000, James Morris said: > > > - Francis asked for a much-secure or safer workaround to the issue. > > Given that the driver is messing with kernel security, is also broken in > > its use of a security API, and not maintained, I'm certainly not going to > > recommend its continued use in this context. >From the perspective of security and safety, I agree with James in simply *not* using the fglrx driver, in favor of a VESA or compatible open-source device driver; however, that being said, it will essentially cripple the usage of the full range of the video card's capabilities. It is acceptable if I were to only be limited to simple text editing and low intensity graphics. However, it does mean that any photo-realistic and intense graphics manipulation will suffer, which I can live with for a little while, but not forever. > Given the fact it's a kernel BUG, I wonder if the *real* issue isn't > that the driver doesn't support SELinux, but that it doesn't understand > the expanded more-than-32-bits capabilities in recent kernels, causing > something to overlay something it shouldn't have... If this is the case, then I would be happy to tell AMD/ATI about this interface bug; however, I think that SELinux itself, Linux and the Open-source community should use incidences like this as further proof-of-application (versus proof-of-concept). At least, in this respect, there should be an opportunity for strengthening liason between *us* and the AMD/ATI team. Peace, Frank From usenet at laliluna.de Sun Sep 28 08:37:29 2008 From: usenet at laliluna.de (Sebastian Hennebrueder) Date: Sun, 28 Sep 2008 10:37:29 +0200 Subject: cron_t freshclam Message-ID: <48DF4249.9030604@laliluna.de> Hello, the freshclam daemon tries to download the updated virus definition to /var/clamav The directory has the context drwxr-xr-x clamav clamav system_u:object_r:clamd_t clamav I get the following error message type=AVC msg=audit(1222221728.847:3043): avc: denied { write } for pid=10192 comm="freshclam" name="clamav" dev=dm-1 ino=522241 scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:object_r:clamd_t:s0 tclass=dir type=AVC msg=audit(1222304223.589:82): avc: denied { write } for pid=6100 comm="freshclam" name="clamav" dev=dm-1 ino=522241 scontext=system_u:system_r:crond_t:s0-s0:c0.c1023 tcontext=system_u:object_r:clamd_t:s0 tclass=dir type=AVC msg=audit(1222304223.666:83): avc: denied { write } for pid=6100 comm="freshclam" name="clamav" dev=dm-1 ino=522241 scontext=system_u:system_r:crond_t:s0-s0:c0.c1023 tcontext=system_u:object_r:clamd_t:s0 tclass=dir type=AVC msg=audit(1222308125.673:100): avc: denied { write } for pid=7622 comm="freshclam" name="clamav" dev=dm-1 ino=522241 scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:object_r:clamd_t:s0 tclass=dir type=AVC msg=audit(1222308125.911:101): avc: denied { write } for pid=7622 comm="freshclam" name="clamav" dev=dm-1 ino=522241 scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:object_r:clamd_t:s0 tclass=dir Using audit2allow I get module dummy 1.0; require { type unconfined_t; type crond_t; type clamd_t; class dir write; } #============= crond_t ============== allow crond_t clamd_t:dir write; #============= unconfined_t ============== allow unconfined_t clamd_t:dir write; My impression was that unconfined_ access allows a quite wide access but some testing showed me that without even root cannot create files in that directory. type=AVC msg=audit(1222590942.079:771): avc: denied { write } for pid=27753 comm="touch" name="clamav" dev=dm-1 ino=522241 scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:object_r:clamd_t:s0 tclass=dir type=SYSCALL msg=audit(1222590942.079:771): arch=c000003e syscall=2 success=no exit=-13 a0=7fffc9188c93 a1=941 a2=1b6 a3=3ff8d4e0ec items=0 ppid=25482 pid=27753 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=96 comm="touch" exe="/bin/touch" subj=user_u:system_r:unconfined_t:s0 key=(null) So my question, can I allow unconfined access and to which extend will this open the directory? Best Regards Sebastian Hennebrueder From sds at tycho.nsa.gov Mon Sep 29 13:13:13 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 29 Sep 2008 09:13:13 -0400 Subject: SELinux detects problem with proprietary binary fglrx driver; however, AMD/ATI will not help In-Reply-To: <1222348415.2872.87.camel@localhost.localdomain> References: <1222297213.11556.18.camel@mobile-pc.localdomain> <1222348415.2872.87.camel@localhost.localdomain> Message-ID: <1222693993.5429.12.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2008-09-25 at 09:13 -0400, Eric Paris wrote: > On Thu, 2008-09-25 at 14:15 +1000, James Morris wrote: > > On Wed, 24 Sep 2008, Francis K Shim wrote: > > > > > > > > I could disable SELinux and I would not have this problem; however, I > > > was hoping that there was a much secure or safer work-around to this > > > problem. > > > > The video driver is inherently dangerous, so the safe approach is not to > > use it. > > James isn't exactly being helpful, but the reason is because as you > guessed the problem lies squarely and obviously with AMD/ATI and there > isn't much we can do to help with closed source proprietary software. > AMD/ATI is obviously doing it wrong and when it comes to security doing > it wrong is never a good idea. Sadly we don't have their source so I > can't show you the line of code (or do anything to fix it), but your > backtrace should make it pretty obvious if anyone inside ATI decides to > care. > > Stephen James, what do the two of you think about something like this? > Maybe a WARN_ONCE() ? > > security/selinux/hooks.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c > index 03fc6a8..14f1242 100644 > --- a/security/selinux/hooks.c > +++ b/security/selinux/hooks.c > @@ -1385,7 +1385,8 @@ static int task_has_capability(struct task_struct *tsk, > default: > printk(KERN_ERR > "SELinux: out of range capability %d\n", cap); > - BUG(); > + WARN(); > + return -EPERM; > } > return avc_has_perm(tsec->sid, tsec->sid, sclass, av, &ad); > } I'm not opposed to changing it to an error return, although I'm not clear that will help. Does anyone know what the driver is actually trying to do here? The message said: SELinux: out of range capability -157851600 and -157851600 == 0xf6976030 Obviously that isn't what they meant to pass to capable(). -- Stephen Smalley National Security Agency From eparis at redhat.com Mon Sep 29 13:31:46 2008 From: eparis at redhat.com (Eric Paris) Date: Mon, 29 Sep 2008 09:31:46 -0400 Subject: SELinux detects problem with proprietary binary fglrx driver; however, AMD/ATI will not help In-Reply-To: <1222693993.5429.12.camel@moss-spartans.epoch.ncsc.mil> References: <1222297213.11556.18.camel@mobile-pc.localdomain> <1222348415.2872.87.camel@localhost.localdomain> <1222693993.5429.12.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1222695106.28251.12.camel@localhost.localdomain> On Mon, 2008-09-29 at 09:13 -0400, Stephen Smalley wrote: > On Thu, 2008-09-25 at 09:13 -0400, Eric Paris wrote: > > On Thu, 2008-09-25 at 14:15 +1000, James Morris wrote: > > > On Wed, 24 Sep 2008, Francis K Shim wrote: > > > > > > > > > > > I could disable SELinux and I would not have this problem; however, I > > > > was hoping that there was a much secure or safer work-around to this > > > > problem. > > > > > > The video driver is inherently dangerous, so the safe approach is not to > > > use it. > > > > James isn't exactly being helpful, but the reason is because as you > > guessed the problem lies squarely and obviously with AMD/ATI and there > > isn't much we can do to help with closed source proprietary software. > > AMD/ATI is obviously doing it wrong and when it comes to security doing > > it wrong is never a good idea. Sadly we don't have their source so I > > can't show you the line of code (or do anything to fix it), but your > > backtrace should make it pretty obvious if anyone inside ATI decides to > > care. > > > > Stephen James, what do the two of you think about something like this? > > Maybe a WARN_ONCE() ? > > > > security/selinux/hooks.c | 3 ++- > > 1 files changed, 2 insertions(+), 1 deletions(-) > > > > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c > > index 03fc6a8..14f1242 100644 > > --- a/security/selinux/hooks.c > > +++ b/security/selinux/hooks.c > > @@ -1385,7 +1385,8 @@ static int task_has_capability(struct task_struct *tsk, > > default: > > printk(KERN_ERR > > "SELinux: out of range capability %d\n", cap); > > - BUG(); > > + WARN(); > > + return -EPERM; > > } > > return avc_has_perm(tsec->sid, tsec->sid, sclass, av, &ad); > > } > > I'm not opposed to changing it to an error return, although I'm not > clear that will help. > > Does anyone know what the driver is actually trying to do here? The > message said: > SELinux: out of range capability -157851600 > and -157851600 == 0xf6976030 > Obviously that isn't what they meant to pass to capable(). I don't think any of us have any idea what the driver was trying to do here, but clearly they are doing it wrong. Maybe you can turn on your NSA brain reading satellite and peer into the brain of an ATI programmer.... I'm actually quite shocked it didn't blow up in cap_raised #define cap_raised(c, flag) ((c).cap[CAP_TO_INDEX(flag)] & CAP_TO_MASK(flag)) its just got to be darn lucky that c.cap[huge index] actually hit a legal spot of memory and didn't bug on a pagefault right there. (I'm pretty sure 64 bit capabilities were in 2.6.25 right?) Before 64 bit caps I don't think we had the array index and only had the mask, so something huge wouldn't explode in the cap code... We can turn this into a WARN_ONCE() but people with this driver would still be taking a walk on the wild side since there is no bounds checking what-so-ever in the cap code.... I feel your pain, and we can make the kernel stop BUGing in SELinux code, but after looking at the cap code that it already ran your just as likely to BUG even without SELinux (and not nearly as cleanly...) I'm sorry to say I think its probably best for us to leave the BUG so at least the kernel will explode predictably rather than randomly and in a harder to track down way... I wonder if I should propose adding a cap_valid() check to cap_capable() upstream... -Eric From dwalsh at redhat.com Mon Sep 29 14:54:38 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 29 Sep 2008 10:54:38 -0400 Subject: cron_t freshclam In-Reply-To: <48DF4249.9030604@laliluna.de> References: <48DF4249.9030604@laliluna.de> Message-ID: <48E0EC2E.70505@redhat.com> Sebastian Hennebrueder wrote: > Hello, > the freshclam daemon tries to download the updated virus definition to > /var/clamav > > The directory has the context > drwxr-xr-x clamav clamav system_u:object_r:clamd_t clamav > A directory should not have a type of clamd_t, This is a processes type. You probably want to label this clamd_var_lib_t. Then everything should work. You must have put this label on in permissive mode. chcon -t clamd_var_lib_t /var/clamav will fix the problem. Is this a standard directory for this? My policy expects you to use /var/lib/clamav? Although I just saw mention of this directory in debian policy. > I get the following error message > type=AVC msg=audit(1222221728.847:3043): avc: denied { write } for > pid=10192 comm="freshclam" name="clamav" dev=dm-1 ino=522241 > scontext=user_u:system_r:unconfined_t:s0 > tcontext=system_u:object_r:clamd_t:s0 tclass=dir > type=AVC msg=audit(1222304223.589:82): avc: denied { write } for > pid=6100 comm="freshclam" name="clamav" dev=dm-1 ino=522241 > scontext=system_u:system_r:crond_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:clamd_t:s0 tclass=dir > type=AVC msg=audit(1222304223.666:83): avc: denied { write } for > pid=6100 comm="freshclam" name="clamav" dev=dm-1 ino=522241 > scontext=system_u:system_r:crond_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:clamd_t:s0 tclass=dir > type=AVC msg=audit(1222308125.673:100): avc: denied { write } for > pid=7622 comm="freshclam" name="clamav" dev=dm-1 ino=522241 > scontext=user_u:system_r:unconfined_t:s0 > tcontext=system_u:object_r:clamd_t:s0 tclass=dir > type=AVC msg=audit(1222308125.911:101): avc: denied { write } for > pid=7622 comm="freshclam" name="clamav" dev=dm-1 ino=522241 > scontext=user_u:system_r:unconfined_t:s0 > tcontext=system_u:object_r:clamd_t:s0 tclass=dir > > Using audit2allow I get > module dummy 1.0; > > require { > type unconfined_t; > type crond_t; > type clamd_t; > class dir write; > } > > #============= crond_t ============== > allow crond_t clamd_t:dir write; > > #============= unconfined_t ============== > allow unconfined_t clamd_t:dir write; > > > My impression was that unconfined_ access allows a quite wide access but > some testing showed me that without even root cannot create files in > that directory. > type=AVC msg=audit(1222590942.079:771): avc: denied { write } for > pid=27753 comm="touch" name="clamav" dev=dm-1 ino=522241 > scontext=user_u:system_r:unconfined_t:s0 > tcontext=system_u:object_r:clamd_t:s0 tclass=dir > type=SYSCALL msg=audit(1222590942.079:771): arch=c000003e syscall=2 > success=no exit=-13 a0=7fffc9188c93 a1=941 a2=1b6 a3=3ff8d4e0ec items=0 > ppid=25482 pid=27753 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=pts0 ses=96 comm="touch" exe="/bin/touch" > subj=user_u:system_r:unconfined_t:s0 key=(null) > > So my question, can I allow unconfined access and to which extend will > this open the directory? > > Best Regards > > Sebastian Hennebrueder > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From pemboa at gmail.com Mon Sep 29 20:31:32 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 29 Sep 2008 15:31:32 -0500 Subject: Alternate OpenSSH ports Message-ID: <16de708d0809291331o57506303jaf600e6fd00adb7@mail.gmail.com> I'm getting an denial when I attempt o use port 23 as an additional port for sshd. That makes sense. What's the best way to define alternate SSHd ports? -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From usenet at laliluna.de Mon Sep 29 20:38:35 2008 From: usenet at laliluna.de (Sebastian Hennebrueder) Date: Mon, 29 Sep 2008 22:38:35 +0200 Subject: Alternate OpenSSH ports In-Reply-To: <16de708d0809291331o57506303jaf600e6fd00adb7@mail.gmail.com> References: <16de708d0809291331o57506303jaf600e6fd00adb7@mail.gmail.com> Message-ID: <48E13CCB.1020800@laliluna.de> Arthur Pemberton schrieb: > I'm getting an denial when I attempt o use port 23 as an additional > port for sshd. That makes sense. What's the best way to define > alternate SSHd ports? > > http://wiki.centos.org/HowTos/SELinux#head-ad837f60830442ae77a81aedd10c20305a811388 Best Regards Sebastian From sds at tycho.nsa.gov Mon Sep 29 20:40:15 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 29 Sep 2008 16:40:15 -0400 Subject: Alternate OpenSSH ports In-Reply-To: <16de708d0809291331o57506303jaf600e6fd00adb7@mail.gmail.com> References: <16de708d0809291331o57506303jaf600e6fd00adb7@mail.gmail.com> Message-ID: <1222720815.5429.77.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2008-09-29 at 15:31 -0500, Arthur Pemberton wrote: > I'm getting an denial when I attempt o use port 23 as an additional > port for sshd. That makes sense. What's the best way to define > alternate SSHd ports? semanage port -m -t ssh_port_t -p tcp 23 -- Stephen Smalley National Security Agency From pemboa at gmail.com Mon Sep 29 21:49:10 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 29 Sep 2008 16:49:10 -0500 Subject: Alternate OpenSSH ports In-Reply-To: <1222720815.5429.77.camel@moss-spartans.epoch.ncsc.mil> References: <16de708d0809291331o57506303jaf600e6fd00adb7@mail.gmail.com> <1222720815.5429.77.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <16de708d0809291449wbf424e0hce33f0da76a6ec77@mail.gmail.com> Thanks guys. From pemboa at gmail.com Tue Sep 30 02:17:45 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 29 Sep 2008 21:17:45 -0500 Subject: Alternate OpenSSH ports In-Reply-To: <1222720815.5429.77.camel@moss-spartans.epoch.ncsc.mil> References: <16de708d0809291331o57506303jaf600e6fd00adb7@mail.gmail.com> <1222720815.5429.77.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <16de708d0809291917w5c1abe6dpfd1a62a7da7b8018@mail.gmail.com> On Mon, Sep 29, 2008 at 3:40 PM, Stephen Smalley wrote: > > On Mon, 2008-09-29 at 15:31 -0500, Arthur Pemberton wrote: >> I'm getting an denial when I attempt o use port 23 as an additional >> port for sshd. That makes sense. What's the best way to define >> alternate SSHd ports? > > semanage port -m -t ssh_port_t -p tcp 23 When trying this, I get: sealert -l 819f882a-3d08-41da-bc19-4168c9b8b4cb Even after doing that, I get this on `service sshd restart`: sealert -l 82267d8b-d557-4891-bdb0-26e0feb1e986 -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From frankly3d at gmail.com Tue Sep 30 09:24:53 2008 From: frankly3d at gmail.com (Frank Murphy) Date: Tue, 30 Sep 2008 10:24:53 +0100 Subject: Need Info adding\editing to a personal module? Message-ID: <1222766693.2427.25.camel@frank-01> Examples only: If exim gave an avc denial. 1: Create policy. audit2allow -M myexim < /var/log/audit/audit.log then enable it. semodule -i myexim.pp 2: If then in a couple of days exim generates another avc denial, different from the first. How does one edid\use audid2allow to include the new avc. Have looked at "man audit2allow" and can't seem to grasp an edit from the options. Frank -- gpg id EB547226 Revoked Forgot Password :( aMSN: Frankly3D http://www.frankly3d.com From dwalsh at redhat.com Tue Sep 30 12:41:54 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 30 Sep 2008 08:41:54 -0400 Subject: Alternate OpenSSH ports In-Reply-To: <16de708d0809291917w5c1abe6dpfd1a62a7da7b8018@mail.gmail.com> References: <16de708d0809291331o57506303jaf600e6fd00adb7@mail.gmail.com> <1222720815.5429.77.camel@moss-spartans.epoch.ncsc.mil> <16de708d0809291917w5c1abe6dpfd1a62a7da7b8018@mail.gmail.com> Message-ID: <48E21E92.3070507@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Arthur Pemberton wrote: > On Mon, Sep 29, 2008 at 3:40 PM, Stephen Smalley wrote: >> On Mon, 2008-09-29 at 15:31 -0500, Arthur Pemberton wrote: >>> I'm getting an denial when I attempt o use port 23 as an additional >>> port for sshd. That makes sense. What's the best way to define >>> alternate SSHd ports? >> semanage port -m -t ssh_port_t -p tcp 23 > > > > When trying this, I get: > sealert -l 819f882a-3d08-41da-bc19-4168c9b8b4cb > > Even after doing that, I get this on `service sshd restart`: > sealert -l 82267d8b-d557-4891-bdb0-26e0feb1e986 > > Please send the output from that command, that number is only local to your machine. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjiHpIACgkQrlYvE4MpobPNWgCeMpVLQdhE00L2SfmmUQobGxD8 f8sAoIDACqkdQi59mZ1XpOaGXQsvhbRn =8oVl -----END PGP SIGNATURE----- From sds at tycho.nsa.gov Tue Sep 30 13:18:04 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 30 Sep 2008 09:18:04 -0400 Subject: Alternate OpenSSH ports In-Reply-To: <48E21E92.3070507@redhat.com> References: <16de708d0809291331o57506303jaf600e6fd00adb7@mail.gmail.com> <1222720815.5429.77.camel@moss-spartans.epoch.ncsc.mil> <16de708d0809291917w5c1abe6dpfd1a62a7da7b8018@mail.gmail.com> <48E21E92.3070507@redhat.com> Message-ID: <1222780684.19676.55.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2008-09-30 at 08:41 -0400, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Arthur Pemberton wrote: > > On Mon, Sep 29, 2008 at 3:40 PM, Stephen Smalley wrote: > >> On Mon, 2008-09-29 at 15:31 -0500, Arthur Pemberton wrote: > >>> I'm getting an denial when I attempt o use port 23 as an additional > >>> port for sshd. That makes sense. What's the best way to define > >>> alternate SSHd ports? > >> semanage port -m -t ssh_port_t -p tcp 23 > > > > > > > > When trying this, I get: > > sealert -l 819f882a-3d08-41da-bc19-4168c9b8b4cb > > > > Even after doing that, I get this on `service sshd restart`: > > sealert -l 82267d8b-d557-4891-bdb0-26e0feb1e986 > > > > > Please send the output from that command, that number is only local to > your machine. Wondering if libsemanage does the right thing when the port already exists in the base policy, as in this case. It should override the base policy definition with the local one, but I'm not 100% sure it does. -- Stephen Smalley National Security Agency From eparis at redhat.com Tue Sep 30 14:08:51 2008 From: eparis at redhat.com (Eric Paris) Date: Tue, 30 Sep 2008 10:08:51 -0400 Subject: SELinux detects problem with proprietary binary fglrx driver; however, AMD/ATI will not help In-Reply-To: <1222695106.28251.12.camel@localhost.localdomain> References: <1222297213.11556.18.camel@mobile-pc.localdomain> <1222348415.2872.87.camel@localhost.localdomain> <1222693993.5429.12.camel@moss-spartans.epoch.ncsc.mil> <1222695106.28251.12.camel@localhost.localdomain> Message-ID: <1222783731.28251.67.camel@localhost.localdomain> On Mon, 2008-09-29 at 09:31 -0400, Eric Paris wrote: > I wonder if I should propose adding a cap_valid() check to cap_capable() > upstream... Couple minutes on kernelopps.org showed that almost 3000 others had this same problem. So anyway, the problem is absolutely in the firegl code but I did propose something upstream to try to hopefully keep people's computers alive. We'll see what the comments are.... http://marc.info/?l=linux-kernel&m=122278342811993&w=2 -Eric From belfrancis2001 at yahoo.ca Tue Sep 30 16:57:44 2008 From: belfrancis2001 at yahoo.ca (Francis K Shim) Date: Tue, 30 Sep 2008 12:57:44 -0400 Subject: SELinux detects problem with proprietary binary fglrx driver; however, AMD/ATI will not help In-Reply-To: <1222783731.28251.67.camel@localhost.localdomain> References: <1222297213.11556.18.camel@mobile-pc.localdomain> <1222348415.2872.87.camel@localhost.localdomain> <1222693993.5429.12.camel@moss-spartans.epoch.ncsc.mil> <1222695106.28251.12.camel@localhost.localdomain> <1222783731.28251.67.camel@localhost.localdomain> Message-ID: <1222793864.5914.3.camel@mobile-pc.localdomain> Thanks for the further information. Eric, I hope you do not mind, but I forwarded this information to the AMD/ATI technical support using their ticket system. I am hoping that somehow a light-bulb will actually go off among the "customer technical support" crew to actually forward this and past information to their actual coders/programmers. Peace, Frank On Tue, 2008-09-30 at 10:08 -0400, Eric Paris wrote: > 2