From ekuns at kilroy.chi.il.us Sat Mar 1 03:45:23 2008 From: ekuns at kilroy.chi.il.us (Edward Kuns) Date: Fri, 29 Feb 2008 21:45:23 -0600 Subject: SELinux interfering with clamav? In-Reply-To: <47C81913.2030902@redhat.com> References: <1204259483.32130.2120.camel@kilroy.chi.il.us> <47C813C2.1040405@redhat.com> <1204295400.32130.2186.camel@kilroy.chi.il.us> <47C81913.2030902@redhat.com> Message-ID: <1204343123.4261.85.camel@kilroy.chi.il.us> Interesting. After I enabled the last policy, I get one new AVC about lnk files. I make a new policy using the same method as before and now I get this policy: module myclamav 1.0; require { type bin_t; type clamd_t; class lnk_file read; class dir search; } #============= clamd_t ============== allow clamd_t bin_t:dir search; allow clamd_t bin_t:lnk_file read; I'll let you know if more show up with the modified policy above applied. Here is the AVC: Summary SELinux is preventing /usr/sbin/clamav-milter (clamd_t) "read" to (bin_t). Detailed Description SELinux denied access requested by /usr/sbin/clamav-milter. It is not expected that this access is required by /usr/sbin/clamav-milter 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 , restorecon -v 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 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 http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Additional Information Source Context system_u:system_r:clamd_t:s0 Target Context system_u:object_r:bin_t:s0 Target Objects None [ lnk_file ] Affected RPM Packages clamav-milter-0.92.1-1.fc8 [application] Policy RPM selinux-policy-3.0.8-84.fc8 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.catchall_file Host Name kilroy.chi.il.us Platform Linux kilroy.chi.il.us 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:48:34 EST 2008 i686 i686 Alert Count 4 First Seen Fri 29 Feb 2008 12:22:44 PM CST Last Seen Fri 29 Feb 2008 07:56:45 PM CST Local ID c5169662-b069-4270-84f8-a7aa4aa38100 Line Numbers Raw Audit Messages avc: denied { read } for comm=clamav-milter dev=dm-0 egid=486 euid=492 exe=/usr/sbin/clamav-milter exit=-13 fsgid=486 fsuid=492 gid=486 items=0 name=sh pid=2928 scontext=system_u:system_r:clamd_t:s0 sgid=486 subj=system_u:system_r:clamd_t:s0 suid=492 tclass=lnk_file tcontext=system_u:object_r:bin_t:s0 tty=(none) uid=492 From kcc1967 at gmail.com Sat Mar 1 09:49:31 2008 From: kcc1967 at gmail.com (Kuang-Chun Cheng) Date: Sat, 1 Mar 2008 17:49:31 +0800 Subject: SELinux PHP setup, how ? Message-ID: <5eb4b0650803010149h7651d175uac6d6a15d5462d69@mail.gmail.com> Hi, I'm new to RH5.x/SELinux. I have a simple PHP script which will call passthru() or exec() to invoke "/bin/ls" or other external commands to do some taskes. The SELinux (targeted policy) deny the action by default. Following the message in sealert which ask me to relabel /bin/ls to allow httpd to invoke /bin/ls from my PHP (ls.php) ... well, it's OK ... but I'm wondering if I can only limit invoking "/bin/ls" from ONLY my "ls.php". So, other PHP still can't call exec() to invoke "/bin/ls". Is this possible in targeted policy ? Thanks KC From ekuns at kilroy.chi.il.us Sat Mar 1 21:22:51 2008 From: ekuns at kilroy.chi.il.us (Edward Kuns) Date: Sat, 01 Mar 2008 15:22:51 -0600 Subject: SELinux interfering with clamav? In-Reply-To: <47C813C2.1040405@redhat.com> References: <1204259483.32130.2120.camel@kilroy.chi.il.us> <47C813C2.1040405@redhat.com> Message-ID: <1204406571.4261.311.camel@kilroy.chi.il.us> Well what do you know! Allowing bin_t dir search and lnk read, today I get the following AVC (cleaned up a bit). It looks like the clamav milter is trying to run a script. I am making the assumption that this script execution is valid. Summary SELinux is preventing /usr/sbin/clamav-milter (clamd_t) "execute" to (shell_exec_t). Additional Information Source Context system_u:system_r:clamd_t:s0 Target Context system_u:object_r:shell_exec_t:s0 Target Objects None [ file ] Affected RPM Packages clamav-milter-0.92.1-1.fc8 [application] Policy RPM selinux-policy-3.0.8-84.fc8 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.catchall_file Host Name kilroy.chi.il.us Platform Linux kilroy.chi.il.us 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:48:34 EST 2008 i686 i686 Alert Count 1 First Seen Sat 01 Mar 2008 03:13:03 PM CST Last Seen Sat 01 Mar 2008 03:13:03 PM CST Local ID e5f2cc68-acf3-4cc6-8c75-c73e0863d49a Line Numbers Raw Audit Messages avc: denied { execute } for comm=clamav-milter dev=dm-0 egid=486 euid=492 exe=/usr/sbin/clamav-milter exit=-13 fsgid=486 fsuid=492 gid=486 items=0 name=bash pid=22644 scontext=system_u:system_r:clamd_t:s0 sgid=486 subj=system_u:system_r:clamd_t:s0 suid=492 tclass=file tcontext=system_u:object_r:shell_exec_t:s0 tty=(none) uid=492 The now current policy with all changes mentioned before is: module myclamav 1.0; require { type shell_exec_t; type bin_t; type clamd_t; class lnk_file read; class file execute; class dir search; } #============= clamd_t ============== allow clamd_t bin_t:dir search; allow clamd_t bin_t:lnk_file read; allow clamd_t shell_exec_t:file execute; If I get anything new I will send another EMail. I'll also upgrade to the latest Fedora 8 selinux policy and setroubleshoot soon. :) Eddie -- Edward Kuns From ekuns at kilroy.chi.il.us Sat Mar 1 21:36:18 2008 From: ekuns at kilroy.chi.il.us (Edward Kuns) Date: Sat, 01 Mar 2008 15:36:18 -0600 Subject: SELinux interfering with clamav? In-Reply-To: <1204406571.4261.311.camel@kilroy.chi.il.us> References: <1204259483.32130.2120.camel@kilroy.chi.il.us> <47C813C2.1040405@redhat.com> <1204406571.4261.311.camel@kilroy.chi.il.us> Message-ID: <1204407378.4261.317.camel@kilroy.chi.il.us> On Sat, 2008-03-01 at 15:22 -0600, Edward Kuns wrote: > It looks like the clamav milter is trying to run a script. > I am making the assumption that this script execution is valid. Yes. Looking further into logs, I get this AVC when clamav-milter detects an incoming virus, which explains why the timing of my getting these AVCs is so intermittent. Eddie -- Edward Kuns From ekuns at kilroy.chi.il.us Sat Mar 1 22:58:29 2008 From: ekuns at kilroy.chi.il.us (Edward Kuns) Date: Sat, 01 Mar 2008 16:58:29 -0600 Subject: selinux interfering with dynamic dns Message-ID: <1204412309.4261.336.camel@kilroy.chi.il.us> I have dhcp + named set up to cooperate, but selinux (understandably) denies named write access to the files it needs to modify for dynamic dns updates. I have created the following policy. Is there a better way of doing this? Best would be if there was a way to allow write access *only* to those handful of files in /var/named/chroot/var/named that are truly dynamic, perhaps by labeling. Would it be possible or reasonable to add named_dynamic_zone_t or some equivalent? Is there a better way to solve this problem or am I missing some already-available mechanism? Thanks Eddie module mybind 1.0; require { type named_t; type named_zone_t; class file write; } #============= named_t ============== allow named_t named_zone_t:file write; -- Edward Kuns From shintaro.fujiwara at gmail.com Sun Mar 2 14:43:45 2008 From: shintaro.fujiwara at gmail.com (Shintaro Fujiwara) Date: Sun, 2 Mar 2008 23:43:45 +0900 Subject: segatex-5.30 released Message-ID: I released segatex-5.30. Incorporated aureport. almost all the options you can enjoy. http://sourceforge.net/projects/segatex/ ####################################### About segatex segatex is a program even if not knowing much about SELinux commands, can easily set SELinux commands by GUI. Written in C++. Requires Qt ( qt-devel package ). ####################################### -- http://intrajp.no-ip.com/ Home Page -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekuns at kilroy.chi.il.us Mon Mar 3 05:40:17 2008 From: ekuns at kilroy.chi.il.us (Edward Kuns) Date: Sun, 02 Mar 2008 23:40:17 -0600 Subject: SELinux interfering with clamav? In-Reply-To: <1204406571.4261.311.camel@kilroy.chi.il.us> References: <1204259483.32130.2120.camel@kilroy.chi.il.us> <47C813C2.1040405@redhat.com> <1204406571.4261.311.camel@kilroy.chi.il.us> Message-ID: <1204522817.3979.213.camel@kilroy.chi.il.us> It's taking a while to track down the full policy needed for clamav-milter to be able to detect a virus and react fully, as I have to wait until I receive a virus (sending out outgoing doesn't trigger the same results). Here is my current policy after a few rounds of adding another incremental rule: module myclamav 1.0; require { type shell_exec_t; type sendmail_exec_t; type clamd_t; class file { execute getattr }; } #============= clamd_t ============== allow clamd_t sendmail_exec_t:file { execute getattr }; allow clamd_t shell_exec_t:file getattr; It looks like clamav-milter is running /usr/sbin/sendmail.sendmail via a bash script, but I haven't looked into the workings to really be sure. Eddie -- Edward Kuns From dwalsh at redhat.com Mon Mar 3 14:37:58 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 03 Mar 2008 09:37:58 -0500 Subject: selinux interfering with dynamic dns In-Reply-To: <1204412309.4261.336.camel@kilroy.chi.il.us> References: <1204412309.4261.336.camel@kilroy.chi.il.us> Message-ID: <47CC0D46.70607@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Edward Kuns wrote: > I have dhcp + named set up to cooperate, but selinux (understandably) > denies named write access to the files it needs to modify for dynamic > dns updates. I have created the following policy. Is there a better > way of doing this? Best would be if there was a way to allow write > access *only* to those handful of files in /var/named/chroot/var/named > that are truly dynamic, perhaps by labeling. Would it be possible or > reasonable to add named_dynamic_zone_t or some equivalent? Is there a > better way to solve this problem or am I missing some already-available > mechanism? > > Thanks > > Eddie > > > module mybind 1.0; > > require { > type named_t; > type named_zone_t; > class file write; > } > > #============= named_t ============== > allow named_t named_zone_t:file write; > There is currently a boolean to allow this. getsebool named_write_master_zones man named_selinux will give further explanation. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfMDUUACgkQrlYvE4MpobOAwACffe9PMezUzaeK9I8hhuZMsT8F FiUAn2Ymv35JgeTct8MyLwkxvuRGJmJH =K4Cb -----END PGP SIGNATURE----- From selinux at gmail.com Mon Mar 3 19:08:38 2008 From: selinux at gmail.com (Tom London) Date: Mon, 3 Mar 2008 11:08:38 -0800 Subject: logrotate_t wants ptrace to the masses.... ;) Message-ID: <4c4ba1530803031108w113e35d3h9a27de58229b1665@mail.gmail.com> Running current Rawhide, logrotate must have kicked in and generated lots of AVCs when in enforcing mode. All of them are for ptrace: #============= logrotate_t ============== allow logrotate_t NetworkManager_t:process ptrace; allow logrotate_t apmd_t:process ptrace; allow logrotate_t audisp_t:process ptrace; allow logrotate_t auditd_t:process ptrace; allow logrotate_t consolekit_t:process ptrace; allow logrotate_t crond_t:process ptrace; allow logrotate_t cupsd_t:process ptrace; allow logrotate_t dhcpc_t:process ptrace; allow logrotate_t entropyd_t:process ptrace; allow logrotate_t fsdaemon_t:process ptrace; allow logrotate_t getty_t:process ptrace; allow logrotate_t hald_t:process ptrace; allow logrotate_t init_t:process ptrace; allow logrotate_t initrc_t:process ptrace; allow logrotate_t klogd_t:process ptrace; allow logrotate_t mount_t:process ptrace; allow logrotate_t restorecond_t:process ptrace; allow logrotate_t self:capability sys_ptrace; allow logrotate_t self:process ptrace; allow logrotate_t setrans_t:process ptrace; allow logrotate_t setroubleshootd_t:process ptrace; allow logrotate_t sshd_t:process ptrace; allow logrotate_t syslogd_t:process ptrace; allow logrotate_t system_crond_t:process ptrace; allow logrotate_t udev_t:process ptrace; allow logrotate_t unconfined_t:process ptrace; allow logrotate_t xdm_t:process ptrace; allow logrotate_t xdm_xserver_t:process ptrace; Complete audit.log attached. tom -- Tom London -------------- next part -------------- A non-text attachment was scrubbed... Name: log.gz Type: application/x-gzip Size: 4277 bytes Desc: not available URL: From rnicholsNOSPAM at comcast.net Mon Mar 3 19:10:38 2008 From: rnicholsNOSPAM at comcast.net (Robert Nichols) Date: Mon, 03 Mar 2008 13:10:38 -0600 Subject: Trying SELinux again on CentOS 5.1 - local script problems Message-ID: Being masochistic by nature, I decided to take another crack at getting SELinux running on my system, and ran into a couple of problems with some important local scripts. First, some system information: System: CentOS 5.1 on an Intel Pentium 4 CPU kernel-2.6.18-53.1.13.el5 selinux-policy-targeted-2.4.6-106.el5_1.3 setools-3.0-3.el5 Problem 1: Here, my dhclient-exit-hooks script is examining the 'named' configuration file to verify that the local DNS server will be forwarding queries to the servers assigned by DHCP. The script will reconfigure and restart 'named' if necessary, and that would undoubtedly result in more AVCs. Testing every combination of things that might happen is impractical, so just running audit2allow on these AVCs is almost certainly insufficient. Operation of this script absolutely must not be blocked. How can I open the door wide enough to ensure that? avc: denied { search } for pid=2551 comm="dhclient-script" name="named" dev=hda6 ino=267649 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:named_zone_t:s0 tclass=dir avc: denied { search } for pid=2551 comm="dhclient-script" name="chroot" dev=hda6 ino=267651 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:named_conf_t:s0 tclass=dir avc: denied { getattr } for pid=2551 comm="dhclient-script" path="/var/named/chroot/etc/named.conf" dev=hda6 ino=267674 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:named_conf_t:s0 tclass=file avc: denied { read } for pid=2599 comm="grep" name="named.conf" dev=hda6 ino=267674 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:named_conf_t:s0 tclass=file Problem 2: Here, my ifup-local script is starting a tcpdump capture on eth1. It is important to me that this capture begin automatically with the eth1 link is started. The actual directory where the capture files are stored has been given a context system_u:object_r:netutils_tmp_t, and that works without complaint (and does not appear below). Is there a way to make this work other than blindly running audit2allow on all these AVCs? Other than perhaps the stderr file (/root/eth1-cap.out), I don't see any possibility of adjusting target contexts. (Why system_u:system_r:netutils_t should be denied search and read permission in /proc is puzzling.) avc: denied { write } for pid=2670 comm="tcpdump" path="/root/eth1-cap.out" dev=hda2 ino=43920 scontext=system_u:system_r:netutils_t:s0 tcontext=user_u:object_r:user_home_t:s0 tclass=file avc: denied { search } for pid=2670 comm="tcpdump" name="nscd" dev=hda6 ino=283420 scontext=system_u:system_r:netutils_t:s0 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=dir avc: denied { search } for pid=2670 comm="tcpdump" name="sys" dev=proc ino=-268435428 scontext=system_u:system_r:netutils_t:s0 tcontext=system_u:object_r:sysctl_t:s0 tclass=dir avc: denied { search } for pid=2670 comm="tcpdump" name="kernel" dev=proc ino=-268435416 scontext=system_u:system_r:netutils_t:s0 tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=dir avc: denied { read } for pid=2670 comm="tcpdump" name="ngroups_max" dev=proc ino=-268435369 scontext=system_u:system_r:netutils_t:s0 tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=file avc: denied { search } for pid=2670 comm="tcpdump" name="/" dev=hdb1 ino=2 scontext=system_u:system_r:netutils_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=dir That last AVC is puzzling, because the root directory ("/") is not located on hdb1. That device holds the directory where the capture files are being stored. Inode 2 on /dev/hdb1 is on mount point "/x" in the filesystem. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. From dwalsh at redhat.com Mon Mar 3 20:53:33 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 03 Mar 2008 15:53:33 -0500 Subject: Trying SELinux again on CentOS 5.1 - local script problems In-Reply-To: References: Message-ID: <47CC654D.5060100@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Nichols wrote: > Being masochistic by nature, I decided to take another crack at getting > SELinux running on my system, and ran into a couple of problems with > some important local scripts. First, some system information: > > System: CentOS 5.1 on an Intel Pentium 4 CPU > kernel-2.6.18-53.1.13.el5 > selinux-policy-targeted-2.4.6-106.el5_1.3 > setools-3.0-3.el5 > > Problem 1: > > Here, my dhclient-exit-hooks script is examining the 'named' configuration > file to verify that the local DNS server will be forwarding queries to the > servers assigned by DHCP. The script will reconfigure and restart 'named' > if necessary, and that would undoubtedly result in more AVCs. Testing > every > combination of things that might happen is impractical, so just running > audit2allow on these AVCs is almost certainly insufficient. Operation of > this script absolutely must not be blocked. How can I open the door wide > enough to ensure that? > > avc: denied { search } for pid=2551 comm="dhclient-script" > name="named" dev=hda6 ino=267649 scontext=system_u:system_r:dhcpc_t:s0 > tcontext=system_u:object_r:named_zone_t:s0 tclass=dir > avc: denied { search } for pid=2551 comm="dhclient-script" > name="chroot" dev=hda6 ino=267651 scontext=system_u:system_r:dhcpc_t:s0 > tcontext=system_u:object_r:named_conf_t:s0 tclass=dir > avc: denied { getattr } for pid=2551 comm="dhclient-script" > path="/var/named/chroot/etc/named.conf" dev=hda6 ino=267674 > scontext=system_u:system_r:dhcpc_t:s0 > tcontext=system_u:object_r:named_conf_t:s0 tclass=file > avc: denied { read } for pid=2599 comm="grep" name="named.conf" > dev=hda6 ino=267674 scontext=system_u:system_r:dhcpc_t:s0 > tcontext=system_u:object_r:named_conf_t:s0 tclass=file > > Problem 2: > > Here, my ifup-local script is starting a tcpdump capture on eth1. It is > important to me that this capture begin automatically with the eth1 link > is started. The actual directory where the capture files are stored has > been given a context system_u:object_r:netutils_tmp_t, and that works > without complaint (and does not appear below). Is there a way to make > this work other than blindly running audit2allow on all these AVCs? > Other than perhaps the stderr file (/root/eth1-cap.out), I don't see any > possibility of adjusting target contexts. (Why > system_u:system_r:netutils_t > should be denied search and read permission in /proc is puzzling.) > > avc: denied { write } for pid=2670 comm="tcpdump" > path="/root/eth1-cap.out" dev=hda2 ino=43920 > scontext=system_u:system_r:netutils_t:s0 > tcontext=user_u:object_r:user_home_t:s0 tclass=file > avc: denied { search } for pid=2670 comm="tcpdump" name="nscd" > dev=hda6 ino=283420 scontext=system_u:system_r:netutils_t:s0 > tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=dir > avc: denied { search } for pid=2670 comm="tcpdump" name="sys" > dev=proc ino=-268435428 scontext=system_u:system_r:netutils_t:s0 > tcontext=system_u:object_r:sysctl_t:s0 tclass=dir > avc: denied { search } for pid=2670 comm="tcpdump" name="kernel" > dev=proc ino=-268435416 scontext=system_u:system_r:netutils_t:s0 > tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=dir > avc: denied { read } for pid=2670 comm="tcpdump" name="ngroups_max" > dev=proc ino=-268435369 scontext=system_u:system_r:netutils_t:s0 > tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=file > avc: denied { search } for pid=2670 comm="tcpdump" name="/" dev=hdb1 > ino=2 scontext=system_u:system_r:netutils_t:s0 > tcontext=system_u:object_r:default_t:s0 tclass=dir > > That last AVC is puzzling, because the root directory ("/") is not located > on hdb1. That device holds the directory where the capture files are > being stored. Inode 2 on /dev/hdb1 is on mount point "/x" in the > filesystem. > Simplest thing is to run this through # grep avc /var/log/audit2allow | audit2allow -M mypol # semodule -i mypol.pp You might want to first update to the U2 preview policy, available on http://people.redhat.com/dwalsh/SELinux/RHEL5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfMZUwACgkQrlYvE4MpobP6BQCfRuiyKhp3dQfk6/eDhj2ZXY3k qGUAn2jzSJsPWOB5pKNF2LwgCvMI26LI =Jq+9 -----END PGP SIGNATURE----- From olivares14031 at yahoo.com Mon Mar 3 22:01:52 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Mon, 3 Mar 2008 14:01:52 -0800 (PST) Subject: SELinux is preventing npviewer.bin (nsplugin_t) "read" to controlC0 (sound_device_t). Message-ID: <907187.66631.qm@web52603.mail.re2.yahoo.com> Dear all, I am getting to see the following errors that slow down my machine and take CPU to 100% Thanks, Antonio Summary: SELinux is preventing npviewer.bin (nsplugin_t) "read" to controlC0 (sound_device_t). Detailed Description: SELinux denied access requested by npviewer.bin. It is not expected that this access is required by npviewer.bin 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 controlC0, restorecon -v 'controlC0' 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:unconfined_r:nsplugin_t:SystemLow- SystemHigh Target Context system_u:object_r:sound_device_t Target Objects controlC0 [ chr_file ] Source npviewer.bin Source Path /usr/lib/nspluginwrapper/npviewer.bin Port Host localhost Source RPM Packages nspluginwrapper-0.9.91.5-23.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-9.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name localhost Platform Linux localhost 2.6.25-0.80.rc3.git2.fc9 #1 SMP Fri Feb 29 18:17:34 EST 2008 i686 athlon Alert Count 2689 First Seen Tue 26 Feb 2008 03:24:34 PM CST Last Seen Mon 03 Mar 2008 03:54:56 PM CST Local ID 469b1532-4ab3-4757-be58-2248cc0f9f05 Line Numbers Raw Audit Messages host=localhost type=AVC msg=audit(1204581296.416:2216): avc: denied { read } for pid=1218 comm="npviewer.bin" name="controlC0" dev=tmpfs ino=5312 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sound_device_t:s0 tclass=chr_file host=localhost type=SYSCALL msg=audit(1204581296.416:2216): arch=40000003 syscall=5 success=no exit=-13 a0=bfe497f2 a1=0 a2=1e a3=bfe497f2 items=0 ppid=32748 pid=1218 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="npviewer.bin" exe="/usr/lib/nspluginwrapper/npviewer.bin" subj=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 key=(null) ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From olivares14031 at yahoo.com Mon Mar 3 22:03:12 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Mon, 3 Mar 2008 14:03:12 -0800 (PST) Subject: SELinux prevented dbus-daemon from using the terminal /dev/tty1. Message-ID: <279047.79234.qm@web52601.mail.re2.yahoo.com> At one point, these were cured and now they reappear. How can I make them go away for good? Thanks, Antonio Summary: SELinux prevented dbus-daemon from using the terminal /dev/tty1. Detailed Description: SELinux prevented dbus-daemon from using the terminal /dev/tty1. In most cases daemons do not need to interact with the terminal, usually these avc messages can be ignored. All of the confined daemons should have dontaudit rules around using the terminal. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this selinux-policy. If you would like to allow all daemons to interact with the terminal, you can turn on the allow_daemons_use_tty boolean. Allowing Access: Changing the "allow_daemons_use_tty" boolean to true will allow this access: "setsebool -P allow_daemons_use_tty=1." Fix Command: setsebool -P allow_daemons_use_tty=1 Additional Information: Source Context unconfined_u:unconfined_r:unconfined_dbusd_t :SystemLow-SystemHigh Target Context unconfined_u:object_r:unconfined_tty_device_t Target Objects /dev/tty1 [ chr_file ] Source dbus-daemon Source Path /bin/dbus-daemon Port Host localhost Source RPM Packages dbus-1.1.20-1.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-9.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name allow_daemons_use_tty Host Name localhost Platform Linux localhost 2.6.25-0.80.rc3.git2.fc9 #1 SMP Fri Feb 29 18:17:34 EST 2008 i686 athlon Alert Count 14 First Seen Fri 01 Feb 2008 05:06:20 PM CST Last Seen Mon 03 Mar 2008 03:57:07 PM CST Local ID c0a79310-b4d4-41fc-a712-a4db505290d5 Line Numbers Raw Audit Messages host=localhost type=AVC msg=audit(1204581427.951:2778): avc: denied { read write } for pid=1306 comm="dbus-daemon" path="/dev/tty1" dev=tmpfs ino=1857 scontext=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:unconfined_tty_device_t:s0 tclass=chr_file host=localhost type=SYSCALL msg=audit(1204581427.951:2778): arch=40000003 syscall=11 success=yes exit=0 a0=804c908 a1=bf92fc8c a2=bf9310b4 a3=7 items=0 ppid=1305 pid=1306 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="dbus-daemon" exe="/bin/dbus-daemon" subj=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 key=(null) ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From olivares14031 at yahoo.com Mon Mar 3 22:05:40 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Mon, 3 Mar 2008 14:05:40 -0800 (PST) Subject: SELinux is preventing access to files with the label, file_t. Message-ID: <219731.39915.qm@web52607.mail.re2.yahoo.com> Dear all, I have done this before : "touch /.autorelabel; reboot" several days pass and I see this file_t again and I have to do "in quote" this again . What is file_t anyway? I do not know of any in my system. Thanks, Antonio Summary: SELinux is preventing access to files with the label, file_t. Detailed Description: SELinux permission checks on files labeled file_t are being denied. file_t is the context the SELinux kernel gives to files that do not have a label. This indicates a serious labeling problem. No files on an SELinux box should ever be labeled file_t. If you have just added a new disk drive to the system you can relabel it using the restorecon command. Otherwise you should relabel the entire files system. Allowing Access: You can execute the following command as root to relabel your computer system: "touch /.autorelabel; reboot" Additional Information: Source Context system_u:system_r:tmpreaper_t Target Context system_u:object_r:file_t Target Objects ./virtual-olivares.1dNZIJ [ dir ] Source tmpwatch Source Path /usr/sbin/tmpwatch Port Host localhost Source RPM Packages tmpwatch-2.9.13-2 Target RPM Packages Policy RPM selinux-policy-3.3.1-9.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name file Host Name localhost Platform Linux localhost 2.6.25-0.80.rc3.git2.fc9 #1 SMP Fri Feb 29 18:17:34 EST 2008 i686 athlon Alert Count 1 First Seen Mon 03 Mar 2008 10:01:18 AM CST Last Seen Mon 03 Mar 2008 10:01:18 AM CST Local ID 08676827-232c-4027-aa44-9431e45d6d53 Line Numbers Raw Audit Messages host=localhost type=AVC msg=audit(1204560078.2:50): avc: denied { rmdir } for pid=32386 comm="tmpwatch" name="virtual-olivares.1dNZIJ" dev=dm-0 ino=31391789 scontext=system_u:system_r:tmpreaper_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=dir host=localhost type=SYSCALL msg=audit(1204560078.2:50): arch=40000003 syscall=40 success=no exit=-13 a0=960ec33 a1=28 a2=960f1a0 a3=960ec33 items=0 ppid=32384 pid=32386 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="tmpwatch" exe="/usr/sbin/tmpwatch" subj=system_u:system_r:tmpreaper_t:s0 key=(null) ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From rnicholsNOSPAM at comcast.net Tue Mar 4 00:25:07 2008 From: rnicholsNOSPAM at comcast.net (Robert Nichols) Date: Mon, 03 Mar 2008 18:25:07 -0600 Subject: Trying SELinux again on CentOS 5.1 - HOPELESS In-Reply-To: <47CC654D.5060100@redhat.com> References: <47CC654D.5060100@redhat.com> Message-ID: Daniel J Walsh wrote: > Simplest thing is to run this through > # grep avc /var/log/audit2allow | audit2allow -M mypol > # semodule -i mypol.pp > > > You might want to first update to the U2 preview policy, available on > http://people.redhat.com/dwalsh/SELinux/RHEL5 This is turning into a worse disaster than I would have imagined. I updated to selinux-policy-targeted-2.4.6-122.el5 and ran audit2allow and semodule from the AVCs I now got when starting eth1. All looked good for a moment. Then I tried changing the config file for named so that the next network restart would cause an update. Got 151 new AVCs from that. Built a new policy to include allows for those AVCs, installed that, and tried the experiment again. Got another 20 AVCs. This is unending. The cuplrit appears to be a "pidof -o $PPID named" command which is getting a denial for each process on the system: avc: denied { ptrace } for pid=6134 comm="pidof" scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:udev_t:s0-s0:c0.c1023 tclass=process OK, it only really needs to succeed for the tcontext of the actual named process, but the log is going to get flooded with meaningless denials every time this runs. While I was tracking that down, a cron job that fetches news started and plopped a bunch more AVC denials in the log. When I printed out the /etc/dhclient-exit-hooks script for study, I got a whole bunch move denials from the hplip package. This situation is 100% hopeless. SELinux just keeps getting worse and worse. Enforcing mode would be equivalent to turning the system off. I'd need a daemon that scans the log for AVC denials and automatically runs audit2allow, etc., on whatever it finds to have any hope of keeping up. Absent a paid expert to write custom policy, SELinux on the desktop is suitable only for systems that run the Linux distribution 100% as supplied, with no changes whatsoever, and with the additional restriction that the user's interaction is limited to clicking on icons. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. From pemboa at gmail.com Tue Mar 4 00:29:12 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 3 Mar 2008 18:29:12 -0600 Subject: Trying SELinux again on CentOS 5.1 - HOPELESS In-Reply-To: References: <47CC654D.5060100@redhat.com> Message-ID: <16de708d0803031629o50a21459le7f306d61d9add2b@mail.gmail.com> On Mon, Mar 3, 2008 at 6:25 PM, Robert Nichols wrote: > Daniel J Walsh wrote: > > Simplest thing is to run this through > > # grep avc /var/log/audit2allow | audit2allow -M mypol > > # semodule -i mypol.pp > > > > > > You might want to first update to the U2 preview policy, available on > > http://people.redhat.com/dwalsh/SELinux/RHEL5 > > This is turning into a worse disaster than I would have imagined. I have SELinux running in targeted mode on two machines with Centos5 without issue. What exactly is the problem you are having? From rnicholsNOSPAM at comcast.net Tue Mar 4 03:34:47 2008 From: rnicholsNOSPAM at comcast.net (Robert Nichols) Date: Mon, 03 Mar 2008 21:34:47 -0600 Subject: Trying SELinux again on CentOS 5.1 - HOPELESS In-Reply-To: <16de708d0803031629o50a21459le7f306d61d9add2b@mail.gmail.com> References: <47CC654D.5060100@redhat.com> <16de708d0803031629o50a21459le7f306d61d9add2b@mail.gmail.com> Message-ID: Arthur Pemberton wrote: > On Mon, Mar 3, 2008 at 6:25 PM, Robert Nichols > wrote: >> Daniel J Walsh wrote: >> > Simplest thing is to run this through >> > # grep avc /var/log/audit2allow | audit2allow -M mypol >> > # semodule -i mypol.pp >> > >> > >> > You might want to first update to the U2 preview policy, available on >> > http://people.redhat.com/dwalsh/SELinux/RHEL5 >> >> This is turning into a worse disaster than I would have imagined. > > > I have SELinux running in targeted mode on two machines with Centos5 > without issue. What exactly is the problem you are having? You really want to know?? OK, there's probably enough here to get me banned from the list, but here it comes ... : 1) The bulk of the AVCs are coming from 'pidof' running in context system_u:system_r:dhcpc_t needing "ptrace" capability for every tcontext that might show up in /proc. audit2allow is NOT the solution for that. Apart from the problem of individually allowing every possible tcontext, allowing "ptrace" for just any process that might be running with that scontext would be a big security hole. 2) Here is what happened when the news fetch started. This looks like the classic problem of using shell I/O redirection to do the unthinkable and send the output from a command to a file. Why someone thought that 'grephistory' needed to be restricted is totally unfathomable to me: avc: denied { write } for pid=6305 comm="grephistory" path="/var/local/suck/suck.new-ids" dev=hda6 ino=189277 scontext=root:system_r:innd_t:s0-s0:c0.c1023 tcontext=root:object_r:var_t:s0 tclass=file avc: denied { read write } for pid=6305 comm="grephistory" path="socket:[63191]" dev=sockfs ino=63191 scontext=root:system_r:innd_t:s0-s0:c0.c1023 tcontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tclass=tcp_socket avc: denied { getattr } for pid=6305 comm="grephistory" path="/var/local/suck/suck.new-ids" dev=hda6 ino=189277 scontext=root:system_r:innd_t:s0-s0:c0.c1023 tcontext=root:object_r:var_t:s0 tclass=file 3) Here are the complaints resulting from running "enscript -f Courier9 /etc/dhclient-exit-hooks" (output going to an HP printer). I have no idea what the problem is here, but it looks major: avc: denied { getattr } for pid=6927 comm="python" path="/var/run/cups/cups.sock" dev=hda6 ino=283435 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:cupsd_var_run_t:s0 tclass=sock_file avc: denied { read } for pid=6927 comm="python" name="random" dev=tmpfs ino=2188 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file avc: denied { write } for pid=6927 comm="python" name="cups.sock" dev=hda6 ino=283435 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:cupsd_var_run_t:s0 tclass=sock_file avc: denied { connectto } for pid=6927 comm="python" path="/var/run/cups/cups.sock" scontext=system_u:system_r:hald_t:s0 tcontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tclass=unix_stream_socket avc: denied { read } for pid=6927 comm="python" name="0" dev=hda6 ino=283436 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:cupsd_var_run_t:s0 tclass=file avc: denied { getattr } for pid=6927 comm="python" path="/var/run/cups/certs/0" dev=hda6 ino=283436 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:cupsd_var_run_t:s0 tclass=file avc: denied { getattr } for pid=6955 comm="sh" path="/usr/bin/hpijs" dev=hda5 ino=65915 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:hplip_exec_t:s0 tclass=file avc: denied { execute } for pid=6955 comm="sh" name="hpijs" dev=hda5 ino=65915 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:hplip_exec_t:s0 tclass=file avc: denied { read } for pid=6955 comm="sh" name="hpijs" dev=hda5 ino=65915 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:hplip_exec_t:s0 tclass=file avc: denied { execute_no_trans } for pid=6955 comm="sh" path="/usr/bin/hpijs" dev=hda5 ino=65915 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:hplip_exec_t:s0 tclass=file 4) Oh yes, some mail arrived around this time. Here are the complaints from procmail. Someone apparently feels that 'pidof' should be locked away for life without parole. avc: denied { read } for pid=5231 comm="pidof" name="stat" dev=proc ino=217317389 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:sendmail_t:s0 tclass=file avc: denied { getattr } for pid=5231 comm="pidof" path="/proc/3316/stat" dev=proc ino=217317389 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:sendmail_t:s0 tclass=file 5) There are also a bunch of AVCs that occur during system boot and shutdown. For example, here are a couple that come up during boot. Now of course 'klogd' should be denied read permission for /proc/kmesg -- that is just _such_ an _evil_ thing for it to be doing! As for mcstransd, looks like it found it's way down into /var/named/chroot/proc and obviously couldn't be trusted there. avc: denied { read } for pid=2747 comm="klogd" path="/proc/kmsg" dev=proc ino=-268435447 scontext=system_u:system_r:klogd_t:s0 tcontext=system_u:object_r:named_conf_t:s0 tclass=file avc: denied { search } for pid=2768 comm="mcstransd" name="/" dev=proc ino=1 scontext=system_u:system_r:setrans_t:s0-s0:c0.c1023 tcontext=system_u:object_r:named_conf_t:s0 tclass=dir The phrase, "Not ready for prime time" comes to mind. I am simply not prepared to go through sorting out these sorts of problems every time I do something that isn't an exact repeat of something I've done before and fought through the problems that came up. So, shut it off and geridduvit. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. From pemboa at gmail.com Tue Mar 4 03:51:52 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 3 Mar 2008 21:51:52 -0600 Subject: Trying SELinux again on CentOS 5.1 - HOPELESS In-Reply-To: References: <47CC654D.5060100@redhat.com> <16de708d0803031629o50a21459le7f306d61d9add2b@mail.gmail.com> Message-ID: <16de708d0803031951j61ec28b5y1e1919ca743661d7@mail.gmail.com> On Mon, Mar 3, 2008 at 9:34 PM, Robert Nichols wrote: > > Arthur Pemberton wrote: > > On Mon, Mar 3, 2008 at 6:25 PM, Robert Nichols > > wrote: > >> Daniel J Walsh wrote: > >> > Simplest thing is to run this through > >> > # grep avc /var/log/audit2allow | audit2allow -M mypol > >> > # semodule -i mypol.pp > >> > > >> > > >> > You might want to first update to the U2 preview policy, available on > >> > http://people.redhat.com/dwalsh/SELinux/RHEL5 > >> > >> This is turning into a worse disaster than I would have imagined. > > > > > > I have SELinux running in targeted mode on two machines with Centos5 > > without issue. What exactly is the problem you are having? > > You really want to know?? OK, there's probably enough here to get > me banned from the list, but here it comes ... : Lets abstract this issue a bit... 1) what exactly are you trying to do with the machine 2) have you installed any software outside the centos repos? 3) when did these problems start? I hope you realize that your situation is not the norm. A lot of people run RedHat/Centos servers wit SELinux so it is definitely not mission impossible. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From eparis at redhat.com Tue Mar 4 04:48:05 2008 From: eparis at redhat.com (Eric Paris) Date: Mon, 03 Mar 2008 23:48:05 -0500 Subject: Trying SELinux again on CentOS 5.1 - not quite HOPELESS In-Reply-To: References: <47CC654D.5060100@redhat.com> <16de708d0803031629o50a21459le7f306d61d9add2b@mail.gmail.com> Message-ID: <1204606085.3216.84.camel@localhost.localdomain> On Mon, 2008-03-03 at 21:34 -0600, Robert Nichols wrote: > Arthur Pemberton wrote: > > On Mon, Mar 3, 2008 at 6:25 PM, Robert Nichols > > wrote: > >> Daniel J Walsh wrote: > >> > Simplest thing is to run this through > >> > # grep avc /var/log/audit2allow | audit2allow -M mypol > >> > # semodule -i mypol.pp > >> > > >> > > >> > You might want to first update to the U2 preview policy, available on > >> > http://people.redhat.com/dwalsh/SELinux/RHEL5 > >> > >> This is turning into a worse disaster than I would have imagined. > > > > > > I have SELinux running in targeted mode on two machines with Centos5 > > without issue. What exactly is the problem you are having? > > You really want to know?? OK, there's probably enough here to get > me banned from the list, but here it comes ... : > > 1) The bulk of the AVCs are coming from 'pidof' running in context > system_u:system_r:dhcpc_t needing "ptrace" capability for every > tcontext that might show up in /proc. audit2allow is NOT the > solution for that. Apart from the problem of individually allowing > every possible tcontext, allowing "ptrace" for just any process > that might be running with that scontext would be a big security > hole. sounds like you want 2 rules allow dhcpc_t named_t:process ptrace dontaudit dhcpc_t *:process ptrace never tried it, but I think that will take care of it. dhcpc_t will be able to only troll around in the correct /proc directories and your logs will be empty from all the denials. > 2) Here is what happened when the news fetch started. This looks > like the classic problem of using shell I/O redirection to do the > unthinkable and send the output from a command to a file. Why > someone thought that 'grephistory' needed to be restricted is > totally unfathomable to me: > > avc: denied { write } for pid=6305 comm="grephistory" path="/var/local/suck/suck.new-ids" dev=hda6 ino=189277 > scontext=root:system_r:innd_t:s0-s0:c0.c1023 tcontext=root:object_r:var_t:s0 tclass=file > avc: denied { read write } for pid=6305 comm="grephistory" path="socket:[63191]" dev=sockfs ino=63191 > scontext=root:system_r:innd_t:s0-s0:c0.c1023 tcontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tclass=tcp_socket > avc: denied { getattr } for pid=6305 comm="grephistory" path="/var/local/suck/suck.new-ids" dev=hda6 ino=189277 > scontext=root:system_r:innd_t:s0-s0:c0.c1023 tcontext=root:object_r:var_t:s0 tclass=file Its no grephistory that is confined. The program that called it was running as innd_t and so when it called grephistory it continued to run in the innd_t domain. /me knows nothing about the news stuff, but this sounds like something that needs to be fixed with labeling rather than allow rules. The issue is that (and I'm just guessing here) /var/local/suck is not the standard place innd needs to write. Since you changed where it needs to write you need to make sure those files are labeled the way they needs to be to accept writes rather than the generic default fallback var_t. I have no idea what innd_t is supposed to be able to write to, but lets assume there are types which fit (aka run matchpathcon against a path name you know it is able to write to). Then do something like "semanage fcontext -a -t [insert type] "/var/local/suck(/.*)?" followed by restorecon -R -v /var/local/suck. Viola, no custom policy, just telling it how things need to be labeled. > 3) Here are the complaints resulting from running "enscript -f > Courier9 /etc/dhclient-exit-hooks" (output going to an HP printer). > I have no idea what the problem is here, but it looks major: > > avc: denied { getattr } for pid=6927 comm="python" path="/var/run/cups/cups.sock" dev=hda6 ino=283435 > scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:cupsd_var_run_t:s0 tclass=sock_file > avc: denied { read } for pid=6927 comm="python" name="random" dev=tmpfs ino=2188 scontext=system_u:system_r:hald_t:s0 > tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file > avc: denied { write } for pid=6927 comm="python" name="cups.sock" dev=hda6 ino=283435 > scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:cupsd_var_run_t:s0 tclass=sock_file > avc: denied { connectto } for pid=6927 comm="python" path="/var/run/cups/cups.sock" > scontext=system_u:system_r:hald_t:s0 tcontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tclass=unix_stream_socket > avc: denied { read } for pid=6927 comm="python" name="0" dev=hda6 ino=283436 scontext=system_u:system_r:hald_t:s0 > tcontext=system_u:object_r:cupsd_var_run_t:s0 tclass=file > avc: denied { getattr } for pid=6927 comm="python" path="/var/run/cups/certs/0" dev=hda6 ino=283436 > scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:cupsd_var_run_t:s0 tclass=file > avc: denied { getattr } for pid=6955 comm="sh" path="/usr/bin/hpijs" dev=hda5 ino=65915 > scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:hplip_exec_t:s0 tclass=file > avc: denied { execute } for pid=6955 comm="sh" name="hpijs" dev=hda5 ino=65915 > scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:hplip_exec_t:s0 tclass=file > avc: denied { read } for pid=6955 comm="sh" name="hpijs" dev=hda5 ino=65915 > scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:hplip_exec_t:s0 tclass=file > avc: denied { execute_no_trans } for pid=6955 comm="sh" path="/usr/bin/hpijs" dev=hda5 ino=65915 > scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:hplip_exec_t:s0 tclass=file /me leaves this one for Dan to look at in the morning. some of it looks like a simple bug dan needs to fix in policy and isn't your fault (aka the cupsd_t -> hplip_exec_t stuff) but the right way to fix the hald_t -> cups issue I'm not sure of and we should leave that to the policy expert. > 4) Oh yes, some mail arrived around this time. Here are the complaints > from procmail. Someone apparently feels that 'pidof' should be locked > away for life without parole. > > avc: denied { read } for pid=5231 comm="pidof" name="stat" dev=proc ino=217317389 > scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:sendmail_t:s0 tclass=file > avc: denied { getattr } for pid=5231 comm="pidof" path="/proc/3316/stat" dev=proc ino=217317389 > scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:sendmail_t:s0 tclass=file remember, its not that pidof is being locked away without parole, its that dhcpc_t is being locked away. 2 options really: open up dhcpc_t policy with audit2allow -a/rinse/repeat (or do it in permissive one time rather than rinse repeat which you seem to have discovered) or add a new transition so that dhcpc_t can run pidof in an unconfined domain. I'm sure Dan will give details on this when he wakes up. > 5) There are also a bunch of AVCs that occur during system boot and shutdown. > For example, here are a couple that come up during boot. Now of course > 'klogd' should be denied read permission for /proc/kmesg -- that is just > _such_ an _evil_ thing for it to be doing! As for mcstransd, looks like > it found it's way down into /var/named/chroot/proc and obviously couldn't > be trusted there. > > avc: denied { read } for pid=2747 comm="klogd" path="/proc/kmsg" dev=proc ino=-268435447 > scontext=system_u:system_r:klogd_t:s0 tcontext=system_u:object_r:named_conf_t:s0 tclass=file > avc: denied { search } for pid=2768 comm="mcstransd" name="/" dev=proc ino=1 > scontext=system_u:system_r:setrans_t:s0-s0:c0.c1023 tcontext=system_u:object_r:named_conf_t:s0 tclass=dir Hmmmm, both of these are an issue with your having proc mounted inside the named chroot, why klogd is looking at the /proc/kmsg inside the chroot I have no idea. I thought that labeling for /proc would be correct even with strange mount points, I'll have to think about this when I get up in the morning. It is almost midnight here. > The phrase, "Not ready for prime time" comes to mind. I think we both agree you have the dhcp client do some pretty damn extraordinary things and no access control system is going to allow all of this out of the box. Somce things we can still fix easily (dontaudit and labeling for innd_t) and some things that I'm not sure what's wrong but I'm not the policy guru. Just remember you are trying to make dhcpc_t do things it was absolutely not designed to do. While I'll admit coming at this with no experience may make it seem daunting I'm sure you'll agree that most of the issues can be solved with little trouble. (I wish I could say all, but I don't even know the solution to all of them without a little playing a dabbling) as a sidebar, you might consider adding an audit rule like auditctl -a exit,always -S kill -F pid=1 this will add audit syscall overhead (which maybe be an issue if you box can't handle a bit more load) but will give you 'better' path names and such in your denial messages so you don't usually have to hunt down things like inode numbers.... -Eric From rnicholsNOSPAM at comcast.net Tue Mar 4 05:32:05 2008 From: rnicholsNOSPAM at comcast.net (Robert Nichols) Date: Mon, 03 Mar 2008 23:32:05 -0600 Subject: Trying SELinux again on CentOS 5.1 - HOPELESS In-Reply-To: <16de708d0803031951j61ec28b5y1e1919ca743661d7@mail.gmail.com> References: <47CC654D.5060100@redhat.com> <16de708d0803031629o50a21459le7f306d61d9add2b@mail.gmail.com> <16de708d0803031951j61ec28b5y1e1919ca743661d7@mail.gmail.com> Message-ID: Arthur Pemberton wrote: > On Mon, Mar 3, 2008 at 9:34 PM, Robert Nichols > wrote: >> Arthur Pemberton wrote: >> > On Mon, Mar 3, 2008 at 6:25 PM, Robert Nichols >> > wrote: >> >> Daniel J Walsh wrote: >> >> > Simplest thing is to run this through >> >> > # grep avc /var/log/audit2allow | audit2allow -M mypol >> >> > # semodule -i mypol.pp >> >> > >> >> > >> >> > You might want to first update to the U2 preview policy, available on >> >> > http://people.redhat.com/dwalsh/SELinux/RHEL5 >> >> >> >> This is turning into a worse disaster than I would have imagined. >> > >> > >> > I have SELinux running in targeted mode on two machines with Centos5 >> > without issue. What exactly is the problem you are having? >> >> You really want to know?? OK, there's probably enough here to get >> me banned from the list, but here it comes ... : > > Lets abstract this issue a bit... > > 1) what exactly are you trying to do with the machine > 2) have you installed any software outside the centos repos? > 3) when did these problems start? > > I hope you realize that your situation is not the norm. A lot of > people run RedHat/Centos servers wit SELinux so it is definitely not > mission impossible. Have you actually read any of this thread? As I said before, SELinux is likely to be just fine on a server doing the same fairly limited things over and over, or on a desktop that runs a Linux distribution without modification or augmentation and preferably with a user who doesn't do anything sinister like run commands from a shell prompt. I have a lot of 3rd party software installed, plus scripts like my /etc/dhclient-exit-hooks and /sbin/ifup.local that do things important to me when network interfaces are started, a version of hplip taken from Fedora Core 6 because it supports my printer and the version supplied with Centos 5.1 does not, video editing and DVD authoring software, plus a lot more. If all I wanted to do was browse the Web and read e-mail I'd just run MS-Windows. I decided to take a crack at getting SELinux to run because I'd heard good things about how much better and easier to use it was since I'd last tried it back in FC-3. Initially, I was pleasantly surprised. I have some oddities in my configuration, such as home directories in /var/home (bind-mounted to /home) and expected that sort of thing to be a big problem. What I found was that semanage made it really, really easy to set up the file contexts to make that work. Then I started running into the silly policy restrictions that make it almost impossible to make basic things like shell scripts work because, my God, you can't have commands sending their output to a file!! That sort of thing is just not allowable!! About the time I analyze those problems enough to find that there might be just a few underlying causes that a little expert help could solve, I start seeing things like the boot and shutdown AVCs that aren't related to anything I've changed at all. As far as I can see, nothing has changed since the bad old days. You can (a) use SELinux on a server and have a reasonable chance of working out the problems for the limited set of things a server is called upon to do, or (b) use it on a desktop provided you install the distribution as it comes and don't add or modify anything, or (c) don't run SELinux at all. I am firmly back in category c. At this point I've uninstalled the policy and support tools, returned to my previous setting of selinux=0 as a kernel boot parameter, and cleared the security ACLs from all inodes on my filesystems. If I take another look, it'll probably be around FC-10 or FC-11. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. From rnicholsNOSPAM at comcast.net Tue Mar 4 08:10:51 2008 From: rnicholsNOSPAM at comcast.net (Robert Nichols) Date: Tue, 04 Mar 2008 02:10:51 -0600 Subject: Trying SELinux again on CentOS 5.1 - not quite HOPELESS In-Reply-To: <1204606085.3216.84.camel@localhost.localdomain> References: <47CC654D.5060100@redhat.com> <16de708d0803031629o50a21459le7f306d61d9add2b@mail.gmail.com> <1204606085.3216.84.camel@localhost.localdomain> Message-ID: Eric Paris wrote: > On Mon, 2008-03-03 at 21:34 -0600, Robert Nichols wrote: >> 1) The bulk of the AVCs are coming from 'pidof' running in context >> system_u:system_r:dhcpc_t needing "ptrace" capability for every >> tcontext that might show up in /proc. audit2allow is NOT the >> solution for that. Apart from the problem of individually allowing >> every possible tcontext, allowing "ptrace" for just any process >> that might be running with that scontext would be a big security >> hole. > > sounds like you want 2 rules > > allow dhcpc_t named_t:process ptrace > dontaudit dhcpc_t *:process ptrace > > never tried it, but I think that will take care of it. dhcpc_t will be > able to only troll around in the correct /proc directories and your logs > will be empty from all the denials. > >> 2) Here is what happened when the news fetch started. This looks >> like the classic problem of using shell I/O redirection to do the >> unthinkable and send the output from a command to a file. Why >> someone thought that 'grephistory' needed to be restricted is >> totally unfathomable to me: >> >> avc: denied { write } for pid=6305 comm="grephistory" path="/var/local/suck/suck.new-ids" dev=hda6 ino=189277 >> scontext=root:system_r:innd_t:s0-s0:c0.c1023 tcontext=root:object_r:var_t:s0 tclass=file >> avc: denied { read write } for pid=6305 comm="grephistory" path="socket:[63191]" dev=sockfs ino=63191 >> scontext=root:system_r:innd_t:s0-s0:c0.c1023 tcontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tclass=tcp_socket >> avc: denied { getattr } for pid=6305 comm="grephistory" path="/var/local/suck/suck.new-ids" dev=hda6 ino=189277 >> scontext=root:system_r:innd_t:s0-s0:c0.c1023 tcontext=root:object_r:var_t:s0 tclass=file > > Its no grephistory that is confined. The program that called it was > running as innd_t and so when it called grephistory it continued to run > in the innd_t domain. The program that called grephistory was running from root's crontab. No way was that running as innd_t. Perhaps grephistory transitioned to that domain to ensure access to the innd database. I guess I could make that file news_spool_t, or just create it somewhere in the news spool, where innd normally operates. That still leaves the 2nd AVC, path="socket[63191]". I have no idea what that socket is for. OK, I just ran an strace on grephistory, and the only socket it uses is to /dev/log. What, innd_t isn't allowed to talk to syslogd?!?!? > >> 3) Here are the complaints resulting from running "enscript -f >> Courier9 /etc/dhclient-exit-hooks" (output going to an HP printer). >> I have no idea what the problem is here, but it looks major: >> >> avc: denied { getattr } for pid=6927 comm="python" path="/var/run/cups/cups.sock" dev=hda6 ino=283435 >> scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:cupsd_var_run_t:s0 tclass=sock_file >> avc: denied { read } for pid=6927 comm="python" name="random" dev=tmpfs ino=2188 scontext=system_u:system_r:hald_t:s0 >> tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file >> avc: denied { write } for pid=6927 comm="python" name="cups.sock" dev=hda6 ino=283435 >> scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:cupsd_var_run_t:s0 tclass=sock_file >> avc: denied { connectto } for pid=6927 comm="python" path="/var/run/cups/cups.sock" >> scontext=system_u:system_r:hald_t:s0 tcontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tclass=unix_stream_socket >> avc: denied { read } for pid=6927 comm="python" name="0" dev=hda6 ino=283436 scontext=system_u:system_r:hald_t:s0 >> tcontext=system_u:object_r:cupsd_var_run_t:s0 tclass=file >> avc: denied { getattr } for pid=6927 comm="python" path="/var/run/cups/certs/0" dev=hda6 ino=283436 >> scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:cupsd_var_run_t:s0 tclass=file >> avc: denied { getattr } for pid=6955 comm="sh" path="/usr/bin/hpijs" dev=hda5 ino=65915 >> scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:hplip_exec_t:s0 tclass=file >> avc: denied { execute } for pid=6955 comm="sh" name="hpijs" dev=hda5 ino=65915 >> scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:hplip_exec_t:s0 tclass=file >> avc: denied { read } for pid=6955 comm="sh" name="hpijs" dev=hda5 ino=65915 >> scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:hplip_exec_t:s0 tclass=file >> avc: denied { execute_no_trans } for pid=6955 comm="sh" path="/usr/bin/hpijs" dev=hda5 ino=65915 >> scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:hplip_exec_t:s0 tclass=file > > /me leaves this one for Dan to look at in the morning. some of it looks > like a simple bug dan needs to fix in policy and isn't your fault (aka > the cupsd_t -> hplip_exec_t stuff) but the right way to fix the hald_t > -> cups issue I'm not sure of and we should leave that to the policy > expert. Could still be my fault. I'm running hplip-1.7.4a-3.fc6, not the older version that's in CentOS 5.1 (which doesn't support my printer), but FC6 was the basis for RHEL5/CentOS-5. >> 4) Oh yes, some mail arrived around this time. Here are the complaints >> from procmail. Someone apparently feels that 'pidof' should be locked >> away for life without parole. >> >> avc: denied { read } for pid=5231 comm="pidof" name="stat" dev=proc ino=217317389 >> scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:sendmail_t:s0 tclass=file >> avc: denied { getattr } for pid=5231 comm="pidof" path="/proc/3316/stat" dev=proc ino=217317389 >> scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:sendmail_t:s0 tclass=file > > remember, its not that pidof is being locked away without parole, its > that dhcpc_t is being locked away. 2 options really: open up dhcpc_t > policy with audit2allow -a/rinse/repeat (or do it in permissive one time > rather than rinse repeat which you seem to have discovered) or add a new > transition so that dhcpc_t can run pidof in an unconfined domain. I'm > sure Dan will give details on this when he wakes up. > >> 5) There are also a bunch of AVCs that occur during system boot and shutdown. >> For example, here are a couple that come up during boot. Now of course >> 'klogd' should be denied read permission for /proc/kmesg -- that is just >> _such_ an _evil_ thing for it to be doing! As for mcstransd, looks like >> it found it's way down into /var/named/chroot/proc and obviously couldn't >> be trusted there. >> >> avc: denied { read } for pid=2747 comm="klogd" path="/proc/kmsg" dev=proc ino=-268435447 >> scontext=system_u:system_r:klogd_t:s0 tcontext=system_u:object_r:named_conf_t:s0 tclass=file >> avc: denied { search } for pid=2768 comm="mcstransd" name="/" dev=proc ino=1 >> scontext=system_u:system_r:setrans_t:s0-s0:c0.c1023 tcontext=system_u:object_r:named_conf_t:s0 tclass=dir > > Hmmmm, both of these are an issue with your having proc mounted inside > the named chroot, why klogd is looking at the /proc/kmsg inside the > chroot I have no idea. I thought that labeling for /proc would be > correct even with strange mount points, I'll have to think about this > when I get up in the morning. It is almost midnight here. That's a non-issue, then. Somehow I missed the "named_conf_t" on that first AVC. If I had SELinux running in enforcing mode, there would be no need to run named chroot-ed. >> The phrase, "Not ready for prime time" comes to mind. > > I think we both agree you have the dhcp client do some pretty damn > extraordinary things and no access control system is going to allow all > of this out of the box. Somce things we can still fix easily (dontaudit > and labeling for innd_t) and some things that I'm not sure what's wrong > but I'm not the policy guru. Just remember you are trying to make > dhcpc_t do things it was absolutely not designed to do. While I'll > admit coming at this with no experience may make it seem daunting I'm > sure you'll agree that most of the issues can be solved with little > trouble. (I wish I could say all, but I don't even know the solution to > all of them without a little playing a dabbling) > > as a sidebar, you might consider adding an audit rule like > > auditctl -a exit,always -S kill -F pid=1 > > this will add audit syscall overhead (which maybe be an issue if you box > can't handle a bit more load) but will give you 'better' path names and > such in your denial messages so you don't usually have to hunt down > things like inode numbers.... Thanks, Eric. That's a bit more encouraging. I'm going to give this a rest for a week or so. Right now I've restored my system back to the way it was before I started experimenting. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. From paul at city-fan.org Tue Mar 4 13:26:59 2008 From: paul at city-fan.org (Paul Howarth) Date: Tue, 04 Mar 2008 13:26:59 +0000 Subject: mock context needs updating Message-ID: <47CD4E23.4030700@city-fan.org> Since mock 0.9.x (I think), mock has dropped the SUID helper and become a consolehelper-based application. So /usr/bin/mock, which used to be a regular file labelled as unconfined_notrans_exec_t, is now a symlink to /usr/sbin/mock. As a result of this, mock now does domain transitions and that results in some AVCs. I think that labelling /usr/sbin/mock as unconfined_notrans_exec_t should fix it. I believe this currently affects Fedora 8 and Rawhide but not (yet) Fedora 7. Paul. From paul at city-fan.org Tue Mar 4 13:35:17 2008 From: paul at city-fan.org (Paul Howarth) Date: Tue, 04 Mar 2008 13:35:17 +0000 Subject: F8 samba AVCs Message-ID: <47CD5015.2030400@city-fan.org> I seem to have started getting some strange samba AVCs recently. time->Tue Mar 4 09:19:23 2008 type=SYSCALL msg=audit(1204622363.345:5098): arch=c000003e syscall=4 success=no exit=-13 a0=7fff884950d0 a1=7fff88494800 a2=7fff88494800 a3=7fff88494cd0 items=0 ppid=6593 pid=1987 auid=500 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) comm="smbd" exe="/usr/sbin/smbd" subj=unconfined_u:system_r:smbd_t:s0 key=(null) type=AVC msg=audit(1204622363.345:5098): avc: denied { getattr } for pid=1987 comm="smbd" path="/home/paul/.recently-used.xbel" dev=dm-16 ino=2442050 scontext=unconfined_u:system_r:smbd_t:s0 tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=file This is despite having samba_enable_home_dirs set: # getsebool -a | grep samba samba_domain_controller --> off samba_enable_home_dirs --> on samba_export_all_ro --> off samba_export_all_rw --> off samba_run_unconfined --> on samba_share_nfs --> off use_samba_home_dirs --> off # rpm -qa --last selinux\* selinux-policy-devel-3.0.8-87.fc8 Fri 29 Feb 2008 11:23:47 AM GMT selinux-policy-targeted-3.0.8-87.fc8 Fri 29 Feb 2008 11:23:32 AM GMT selinux-policy-3.0.8-87.fc8 Fri 29 Feb 2008 11:23:28 AM GMT BTW, what does samba_run_unconfined do? What's the difference between user_home_t and unconfined_home_t? This box is a fresh install of F8 but with /home preserved from F7. Paul. From dwalsh at redhat.com Tue Mar 4 14:24:36 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 04 Mar 2008 09:24:36 -0500 Subject: SELinux is preventing access to files with the label, file_t. In-Reply-To: <219731.39915.qm@web52607.mail.re2.yahoo.com> References: <219731.39915.qm@web52607.mail.re2.yahoo.com> Message-ID: <47CD5BA4.6030803@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Antonio Olivares wrote: > Dear all, > > I have done this before : > > "touch /.autorelabel; reboot" > > several days pass and I see this file_t again and I > have to do "in quote" this again . What is file_t > anyway? > I do not know of any in my system. > > Thanks, > > Antonio > > Summary: > > SELinux is preventing access to files with the label, > file_t. > > Detailed Description: > > SELinux permission checks on files labeled file_t are > being denied. file_t is > the context the SELinux kernel gives to files that do > not have a label. This > indicates a serious labeling problem. No files on an > SELinux box should ever be > labeled file_t. If you have just added a new disk > drive to the system you can > relabel it using the restorecon command. Otherwise you > should relabel the entire > files system. > > Allowing Access: > > You can execute the following command as root to > relabel your computer system: > "touch /.autorelabel; reboot" > > Additional Information: > > Source Context > system_u:system_r:tmpreaper_t > Target Context system_u:object_r:file_t > Target Objects > ./virtual-olivares.1dNZIJ [ dir ] > Source tmpwatch > Source Path /usr/sbin/tmpwatch > Port > Host localhost > Source RPM Packages tmpwatch-2.9.13-2 > Target RPM Packages > Policy RPM > selinux-policy-3.3.1-9.fc9 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name file > Host Name localhost > Platform Linux localhost > 2.6.25-0.80.rc3.git2.fc9 #1 SMP > Fri Feb 29 18:17:34 EST > 2008 i686 athlon > Alert Count 1 > First Seen Mon 03 Mar 2008 10:01:18 > AM CST > Last Seen Mon 03 Mar 2008 10:01:18 > AM CST > Local ID > 08676827-232c-4027-aa44-9431e45d6d53 > Line Numbers > > Raw Audit Messages > > host=localhost type=AVC msg=audit(1204560078.2:50): > avc: denied { rmdir } for pid=32386 comm="tmpwatch" > name="virtual-olivares.1dNZIJ" dev=dm-0 ino=31391789 > scontext=system_u:system_r:tmpreaper_t:s0 > tcontext=system_u:object_r:file_t:s0 tclass=dir > > host=localhost type=SYSCALL > msg=audit(1204560078.2:50): arch=40000003 syscall=40 > success=no exit=-13 a0=960ec33 a1=28 a2=960f1a0 > a3=960ec33 items=0 ppid=32384 pid=32386 > auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 > egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 > comm="tmpwatch" exe="/usr/sbin/tmpwatch" > subj=system_u:system_r:tmpreaper_t:s0 key=(null) > > > > > > ____________________________________________________________________________________ > Never miss a thing. Make Yahoo your home page. > http://www.yahoo.com/r/hs > File_t is an unlabeled file. The kernel looks at the extended attributes of a file for its file context, if none are found it reports it as file_t. The only way you should be able to get a file_t is if you put in an unlabeled file system and moved the file over. This should not happen ordinarily. Also you can fix the file labels with a restorecon/chcon call rather then a full relabel, or you can just delete the file. Is this file being created from a virtual machine? How is this file getting there? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfNW6QACgkQrlYvE4MpobPzUACfT2F2yntWpqzYgHfWZY2CDAwB piIAnihXDsWWR9lHmsQ0zkgJMVCCYq/y =D9f5 -----END PGP SIGNATURE----- From ekuns at kilroy.chi.il.us Tue Mar 4 14:31:42 2008 From: ekuns at kilroy.chi.il.us (Edward Kuns) Date: Tue, 04 Mar 2008 08:31:42 -0600 Subject: F8 samba AVCs In-Reply-To: <47CD5015.2030400@city-fan.org> References: <47CD5015.2030400@city-fan.org> Message-ID: <1204641102.3979.407.camel@kilroy.chi.il.us> On Tue, 2008-03-04 at 13:35 +0000, Paul Howarth wrote: > I seem to have started getting some strange samba AVCs recently. > > This is despite having samba_enable_home_dirs set: I have seen this also. Everything *appears* to work, but I do see this AVC or one a lot like it. Eddie From dwalsh at redhat.com Tue Mar 4 14:52:32 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 04 Mar 2008 09:52:32 -0500 Subject: Trying SELinux again on CentOS 5.1 - not quite HOPELESS In-Reply-To: <1204606085.3216.84.camel@localhost.localdomain> References: <47CC654D.5060100@redhat.com> <16de708d0803031629o50a21459le7f306d61d9add2b@mail.gmail.com> <1204606085.3216.84.camel@localhost.localdomain> Message-ID: <47CD6230.6000708@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Paris wrote: > On Mon, 2008-03-03 at 21:34 -0600, Robert Nichols wrote: >> Arthur Pemberton wrote: >>> On Mon, Mar 3, 2008 at 6:25 PM, Robert Nichols >>> wrote: >>>> Daniel J Walsh wrote: >>>> > Simplest thing is to run this through >>>> > # grep avc /var/log/audit2allow | audit2allow -M mypol >>>> > # semodule -i mypol.pp >>>> > >>>> > >>>> > You might want to first update to the U2 preview policy, available on >>>> > http://people.redhat.com/dwalsh/SELinux/RHEL5 >>>> >>>> This is turning into a worse disaster than I would have imagined. >>> >>> I have SELinux running in targeted mode on two machines with Centos5 >>> without issue. What exactly is the problem you are having? >> You really want to know?? OK, there's probably enough here to get >> me banned from the list, but here it comes ... : >> >> 1) The bulk of the AVCs are coming from 'pidof' running in context >> system_u:system_r:dhcpc_t needing "ptrace" capability for every >> tcontext that might show up in /proc. audit2allow is NOT the >> solution for that. Apart from the problem of individually allowing >> every possible tcontext, allowing "ptrace" for just any process >> that might be running with that scontext would be a big security >> hole. > > sounds like you want 2 rules > > allow dhcpc_t named_t:process ptrace > dontaudit dhcpc_t *:process ptrace Using interfaces this will probably work. ps_process_pattern(dhcpc_t, named_t) domain_dontaudit_ptrace_all_domains(dhcpc_t) domain_dontaudit_read_all_domains_state(dhcpc_t) > > never tried it, but I think that will take care of it. dhcpc_t will be > able to only troll around in the correct /proc directories and your logs > will be empty from all the denials. > >> 2) Here is what happened when the news fetch started. This looks >> like the classic problem of using shell I/O redirection to do the >> unthinkable and send the output from a command to a file. Why >> someone thought that 'grephistory' needed to be restricted is >> totally unfathomable to me: >> >> avc: denied { write } for pid=6305 comm="grephistory" path="/var/local/suck/suck.new-ids" dev=hda6 ino=189277 >> scontext=root:system_r:innd_t:s0-s0:c0.c1023 tcontext=root:object_r:var_t:s0 tclass=file >> avc: denied { read write } for pid=6305 comm="grephistory" path="socket:[63191]" dev=sockfs ino=63191 >> scontext=root:system_r:innd_t:s0-s0:c0.c1023 tcontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tclass=tcp_socket >> avc: denied { getattr } for pid=6305 comm="grephistory" path="/var/local/suck/suck.new-ids" dev=hda6 ino=189277 >> scontext=root:system_r:innd_t:s0-s0:c0.c1023 tcontext=root:object_r:var_t:s0 tclass=file > > Its no grephistory that is confined. The program that called it was > running as innd_t and so when it called grephistory it continued to run > in the innd_t domain. /me knows nothing about the news stuff, but this > sounds like something that needs to be fixed with labeling rather than > allow rules. The issue is that (and I'm just guessing > here) /var/local/suck is not the standard place innd needs to write. > Since you changed where it needs to write you need to make sure those > files are labeled the way they needs to be to accept writes rather than > the generic default fallback var_t. I have no idea what innd_t is > supposed to be able to write to, but lets assume there are types which > fit (aka run matchpathcon against a path name you know it is able to > write to). Then do something like "semanage fcontext -a -t [insert > type] "/var/local/suck(/.*)?" followed by restorecon -R > -v /var/local/suck. Viola, no custom policy, just telling it how > things need to be labeled. > # semanage fcontext -a -t innd_var_run_t /var/local/suck(/.*)? # restorecon -R -v /var/local/suck Or better yet move this file to /var/run/innd or /var/lib/news >> 3) Here are the complaints resulting from running "enscript -f >> Courier9 /etc/dhclient-exit-hooks" (output going to an HP printer). >> I have no idea what the problem is here, but it looks major: >> >> avc: denied { getattr } for pid=6927 comm="python" path="/var/run/cups/cups.sock" dev=hda6 ino=283435 >> scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:cupsd_var_run_t:s0 tclass=sock_file >> avc: denied { read } for pid=6927 comm="python" name="random" dev=tmpfs ino=2188 scontext=system_u:system_r:hald_t:s0 >> tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file >> avc: denied { write } for pid=6927 comm="python" name="cups.sock" dev=hda6 ino=283435 >> scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:cupsd_var_run_t:s0 tclass=sock_file >> avc: denied { connectto } for pid=6927 comm="python" path="/var/run/cups/cups.sock" >> scontext=system_u:system_r:hald_t:s0 tcontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tclass=unix_stream_socket >> avc: denied { read } for pid=6927 comm="python" name="0" dev=hda6 ino=283436 scontext=system_u:system_r:hald_t:s0 >> tcontext=system_u:object_r:cupsd_var_run_t:s0 tclass=file >> avc: denied { getattr } for pid=6927 comm="python" path="/var/run/cups/certs/0" dev=hda6 ino=283436 >> scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:cupsd_var_run_t:s0 tclass=file >> avc: denied { getattr } for pid=6955 comm="sh" path="/usr/bin/hpijs" dev=hda5 ino=65915 >> scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:hplip_exec_t:s0 tclass=file >> avc: denied { execute } for pid=6955 comm="sh" name="hpijs" dev=hda5 ino=65915 >> scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:hplip_exec_t:s0 tclass=file >> avc: denied { read } for pid=6955 comm="sh" name="hpijs" dev=hda5 ino=65915 >> scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:hplip_exec_t:s0 tclass=file >> avc: denied { execute_no_trans } for pid=6955 comm="sh" path="/usr/bin/hpijs" dev=hda5 ino=65915 >> scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:hplip_exec_t:s0 tclass=file > This would either involve writing your own policy of sucking in the hal and cups policy from Fedora. > /me leaves this one for Dan to look at in the morning. some of it looks > like a simple bug dan needs to fix in policy and isn't your fault (aka > the cupsd_t -> hplip_exec_t stuff) but the right way to fix the hald_t > -> cups issue I'm not sure of and we should leave that to the policy > expert. > >> 4) Oh yes, some mail arrived around this time. Here are the complaints >> from procmail. Someone apparently feels that 'pidof' should be locked >> away for life without parole. >> >> avc: denied { read } for pid=5231 comm="pidof" name="stat" dev=proc ino=217317389 >> scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:sendmail_t:s0 tclass=file >> avc: denied { getattr } for pid=5231 comm="pidof" path="/proc/3316/stat" dev=proc ino=217317389 >> scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:sendmail_t:s0 tclass=file > THese are the same bugs as above and the dontaudit interfaces would remove it. This is just a matter of dhcpc_t trying to read all processes. > remember, its not that pidof is being locked away without parole, its > that dhcpc_t is being locked away. 2 options really: open up dhcpc_t > policy with audit2allow -a/rinse/repeat (or do it in permissive one time > rather than rinse repeat which you seem to have discovered) or add a new > transition so that dhcpc_t can run pidof in an unconfined domain. I'm > sure Dan will give details on this when he wakes up. > >> 5) There are also a bunch of AVCs that occur during system boot and shutdown. >> For example, here are a couple that come up during boot. Now of course >> 'klogd' should be denied read permission for /proc/kmesg -- that is just >> _such_ an _evil_ thing for it to be doing! As for mcstransd, looks like >> it found it's way down into /var/named/chroot/proc and obviously couldn't >> be trusted there. >> >> avc: denied { read } for pid=2747 comm="klogd" path="/proc/kmsg" dev=proc ino=-268435447 >> scontext=system_u:system_r:klogd_t:s0 tcontext=system_u:object_r:named_conf_t:s0 tclass=file >> avc: denied { search } for pid=2768 comm="mcstransd" name="/" dev=proc ino=1 >> scontext=system_u:system_r:setrans_t:s0-s0:c0.c1023 tcontext=system_u:object_r:named_conf_t:s0 tclass=dir > THese are bugs in named-chroot. You can also turn off msctransd as it does very little for you. > Hmmmm, both of these are an issue with your having proc mounted inside > the named chroot, why klogd is looking at the /proc/kmsg inside the > chroot I have no idea. I thought that labeling for /proc would be > correct even with strange mount points, I'll have to think about this > when I get up in the morning. It is almost midnight here. > >> The phrase, "Not ready for prime time" comes to mind. > > I think we both agree you have the dhcp client do some pretty damn > extraordinary things and no access control system is going to allow all > of this out of the box. Somce things we can still fix easily (dontaudit > and labeling for innd_t) and some things that I'm not sure what's wrong > but I'm not the policy guru. Just remember you are trying to make > dhcpc_t do things it was absolutely not designed to do. While I'll > admit coming at this with no experience may make it seem daunting I'm > sure you'll agree that most of the issues can be solved with little > trouble. (I wish I could say all, but I don't even know the solution to > all of them without a little playing a dabbling) > > as a sidebar, you might consider adding an audit rule like > > auditctl -a exit,always -S kill -F pid=1 > > this will add audit syscall overhead (which maybe be an issue if you box > can't handle a bit more load) but will give you 'better' path names and > such in your denial messages so you don't usually have to hunt down > things like inode numbers.... > > -Eric > Robert, As Eric said the policy changes you want are not going to be fixed in Fedora 9/10/11. They are caused by you running a lots of additional applications that a confined domain is not expected to run. We can know all possible code paths for what people are going to do, and if you believe SELinux is not ready for prime time, that is fine. We have the flexibilty to work though all of your avc messages and customize the policy, but if you decide you don't want the headache then turn it off. SELinux is attempting to confine potentially dangerous applications like dhcp which listens to untrusted content on the wire and executes as root. We try to design the policy as flexible as possible, but in a customized environment like yours, it will fail, with out a decent amount of policy writing. > -- > 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.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfNYjAACgkQrlYvE4MpobMo7wCg5H1eEPjB3n7q5LwBoB+Ew4QB qswAoKNcEjUecDYJZsHZV2cjrCdF4y9Z =6DNE -----END PGP SIGNATURE----- From dwalsh at redhat.com Tue Mar 4 15:02:00 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 04 Mar 2008 10:02:00 -0500 Subject: Trying SELinux again on CentOS 5.1 - not quite HOPELESS In-Reply-To: References: <47CC654D.5060100@redhat.com> <16de708d0803031629o50a21459le7f306d61d9add2b@mail.gmail.com> <1204606085.3216.84.camel@localhost.localdomain> Message-ID: <47CD6468.1070206@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Nichols wrote: > Eric Paris wrote: >> On Mon, 2008-03-03 at 21:34 -0600, Robert Nichols wrote: >>> 1) The bulk of the AVCs are coming from 'pidof' running in context >>> system_u:system_r:dhcpc_t needing "ptrace" capability for every >>> tcontext that might show up in /proc. audit2allow is NOT the >>> solution for that. Apart from the problem of individually allowing >>> every possible tcontext, allowing "ptrace" for just any process >>> that might be running with that scontext would be a big security >>> hole. >> >> sounds like you want 2 rules >> >> allow dhcpc_t named_t:process ptrace >> dontaudit dhcpc_t *:process ptrace >> >> never tried it, but I think that will take care of it. dhcpc_t will be >> able to only troll around in the correct /proc directories and your logs >> will be empty from all the denials. >> >>> 2) Here is what happened when the news fetch started. This looks >>> like the classic problem of using shell I/O redirection to do the >>> unthinkable and send the output from a command to a file. Why >>> someone thought that 'grephistory' needed to be restricted is >>> totally unfathomable to me: >>> >>> avc: denied { write } for pid=6305 comm="grephistory" >>> path="/var/local/suck/suck.new-ids" dev=hda6 ino=189277 >>> scontext=root:system_r:innd_t:s0-s0:c0.c1023 >>> tcontext=root:object_r:var_t:s0 tclass=file >>> avc: denied { read write } for pid=6305 comm="grephistory" >>> path="socket:[63191]" dev=sockfs ino=63191 >>> scontext=root:system_r:innd_t:s0-s0:c0.c1023 >>> tcontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tclass=tcp_socket >>> avc: denied { getattr } for pid=6305 comm="grephistory" >>> path="/var/local/suck/suck.new-ids" dev=hda6 ino=189277 >>> scontext=root:system_r:innd_t:s0-s0:c0.c1023 >>> tcontext=root:object_r:var_t:s0 tclass=file >> >> Its no grephistory that is confined. The program that called it was >> running as innd_t and so when it called grephistory it continued to run >> in the innd_t domain. > > The program that called grephistory was running from root's crontab. No > way > was that running as innd_t. Perhaps grephistory transitioned to that > domain to ensure access to the innd database. I guess I could make that > file news_spool_t, or just create it somewhere in the news spool, where > innd > normally operates. That still leaves the 2nd AVC, path="socket[63191]". > I have no idea what that socket is for. OK, I just ran an strace on > grephistory, and the only socket it uses is to /dev/log. What, innd_t > isn't > allowed to talk to syslogd?!?!? > NO this is a leaked file descriptor. You have a process running unconfined_t that is transitioning to innd_t and leaking an open file descriptor to innd_t. Without SELinux innd_t would be able to communicate on this open tcp_socket. SELinux closes the descriptor and reports the AVC. >> >>> 3) Here are the complaints resulting from running "enscript -f >>> Courier9 /etc/dhclient-exit-hooks" (output going to an HP printer). >>> I have no idea what the problem is here, but it looks major: >>> >>> avc: denied { getattr } for pid=6927 comm="python" >>> path="/var/run/cups/cups.sock" dev=hda6 ino=283435 >>> scontext=system_u:system_r:hald_t:s0 >>> tcontext=system_u:object_r:cupsd_var_run_t:s0 tclass=sock_file >>> avc: denied { read } for pid=6927 comm="python" name="random" >>> dev=tmpfs ino=2188 scontext=system_u:system_r:hald_t:s0 >>> tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file >>> avc: denied { write } for pid=6927 comm="python" name="cups.sock" >>> dev=hda6 ino=283435 scontext=system_u:system_r:hald_t:s0 >>> tcontext=system_u:object_r:cupsd_var_run_t:s0 tclass=sock_file >>> avc: denied { connectto } for pid=6927 comm="python" >>> path="/var/run/cups/cups.sock" scontext=system_u:system_r:hald_t:s0 >>> tcontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 >>> tclass=unix_stream_socket >>> avc: denied { read } for pid=6927 comm="python" name="0" dev=hda6 >>> ino=283436 scontext=system_u:system_r:hald_t:s0 >>> tcontext=system_u:object_r:cupsd_var_run_t:s0 tclass=file >>> avc: denied { getattr } for pid=6927 comm="python" >>> path="/var/run/cups/certs/0" dev=hda6 ino=283436 >>> scontext=system_u:system_r:hald_t:s0 >>> tcontext=system_u:object_r:cupsd_var_run_t:s0 tclass=file >>> avc: denied { getattr } for pid=6955 comm="sh" >>> path="/usr/bin/hpijs" dev=hda5 ino=65915 >>> scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 >>> tcontext=system_u:object_r:hplip_exec_t:s0 tclass=file >>> avc: denied { execute } for pid=6955 comm="sh" name="hpijs" >>> dev=hda5 ino=65915 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 >>> tcontext=system_u:object_r:hplip_exec_t:s0 tclass=file >>> avc: denied { read } for pid=6955 comm="sh" name="hpijs" dev=hda5 >>> ino=65915 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 >>> tcontext=system_u:object_r:hplip_exec_t:s0 tclass=file >>> avc: denied { execute_no_trans } for pid=6955 comm="sh" >>> path="/usr/bin/hpijs" dev=hda5 ino=65915 >>> scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 >>> tcontext=system_u:object_r:hplip_exec_t:s0 tclass=file >> >> /me leaves this one for Dan to look at in the morning. some of it looks >> like a simple bug dan needs to fix in policy and isn't your fault (aka >> the cupsd_t -> hplip_exec_t stuff) but the right way to fix the hald_t >> -> cups issue I'm not sure of and we should leave that to the policy >> expert. > > Could still be my fault. I'm running hplip-1.7.4a-3.fc6, not the older > version that's in CentOS 5.1 (which doesn't support my printer), but FC6 > was the basis for RHEL5/CentOS-5. > These are in Rawhide and Fedora 8 policy so I will add them to RHEL5.2 policy domtrans_pattern(cupsd_t,hplip_exec_t, hplip_t) domtrans_pattern(cupsd_config_t,hplip_exec_t, hplip_t) >>> 4) Oh yes, some mail arrived around this time. Here are the complaints >>> from procmail. Someone apparently feels that 'pidof' should be locked >>> away for life without parole. >>> >>> avc: denied { read } for pid=5231 comm="pidof" name="stat" >>> dev=proc ino=217317389 scontext=system_u:system_r:dhcpc_t:s0 >>> tcontext=system_u:system_r:sendmail_t:s0 tclass=file >>> avc: denied { getattr } for pid=5231 comm="pidof" >>> path="/proc/3316/stat" dev=proc ino=217317389 >>> scontext=system_u:system_r:dhcpc_t:s0 >>> tcontext=system_u:system_r:sendmail_t:s0 tclass=file >> >> remember, its not that pidof is being locked away without parole, its >> that dhcpc_t is being locked away. 2 options really: open up dhcpc_t >> policy with audit2allow -a/rinse/repeat (or do it in permissive one time >> rather than rinse repeat which you seem to have discovered) or add a new >> transition so that dhcpc_t can run pidof in an unconfined domain. I'm >> sure Dan will give details on this when he wakes up. >> >>> 5) There are also a bunch of AVCs that occur during system boot and >>> shutdown. >>> For example, here are a couple that come up during boot. Now of course >>> 'klogd' should be denied read permission for /proc/kmesg -- that is just >>> _such_ an _evil_ thing for it to be doing! As for mcstransd, looks like >>> it found it's way down into /var/named/chroot/proc and obviously >>> couldn't >>> be trusted there. >>> >>> avc: denied { read } for pid=2747 comm="klogd" path="/proc/kmsg" >>> dev=proc ino=-268435447 scontext=system_u:system_r:klogd_t:s0 >>> tcontext=system_u:object_r:named_conf_t:s0 tclass=file >>> avc: denied { search } for pid=2768 comm="mcstransd" name="/" >>> dev=proc ino=1 scontext=system_u:system_r:setrans_t:s0-s0:c0.c1023 >>> tcontext=system_u:object_r:named_conf_t:s0 tclass=dir >> >> Hmmmm, both of these are an issue with your having proc mounted inside >> the named chroot, why klogd is looking at the /proc/kmsg inside the >> chroot I have no idea. I thought that labeling for /proc would be >> correct even with strange mount points, I'll have to think about this >> when I get up in the morning. It is almost midnight here. > > That's a non-issue, then. Somehow I missed the "named_conf_t" on that > first AVC. If I had SELinux running in enforcing mode, there would be > no need to run named chroot-ed. > >>> The phrase, "Not ready for prime time" comes to mind. >> >> I think we both agree you have the dhcp client do some pretty damn >> extraordinary things and no access control system is going to allow all >> of this out of the box. Somce things we can still fix easily (dontaudit >> and labeling for innd_t) and some things that I'm not sure what's wrong >> but I'm not the policy guru. Just remember you are trying to make >> dhcpc_t do things it was absolutely not designed to do. While I'll >> admit coming at this with no experience may make it seem daunting I'm >> sure you'll agree that most of the issues can be solved with little >> trouble. (I wish I could say all, but I don't even know the solution to >> all of them without a little playing a dabbling) >> >> as a sidebar, you might consider adding an audit rule like >> >> auditctl -a exit,always -S kill -F pid=1 >> >> this will add audit syscall overhead (which maybe be an issue if you box >> can't handle a bit more load) but will give you 'better' path names and >> such in your denial messages so you don't usually have to hunt down >> things like inode numbers.... > > Thanks, Eric. That's a bit more encouraging. I'm going to give this a > rest for a week or so. Right now I've restored my system back to the > way it was before I started experimenting. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfNZGgACgkQrlYvE4MpobO1MgCgjJPbXGV26MkDg1OaduAzERt3 eX0An1yr40QV6Oy0VCqDQ1AsKZkXYRUf =UPMW -----END PGP SIGNATURE----- From dwalsh at redhat.com Tue Mar 4 15:03:59 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 04 Mar 2008 10:03:59 -0500 Subject: SELinux is preventing npviewer.bin (nsplugin_t) "read" to controlC0 (sound_device_t). In-Reply-To: <907187.66631.qm@web52603.mail.re2.yahoo.com> References: <907187.66631.qm@web52603.mail.re2.yahoo.com> Message-ID: <47CD64DF.1050301@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Antonio Olivares wrote: > Dear all, > > I am getting to see the following errors that slow > down my machine and take CPU to 100% > > Thanks, > > Antonio > > Summary: > > SELinux is preventing npviewer.bin (nsplugin_t) "read" > to controlC0 > (sound_device_t). > > Detailed Description: > > SELinux denied access requested by npviewer.bin. It is > not expected that this > access is required by npviewer.bin 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 controlC0, > > restorecon -v 'controlC0' > > 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:unconfined_r:nsplugin_t:SystemLow- > SystemHigh > Target Context > system_u:object_r:sound_device_t > Target Objects controlC0 [ chr_file ] > Source npviewer.bin > Source Path > /usr/lib/nspluginwrapper/npviewer.bin > Port > Host localhost > Source RPM Packages > nspluginwrapper-0.9.91.5-23.fc9 > Target RPM Packages > Policy RPM > selinux-policy-3.3.1-9.fc9 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name catchall_file > Host Name localhost > Platform Linux localhost > 2.6.25-0.80.rc3.git2.fc9 #1 SMP > Fri Feb 29 18:17:34 EST > 2008 i686 athlon > Alert Count 2689 > First Seen Tue 26 Feb 2008 03:24:34 > PM CST > Last Seen Mon 03 Mar 2008 03:54:56 > PM CST > Local ID > 469b1532-4ab3-4757-be58-2248cc0f9f05 > Line Numbers > > Raw Audit Messages > > host=localhost type=AVC > msg=audit(1204581296.416:2216): avc: denied { read } > for pid=1218 comm="npviewer.bin" name="controlC0" > dev=tmpfs ino=5312 > scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:sound_device_t:s0 > tclass=chr_file > > host=localhost type=SYSCALL > msg=audit(1204581296.416:2216): arch=40000003 > syscall=5 success=no exit=-13 a0=bfe497f2 a1=0 a2=1e > a3=bfe497f2 items=0 ppid=32748 pid=1218 auid=500 > uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 > sgid=500 fsgid=500 tty=(none) ses=1 > comm="npviewer.bin" > exe="/usr/lib/nspluginwrapper/npviewer.bin" > subj=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 > key=(null) > > > > Just add the rule using audit2allow. I will add tonight. > > ____________________________________________________________________________________ > Be a better friend, newshound, and > know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfNZN8ACgkQrlYvE4MpobNxTgCgplKlWIMqwGT5C5vpfIFq9+kI XNYAnjZhaNkPYJ1mcwIzZHADiSfpxp/m =P1g6 -----END PGP SIGNATURE----- From dwalsh at redhat.com Tue Mar 4 15:10:36 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 04 Mar 2008 10:10:36 -0500 Subject: SELinux prevented dbus-daemon from using the terminal /dev/tty1. In-Reply-To: <279047.79234.qm@web52601.mail.re2.yahoo.com> References: <279047.79234.qm@web52601.mail.re2.yahoo.com> Message-ID: <47CD666C.9090001@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Antonio Olivares wrote: > At one point, these were cured and now they reappear. > How can I make them go away for good? > > Thanks, > > Antonio > > Summary: > > SELinux prevented dbus-daemon from using the terminal > /dev/tty1. > > Detailed Description: > > SELinux prevented dbus-daemon from using the terminal > /dev/tty1. In most cases > daemons do not need to interact with the terminal, > usually these avc messages > can be ignored. All of the confined daemons should > have dontaudit rules around > using the terminal. Please file a bug report > (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) > against this selinux-policy. > If you would like to allow all daemons to interact > with the terminal, you can > turn on the allow_daemons_use_tty boolean. > > Allowing Access: > > Changing the "allow_daemons_use_tty" boolean to true > will allow this access: > "setsebool -P allow_daemons_use_tty=1." > > Fix Command: > > setsebool -P allow_daemons_use_tty=1 > > Additional Information: > > Source Context > unconfined_u:unconfined_r:unconfined_dbusd_t > :SystemLow-SystemHigh > Target Context > unconfined_u:object_r:unconfined_tty_device_t > Target Objects /dev/tty1 [ chr_file ] > Source dbus-daemon > Source Path /bin/dbus-daemon > Port > Host localhost > Source RPM Packages dbus-1.1.20-1.fc9 > Target RPM Packages > Policy RPM > selinux-policy-3.3.1-9.fc9 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name allow_daemons_use_tty > Host Name localhost > Platform Linux localhost > 2.6.25-0.80.rc3.git2.fc9 #1 SMP > Fri Feb 29 18:17:34 EST > 2008 i686 athlon > Alert Count 14 > First Seen Fri 01 Feb 2008 05:06:20 > PM CST > Last Seen Mon 03 Mar 2008 03:57:07 > PM CST > Local ID > c0a79310-b4d4-41fc-a712-a4db505290d5 > Line Numbers > > Raw Audit Messages > > host=localhost type=AVC > msg=audit(1204581427.951:2778): avc: denied { read > write } for pid=1306 comm="dbus-daemon" > path="/dev/tty1" dev=tmpfs ino=1857 > scontext=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 > tcontext=unconfined_u:object_r:unconfined_tty_device_t:s0 > tclass=chr_file > > host=localhost type=SYSCALL > msg=audit(1204581427.951:2778): arch=40000003 > syscall=11 success=yes exit=0 a0=804c908 a1=bf92fc8c > a2=bf9310b4 a3=7 items=0 ppid=1305 pid=1306 auid=500 > uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 > sgid=500 fsgid=500 tty=(none) ses=1 comm="dbus-daemon" > exe="/bin/dbus-daemon" > subj=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 > key=(null) > > > > > > ____________________________________________________________________________________ > Never miss a thing. Make Yahoo your home page. > http://www.yahoo.com/r/hs > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list This can be ignored. Did you restart the dbus daemon from a terminal shell? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfNZmwACgkQrlYvE4MpobPguwCgiJIsNmha8CTPf099v1OFvNIn qYMAoLdO8nB4RQOLq5luCozLL77bRHrz =65w4 -----END PGP SIGNATURE----- From rnicholsNOSPAM at comcast.net Wed Mar 5 01:52:26 2008 From: rnicholsNOSPAM at comcast.net (Robert Nichols) Date: Tue, 04 Mar 2008 19:52:26 -0600 Subject: Trying SELinux again on CentOS 5.1 - not quite HOPELESS In-Reply-To: <47CD6468.1070206@redhat.com> References: <47CC654D.5060100@redhat.com> <16de708d0803031629o50a21459le7f306d61d9add2b@mail.gmail.com> <1204606085.3216.84.camel@localhost.localdomain> <47CD6468.1070206@redhat.com> Message-ID: Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Robert Nichols wrote: >> That still leaves the 2nd AVC, path="socket[63191]". >> I have no idea what that socket is for. OK, I just ran an strace on >> grephistory, and the only socket it uses is to /dev/log. What, innd_t >> isn't >> allowed to talk to syslogd?!?!? >> > NO this is a leaked file descriptor. You have a process running > unconfined_t that is transitioning to innd_t and leaking an open file > descriptor to innd_t. Without SELinux innd_t would be able to > communicate on this open tcp_socket. SELinux closes the descriptor and > reports the AVC. Good call. The socket to the upstream news server was indeed being leaked. I'll set the close-on-exec flag on its file descriptor. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. From selinux.list at troodos.demon.co.uk Wed Mar 5 15:16:18 2008 From: selinux.list at troodos.demon.co.uk (Arthur Dent) Date: Wed, 5 Mar 2008 15:16:18 +0000 Subject: Partitions Mounted by fstab Message-ID: <20080305151618.GA9985@troodos.org.uk> Hello Chaps, I'm running SELinux in permissive mode on F8. I was thinking of switching to enforcing mode and took a peek inside /var/log/messages to see what denials SELinux is currently reporting. I was *horrified* - there must be thousands there! Doing "cat /var/log/audit/audit.log" is even worse - it takes about a minute to scroll through! They mainly relate to procmail, clamd and samba but I get many reports of incorrectly labelled files (file_t). I want to tackle these one step at a time and I think the first place to start is with the incorrectly labelled files. I have tried the "touch ./autorelabel; reboot" trick (several times!) but I still get the same errors. As a mater of interest, I have a procmail recipe which writes a copy of every mail I receive to a backup area on my /dev/sda8 partition, mounted as /mnt/backup/ by fstab. (It is an ext3 partition). I have tried doing: "restorecon -v -R /mnt/backup" and even: "fixfiles relabel" on this partition, but I gather this will not work. I think that I must somehow define a policy for this (and probably other) partition(s), but I am unclear as to how to go about this. I am reasonably familiar with Linux generally, but am a complete SELinux virgin (and frankly scared silly of it). I normally turn off SELinux as my first action after installing a distro, but I think it's about time I got to grips with its security benefits. I would be very grateful therefore if someone could hold my hand through this learning process! I have to run this particular box headless and access via ssh so I have to do everything with command-line tools. Thanks in advance... Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kwizart at gmail.com Wed Mar 5 15:25:16 2008 From: kwizart at gmail.com (KH KH) Date: Wed, 5 Mar 2008 16:25:16 +0100 Subject: Support for xorg-x11-drv-ivtv Message-ID: Hello ! I maintain xorg-x11-drv-ivtv within fedora. This is a Xorg driver for the PVR-350 video device. quote of the delopper ------------------- One thing I did notice in testing is that SELinux blocks X from accessing /dev/video48. This cripples the ivtv X driver, since it requires the video device (video48->video55) to add Xv overlay support to X. Without Xv support, video playback in programs such a mplayer, xine, mythtv, etc. won't work very well. I've attached the actual report from SELinux regarding the device access. ------------------ I wonder if this special context should be handled with a selinux-policy-'any' package and if something with udev device creation would be required. This driver remains in updates-testing for now (with F-7 F-8) and will hit Rawhide as soon as i have backported the required libpciacces patch. Nicolas (kwizart) -------------- next part -------------- A non-text attachment was scrubbed... Name: SELinux xf86-video-ivtv Type: application/octet-stream Size: 2895 bytes Desc: not available URL: From sds at tycho.nsa.gov Wed Mar 5 15:47:15 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 05 Mar 2008 10:47:15 -0500 Subject: Partitions Mounted by fstab In-Reply-To: <20080305151618.GA9985@troodos.org.uk> References: <20080305151618.GA9985@troodos.org.uk> Message-ID: <1204732035.1397.56.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-03-05 at 15:16 +0000, Arthur Dent wrote: > Hello Chaps, > > I'm running SELinux in permissive mode on F8. I was thinking of switching to > enforcing mode and took a peek inside /var/log/messages to see what denials > SELinux is currently reporting. I was *horrified* - there must be thousands > there! Doing "cat /var/log/audit/audit.log" is even worse - it takes about a minute to > scroll through! > > They mainly relate to procmail, clamd and samba but I get many reports of > incorrectly labelled files (file_t). > > I want to tackle these one step at a time and I think the first place to start > is with the incorrectly labelled files. > > I have tried the "touch ./autorelabel; reboot" trick (several times!) but I > still get the same errors. > > As a mater of interest, I have a procmail recipe which writes a copy of every > mail I receive to a backup area on my /dev/sda8 partition, mounted as > /mnt/backup/ by fstab. (It is an ext3 partition). > > I have tried doing: > "restorecon -v -R /mnt/backup" > and even: > "fixfiles relabel" > > on this partition, but I gather this will not work. I think that I must > somehow define a policy for this (and probably other) partition(s), but I am > unclear as to how to go about this. You might try something like this, assuming that you only store mail files under /mnt/backup and only procmail requires access: semanage fcontext -a -t mail_spool_t "/mnt/backup(/.*)?" restorecon -v -R /mnt/backup If you need other things to be able to access it, then we'll have to know more to decide how to label it, or you could possibly move it to a subdir of /mnt/backup like /mnt/backup/spool that can be devoted to procmail's use. > I am reasonably familiar with Linux generally, but am a complete SELinux > virgin (and frankly scared silly of it). I normally turn off SELinux as my > first action after installing a distro, but I think it's about time I got to > grips with its security benefits. > > I would be very grateful therefore if someone could hold my hand through this > learning process! > > I have to run this particular box headless and access via ssh so I have to do > everything with command-line tools. > > > Thanks in advance... > > Mark > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -- Stephen Smalley National Security Agency From selinux.list at troodos.demon.co.uk Wed Mar 5 16:12:13 2008 From: selinux.list at troodos.demon.co.uk (Arthur Dent) Date: Wed, 5 Mar 2008 16:12:13 +0000 Subject: Partitions Mounted by fstab In-Reply-To: <1204732035.1397.56.camel@moss-spartans.epoch.ncsc.mil> References: <20080305151618.GA9985@troodos.org.uk> <1204732035.1397.56.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20080305161213.GA10307@troodos.org.uk> On Wed, Mar 05, 2008 at 10:47:15AM -0500, Stephen Smalley wrote: Hi Stephen, > > > > As a mater of interest, I have a procmail recipe which writes a copy of every > > mail I receive to a backup area on my /dev/sda8 partition, mounted as > > /mnt/backup/ by fstab. (It is an ext3 partition). > > > > I have tried doing: > > "restorecon -v -R /mnt/backup" > > and even: > > "fixfiles relabel" > > > > on this partition, but I gather this will not work. I think that I must > > somehow define a policy for this (and probably other) partition(s), but I am > > unclear as to how to go about this. > > You might try something like this, assuming that you only store mail > files under /mnt/backup and only procmail requires access: > > semanage fcontext -a -t mail_spool_t "/mnt/backup(/.*)?" > restorecon -v -R /mnt/backup > Thanks! This is really helpful. > If you need other things to be able to access it, then we'll have to > know more to decide how to label it, or you could possibly move it to a > subdir of /mnt/backup like /mnt/backup/spool that can be devoted to > procmail's use. > Well, before I try the above commands... Generally it is only procmail that needs access, however, I have this file "rotated" by logrotate (run as root) on a monthly basis. It is rotated with the "date" extension and that file is archived by a cron job (root) to DVD. Oh, and I have a daily backup routine that uses "tar" run from a cron job that also includes this directory... Will those things invalidate your suggested solution? Thanks again for you help so far. Much Appreciated... Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sds at tycho.nsa.gov Wed Mar 5 16:59:16 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 05 Mar 2008 11:59:16 -0500 Subject: Partitions Mounted by fstab In-Reply-To: <20080305161213.GA10307@troodos.org.uk> References: <20080305151618.GA9985@troodos.org.uk> <1204732035.1397.56.camel@moss-spartans.epoch.ncsc.mil> <20080305161213.GA10307@troodos.org.uk> Message-ID: <1204736356.1397.78.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-03-05 at 16:12 +0000, Arthur Dent wrote: > On Wed, Mar 05, 2008 at 10:47:15AM -0500, Stephen Smalley wrote: > > Hi Stephen, > > > > > > > As a mater of interest, I have a procmail recipe which writes a copy of every > > > mail I receive to a backup area on my /dev/sda8 partition, mounted as > > > /mnt/backup/ by fstab. (It is an ext3 partition). > > > > > > I have tried doing: > > > "restorecon -v -R /mnt/backup" > > > and even: > > > "fixfiles relabel" > > > > > > on this partition, but I gather this will not work. I think that I must > > > somehow define a policy for this (and probably other) partition(s), but I am > > > unclear as to how to go about this. > > > > You might try something like this, assuming that you only store mail > > files under /mnt/backup and only procmail requires access: > > > > semanage fcontext -a -t mail_spool_t "/mnt/backup(/.*)?" > > restorecon -v -R /mnt/backup > > > Thanks! This is really helpful. > > > If you need other things to be able to access it, then we'll have to > > know more to decide how to label it, or you could possibly move it to a > > subdir of /mnt/backup like /mnt/backup/spool that can be devoted to > > procmail's use. > > > > Well, before I try the above commands... > > Generally it is only procmail that needs access, however, I have this file > "rotated" by logrotate (run as root) on a monthly basis. It is rotated with > the "date" extension and that file is archived by a cron job (root) to DVD. > > Oh, and I have a daily backup routine that uses "tar" run from a cron job that > also includes this directory... > > Will those things invalidate your suggested solution? You'll likely need a local policy module then to permit such access in addition to the commands above. Maybe something like this: # cat mymailbackup.te policy_module(mybackup, 1.0) require { # Symbols defined outside of this module. type system_crond_t; type user_crond_t; type mail_spool_t; } # Mark mail_spool_t as a log file that can be managed by logrotate. logging_log_file(mail_spool_t) # Let system and user cron jobs read it. read_files_pattern(system_crond_t, mail_spool_t, mail_spool_t) read_files_pattern(user_crond_t, mail_spool_t, mail_spool_t) # make -f /usr/share/selinux/devel/Makefile mybackup.pp # semodule -i mybackup.pp -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Wed Mar 5 17:02:40 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 05 Mar 2008 12:02:40 -0500 Subject: Partitions Mounted by fstab In-Reply-To: <1204736356.1397.78.camel@moss-spartans.epoch.ncsc.mil> References: <20080305151618.GA9985@troodos.org.uk> <1204732035.1397.56.camel@moss-spartans.epoch.ncsc.mil> <20080305161213.GA10307@troodos.org.uk> <1204736356.1397.78.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1204736560.1397.81.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-03-05 at 11:59 -0500, Stephen Smalley wrote: > On Wed, 2008-03-05 at 16:12 +0000, Arthur Dent wrote: > > On Wed, Mar 05, 2008 at 10:47:15AM -0500, Stephen Smalley wrote: > > > > Hi Stephen, > > > > > > > > > > As a mater of interest, I have a procmail recipe which writes a copy of every > > > > mail I receive to a backup area on my /dev/sda8 partition, mounted as > > > > /mnt/backup/ by fstab. (It is an ext3 partition). > > > > > > > > I have tried doing: > > > > "restorecon -v -R /mnt/backup" > > > > and even: > > > > "fixfiles relabel" > > > > > > > > on this partition, but I gather this will not work. I think that I must > > > > somehow define a policy for this (and probably other) partition(s), but I am > > > > unclear as to how to go about this. > > > > > > You might try something like this, assuming that you only store mail > > > files under /mnt/backup and only procmail requires access: > > > > > > semanage fcontext -a -t mail_spool_t "/mnt/backup(/.*)?" > > > restorecon -v -R /mnt/backup > > > > > Thanks! This is really helpful. > > > > > If you need other things to be able to access it, then we'll have to > > > know more to decide how to label it, or you could possibly move it to a > > > subdir of /mnt/backup like /mnt/backup/spool that can be devoted to > > > procmail's use. > > > > > > > Well, before I try the above commands... > > > > Generally it is only procmail that needs access, however, I have this file > > "rotated" by logrotate (run as root) on a monthly basis. It is rotated with > > the "date" extension and that file is archived by a cron job (root) to DVD. > > > > Oh, and I have a daily backup routine that uses "tar" run from a cron job that > > also includes this directory... > > > > Will those things invalidate your suggested solution? > > You'll likely need a local policy module then to permit such access > in addition to the commands above. > Maybe something like this: > > # cat mymailbackup.te > policy_module(mybackup, 1.0) > require { > # Symbols defined outside of this module. > type system_crond_t; > type user_crond_t; > type mail_spool_t; > } > > # Mark mail_spool_t as a log file that can be managed by logrotate. > logging_log_file(mail_spool_t) > # Let system and user cron jobs read it. > read_files_pattern(system_crond_t, mail_spool_t, mail_spool_t) > read_files_pattern(user_crond_t, mail_spool_t, mail_spool_t) > > # make -f /usr/share/selinux/devel/Makefile mybackup.pp > # semodule -i mybackup.pp Actually, did you need write access to /mnt/backup from the cron job, or only read access? The above only gives read access. Also, on second thought, I suppose that if you are running these as user cron jobs, they'll run unconfined_t under the default targeted policy and thus not require any additional rules at all. So you may only need the logging_log_file() part. -- Stephen Smalley National Security Agency From selinux at gmail.com Wed Mar 5 17:16:14 2008 From: selinux at gmail.com (Tom London) Date: Wed, 5 Mar 2008 09:16:14 -0800 Subject: gvfs-fuse-daemon throws read/write AVC for /dev/fuse Message-ID: <4c4ba1530803050916g6f76a513q3456f1eb80ab19a2@mail.gmail.com> Running rawhide, targeted/enforcing (selinux-policy-3.3.1-10.fc9.noarch) Notice this in /var/log/audit/audit.log: type=AVC msg=audit(1204736621.705:13): avc: denied { read write } for pid=2823 comm="gvfs-fuse-daemo" name="fuse" dev=tmpfs ino=2019 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fuse_device_t:s0 tclass=chr_file type=SYSCALL msg=audit(1204736621.705:13): arch=40000003 syscall=5 success=no exit=-13 a0=9d9118 a1=8002 a2=0 a3=8002 items=0 ppid=1 pid=2823 auid=4294967295 uid=42 gid=42 euid=42 suid=42 fsuid=42 egid=42 sgid=42 fsgid=42 tty=(none) ses=4294967295 comm="gvfs-fuse-daemo" exe="/usr/libexec/gvfs-fuse-daemon" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) But, gvfs-fuse-daemon appears to be running in unconfined_t, why xdm_t? [root at localhost ~]# ps agxZ | grep gvfs unconfined_u:unconfined_r:unconfined_t 3130 ? S 0:00 /usr/libexec/gvfsd unconfined_u:unconfined_r:unconfined_t 3137 ? Ssl 0:00 /usr/libexec//gvfs-fuse-daemon /home/tbl/.gvfs unconfined_u:unconfined_r:unconfined_t 3144 ? S 0:00 /usr/libexec/gvfsd-trash --spawner :1.8 /org/gtk/gvfs/exec_spaw/0 unconfined_u:unconfined_r:unconfined_t 3155 ? S 0:00 /usr/libexec/gvfsd-burn --spawner :1.8 /org/gtk/gvfs/exec_spaw/1 unconfined_u:unconfined_r:unconfined_t 3673 pts/0 S+ 0:00 grep gvfs [root at localhost ~]# The AVC appears to occur after the CUPS LABEL_LEVEL_CHANGES audit messages, but before the USER_AUTH from gdm-greeter. Is this some sort of transition/timing issue? tom -- Tom London From selinux at gmail.com Wed Mar 5 23:24:15 2008 From: selinux at gmail.com (Tom London) Date: Wed, 5 Mar 2008 15:24:15 -0800 Subject: qemu-kvm AVCs for tmp_t with -smb Message-ID: <4c4ba1530803051524q2acebb0ldd833097db8c2d7c@mail.gmail.com> Running rawhide, targeted/permissive: Get the following when I run "qemu-kvm .... -smb ~/dir": type=AVC msg=audit(1204759184.650:46): avc: denied { write } for pid=12188 comm="qemu-kvm" name="tmp" dev=dm-0 ino=2686977 scontext=unconfined_u:unconfined_r:qemu_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir type=AVC msg=audit(1204759184.650:46): avc: denied { add_name } for pid=12188 comm="qemu-kvm" name="qemu-smb.12188" scontext=unconfined_u:unconfined_r:qemu_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir type=AVC msg=audit(1204759184.650:46): avc: denied { create } for pid=12188 comm="qemu-kvm" name="qemu-smb.12188" scontext=unconfined_u:unconfined_r:qemu_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=dir type=SYSCALL msg=audit(1204759184.650:46): arch=40000003 syscall=39 success=yes exit=0 a0=82cb740 a1=1c0 a2=8177c24 a3=bfd0e6fd items=0 ppid=12187 pid=12188 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts1 ses=1 comm="qemu-kvm" exe="/usr/bin/qemu-kvm" subj=unconfined_u:unconfined_r:qemu_t:s0 key=(null) type=AVC msg=audit(1204759184.650:47): avc: denied { write } for pid=12188 comm="qemu-kvm" name="qemu-smb.12188" dev=dm-0 ino=2687085 scontext=unconfined_u:unconfined_r:qemu_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=dir type=AVC msg=audit(1204759184.650:47): avc: denied { add_name } for pid=12188 comm="qemu-kvm" name="smb.conf" scontext=unconfined_u:unconfined_r:qemu_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=dir type=AVC msg=audit(1204759184.650:47): avc: denied { create } for pid=12188 comm="qemu-kvm" name="smb.conf" scontext=unconfined_u:unconfined_r:qemu_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file type=AVC msg=audit(1204759184.650:47): avc: denied { write } for pid=12188 comm="qemu-kvm" name="smb.conf" dev=dm-0 ino=2687118 scontext=unconfined_u:unconfined_r:qemu_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file type=SYSCALL msg=audit(1204759184.650:47): arch=40000003 syscall=5 success=yes exit=3 a0=bfd0b150 a1=8241 a2=1b6 a3=240 items=0 ppid=12187 pid=12188 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts1 ses=1 comm="qemu-kvm" exe="/usr/bin/qemu-kvm" subj=unconfined_u:unconfined_r:qemu_t:s0 key=(null) type=AVC msg=audit(1204759184.651:48): avc: denied { getattr } for pid=12188 comm="qemu-kvm" path="/tmp/qemu-smb.12188/smb.conf" dev=dm-0 ino=2687118 scontext=unconfined_u:unconfined_r:qemu_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file type=SYSCALL msg=audit(1204759184.651:48): arch=40000003 syscall=197 success=yes exit=0 a0=3 a1=bfd09fa4 a2=2aaff4 a3=a3c6d60 items=0 ppid=12187 pid=12188 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts1 ses=1 comm="qemu-kvm" exe="/usr/bin/qemu-kvm" subj=unconfined_u:unconfined_r:qemu_t:s0 key=(null) or #============= qemu_t ============== allow qemu_t tmp_t:dir { write create add_name }; allow qemu_t tmp_t:file { write create getattr }; Is this a problem caused by me running the shell commands instead of virt-manager? tom -- Tom London From linuxweb at gmail.com Wed Mar 5 23:34:42 2008 From: linuxweb at gmail.com (Johnny Tan) Date: Wed, 05 Mar 2008 18:34:42 -0500 Subject: getting denials when run from init script but not from command-line Message-ID: <47CF2E12.10008@gmail.com> I took the Fedora-8 SRPM for rsyslog 2.0.2 and rebuilt it for CentOS-5 x86_64. After doing: # semanage fcontext -a -t syslogd_exec_t /sbin/rsyslogd # semanage fcontext -a -t klogd_exec_t /sbin/rklogd I can do "service rsyslog start" and it works. Then, I did the rebuild for rsyslog version 3.11.6. Had to tweak the spec and conf files a bit, but got it packaged and installed. And made sure the above contexts were retained (they were). However, when I go to run it "service rsyslog start" using the same init script that worked with the 2.0.2 version, I get this: == type=SYSCALL msg=audit(03/05/2008 17:43:26.966:224) : arch=x86_64 syscall=bind success=yes exit=0 a0=1 a1=51b2ae0 a2=10 a3=7fffa9e3f63c items=0 ppid=29717 pid=29718 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) comm=rsyslogd exe=/sbin/rsyslogd subj=root:system_r:syslogd_t:s0 key=(null) type=AVC msg=audit(03/05/2008 17:43:26.966:224) : avc: denied { node_bind } for pid=29718 comm=rsyslogd src=61514 scontext=root:system_r:syslogd_t:s0 tcontext=system_u:object_r:inaddr_any_node_t:s0 tclass=tcp_socket == BUT, when I run it directly from the command-line: /sbin/rsyslogd I do NOT get those denials. I know how to create the module to allow the above, but what I'm more interested in is what allows me to run it from the command-line but not from the init script. The line that starts the rsyslogd in the init script is: daemon rsyslogd $SYSLOGD_OPTIONS ("daemon" being a function sourced from /etc/init.d/functions) But even if I replace that line with a simple: /sbin/rsyslogd it still gives me the denials. Anyone have ideas why? I don't want to just create the module and sweep this under the rug. Here's the full start() function section of the /etc/init.d/rsyslog: start() { [ -x /sbin/rsyslogd ] || exit 5 # Source config if [ -f /etc/sysconfig/rsyslog ] ; then . /etc/sysconfig/rsyslog else KLOGD_OPTIONS="-2" fi if [ -z "$SYSLOG_UMASK" ] ; then SYSLOG_UMASK=077; fi umask $SYSLOG_UMASK echo -n $"Starting system logger: " daemon rsyslogd $SYSLOGD_OPTIONS RETVAL=$? echo [ $RETVAL -eq 0 ] && touch /var/lock/subsys/rsyslog return $RETVAL } Thanks, johnn From ekuns at kilroy.chi.il.us Thu Mar 6 04:38:42 2008 From: ekuns at kilroy.chi.il.us (Edward Kuns) Date: Wed, 05 Mar 2008 22:38:42 -0600 Subject: Please help getting a policy to compile with mta_send_mail() Message-ID: <1204778322.3979.693.camel@kilroy.chi.il.us> I know I must be doing something wrong, but hours and hours of googling have not turned up any help. The following is in myclamav.te: module myclamav 1.0; require { type shell_exec_t; type sendmail_exec_t; type bin_t; type clamd_t; class dir search; class file { execute getattr }; } mta_send_mail(clamd_t); #============= clamd_t ============== allow clamd_t bin_t:dir search; allow clamd_t sendmail_exec_t:file { execute getattr }; allow clamd_t shell_exec_t:file getattr; As root, I run: checkmodule -m myclamav.te which if I understand things will compile the TE file into a PP file which I can load. However, it complains about a syntax error on the mta_send_mail line. I've tried a lot of variations, but I cannot make this file compile. Looking for examples, I look in /etc/selinux/targeted/src, but the "src" directory does not exist. I believe I have all RPMs installed that I need: # rpm -qa 'selinux*' 'setroubleshoot*' 'setools*' selinux-policy-targeted-3.0.8-87.fc8 setools-console-3.3.1-7.fc8 selinux-policy-devel-3.0.8-87.fc8 selinux-doc-1.26-1.1 selinux-policy-3.0.8-87.fc8 setroubleshoot-server-2.0.5-2.fc8 setroubleshoot-2.0.5-2.fc8 setroubleshoot-plugins-2.0.4-3.fc8 setools-3.3.1-7.fc8 setools-libs-tcl-3.3.1-7.fc8 setools-libs-3.3.1-7.fc8 setools-gui-3.3.1-7.fc8 I know I must be missing something obvious, but I am out of clues. Thanks Eddie From tibbs at math.uh.edu Thu Mar 6 07:36:48 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 Mar 2008 01:36:48 -0600 Subject: /var/tmp/host_0 context getting set to initrc_tmp_t Message-ID: I'm trying to track down a situation where the context of /var/tmp/host_0 somehow gets set to initrc_tmp_t instead of krb5_host_rcache_t. When this happens, I get the following denial: audit(1204783558.948:68): avc: denied { getattr } for pid=11121 comm="sshd" path="/var/tmp/host_0" dev=dm-3 ino=753668 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:initrc_tmp_t:s0 tclass=file and ssh gssapi authentication stops working. This machine is a kerberos slave server, and my best guess is that kpropd (which runs as initrc_t) is rewriting (i.e. deleting and recreating) that file at some point. Unfortunately I can't cause it to happen so I'm not sure that's what's going on. This is probably a corner case among corner cases, but has anyone seen anything like this? - J< From paul at city-fan.org Thu Mar 6 09:09:25 2008 From: paul at city-fan.org (Paul Howarth) Date: Thu, 06 Mar 2008 09:09:25 +0000 Subject: getting denials when run from init script but not from command-line In-Reply-To: <47CF2E12.10008@gmail.com> References: <47CF2E12.10008@gmail.com> Message-ID: <47CFB4C5.1010208@city-fan.org> Johnny Tan wrote: > I took the Fedora-8 SRPM for rsyslog 2.0.2 and rebuilt it for CentOS-5 > x86_64. After doing: > > # semanage fcontext -a -t syslogd_exec_t /sbin/rsyslogd > # semanage fcontext -a -t klogd_exec_t /sbin/rklogd > > I can do "service rsyslog start" and it works. > > > Then, I did the rebuild for rsyslog version 3.11.6. Had to tweak the > spec and conf files a bit, but got it packaged and installed. And made > sure the above contexts were retained (they were). > > However, when I go to run it "service rsyslog start" using the same init > script that worked with the 2.0.2 version, I get this: > > == > type=SYSCALL msg=audit(03/05/2008 17:43:26.966:224) : arch=x86_64 > syscall=bind success=yes exit=0 a0=1 a1=51b2ae0 a2=10 a3=7fffa9e3f63c > items=0 ppid=29717 pid=29718 auid=root uid=root gid=root euid=root > suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) > comm=rsyslogd exe=/sbin/rsyslogd subj=root:system_r:syslogd_t:s0 key=(null) > type=AVC msg=audit(03/05/2008 17:43:26.966:224) : avc: denied { > node_bind } for pid=29718 comm=rsyslogd src=61514 > scontext=root:system_r:syslogd_t:s0 > tcontext=system_u:object_r:inaddr_any_node_t:s0 tclass=tcp_socket > == > > > BUT, when I run it directly from the command-line: > /sbin/rsyslogd > I do NOT get those denials. > > I know how to create the module to allow the above, but what I'm more > interested in is what allows me to run it from the command-line but not > from the init script. > > The line that starts the rsyslogd in the init script is: > daemon rsyslogd $SYSLOGD_OPTIONS > ("daemon" being a function sourced from /etc/init.d/functions) > > But even if I replace that line with a simple: > /sbin/rsyslogd > it still gives me the denials. > > > Anyone have ideas why? I don't want to just create the module and sweep > this under the rug. This is normal behaviour for confined daemons (those that policy has been written for); they transition to their own domain (syslogd_t in this case) and are confined to that domain when run from the initscript but don't transition and run unconfined if you start them directly from the command line. Paul. From paul at city-fan.org Thu Mar 6 09:22:47 2008 From: paul at city-fan.org (Paul Howarth) Date: Thu, 06 Mar 2008 09:22:47 +0000 Subject: Please help getting a policy to compile with mta_send_mail() In-Reply-To: <1204778322.3979.693.camel@kilroy.chi.il.us> References: <1204778322.3979.693.camel@kilroy.chi.il.us> Message-ID: <47CFB7E7.7040509@city-fan.org> Edward Kuns wrote: > I know I must be doing something wrong, but hours and hours of googling > have not turned up any help. The following is in myclamav.te: > > module myclamav 1.0; > > require { > type shell_exec_t; > type sendmail_exec_t; > type bin_t; > type clamd_t; > class dir search; > class file { execute getattr }; > } > > mta_send_mail(clamd_t); > > #============= clamd_t ============== > allow clamd_t bin_t:dir search; > allow clamd_t sendmail_exec_t:file { execute getattr }; > allow clamd_t shell_exec_t:file getattr; > > > As root, I run: > > checkmodule -m myclamav.te > > which if I understand things will compile the TE file into a PP file > which I can load. However, it complains about a syntax error on the > mta_send_mail line. I've tried a lot of variations, but I cannot make > this file compile. > > Looking for examples, I look in /etc/selinux/targeted/src, but the "src" > directory does not exist. I believe I have all RPMs installed that I > need: > > # rpm -qa 'selinux*' 'setroubleshoot*' 'setools*' > selinux-policy-targeted-3.0.8-87.fc8 > setools-console-3.3.1-7.fc8 > selinux-policy-devel-3.0.8-87.fc8 > selinux-doc-1.26-1.1 > selinux-policy-3.0.8-87.fc8 > setroubleshoot-server-2.0.5-2.fc8 > setroubleshoot-2.0.5-2.fc8 > setroubleshoot-plugins-2.0.4-3.fc8 > setools-3.3.1-7.fc8 > setools-libs-tcl-3.3.1-7.fc8 > setools-libs-3.3.1-7.fc8 > setools-gui-3.3.1-7.fc8 > > I know I must be missing something obvious, but I am out of clues. You need to install the selinux-policy SRPM and "prep" it to read through the main policy source. See http://www.city-fan.org/tips/BuildSeLinuxPolicyModules (section "Examining Policy Sources"). Paul. From selinux.list at troodos.demon.co.uk Thu Mar 6 10:07:38 2008 From: selinux.list at troodos.demon.co.uk (Arthur Dent) Date: Thu, 6 Mar 2008 10:07:38 +0000 Subject: Partitions Mounted by fstab In-Reply-To: <1204736560.1397.81.camel@moss-spartans.epoch.ncsc.mil> References: <20080305151618.GA9985@troodos.org.uk> <1204732035.1397.56.camel@moss-spartans.epoch.ncsc.mil> <20080305161213.GA10307@troodos.org.uk> <1204736356.1397.78.camel@moss-spartans.epoch.ncsc.mil> <1204736560.1397.81.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20080306100738.GA3593@localhost.localdomain> On Wed, Mar 05, 2008 at 12:02:40PM -0500, Stephen Smalley wrote: > > On Wed, 2008-03-05 at 11:59 -0500, Stephen Smalley wrote: > > On Wed, 2008-03-05 at 16:12 +0000, Arthur Dent wrote: > > > On Wed, Mar 05, 2008 at 10:47:15AM -0500, Stephen Smalley wrote: > > > > > > > You'll likely need a local policy module then to permit such access > > in addition to the commands above. > > Maybe something like this: > > > > # cat mymailbackup.te > > policy_module(mybackup, 1.0) > > require { > > # Symbols defined outside of this module. > > type system_crond_t; > > type user_crond_t; > > type mail_spool_t; > > } > > > > # Mark mail_spool_t as a log file that can be managed by logrotate. > > logging_log_file(mail_spool_t) > > # Let system and user cron jobs read it. > > read_files_pattern(system_crond_t, mail_spool_t, mail_spool_t) > > read_files_pattern(user_crond_t, mail_spool_t, mail_spool_t) > > > > # make -f /usr/share/selinux/devel/Makefile mybackup.pp > > # semodule -i mybackup.pp This is fantastically helpful. Thank you so much! > Actually, did you need write access to /mnt/backup from the cron job, or > only read access? The above only gives read access. > > Also, on second thought, I suppose that if you are running these as user > cron jobs, they'll run unconfined_t under the default targeted policy > and thus not require any additional rules at all. So you may only need > the logging_log_file() part. Well actually the /mnt/backup directory contains 2 subdirs /data and /mail. The /mail dir contains the one backup file that procmail writes to and the archives of that file created by logrotate (until they have been copied onto a DVD by the cron job - which I guess is just a "read" access. The /data dir contains the daily incremental, and weekly full backups created by tar running under cron (one version run as my user and one version - for system files - run by root). Here I guess write access is required, but as you say - running as a cron job. I am so swamped with avc denial that I can't say for certain, but I don't *think* I've seen any related to these jobs. I have therefore implemented your policy with the "read_files" lines commented out. Unfortunately I have only been able to do it this morning and the cron job(s) run overnight - so I will wait to see what the morning brings... Thanks again. Now, by far and away the biggest cause of clutter in the logs is errors caused by the next hop in the procmail processing chain - calling clamav (using clamd). Here is a sample (edited to remove the sealert reference): Mar 6 09:24:06 mydomain setroubleshoot: SELinux is preventing procmail (procmail_t) "search" to ./mnt (mnt_t). Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing the clamdscan from using potentially mislabeled files (/home/mark/Procmail/pmlog). Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing the clamdscan from using potentially mislabeled files (./Msgs). Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing the clamdscan from using potentially mislabeled files (/tmp/clamassassinmsg.gEsPbc3633). Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing clamdscan (clamscan_t) "write" to clamd.sock (var_run_t). Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing the clamd (clamd_t) from binding to port 1839. Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing clamdscan (clamscan_t) "create" to (clamscan_t). Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing clamdscan( clamscan_t) "connect" to (clamscan_t). Mar 6 09:24:08 mydomain setroubleshoot: SELinux is preventing clamdscan (clamscan_t) "write" to socket (clamscan_t). Mar 6 09:24:08 mydomain setroubleshoot: SELinux is preventing the clamdscan from using potentially mislabeled files(/tmp/clamassassinlog.PDbPHf3634). Mar 6 09:30:06 mydomain setroubleshoot: SELinux is preventing clamdscan (clamscan_t) "read" to /var/spool/mqueue/dfm269U2u1003678 (mqueue_spool_t). Mar 6 09:30:06 mydomain setroubleshoot: SELinux is preventing theclamdscan from using potentially mislabeled files (./Msgs). Mar 6 09:30:06 mydomain setroubleshoot: SELinux is preventing clamdscan (clamscan_t) "write" to clamd.sock (var_run_t). Mar 6 09:30:06 mydomain setroubleshoot: SELinux is preventing the clamd (clamd_t) from binding to port 1508. Fetchmail checks for mail every 3 minutes so you can imagine there are quite a few of those entries in the logs! Based on what you showed me for procmail I have tried to create a policy for clamd. However I am not even going to *think* about running it until you have checked it over! ########################################## # cat myclamd.te policy_module(myclamd, 1.0) require { # Symbols defined outside of this module. type clamd_t; type clamscan_t; } # Don't really know what to put here... allow clamd_t bin_t ########################################### Or am I re-inventing the wheel? Surely there must be a ready-made clamd policy? Thanks again. Your help is greatly appreciated. Mark > Stephen Smalley > National Security Agency -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From selinux.list at troodos.demon.co.uk Thu Mar 6 12:40:15 2008 From: selinux.list at troodos.demon.co.uk (Arthur Dent) Date: Thu, 6 Mar 2008 12:40:15 +0000 Subject: Partitions Mounted by fstab In-Reply-To: <20080306100738.GA3593@localhost.localdomain> References: <20080305151618.GA9985@troodos.org.uk> <1204732035.1397.56.camel@moss-spartans.epoch.ncsc.mil> <20080305161213.GA10307@troodos.org.uk> <1204736356.1397.78.camel@moss-spartans.epoch.ncsc.mil> <1204736560.1397.81.camel@moss-spartans.epoch.ncsc.mil> <20080306100738.GA3593@localhost.localdomain> Message-ID: <20080306124014.GA5032@localhost.localdomain> On Thu, Mar 06, 2008 at 10:07:38AM +0000, Arthur Dent wrote: > > Now, by far and away the biggest cause of clutter in the logs is errors > caused by the next hop in the procmail processing chain - calling clamav > (using clamd). > > Here is a sample (edited to remove the sealert reference): > Mar 6 09:24:06 mydomain setroubleshoot: SELinux is preventing procmail (procmail_t) "search" to ./mnt (mnt_t). > Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing the clamdscan from using potentially mislabeled files (/home/mark/Procmail/pmlog). > Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing the clamdscan from using potentially mislabeled files (./Msgs). > Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing the clamdscan from using potentially mislabeled files (/tmp/clamassassinmsg.gEsPbc3633). > Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing clamdscan (clamscan_t) "write" to clamd.sock (var_run_t). > Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing the clamd (clamd_t) from binding to port 1839. > Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing clamdscan (clamscan_t) "create" to (clamscan_t). > Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing clamdscan( clamscan_t) "connect" to (clamscan_t). > Mar 6 09:24:08 mydomain setroubleshoot: SELinux is preventing clamdscan (clamscan_t) "write" to socket (clamscan_t). > Mar 6 09:24:08 mydomain setroubleshoot: SELinux is preventing the clamdscan from using potentially mislabeled files(/tmp/clamassassinlog.PDbPHf3634). > Mar 6 09:30:06 mydomain setroubleshoot: SELinux is preventing clamdscan (clamscan_t) "read" to /var/spool/mqueue/dfm269U2u1003678 (mqueue_spool_t). > Mar 6 09:30:06 mydomain setroubleshoot: SELinux is preventing theclamdscan from using potentially mislabeled files (./Msgs). > Mar 6 09:30:06 mydomain setroubleshoot: SELinux is preventing clamdscan (clamscan_t) "write" to clamd.sock (var_run_t). > Mar 6 09:30:06 mydomain setroubleshoot: SELinux is preventing the clamd (clamd_t) from binding to port 1508. > > Fetchmail checks for mail every 3 minutes so you can imagine there are > quite a few of those entries in the logs! > > Based on what you showed me for procmail I have tried to create a policy > for clamd. However I am not even going to *think* about running it until > you have checked it over! > > ########################################## > # cat myclamd.te > policy_module(myclamd, 1.0) > require { > # Symbols defined outside of this module. > type clamd_t; > type clamscan_t; > } > > # Don't really know what to put here... > allow clamd_t bin_t > ########################################### > > Or am I re-inventing the wheel? Surely there must be a ready-made clamd > policy? Been thinking (always dangerous!) about this... Here's my latest effort. This time I've tried using audit2allow. The output is Greek to me. Is this safe to use? Will it address all the issues? Thanks for any advice... ########################################## # cat myclamd.te policy_module(myclamd, 1.1) require { type clamscan_t; type clamd_t; class tcp_socket { write create connect }; } #============= clamd_t ============== corenet_tcp_bind_generic_port(clamd_t) #============= clamscan_t ============== allow clamscan_t self:tcp_socket { write create connect }; corenet_tcp_connect_generic_port(clamscan_t) mta_read_queue(clamscan_t) procmail_rw_tmp_files(clamscan_t) userdom_read_generic_user_home_content_files(clamscan_t) ########################################## Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sds at tycho.nsa.gov Thu Mar 6 13:24:33 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 06 Mar 2008 08:24:33 -0500 Subject: Please help getting a policy to compile with mta_send_mail() In-Reply-To: <1204778322.3979.693.camel@kilroy.chi.il.us> References: <1204778322.3979.693.camel@kilroy.chi.il.us> Message-ID: <1204809873.1397.178.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-03-05 at 22:38 -0600, Edward Kuns wrote: > I know I must be doing something wrong, but hours and hours of googling > have not turned up any help. The following is in myclamav.te: > > module myclamav 1.0; > > require { > type shell_exec_t; > type sendmail_exec_t; > type bin_t; > type clamd_t; > class dir search; > class file { execute getattr }; > } > > mta_send_mail(clamd_t); > > #============= clamd_t ============== > allow clamd_t bin_t:dir search; > allow clamd_t sendmail_exec_t:file { execute getattr }; > allow clamd_t shell_exec_t:file getattr; > > > As root, I run: > > checkmodule -m myclamav.te When building policy modules that use refpolicy interfaces, you need to use the refpolicy build infrastructure. yum install selinux-policy-devel and make -f /usr/share/selinux/devel/Makefile myclamav.pp. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Thu Mar 6 13:25:55 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 06 Mar 2008 08:25:55 -0500 Subject: /var/tmp/host_0 context getting set to initrc_tmp_t In-Reply-To: References: Message-ID: <1204809955.1397.181.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2008-03-06 at 01:36 -0600, Jason L Tibbitts III wrote: > I'm trying to track down a situation where the context of > /var/tmp/host_0 somehow gets set to initrc_tmp_t instead of > krb5_host_rcache_t. When this happens, I get the following denial: > audit(1204783558.948:68): avc: denied { getattr } for pid=11121 > comm="sshd" path="/var/tmp/host_0" dev=dm-3 ino=753668 > scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 > tcontext=unconfined_u:object_r:initrc_tmp_t:s0 tclass=file > and ssh gssapi authentication stops working. > > This machine is a kerberos slave server, and my best guess is that kpropd > (which runs as initrc_t) is rewriting (i.e. deleting and recreating) > that file at some point. Unfortunately I can't cause it to happen so > I'm not sure that's what's going on. > > This is probably a corner case among corner cases, but has anyone seen > anything like this? You don't want to leave daemons running in initrc_t. So you want to put kpropd into a domain, whether an existing one (if something similar in purpose and required accesses exists) or a new one, and then you can ensure that the file will get the right type when created. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Thu Mar 6 13:32:23 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 06 Mar 2008 08:32:23 -0500 Subject: Partitions Mounted by fstab In-Reply-To: <20080306100738.GA3593@localhost.localdomain> References: <20080305151618.GA9985@troodos.org.uk> <1204732035.1397.56.camel@moss-spartans.epoch.ncsc.mil> <20080305161213.GA10307@troodos.org.uk> <1204736356.1397.78.camel@moss-spartans.epoch.ncsc.mil> <1204736560.1397.81.camel@moss-spartans.epoch.ncsc.mil> <20080306100738.GA3593@localhost.localdomain> Message-ID: <1204810343.1397.189.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2008-03-06 at 10:07 +0000, Arthur Dent wrote: > On Wed, Mar 05, 2008 at 12:02:40PM -0500, Stephen Smalley wrote: > > > > On Wed, 2008-03-05 at 11:59 -0500, Stephen Smalley wrote: > > > On Wed, 2008-03-05 at 16:12 +0000, Arthur Dent wrote: > > > > On Wed, Mar 05, 2008 at 10:47:15AM -0500, Stephen Smalley wrote: > > > > > > > > > > You'll likely need a local policy module then to permit such access > > > in addition to the commands above. > > > Maybe something like this: > > > > > > # cat mymailbackup.te > > > policy_module(mybackup, 1.0) > > > require { > > > # Symbols defined outside of this module. > > > type system_crond_t; > > > type user_crond_t; > > > type mail_spool_t; > > > } > > > > > > # Mark mail_spool_t as a log file that can be managed by logrotate. > > > logging_log_file(mail_spool_t) > > > # Let system and user cron jobs read it. > > > read_files_pattern(system_crond_t, mail_spool_t, mail_spool_t) > > > read_files_pattern(user_crond_t, mail_spool_t, mail_spool_t) > > > > > > # make -f /usr/share/selinux/devel/Makefile mybackup.pp > > > # semodule -i mybackup.pp > > This is fantastically helpful. Thank you so much! > > > Actually, did you need write access to /mnt/backup from the cron job, or > > only read access? The above only gives read access. > > > > Also, on second thought, I suppose that if you are running these as user > > cron jobs, they'll run unconfined_t under the default targeted policy > > and thus not require any additional rules at all. So you may only need > > the logging_log_file() part. > > Well actually the /mnt/backup directory contains 2 subdirs /data and > /mail. > The /mail dir contains the one backup file that procmail writes > to and the archives of that file created by logrotate (until they have > been copied onto a DVD by the cron job - which I guess is just a "read" > access. > The /data dir contains the daily incremental, and weekly full backups > created by tar running under cron (one version run as my user and one > version - for system files - run by root). Here I guess write access is > required, but as you say - running as a cron job. > I am so swamped with avc denial that I can't say for certain, but I > don't *think* I've seen any related to these jobs. Then I would recommend using a different type on /mnt/backup/data(/.*)? vs. /mnt/backup/mail(/.*)?. Then you can differentiate in policy what can access each of them, so that your procmail job can't write to your data/ subdirectory. So you might do: # delete the entry we added earlier for all of /mnt/backup semanage fcontext -d "/mnt/backup(/.*)?" # only apply mail_spool_t to the mail subdir semanage fcontext -a -t mail_spool_t "/mnt/backup/mail(/.*)?" # put some other type on the data subdir - depends on your goal semanage fcontext -a -t "/mnt/backup/data(/.*)?" # apply the new labeling scheme to disk restorecon -R -v /mnt/backup > I have therefore implemented your policy with the "read_files" lines > commented out. Unfortunately I have only been able to do it this morning > and the cron job(s) run overnight - so I will wait to see what the > morning brings... > > Thanks again. > > Now, by far and away the biggest cause of clutter in the logs is errors > caused by the next hop in the procmail processing chain - calling clamav > (using clamd). > > Here is a sample (edited to remove the sealert reference): > Mar 6 09:24:06 mydomain setroubleshoot: SELinux is preventing procmail (procmail_t) "search" to ./mnt (mnt_t). > Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing the clamdscan from using potentially mislabeled files (/home/mark/Procmail/pmlog). > Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing the clamdscan from using potentially mislabeled files (./Msgs). > Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing the clamdscan from using potentially mislabeled files (/tmp/clamassassinmsg.gEsPbc3633). > Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing clamdscan (clamscan_t) "write" to clamd.sock (var_run_t). > Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing the clamd (clamd_t) from binding to port 1839. > Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing clamdscan (clamscan_t) "create" to (clamscan_t). > Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing clamdscan( clamscan_t) "connect" to (clamscan_t). > Mar 6 09:24:08 mydomain setroubleshoot: SELinux is preventing clamdscan (clamscan_t) "write" to socket (clamscan_t). > Mar 6 09:24:08 mydomain setroubleshoot: SELinux is preventing the clamdscan from using potentially mislabeled files(/tmp/clamassassinlog.PDbPHf3634). > Mar 6 09:30:06 mydomain setroubleshoot: SELinux is preventing clamdscan (clamscan_t) "read" to /var/spool/mqueue/dfm269U2u1003678 (mqueue_spool_t). > Mar 6 09:30:06 mydomain setroubleshoot: SELinux is preventing theclamdscan from using potentially mislabeled files (./Msgs). > Mar 6 09:30:06 mydomain setroubleshoot: SELinux is preventing clamdscan (clamscan_t) "write" to clamd.sock (var_run_t). > Mar 6 09:30:06 mydomain setroubleshoot: SELinux is preventing the clamd (clamd_t) from binding to port 1508. > > Fetchmail checks for mail every 3 minutes so you can imagine there are > quite a few of those entries in the logs! > > Based on what you showed me for procmail I have tried to create a policy > for clamd. However I am not even going to *think* about running it until > you have checked it over! > > ########################################## > # cat myclamd.te > policy_module(myclamd, 1.0) > require { > # Symbols defined outside of this module. > type clamd_t; > type clamscan_t; > } > > # Don't really know what to put here... > allow clamd_t bin_t > ########################################### > > Or am I re-inventing the wheel? Surely there must be a ready-made clamd > policy? There is a clamd policy, but apparently it isn't sufficient for your usage. But I see you've discovered audit2allow in a later message. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Thu Mar 6 13:43:26 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 06 Mar 2008 08:43:26 -0500 Subject: Partitions Mounted by fstab In-Reply-To: <20080306124014.GA5032@localhost.localdomain> References: <20080305151618.GA9985@troodos.org.uk> <1204732035.1397.56.camel@moss-spartans.epoch.ncsc.mil> <20080305161213.GA10307@troodos.org.uk> <1204736356.1397.78.camel@moss-spartans.epoch.ncsc.mil> <1204736560.1397.81.camel@moss-spartans.epoch.ncsc.mil> <20080306100738.GA3593@localhost.localdomain> <20080306124014.GA5032@localhost.localdomain> Message-ID: <1204811006.1397.199.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2008-03-06 at 12:40 +0000, Arthur Dent wrote: > On Thu, Mar 06, 2008 at 10:07:38AM +0000, Arthur Dent wrote: > > > > Now, by far and away the biggest cause of clutter in the logs is errors > > caused by the next hop in the procmail processing chain - calling clamav > > (using clamd). > > > > Here is a sample (edited to remove the sealert reference): > > Mar 6 09:24:06 mydomain setroubleshoot: SELinux is preventing procmail (procmail_t) "search" to ./mnt (mnt_t). > > Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing the clamdscan from using potentially mislabeled files (/home/mark/Procmail/pmlog). > > Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing the clamdscan from using potentially mislabeled files (./Msgs). > > Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing the clamdscan from using potentially mislabeled files (/tmp/clamassassinmsg.gEsPbc3633). > > Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing clamdscan (clamscan_t) "write" to clamd.sock (var_run_t). > > Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing the clamd (clamd_t) from binding to port 1839. > > Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing clamdscan (clamscan_t) "create" to (clamscan_t). > > Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing clamdscan( clamscan_t) "connect" to (clamscan_t). > > Mar 6 09:24:08 mydomain setroubleshoot: SELinux is preventing clamdscan (clamscan_t) "write" to socket (clamscan_t). > > Mar 6 09:24:08 mydomain setroubleshoot: SELinux is preventing the clamdscan from using potentially mislabeled files(/tmp/clamassassinlog.PDbPHf3634). > > Mar 6 09:30:06 mydomain setroubleshoot: SELinux is preventing clamdscan (clamscan_t) "read" to /var/spool/mqueue/dfm269U2u1003678 (mqueue_spool_t). > > Mar 6 09:30:06 mydomain setroubleshoot: SELinux is preventing theclamdscan from using potentially mislabeled files (./Msgs). > > Mar 6 09:30:06 mydomain setroubleshoot: SELinux is preventing clamdscan (clamscan_t) "write" to clamd.sock (var_run_t). > > Mar 6 09:30:06 mydomain setroubleshoot: SELinux is preventing the clamd (clamd_t) from binding to port 1508. > > > > Fetchmail checks for mail every 3 minutes so you can imagine there are > > quite a few of those entries in the logs! > > > > Based on what you showed me for procmail I have tried to create a policy > > for clamd. However I am not even going to *think* about running it until > > you have checked it over! > > > > ########################################## > > # cat myclamd.te > > policy_module(myclamd, 1.0) > > require { > > # Symbols defined outside of this module. > > type clamd_t; > > type clamscan_t; > > } > > > > # Don't really know what to put here... > > allow clamd_t bin_t > > ########################################### > > > > Or am I re-inventing the wheel? Surely there must be a ready-made clamd > > policy? > > Been thinking (always dangerous!) about this... > > Here's my latest effort. This time I've tried using audit2allow. The > output is Greek to me. > Is this safe to use? > Will it address all the issues? > > Thanks for any advice... > > ########################################## > # cat myclamd.te > policy_module(myclamd, 1.1) > require { > type clamscan_t; > type clamd_t; > class tcp_socket { write create connect }; > } > > #============= clamd_t ============== > corenet_tcp_bind_generic_port(clamd_t) > > #============= clamscan_t ============== > allow clamscan_t self:tcp_socket { write create connect }; > corenet_tcp_connect_generic_port(clamscan_t) > mta_read_queue(clamscan_t) > procmail_rw_tmp_files(clamscan_t) > userdom_read_generic_user_home_content_files(clamscan_t) > ########################################## This seems consistent with the denials you reported. Ideally we'd identify specific types for the ports to which it is binding and connecting and only give access to those ports rather than opening up generic port access. That would be done via semanage port, similar to the semanage fcontext commands you ran earlier. But if you primarily just want your system to work right now, you can use the above module, and wait on the upstream policy to catch up. Reporting the avc denials from audit.log to this list or to the upstream selinux list will generally ensure that they get addressed in the future. -- Stephen Smalley National Security Agency From selinux.list at troodos.demon.co.uk Thu Mar 6 14:45:01 2008 From: selinux.list at troodos.demon.co.uk (Arthur Dent) Date: Thu, 6 Mar 2008 14:45:01 +0000 Subject: Partitions Mounted by fstab In-Reply-To: <1204811006.1397.199.camel@moss-spartans.epoch.ncsc.mil> References: <20080305151618.GA9985@troodos.org.uk> <1204732035.1397.56.camel@moss-spartans.epoch.ncsc.mil> <20080305161213.GA10307@troodos.org.uk> <1204736356.1397.78.camel@moss-spartans.epoch.ncsc.mil> <1204736560.1397.81.camel@moss-spartans.epoch.ncsc.mil> <20080306100738.GA3593@localhost.localdomain> <20080306124014.GA5032@localhost.localdomain> <1204811006.1397.199.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20080306144500.GA5651@localhost.localdomain> On Thu, Mar 06, 2008 at 08:43:26AM -0500, Stephen Smalley wrote: > > > > > Been thinking (always dangerous!) about this... > > > > Here's my latest effort. This time I've tried using audit2allow. The > > output is Greek to me. > > Is this safe to use? > > Will it address all the issues? > > > > Thanks for any advice... > > > > ########################################## > > # cat myclamd.te > > policy_module(myclamd, 1.1) > > require { > > type clamscan_t; > > type clamd_t; > > class tcp_socket { write create connect }; > > } > > > > #============= clamd_t ============== > > corenet_tcp_bind_generic_port(clamd_t) > > > > #============= clamscan_t ============== > > allow clamscan_t self:tcp_socket { write create connect }; > > corenet_tcp_connect_generic_port(clamscan_t) > > mta_read_queue(clamscan_t) > > procmail_rw_tmp_files(clamscan_t) > > userdom_read_generic_user_home_content_files(clamscan_t) > > ########################################## > > This seems consistent with the denials you reported. > Ideally we'd identify specific types for the ports to which it is > binding and connecting and only give access to those ports rather than > opening up generic port access. That would be done via semanage port, > similar to the semanage fcontext commands you ran earlier. But if you > primarily just want your system to work right now, you can use the above > module, and wait on the upstream policy to catch up. Reporting the avc > denials from audit.log to this list or to the upstream selinux list will > generally ensure that they get addressed in the future. Hi Stephen, Yes, I know it's a bit off-topic for this list (well totally OT really) but why does clamd bind to a different port each time? Is that normal behaviour for clamd or have I got something borked in my setup? Anyway it works (I think)! Thanks very much for all the help and support so far. Now that I have discovered audit2allow there's no stopping me!... I have no idea what most of the things are for, but if I'm careful about watching where the denials take place, is it usually safe to trust audit2allow to create policies for me? After much watching and tail -f ing of logs, here is what I have ended up with... ########################################## # cat myclamd.te policy_module(myclamd, 1.2) require { type clamscan_t; type clamd_t; class tcp_socket { write create connect }; type var_run_t; type user_home_t; class sock_file write; class file append; } #============= clamd_t ============== corenet_tcp_bind_generic_port(clamd_t) #============= clamscan_t ============== allow clamscan_t self:tcp_socket { write create connect }; allow clamscan_t user_home_t:file append; allow clamscan_t var_run_t:sock_file write; corenet_tcp_connect_generic_port(clamscan_t) mta_read_queue(clamscan_t) procmail_rw_tmp_files(clamscan_t) userdom_read_generic_user_home_content_files(clamscan_t) ########################################## It's still Greek to me. I hope I haven't compromised my system in any way... I have just typed "setenforce 1" - Yay! (Expect to hear back from me with tales of woe when it won't work anymore!... Thanks again Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sds at tycho.nsa.gov Thu Mar 6 15:23:53 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 06 Mar 2008 10:23:53 -0500 Subject: Partitions Mounted by fstab In-Reply-To: <20080306144500.GA5651@localhost.localdomain> References: <20080305151618.GA9985@troodos.org.uk> <1204732035.1397.56.camel@moss-spartans.epoch.ncsc.mil> <20080305161213.GA10307@troodos.org.uk> <1204736356.1397.78.camel@moss-spartans.epoch.ncsc.mil> <1204736560.1397.81.camel@moss-spartans.epoch.ncsc.mil> <20080306100738.GA3593@localhost.localdomain> <20080306124014.GA5032@localhost.localdomain> <1204811006.1397.199.camel@moss-spartans.epoch.ncsc.mil> <20080306144500.GA5651@localhost.localdomain> Message-ID: <1204817033.1397.264.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2008-03-06 at 14:45 +0000, Arthur Dent wrote: > Hi Stephen, > > Yes, I know it's a bit off-topic for this list (well totally OT really) > but why does clamd bind to a different port each time? Is that normal > behaviour for clamd or have I got something borked in my setup? Some daemons scan for any available port within a given range, and take the first one available, for transient ports used for data transfer (vs. well-known ports). > Anyway it works (I think)! > > Thanks very much for all the help and support so far. Now that I have > discovered audit2allow there's no stopping me!... > > I have no idea what most of the things are for, but if I'm careful about > watching where the denials take place, is it usually safe to trust > audit2allow to create policies for me? audit2allow just turns every denial into an allow rule. So it can't for example tell you that the real reason you had a denial was because you had a mislabeled file. Your /mnt/backup situation is an example where audit2allow would have given you the wrong solution - allowing access to the default type of /mnt rather than properly configuring your policy to label /mnt/backup with a suitable type. setroubleshoot tries to give you more help via a heuristics-based set of plugins, but it doesn't really have a semantic understanding of the policy, so it too is limited in what it can achieve. But setroubleshoot can sometimes tell you that a file is mislabeled or that you just need to enable some policy boolean. There is ongoing work in policy tools to bridge the semantic gap. > After much watching and tail -f ing of logs, here is what I have ended > up with... > > > ########################################## > # cat myclamd.te > policy_module(myclamd, 1.2) > require { > type clamscan_t; > type clamd_t; > class tcp_socket { write create connect }; > type var_run_t; > type user_home_t; > class sock_file write; > class file append; > > } > > #============= clamd_t ============== > corenet_tcp_bind_generic_port(clamd_t) > > #============= clamscan_t ============== > allow clamscan_t self:tcp_socket { write create connect }; > allow clamscan_t user_home_t:file append; What file in your home directory is clamscan appending to? Maybe we can put it into a distinct type and protect the rest of your files? > allow clamscan_t var_run_t:sock_file write; This suggests that something is creating a socket under /var/run without properly putting it into a distinct type. > corenet_tcp_connect_generic_port(clamscan_t) > mta_read_queue(clamscan_t) > procmail_rw_tmp_files(clamscan_t) > userdom_read_generic_user_home_content_files(clamscan_t) > ########################################## > > > It's still Greek to me. I hope I haven't compromised my system in any way... You can't make your system weaker than it was without SELinux in this manner, since all you are doing is loosening the SELinux restrictions - the usual DAC restrictions still apply. So all you are doing is altering the extent to which SELinux is protecting you. > I have just typed "setenforce 1" - Yay! (Expect to hear back from me > with tales of woe when it won't work anymore!... -- Stephen Smalley National Security Agency From selinux.list at troodos.demon.co.uk Thu Mar 6 15:46:28 2008 From: selinux.list at troodos.demon.co.uk (Arthur Dent) Date: Thu, 6 Mar 2008 15:46:28 +0000 Subject: Partitions Mounted by fstab In-Reply-To: <1204817033.1397.264.camel@moss-spartans.epoch.ncsc.mil> References: <20080305151618.GA9985@troodos.org.uk> <1204732035.1397.56.camel@moss-spartans.epoch.ncsc.mil> <20080305161213.GA10307@troodos.org.uk> <1204736356.1397.78.camel@moss-spartans.epoch.ncsc.mil> <1204736560.1397.81.camel@moss-spartans.epoch.ncsc.mil> <20080306100738.GA3593@localhost.localdomain> <20080306124014.GA5032@localhost.localdomain> <1204811006.1397.199.camel@moss-spartans.epoch.ncsc.mil> <20080306144500.GA5651@localhost.localdomain> <1204817033.1397.264.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20080306154628.GA6057@localhost.localdomain> On Thu, Mar 06, 2008 at 10:23:53AM -0500, Stephen Smalley wrote: > > > # cat myclamd.te > > policy_module(myclamd, 1.2) > > require { > > type clamscan_t; > > type clamd_t; > > class tcp_socket { write create connect }; > > type var_run_t; > > type user_home_t; > > class sock_file write; > > class file append; > > > > } > > > > #============= clamd_t ============== > > corenet_tcp_bind_generic_port(clamd_t) > > > > #============= clamscan_t ============== > > allow clamscan_t self:tcp_socket { write create connect }; > > allow clamscan_t user_home_t:file append; > > What file in your home directory is clamscan appending to? > Maybe we can put it into a distinct type and protect the rest of your > files? > Not sure... clamd is used by clamassassin which is called by procmail. Procmail has local configurations set in various "rc" files in ~/Procmail/ in my home directory. But only procmail would require (read) access to those. Then procmail writes to its log which is ~/Procmail/pmlog (also rotated by logrotate). I'll try commenting out that line and see what happens... Thanks Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From selinux.list at troodos.demon.co.uk Thu Mar 6 15:53:37 2008 From: selinux.list at troodos.demon.co.uk (Arthur Dent) Date: Thu, 6 Mar 2008 15:53:37 +0000 Subject: Partitions Mounted by fstab In-Reply-To: <20080306154628.GA6057@localhost.localdomain> References: <1204732035.1397.56.camel@moss-spartans.epoch.ncsc.mil> <20080305161213.GA10307@troodos.org.uk> <1204736356.1397.78.camel@moss-spartans.epoch.ncsc.mil> <1204736560.1397.81.camel@moss-spartans.epoch.ncsc.mil> <20080306100738.GA3593@localhost.localdomain> <20080306124014.GA5032@localhost.localdomain> <1204811006.1397.199.camel@moss-spartans.epoch.ncsc.mil> <20080306144500.GA5651@localhost.localdomain> <1204817033.1397.264.camel@moss-spartans.epoch.ncsc.mil> <20080306154628.GA6057@localhost.localdomain> Message-ID: <20080306155337.GA6135@localhost.localdomain> On Thu, Mar 06, 2008 at 03:46:28PM +0000, Arthur Dent wrote: > > > > What file in your home directory is clamscan appending to? > > Maybe we can put it into a distinct type and protect the rest of your > > files? > > > Not sure... clamd is used by clamassassin which is called by procmail. > > Procmail has local configurations set in various "rc" files in > ~/Procmail/ in my home directory. But only procmail would require (read) > access to those. Then procmail writes to its log which is > ~/Procmail/pmlog (also rotated by logrotate). > > I'll try commenting out that line and see what happens... > And here's what happens... Summary: SELinux is preventing the clamdscan from using potentially mislabeled files (/home/mark/Procmail/pmlog). Detailed Description: SELinux has denied clamdscan access to potentially mislabeled file(s) (/home/mark/Procmail/pmlog). This means that SELinux will not allow clamdscan to use these files. It is common for users to edit files in their home directory or tmp directories and then move (mv) them to system directories. The problem is that the files end up with the wrong file context which confined applications are not allowed to access. Allowing Access: If you want clamdscan to access this files, you need to relabel them using restorecon -v '/home/mark/Procmail/pmlog'. You might want to relabel the entire directory using restorecon -R -v '/home/mark/Procmail'. Additional Information: Source Context system_u:system_r:clamscan_t:s0 Target Context system_u:object_r:user_home_t:s0 Target Objects /home/mark/Procmail/pmlog [ file ] Source clamdscan Source Path /usr/bin/clamdscan Port Host mydomain.org.uk Source RPM Packages clamav-0.92.1-1.fc8 Target RPM Packages Policy RPM selinux-policy-3.0.8-87.fc8 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name home_tmp_bad_labels Host Name mydomain.org.uk Platform Linux mydomain.org.uk 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:48:34 EST 2008 i686 i686 Alert Count 1 First Seen Thu Mar 6 15:48:08 2008 Last Seen Thu Mar 6 15:48:08 2008 Local ID 1a0e8006-5ae4-41dc-90e3-419c7c32c2b0 Line Numbers Raw Audit Messages host=mydomain.org.uk type=AVC msg=audit(1204818488.711:155): avc: denied { append } for pid=3820 comm="clamdscan" path="/home/mark/Procmail/pmlog" dev=sda12 ino=1426472 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:user_home_t:s0 tclass=file host=mydomain.org.uk type=SYSCALL msg=audit(1204818488.711:155): arch=40000003 syscall=11 success=yes exit=0 a0=933c210 a1=933aa28 a2=93381b0 a3=40 items=0 ppid=3816 pid=3820 auid=4294967295 uid=0 gid=12 euid=0 suid=0 fsuid=0 egid=12 sgid=12 fsgid=12 tty=(none) comm="clamdscan" exe="/usr/bin/clamdscan" subj=system_u:system_r:clamscan_t:s0 key=(null) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sds at tycho.nsa.gov Thu Mar 6 16:27:43 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 06 Mar 2008 11:27:43 -0500 Subject: Partitions Mounted by fstab In-Reply-To: <20080306155337.GA6135@localhost.localdomain> References: <1204732035.1397.56.camel@moss-spartans.epoch.ncsc.mil> <20080305161213.GA10307@troodos.org.uk> <1204736356.1397.78.camel@moss-spartans.epoch.ncsc.mil> <1204736560.1397.81.camel@moss-spartans.epoch.ncsc.mil> <20080306100738.GA3593@localhost.localdomain> <20080306124014.GA5032@localhost.localdomain> <1204811006.1397.199.camel@moss-spartans.epoch.ncsc.mil> <20080306144500.GA5651@localhost.localdomain> <1204817033.1397.264.camel@moss-spartans.epoch.ncsc.mil> <20080306154628.GA6057@localhost.localdomain> <20080306155337.GA6135@localhost.localdomain> Message-ID: <1204820863.1397.296.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2008-03-06 at 15:53 +0000, Arthur Dent wrote: > On Thu, Mar 06, 2008 at 03:46:28PM +0000, Arthur Dent wrote: > > > > > > What file in your home directory is clamscan appending to? > > > Maybe we can put it into a distinct type and protect the rest of your > > > files? > > > > > Not sure... clamd is used by clamassassin which is called by procmail. > > > > Procmail has local configurations set in various "rc" files in > > ~/Procmail/ in my home directory. But only procmail would require (read) > > access to those. Then procmail writes to its log which is > > ~/Procmail/pmlog (also rotated by logrotate). > > > > I'll try commenting out that line and see what happens... > > > And here's what happens... > > Summary: > > SELinux is preventing the clamdscan from using potentially mislabeled > files > (/home/mark/Procmail/pmlog). > > Detailed Description: > > SELinux has denied clamdscan access to potentially mislabeled file(s) > (/home/mark/Procmail/pmlog). This means that SELinux will not allow > clamdscan to > use these files. It is common for users to edit files in their home > directory or > tmp directories and then move (mv) them to system directories. The > problem is > that the files end up with the wrong file context which confined > applications > are not allowed to access. > > Allowing Access: > > If you want clamdscan to access this files, you need to relabel them > using > restorecon -v '/home/mark/Procmail/pmlog'. You might want to relabel the > entire > directory using restorecon -R -v '/home/mark/Procmail'. > > Additional Information: > > Source Context system_u:system_r:clamscan_t:s0 > Target Context system_u:object_r:user_home_t:s0 > Target Objects /home/mark/Procmail/pmlog [ file ] > Source clamdscan > Source Path /usr/bin/clamdscan > Port > Host mydomain.org.uk > Source RPM Packages clamav-0.92.1-1.fc8 > Target RPM Packages > Policy RPM selinux-policy-3.0.8-87.fc8 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name home_tmp_bad_labels > Host Name mydomain.org.uk > Platform Linux mydomain.org.uk 2.6.23.15-137.fc8 #1 > SMP Sun > Feb 10 17:48:34 EST 2008 i686 i686 > Alert Count 1 > First Seen Thu Mar 6 15:48:08 2008 > Last Seen Thu Mar 6 15:48:08 2008 > Local ID 1a0e8006-5ae4-41dc-90e3-419c7c32c2b0 > Line Numbers > > Raw Audit Messages > > host=mydomain.org.uk type=AVC msg=audit(1204818488.711:155): avc: > denied { append } for pid=3820 comm="clamdscan" > path="/home/mark/Procmail/pmlog" dev=sda12 ino=1426472 > scontext=system_u:system_r:clamscan_t:s0 > tcontext=system_u:object_r:user_home_t:s0 tclass=file > > host=mydomain.org.uk type=SYSCALL msg=audit(1204818488.711:155): > arch=40000003 syscall=11 success=yes exit=0 a0=933c210 a1=933aa28 > a2=93381b0 a3=40 items=0 ppid=3816 pid=3820 auid=4294967295 uid=0 gid=12 > euid=0 suid=0 fsuid=0 egid=12 sgid=12 fsgid=12 tty=(none) > comm="clamdscan" exe="/usr/bin/clamdscan" > subj=system_u:system_r:clamscan_t:s0 key=(null) Ok, so it is just appending to a log file there, possibly via an inherited descriptor from the caller. You could possibly put a different type on ~/Procmail and only give permissions to that type, but offhand I don't see an existing type that would fit for that purpose, so you'd have to define a new one. Likely more work than you want to deal with right now. The good news is that it only requires append access, so it cannot overwrite an existing file's contents even if you allow the above. -- Stephen Smalley National Security Agency From tibbs at math.uh.edu Thu Mar 6 16:34:00 2008 From: tibbs at math.uh.edu (Jason Tibbitts) Date: 06 Mar 2008 10:34:00 -0600 Subject: /var/tmp/host_0 context getting set to initrc_tmp_t Message-ID: <3287644456.9498012@mail.math.uh.edu> >You don't want to leave daemons running in initrc_t. So you want to put kpropd into a domain, whether an existing one (if something similar in purpose and required accesses exists) or a new one, and then you can >ensure that the file will get the right type when created. Well, I undeestand what you're saying, but I'm just using the stock F8 policy. Is this bugzilla-worthy? From sds at tycho.nsa.gov Thu Mar 6 16:38:39 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 06 Mar 2008 11:38:39 -0500 Subject: /var/tmp/host_0 context getting set to initrc_tmp_t In-Reply-To: <3287644456.9498012@mail.math.uh.edu> References: <3287644456.9498012@mail.math.uh.edu> Message-ID: <1204821519.1397.300.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2008-03-06 at 10:34 -0600, Jason Tibbitts wrote: > >You don't want to leave daemons running in initrc_t. So you want to put kpropd into a domain, whether an existing one (if something similar in purpose and required accesses exists) or a new one, and then you can > >ensure that the file will get the right type when created. > > Well, I undeestand what you're saying, but I'm just using the stock F8 policy. Is this bugzilla-worthy? Yes, I would say so. -- Stephen Smalley National Security Agency From linuxweb at gmail.com Thu Mar 6 16:44:24 2008 From: linuxweb at gmail.com (Johnny Tan) Date: Thu, 06 Mar 2008 11:44:24 -0500 Subject: getting denials when run from init script but not from command-line In-Reply-To: <47CFB4C5.1010208@city-fan.org> References: <47CF2E12.10008@gmail.com> <47CFB4C5.1010208@city-fan.org> Message-ID: <47D01F68.4010904@gmail.com> Paul Howarth wrote: > Johnny Tan wrote: >> I took the Fedora-8 SRPM for rsyslog 2.0.2 and rebuilt it for CentOS-5 >> x86_64. After doing: >> >> # semanage fcontext -a -t syslogd_exec_t /sbin/rsyslogd >> # semanage fcontext -a -t klogd_exec_t /sbin/rklogd >> >> I can do "service rsyslog start" and it works. >> >> >> Then, I did the rebuild for rsyslog version 3.11.6. Had to tweak the >> spec and conf files a bit, but got it packaged and installed. And made >> sure the above contexts were retained (they were). >> >> However, when I go to run it "service rsyslog start" using the same >> init script that worked with the 2.0.2 version, I get this: >> >> == >> type=SYSCALL msg=audit(03/05/2008 17:43:26.966:224) : arch=x86_64 >> syscall=bind success=yes exit=0 a0=1 a1=51b2ae0 a2=10 a3=7fffa9e3f63c >> items=0 ppid=29717 pid=29718 auid=root uid=root gid=root euid=root >> suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) >> comm=rsyslogd exe=/sbin/rsyslogd subj=root:system_r:syslogd_t:s0 >> key=(null) >> type=AVC msg=audit(03/05/2008 17:43:26.966:224) : avc: denied { >> node_bind } for pid=29718 comm=rsyslogd src=61514 >> scontext=root:system_r:syslogd_t:s0 >> tcontext=system_u:object_r:inaddr_any_node_t:s0 tclass=tcp_socket >> == >> >> >> BUT, when I run it directly from the command-line: >> /sbin/rsyslogd >> I do NOT get those denials. >> >> I know how to create the module to allow the above, but what I'm more >> interested in is what allows me to run it from the command-line but >> not from the init script. >> >> The line that starts the rsyslogd in the init script is: >> daemon rsyslogd $SYSLOGD_OPTIONS >> ("daemon" being a function sourced from /etc/init.d/functions) >> >> But even if I replace that line with a simple: >> /sbin/rsyslogd >> it still gives me the denials. >> >> >> Anyone have ideas why? I don't want to just create the module and >> sweep this under the rug. > > This is normal behaviour for confined daemons (those that policy has > been written for); they transition to their own domain (syslogd_t in > this case) and are confined to that domain when run from the initscript > but don't transition and run unconfined if you start them directly from > the command line. Thanks Paul. I guess what got me is that version 2.0.2 did not exhibit this behavior, even when ran from the *same* init script. Shouldn't it also have been confined and, hence, generate the same AVC denials? Secondly, so I guess if this is "normal" behavior, then I *should* be creating and loading the module to allow the tcp_socket connect that's currently being denied for the v3.11.6 daemon. Correct? Thanks for the insight, johnn From joe at nall.com Thu Mar 6 18:09:38 2008 From: joe at nall.com (Joe Nall) Date: Thu, 6 Mar 2008 12:09:38 -0600 Subject: Rawhide mls avcs on boot Message-ID: rawhide mls (selinux-policy-3.3.1-11) has a number of these avcs in / var/log/messages on boot Mar 6 10:00:01 xw4100 kernel: type=1400 audit(1204819180.560:5): avc: denied { unmount } for pid=1 comm="init" scontext=system_u:system_r:kernel_t:s15:c0.c1023 tcontext=system_u:object_r:tmpfs_t:s0 tclass=filesystem Mar 6 10:00:01 xw4100 kernel: type=1400 audit(1204819180.560:6): avc: denied { unmount } for pid=1 comm="init" scontext=system_u:system_r:kernel_t:s15:c0.c1023 tcontext=system_u:object_r:proc_t:s0 tclass=filesystem Mar 6 10:00:01 xw4100 kernel: type=1400 audit(1204819180.561:7): avc: denied { unmount } for pid=1 comm="init" scontext=system_u:system_r:kernel_t:s15:c0.c1023 tcontext=system_u:object_r:sysfs_t:s0 tclass=filesystem is adding allow kernel_t proc_t:filesystem unmount; allow kernel_t sysfs_t:filesystem unmount; allow kernel_t tmpfs_t:filesystem unmount; to kernel.te the correct fix for this? joe From sds at tycho.nsa.gov Thu Mar 6 18:16:30 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 06 Mar 2008 13:16:30 -0500 Subject: Rawhide mls avcs on boot In-Reply-To: References: Message-ID: <1204827390.1397.314.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2008-03-06 at 12:09 -0600, Joe Nall wrote: > rawhide mls (selinux-policy-3.3.1-11) has a number of these avcs in / > var/log/messages on boot > > Mar 6 10:00:01 xw4100 kernel: type=1400 audit(1204819180.560:5): > avc: denied { unmount } for pid=1 comm="init" > scontext=system_u:system_r:kernel_t:s15:c0.c1023 > tcontext=system_u:object_r:tmpfs_t:s0 tclass=filesystem > Mar 6 10:00:01 xw4100 kernel: type=1400 audit(1204819180.560:6): > avc: denied { unmount } for pid=1 comm="init" > scontext=system_u:system_r:kernel_t:s15:c0.c1023 > tcontext=system_u:object_r:proc_t:s0 tclass=filesystem > Mar 6 10:00:01 xw4100 kernel: type=1400 audit(1204819180.561:7): > avc: denied { unmount } for pid=1 comm="init" > scontext=system_u:system_r:kernel_t:s15:c0.c1023 > tcontext=system_u:object_r:sysfs_t:s0 tclass=filesystem > > is adding > > allow kernel_t proc_t:filesystem unmount; > allow kernel_t sysfs_t:filesystem unmount; > allow kernel_t tmpfs_t:filesystem unmount; > > to kernel.te the correct fix for this? fs_unmount_all_fs(kernel_t) -- Stephen Smalley National Security Agency From selinux at gmail.com Thu Mar 6 18:30:29 2008 From: selinux at gmail.com (Tom London) Date: Thu, 6 Mar 2008 10:30:29 -0800 Subject: gvfs AVC mounting /var/lib/gdm/.gvfs Message-ID: <4c4ba1530803061030j5d0c37dai13f26247fef1315c@mail.gmail.com> See this after today's rawhide update (targeted/enforcing): type=LABEL_LEVEL_CHANGE msg=audit(1204827382.645:12): user pid=2409 uid=0 auid=4294967295 subj=system_u:system_r:cupsd_t:s0-s0:c0.c1023 msg='printer=Local uri=file:/dev/null banners=none,none range=unknown: exe="/usr/sbin/cupsd" (hostname=localhost.localdomain, addr=127.0.0.1, terminal=? res=success)' type=AVC msg=audit(1204827439.066:13): avc: denied { mounton } for pid=2827 comm="gvfs-fuse-daemo" path="/var/lib/gdm/.gvfs" dev=dm-0 ino=66829 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:xdm_var_lib_t:s0 tclass=dir type=SYSCALL msg=audit(1204827439.066:13): arch=40000003 syscall=21 success=no exit=-13 a0=9fa94d0 a1=9fa89e8 a2=9fa9510 a3=6 items=0 ppid=1 pid=2827 auid=4294967295 uid=42 gid=42 euid=42 suid=42 fsuid=42 egid=42 sgid=42 fsgid=42 tty=(none) ses=4294967295 comm="gvfs-fuse-daemo" exe="/usr/libexec/gvfs-fuse-daemon" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) type=USER_AUTH msg=audit(1204827505.624:14): user pid=2815 uid=0 auid=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct=tbl exe="/usr/libexec/gdm-session-worker" (hostname=?, addr=?, terminal=:0 res=failed)' -- Tom London From joe at nall.com Thu Mar 6 18:36:12 2008 From: joe at nall.com (Joe Nall) Date: Thu, 6 Mar 2008 12:36:12 -0600 Subject: Rawhide mls avcs on boot In-Reply-To: <1204827390.1397.314.camel@moss-spartans.epoch.ncsc.mil> References: <1204827390.1397.314.camel@moss-spartans.epoch.ncsc.mil> Message-ID: On Mar 6, 2008, at 12:16 PM, Stephen Smalley wrote: > > On Thu, 2008-03-06 at 12:09 -0600, Joe Nall wrote: >> rawhide mls (selinux-policy-3.3.1-11) has a number of these avcs in / >> var/log/messages on boot >> >> Mar 6 10:00:01 xw4100 kernel: type=1400 audit(1204819180.560:5): >> avc: denied { unmount } for pid=1 comm="init" >> scontext=system_u:system_r:kernel_t:s15:c0.c1023 >> tcontext=system_u:object_r:tmpfs_t:s0 tclass=filesystem >> Mar 6 10:00:01 xw4100 kernel: type=1400 audit(1204819180.560:6): >> avc: denied { unmount } for pid=1 comm="init" >> scontext=system_u:system_r:kernel_t:s15:c0.c1023 >> tcontext=system_u:object_r:proc_t:s0 tclass=filesystem >> Mar 6 10:00:01 xw4100 kernel: type=1400 audit(1204819180.561:7): >> avc: denied { unmount } for pid=1 comm="init" >> scontext=system_u:system_r:kernel_t:s15:c0.c1023 >> tcontext=system_u:object_r:sysfs_t:s0 tclass=filesystem >> >> is adding >> >> allow kernel_t proc_t:filesystem unmount; >> allow kernel_t sysfs_t:filesystem unmount; >> allow kernel_t tmpfs_t:filesystem unmount; >> >> to kernel.te the correct fix for this? > > fs_unmount_all_fs(kernel_t) fs_mount_all_fs(kernel_t) is slready in kernel.te. After further experimentation, I think it is a constraint issue (s15:c0.c1023 unmounting s0). joe From sds at tycho.nsa.gov Thu Mar 6 19:04:41 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 06 Mar 2008 14:04:41 -0500 Subject: Rawhide mls avcs on boot In-Reply-To: References: <1204827390.1397.314.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1204830281.1397.324.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2008-03-06 at 12:36 -0600, Joe Nall wrote: > On Mar 6, 2008, at 12:16 PM, Stephen Smalley wrote: > > > > > On Thu, 2008-03-06 at 12:09 -0600, Joe Nall wrote: > >> rawhide mls (selinux-policy-3.3.1-11) has a number of these avcs in / > >> var/log/messages on boot > >> > >> Mar 6 10:00:01 xw4100 kernel: type=1400 audit(1204819180.560:5): > >> avc: denied { unmount } for pid=1 comm="init" > >> scontext=system_u:system_r:kernel_t:s15:c0.c1023 > >> tcontext=system_u:object_r:tmpfs_t:s0 tclass=filesystem > >> Mar 6 10:00:01 xw4100 kernel: type=1400 audit(1204819180.560:6): > >> avc: denied { unmount } for pid=1 comm="init" > >> scontext=system_u:system_r:kernel_t:s15:c0.c1023 > >> tcontext=system_u:object_r:proc_t:s0 tclass=filesystem > >> Mar 6 10:00:01 xw4100 kernel: type=1400 audit(1204819180.561:7): > >> avc: denied { unmount } for pid=1 comm="init" > >> scontext=system_u:system_r:kernel_t:s15:c0.c1023 > >> tcontext=system_u:object_r:sysfs_t:s0 tclass=filesystem > >> > >> is adding > >> > >> allow kernel_t proc_t:filesystem unmount; > >> allow kernel_t sysfs_t:filesystem unmount; > >> allow kernel_t tmpfs_t:filesystem unmount; > >> > >> to kernel.te the correct fix for this? > > > > fs_unmount_all_fs(kernel_t) > > fs_mount_all_fs(kernel_t) is slready in kernel.te. After further > experimentation, I think it is a constraint issue (s15:c0.c1023 > unmounting s0). Well, I know that fs_mount_all_fs() is already there - but we are talking about unmount, not mount. And it may also involve constraints, in which case kernel_t might need mls_file_write_all_levels(). Which I would think would be needed anyway for e.g. nfsd operation. -- Stephen Smalley National Security Agency From joe at nall.com Thu Mar 6 20:17:51 2008 From: joe at nall.com (Joe Nall) Date: Thu, 6 Mar 2008 14:17:51 -0600 Subject: Rawhide mls avcs on boot In-Reply-To: <1204830281.1397.324.camel@moss-spartans.epoch.ncsc.mil> References: <1204827390.1397.314.camel@moss-spartans.epoch.ncsc.mil> <1204830281.1397.324.camel@moss-spartans.epoch.ncsc.mil> Message-ID: On Mar 6, 2008, at 1:04 PM, Stephen Smalley wrote: > > On Thu, 2008-03-06 at 12:36 -0600, Joe Nall wrote: >> On Mar 6, 2008, at 12:16 PM, Stephen Smalley wrote: >> >>> >>> On Thu, 2008-03-06 at 12:09 -0600, Joe Nall wrote: >>>> rawhide mls (selinux-policy-3.3.1-11) has a number of these avcs >>>> in / >>>> var/log/messages on boot >>>> >>>> Mar 6 10:00:01 xw4100 kernel: type=1400 audit(1204819180.560:5): >>>> avc: denied { unmount } for pid=1 comm="init" >>>> scontext=system_u:system_r:kernel_t:s15:c0.c1023 >>>> tcontext=system_u:object_r:tmpfs_t:s0 tclass=filesystem >>>> Mar 6 10:00:01 xw4100 kernel: type=1400 audit(1204819180.560:6): >>>> avc: denied { unmount } for pid=1 comm="init" >>>> scontext=system_u:system_r:kernel_t:s15:c0.c1023 >>>> tcontext=system_u:object_r:proc_t:s0 tclass=filesystem >>>> Mar 6 10:00:01 xw4100 kernel: type=1400 audit(1204819180.561:7): >>>> avc: denied { unmount } for pid=1 comm="init" >>>> scontext=system_u:system_r:kernel_t:s15:c0.c1023 >>>> tcontext=system_u:object_r:sysfs_t:s0 tclass=filesystem >>>> >>>> is adding >>>> >>>> allow kernel_t proc_t:filesystem unmount; >>>> allow kernel_t sysfs_t:filesystem unmount; >>>> allow kernel_t tmpfs_t:filesystem unmount; >>>> >>>> to kernel.te the correct fix for this? >>> >>> fs_unmount_all_fs(kernel_t) >> >> fs_mount_all_fs(kernel_t) is slready in kernel.te. After further >> experimentation, I think it is a constraint issue (s15:c0.c1023 >> unmounting s0). > > Well, I know that fs_mount_all_fs() is already there - but we are > talking about unmount, not mount. correct > And it may also involve constraints, in which case kernel_t might need > mls_file_write_all_levels(). Which I would think would be needed > anyway > for e.g. nfsd operation. Thanks for the pointer. All three of the following were required. I added them one at a time to the policy and rebooted each time. Patch against selinux-policy-3.3.1-11 attached. fs_unmount_all_fs(kernel_t) mls_file_write_all_levels(kernel_t) mls_file_read_all_levels(kernel_t) -------------- next part -------------- A non-text attachment was scrubbed... Name: kernel.te.patch Type: application/octet-stream Size: 501 bytes Desc: not available URL: -------------- next part -------------- From sds at tycho.nsa.gov Thu Mar 6 20:24:46 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 06 Mar 2008 15:24:46 -0500 Subject: Rawhide mls avcs on boot In-Reply-To: References: <1204827390.1397.314.camel@moss-spartans.epoch.ncsc.mil> <1204830281.1397.324.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1204835086.1397.365.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2008-03-06 at 14:17 -0600, Joe Nall wrote: > On Mar 6, 2008, at 1:04 PM, Stephen Smalley wrote: > > > > > On Thu, 2008-03-06 at 12:36 -0600, Joe Nall wrote: > >> On Mar 6, 2008, at 12:16 PM, Stephen Smalley wrote: > >> > >>> > >>> On Thu, 2008-03-06 at 12:09 -0600, Joe Nall wrote: > >>>> rawhide mls (selinux-policy-3.3.1-11) has a number of these avcs > >>>> in / > >>>> var/log/messages on boot > >>>> > >>>> Mar 6 10:00:01 xw4100 kernel: type=1400 audit(1204819180.560:5): > >>>> avc: denied { unmount } for pid=1 comm="init" > >>>> scontext=system_u:system_r:kernel_t:s15:c0.c1023 > >>>> tcontext=system_u:object_r:tmpfs_t:s0 tclass=filesystem > >>>> Mar 6 10:00:01 xw4100 kernel: type=1400 audit(1204819180.560:6): > >>>> avc: denied { unmount } for pid=1 comm="init" > >>>> scontext=system_u:system_r:kernel_t:s15:c0.c1023 > >>>> tcontext=system_u:object_r:proc_t:s0 tclass=filesystem > >>>> Mar 6 10:00:01 xw4100 kernel: type=1400 audit(1204819180.561:7): > >>>> avc: denied { unmount } for pid=1 comm="init" > >>>> scontext=system_u:system_r:kernel_t:s15:c0.c1023 > >>>> tcontext=system_u:object_r:sysfs_t:s0 tclass=filesystem > >>>> > >>>> is adding > >>>> > >>>> allow kernel_t proc_t:filesystem unmount; > >>>> allow kernel_t sysfs_t:filesystem unmount; > >>>> allow kernel_t tmpfs_t:filesystem unmount; > >>>> > >>>> to kernel.te the correct fix for this? > >>> > >>> fs_unmount_all_fs(kernel_t) > >> > >> fs_mount_all_fs(kernel_t) is slready in kernel.te. After further > >> experimentation, I think it is a constraint issue (s15:c0.c1023 > >> unmounting s0). > > > > Well, I know that fs_mount_all_fs() is already there - but we are > > talking about unmount, not mount. > > correct > > > And it may also involve constraints, in which case kernel_t might need > > mls_file_write_all_levels(). Which I would think would be needed > > anyway > > for e.g. nfsd operation. > > Thanks for the pointer. All three of the following were required. I > added them one at a time to the policy and rebooted each time. Patch > against selinux-policy-3.3.1-11 attached. > > fs_unmount_all_fs(kernel_t) > mls_file_write_all_levels(kernel_t) > mls_file_read_all_levels(kernel_t) Needs to go to Dan for Fedora, and to Chris for upstream. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Thu Mar 6 20:51:19 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 06 Mar 2008 15:51:19 -0500 Subject: Rawhide mls avcs on boot In-Reply-To: <1204835086.1397.365.camel@moss-spartans.epoch.ncsc.mil> References: <1204827390.1397.314.camel@moss-spartans.epoch.ncsc.mil> <1204830281.1397.324.camel@moss-spartans.epoch.ncsc.mil> <1204835086.1397.365.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <47D05947.3090200@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Smalley wrote: > On Thu, 2008-03-06 at 14:17 -0600, Joe Nall wrote: >> On Mar 6, 2008, at 1:04 PM, Stephen Smalley wrote: >> >>> On Thu, 2008-03-06 at 12:36 -0600, Joe Nall wrote: >>>> On Mar 6, 2008, at 12:16 PM, Stephen Smalley wrote: >>>> >>>>> On Thu, 2008-03-06 at 12:09 -0600, Joe Nall wrote: >>>>>> rawhide mls (selinux-policy-3.3.1-11) has a number of these avcs >>>>>> in / >>>>>> var/log/messages on boot >>>>>> >>>>>> Mar 6 10:00:01 xw4100 kernel: type=1400 audit(1204819180.560:5): >>>>>> avc: denied { unmount } for pid=1 comm="init" >>>>>> scontext=system_u:system_r:kernel_t:s15:c0.c1023 >>>>>> tcontext=system_u:object_r:tmpfs_t:s0 tclass=filesystem >>>>>> Mar 6 10:00:01 xw4100 kernel: type=1400 audit(1204819180.560:6): >>>>>> avc: denied { unmount } for pid=1 comm="init" >>>>>> scontext=system_u:system_r:kernel_t:s15:c0.c1023 >>>>>> tcontext=system_u:object_r:proc_t:s0 tclass=filesystem >>>>>> Mar 6 10:00:01 xw4100 kernel: type=1400 audit(1204819180.561:7): >>>>>> avc: denied { unmount } for pid=1 comm="init" >>>>>> scontext=system_u:system_r:kernel_t:s15:c0.c1023 >>>>>> tcontext=system_u:object_r:sysfs_t:s0 tclass=filesystem >>>>>> >>>>>> is adding >>>>>> >>>>>> allow kernel_t proc_t:filesystem unmount; >>>>>> allow kernel_t sysfs_t:filesystem unmount; >>>>>> allow kernel_t tmpfs_t:filesystem unmount; >>>>>> >>>>>> to kernel.te the correct fix for this? >>>>> fs_unmount_all_fs(kernel_t) >>>> fs_mount_all_fs(kernel_t) is slready in kernel.te. After further >>>> experimentation, I think it is a constraint issue (s15:c0.c1023 >>>> unmounting s0). >>> Well, I know that fs_mount_all_fs() is already there - but we are >>> talking about unmount, not mount. >> correct >> >>> And it may also involve constraints, in which case kernel_t might need >>> mls_file_write_all_levels(). Which I would think would be needed >>> anyway >>> for e.g. nfsd operation. >> Thanks for the pointer. All three of the following were required. I >> added them one at a time to the policy and rebooted each time. Patch >> against selinux-policy-3.3.1-11 attached. >> >> fs_unmount_all_fs(kernel_t) >> mls_file_write_all_levels(kernel_t) >> mls_file_read_all_levels(kernel_t) > > Needs to go to Dan for Fedora, and to Chris for upstream. > Added to -12 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfQWUEACgkQrlYvE4MpobOEhwCglVDdZOrdtfvAvHxqTrlur1hr gusAnjD93SizUhq+FK+g4VB8s6DhV2Fe =7lnX -----END PGP SIGNATURE----- From dwalsh at redhat.com Thu Mar 6 21:47:33 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 06 Mar 2008 16:47:33 -0500 Subject: /var/tmp/host_0 context getting set to initrc_tmp_t In-Reply-To: References: Message-ID: <47D06675.5060107@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jason L Tibbitts III wrote: > I'm trying to track down a situation where the context of > /var/tmp/host_0 somehow gets set to initrc_tmp_t instead of > krb5_host_rcache_t. When this happens, I get the following denial: > audit(1204783558.948:68): avc: denied { getattr } for pid=11121 > comm="sshd" path="/var/tmp/host_0" dev=dm-3 ino=753668 > scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 > tcontext=unconfined_u:object_r:initrc_tmp_t:s0 tclass=file > and ssh gssapi authentication stops working. > > This machine is a kerberos slave server, and my best guess is that kpropd > (which runs as initrc_t) is rewriting (i.e. deleting and recreating) > that file at some point. Unfortunately I can't cause it to happen so > I'm not sure that's what's going on. > > This is probably a corner case among corner cases, but has anyone seen > anything like this? > > - J< > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list This should work but is broken. Related to Bugzilla 428355 And kpropd does need a policy written for it. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfQZm8ACgkQrlYvE4MpobPB6ACg59OPfxNm6+B9s4PBhE+4viOp hygAn00F5iiUJ7Cqkz6TO+wIcdxf0mpZ =V+84 -----END PGP SIGNATURE----- From linuxweb at gmail.com Fri Mar 7 16:10:28 2008 From: linuxweb at gmail.com (Johnny Tan) Date: Fri, 07 Mar 2008 11:10:28 -0500 Subject: how to allow one program to mount to /tmp? Message-ID: <47D168F4.2050902@gmail.com> I use puppet to do config management. It writes to /tmp/puppet.$$ files to capture the output of commands, then reads in from those tmp files after. It seems that when puppet attempts to do a mount command to /tmp, selinux is denying it. When I do audit2allow, it comes up with this: == require { type initrc_tmp_t; type mount_t; class file { read write }; } #============= mount_t ============== allow mount_t initrc_tmp_t:file { read write }; == To me, this seems a bit broad. The above allows any program to mount to /tmp, right? How can I modify it such that only my puppet program is allowed, but continued to deny all others? johnn From dwalsh at redhat.com Fri Mar 7 16:48:21 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 07 Mar 2008 11:48:21 -0500 Subject: how to allow one program to mount to /tmp? In-Reply-To: <47D168F4.2050902@gmail.com> References: <47D168F4.2050902@gmail.com> Message-ID: <47D171D5.40004@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johnny Tan wrote: > I use puppet to do config management. It writes to /tmp/puppet.$$ files > to capture the output of commands, then reads in from those tmp files > after. > > It seems that when puppet attempts to do a mount command to /tmp, > selinux is denying it. > First why are you using /tmp? This is a directory that random users can write to. It should never be used from system space. Please read... Daemons "Just say no to using /tmp" --- http://danwalsh.livejournal.com/11467.html Sounds like this is a log file so why not put it in /var/log? I believe mount can mount there now. > When I do audit2allow, it comes up with this: > > == > require { > type initrc_tmp_t; > type mount_t; > class file { read write }; > } > > #============= mount_t ============== > allow mount_t initrc_tmp_t:file { read write }; > == > > > To me, this seems a bit broad. The above allows any program to mount to > /tmp, right? > > How can I modify it such that only my puppet program is allowed, but > continued to deny all others? > > johnn > > -- > 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.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfRcc8ACgkQrlYvE4MpobP4EwCgrmVqTh7Y/xYLxRuioZSn0A+j JnAAn1wiDiDhwMMiUtl5PU4TkJMqa/93 =6XKw -----END PGP SIGNATURE----- From linuxweb at gmail.com Fri Mar 7 16:56:58 2008 From: linuxweb at gmail.com (Johnny Tan) Date: Fri, 07 Mar 2008 11:56:58 -0500 Subject: how to allow one program to mount to /tmp? In-Reply-To: <47D171D5.40004@redhat.com> References: <47D168F4.2050902@gmail.com> <47D171D5.40004@redhat.com> Message-ID: <47D173DA.9020507@gmail.com> Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Johnny Tan wrote: >> I use puppet to do config management. It writes to /tmp/puppet.$$ files >> to capture the output of commands, then reads in from those tmp files >> after. >> >> It seems that when puppet attempts to do a mount command to /tmp, >> selinux is denying it. >> > First why are you using /tmp? This is a directory that random users can > write to. It should never be used from system space. I agree, and I will file an enhancement request to the puppet dev to change that. I think he chose /tmp because the file DOES get removed after the command is run. But for the moment, it doesn't seem this can be set via config file. So I'm wondering if I can possibly load a module for now that allows only puppet to mount to /tmp. johnn From dwalsh at redhat.com Fri Mar 7 18:27:58 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 07 Mar 2008 13:27:58 -0500 Subject: how to allow one program to mount to /tmp? In-Reply-To: <47D173DA.9020507@gmail.com> References: <47D168F4.2050902@gmail.com> <47D171D5.40004@redhat.com> <47D173DA.9020507@gmail.com> Message-ID: <47D1892E.5080100@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johnny Tan wrote: > Daniel J Walsh wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Johnny Tan wrote: >>> I use puppet to do config management. It writes to /tmp/puppet.$$ files >>> to capture the output of commands, then reads in from those tmp files >>> after. >>> >>> It seems that when puppet attempts to do a mount command to /tmp, >>> selinux is denying it. >>> >> First why are you using /tmp? This is a directory that random users can >> write to. It should never be used from system space. > > I agree, and I will file an enhancement request to the puppet dev to > change that. I think he chose /tmp because the file DOES get removed > after the command is run. > > But for the moment, it doesn't seem this can be set via config file. > > So I'm wondering if I can possibly load a module for now that allows > only puppet to mount to /tmp. > > johnn You would have to write a policy for puppet, which will probably need to be an unconfined domain. You could confine it, if you new exactly what puppet would do on your machine. You might need additional calls. Not knowing what puppet will do, here is a guess at a policy. cat mypuppet.te policy_module(mypuppet, 1.0) type mypuppet_t; type mypuppet_exec_t; init_system_domain(mypuppet_t, mypuppet_exec_t); type mypuppet_log_t files_type(mypuppet_log_t) # In order to get proper transitions to confined domains, puppet should use init scripts init_spec_domtrans_script(mypuppet_t) unconfined_domain(mypuppet_t) gen_requires(` attribute domain; ') append_files_pattern(domain, mypuppet_log_t) cat mypuppet.fc /usr/sbin/puppet -- gen_context(system_u:object_r:mypuppet_exec_t,s0) PATHTOMYPUPPET.LOG gen_context(system_u:object_r:mypuppet_log_t,s0) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfRiScACgkQrlYvE4MpobM7ZACghgKp5oPxpZ917nEBgT4+RN1i zCQAnAg/LNWbEt0kI8DO9u6fmcApxNbS =YQdr -----END PGP SIGNATURE----- From linuxweb at gmail.com Fri Mar 7 21:28:28 2008 From: linuxweb at gmail.com (Johnny Tan) Date: Fri, 07 Mar 2008 16:28:28 -0500 Subject: how to allow one program to mount to /tmp? In-Reply-To: <47D1892E.5080100@redhat.com> References: <47D168F4.2050902@gmail.com> <47D171D5.40004@redhat.com> <47D173DA.9020507@gmail.com> <47D1892E.5080100@redhat.com> Message-ID: <47D1B37C.3000400@gmail.com> Daniel J Walsh wrote: >> So I'm wondering if I can possibly load a module for now that allows >> only puppet to mount to /tmp. >> >> johnn > You would have to write a policy for puppet, which will probably need to > be an unconfined domain. You could confine it, if you new exactly what > puppet would do on your machine. You might need additional calls. Not > knowing what puppet will do, here is a guess at a policy. Thanks for the sample policy Dan! johnn From selinux.list at troodos.demon.co.uk Sat Mar 8 09:22:42 2008 From: selinux.list at troodos.demon.co.uk (Arthur Dent) Date: Sat, 8 Mar 2008 09:22:42 +0000 Subject: Bash script problem [OT] Message-ID: <20080308092242.GA8249@localhost.localdomain> Hello all, I run my F8 SELinux machine headless, and administer it through ssh. This means I don't easily have many of the graphical tools available to help. During the early stages of my transition to "enforcing" mode I want to keep a close eye on denials but of course I don't have the wonderful sealert graphical troubleshooter popping up each time something happens. So I have written this little script to check the logs using a cron job every ten minutes. (NB I'm no expert in bash scripting - that much should be obvious!) The script itself works just fine when run from the command line as root. When run from cron however (still as root), no matter what denials there have been, ausearch *always* returns "". I have tried this by putting the ausearch command on a line of its own, and even with the command ausearch -m AVC -ts yesterday (when there *were* denials) it returns "" wehre running the exact same command from the command line produces the correct output. I have no idea why this doesn't work - environment variables perhaps? Any bash script gurus out there? Thanks Mark =====8<=============================================================== #!/bin/bash # selinux_avc_check.sh # This script uses the "ausearch" tool which reads the SELinux # /var/log/audit/audit.log file. # The "-m AVC" means search for the term AVC (denial). # The "-ts recent" means in the last 10 minutes # If there are no AVC denials it will report "" # and all will be well. # If there is any other output (i.e there has been a denial) it # will send an email to root to check the logs. # It is designed to be run as a cron job every 10 mins # */10 * * * * /root/scripts/selinux_avc_check.sh if /sbin/ausearch -m AVC -ts recent 2>&1| grep -q no\ matches then exit 1 else echo "SELinux AVC Denial - please check the logs!" |mail -s "SELinux AVC Denial!" root fi =====8<=============================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From selinux.list at troodos.demon.co.uk Sat Mar 8 13:01:30 2008 From: selinux.list at troodos.demon.co.uk (Arthur Dent) Date: Sat, 8 Mar 2008 13:01:30 +0000 Subject: Bash script problem [OT] - Solved In-Reply-To: <20080308092242.GA8249@localhost.localdomain> References: <20080308092242.GA8249@localhost.localdomain> Message-ID: <20080308130130.GA9853@localhost.localdomain> On Sat, Mar 08, 2008 at 09:22:42AM +0000, Arthur Dent wrote: > > I have no idea why this doesn't work - environment variables perhaps? > Well, I managed to fix this. What I did was to set up an "at" job for the future (which worked) and then look at all the environment variables for the at job. Then, one by one I tried them in my script until it worked from cron. The line that did it was: ${SHELL:-/bin/sh} << `(dd if=/dev/urandom count=200 bs=12>/dev/null|LC_ALL=C tr -d -c '[:alnum:]')` I have no idea what it does (if anyone would care to explain it to me I would be interested) but all I know is it works! Thanks to all... Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From joe at nall.com Sat Mar 8 15:56:55 2008 From: joe at nall.com (Joe Nall) Date: Sat, 8 Mar 2008 09:56:55 -0600 Subject: rawhide, upstart, mls, telinit and udp Message-ID: <401F4100-8A97-41DA-8252-976BCF6B3A3C@nall.com> In rawhide (upstart) mls, I'm seeing avcs like allow initrc_t init_t:unix_dgram_socket sendto; allow init_t staff_t:unix_dgram_socket sendto; allow init_t user_t:unix_dgram_socket sendto; Reading the init.if file there is an empty, depreciated udp interface for init. Adding the following to the init_telinit interface fixes the avc, but it looks like the new interface may be the old udp ... --- serefpolicy-3.3.1/policy/modules/system/init.if.orig 2008-03-08 14:57:10.000000000 -0600 +++ serefpolicy-3.3.1/policy/modules/system/init.if 2008-03-08 14:58:08.000000000 -0600 @@ -470,10 +470,12 @@ interface(`init_write_initctl',` interface(`init_telinit',` gen_require(` type initctl_t; + type init_t; ') dev_list_all_dev_nodes($1) allow $1 initctl_t:fifo_file rw_fifo_file_perms; + allow $1 init_t:unix_dgram_socket sendto; init_exec($1) ') joe From selinux at gmail.com Sat Mar 8 18:07:35 2008 From: selinux at gmail.com (Tom London) Date: Sat, 8 Mar 2008 10:07:35 -0800 Subject: New AVCs with today's rawhide.... (mostly xdm related) Message-ID: <4c4ba1530803081007gb1fb3een53eb26f2d48cbe80@mail.gmail.com> Running rawhide, targeted. Had problems after today's rawhide update. Booting in permissive mode produced: module localxdm 1.0; require { type unconfined_t; type security_t; type xdm_var_lib_t; type syslogd_t; type unconfined_execmem_t; type xdm_xserver_t; type system_map_t; type mono_t; type xdm_t; type mount_t; class unix_stream_socket { read write }; class x_property read; class security { check_context compute_create compute_av }; class file { read write getattr }; class dir { write read mounton }; } #============= mono_t ============== allow mono_t unconfined_t:x_property read; #============= mount_t ============== allow mount_t xdm_t:unix_stream_socket { read write }; allow mount_t xdm_var_lib_t:dir { write read mounton }; #============= syslogd_t ============== allow syslogd_t system_map_t:file { read getattr }; #============= unconfined_execmem_t ============== allow unconfined_execmem_t unconfined_t:x_property read; allow unconfined_execmem_t xdm_t:x_property read; #============= xdm_t ============== allow xdm_t xdm_var_lib_t:dir mounton; #============= xdm_xserver_t ============== allow xdm_xserver_t security_t:dir read; allow xdm_xserver_t security_t:file { write read }; allow xdm_xserver_t security_t:security { check_context compute_create compute_av }; I'll attach the raw audit file below. In addition, there were two avcs produced in /var/log/messages before the start of audit: Mar 8 09:49:52 localhost kernel: type=1400 audit(1204998591.798:3): avc: denied { read } for pid=2257 comm="rsyslogd" name="System.map-2.6.25-0.95.rc4.local2.fc9" dev=sda3 ino=6064 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:system_map_t:s0 tclass=file Mar 8 09:49:52 localhost kernel: type=1400 audit(1204998591.798:4): avc: denied { getattr } for pid=2257 comm="rsyslogd" path="/boot/System.map-2.6.25-0.95.rc4.local2.fc9" dev=sda3 ino=6064 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:system_map_t:s0 tclass=file Not sure all of these need to be "allow", but "semodule -i localxdm.pp" makes the system boot and run in enforcing mode. tom -- Tom London -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: audit-log.txt URL: From olivares14031 at yahoo.com Sat Mar 8 19:17:37 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Sat, 8 Mar 2008 11:17:37 -0800 (PST) Subject: SELinux is preventing gnome-clock-app (gnomeclock_t) "sys_nice" to (gnomeclock_t). Message-ID: <999588.59028.qm@web52606.mail.re2.yahoo.com> Dear all, system time is behind 5 hours, when booting livecd time is correct, and windows also, but in Fedora it is behind 5 hours. I had ntpd to have time correct, but somehow it did not correct the time, upon trying to change date via panel, I was greeted with Summary: SELinux is preventing gnome-clock-app (gnomeclock_t) "sys_nice" to (gnomeclock_t). Detailed Description: SELinux denied access requested by gnome-clock-app. It is not expected that this access is required by gnome-clock-app 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:gnomeclock_t:SystemLow- SystemHigh Target Context system_u:system_r:gnomeclock_t:SystemLow- SystemHigh Target Objects None [ capability ] Source gnome-clock-app Source Path /usr/libexec/gnome-clock-applet-mechanism Port Host localhost Source RPM Packages gnome-panel-2.21.92-5.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-12.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name localhost Platform Linux localhost 2.6.25-0.95.rc4.fc9 #1 SMP Thu Mar 6 01:17:49 EST 2008 i686 athlon Alert Count 1 First Seen Sat 08 Mar 2008 01:12:37 PM CST Last Seen Sat 08 Mar 2008 01:12:37 PM CST Local ID d97e2362-cf08-4c53-a387-56e7c332aaf9 Line Numbers Raw Audit Messages host=localhost type=AVC msg=audit(1205003557.746:18): avc: denied { sys_nice } for pid=2839 comm="gnome-clock-app" capability=23 scontext=system_u:system_r:gnomeclock_t:s0-s0:c0.c1023 tcontext=system_u:system_r:gnomeclock_t:s0-s0:c0.c1023 tclass=capability host=localhost type=SYSCALL msg=audit(1205003557.746:18): arch=40000003 syscall=3 success=yes exit=198 a0=9 a1=bf952768 a2=1000 a3=0 items=0 ppid=1 pid=2839 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="gnome-clock-app" exe="/usr/libexec/gnome-clock-applet-mechanism" subj=system_u:system_r:gnomeclock_t:s0-s0:c0.c1023 key=(null) Thanks in advance Regards, Antonio ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From olivares14031 at yahoo.com Sat Mar 8 19:25:06 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Sat, 8 Mar 2008 11:25:06 -0800 (PST) Subject: SELinux is preventing rsyslogd (syslogd_t) "read" to ./System.map-2.6.25-0.95.rc4.fc9 (system_map_t). Message-ID: <65600.98349.qm@web52611.mail.re2.yahoo.com> Dear all, Upon installing the updates of rawhide Report 20080308, I got the following from setroubleshooter. Suggestions/Comments are welcome. Regards, Antonio Summary: SELinux is preventing rsyslogd (syslogd_t) "read" to ./System.map-2.6.25-0.95.rc4.fc9 (system_map_t). Detailed Description: SELinux denied access requested by rsyslogd. It is not expected that this access is required by rsyslogd 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 ./System.map-2.6.25-0.95.rc4.fc9, restorecon -v './System.map-2.6.25-0.95.rc4.fc9' 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:syslogd_t Target Context system_u:object_r:system_map_t Target Objects ./System.map-2.6.25-0.95.rc4.fc9 [ file ] Source rsyslogd Source Path /sbin/rsyslogd Port Host localhost Source RPM Packages rsyslog-2.0.2-1.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-12.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name localhost Platform Linux localhost 2.6.25-0.95.rc4.fc9 #1 SMP Thu Mar 6 01:17:49 EST 2008 i686 athlon Alert Count 1 First Seen Sat 08 Mar 2008 07:58:10 AM CST Last Seen Sat 08 Mar 2008 07:58:10 AM CST Local ID b9ac46d0-bfde-485c-8cec-2547c11a4daf Line Numbers Raw Audit Messages host=localhost type=AVC msg=audit(1204984690.594:21): avc: denied { read } for pid=2913 comm="rsyslogd" name="System.map-2.6.25-0.95.rc4.fc9" dev=sda3 ino=6052 scontext=unconfined_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:system_map_t:s0 tclass=file host=localhost type=SYSCALL msg=audit(1204984690.594:21): arch=40000003 syscall=5 success=no exit=-13 a0=1357c0 a1=0 a2=1b6 a3=0 items=0 ppid=2912 pid=2913 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="rsyslogd" exe="/sbin/rsyslogd" subj=unconfined_u:system_r:syslogd_t:s0 key=(null) ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From olivares14031 at yahoo.com Sat Mar 8 19:42:53 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Sat, 8 Mar 2008 11:42:53 -0800 (PST) Subject: SELinux is preventing npviewer.bin (nsplugin_t) "write" to controlC0 (sound_device_t) Message-ID: <861425.73227.qm@web52607.mail.re2.yahoo.com> npviewer again, how to fix this. Thanks in Advance(TIA) Regards, Antonio Summary: SELinux is preventing npviewer.bin (nsplugin_t) "write" to controlC0 (sound_device_t). Detailed Description: SELinux denied access requested by npviewer.bin. It is not expected that this access is required by npviewer.bin 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 controlC0, restorecon -v 'controlC0' 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:unconfined_r:nsplugin_t:SystemLow- SystemHigh Target Context system_u:object_r:sound_device_t Target Objects controlC0 [ chr_file ] Source npviewer.bin Source Path /usr/lib/nspluginwrapper/npviewer.bin Port Host localhost Source RPM Packages nspluginwrapper-0.9.91.5-24.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-12.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name localhost Platform Linux localhost 2.6.25-0.95.rc4.fc9 #1 SMP Thu Mar 6 01:17:49 EST 2008 i686 athlon Alert Count 38 First Seen Sat 08 Mar 2008 01:14:52 PM CST Last Seen Sat 08 Mar 2008 01:14:53 PM CST Local ID 9114420d-3aef-41ef-beec-bea0499d79df Line Numbers Raw Audit Messages host=localhost type=AVC msg=audit(1205003693.102:60): avc: denied { write } for pid=2954 comm="npviewer.bin" name="controlC0" dev=tmpfs ino=5307 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sound_device_t:s0 tclass=chr_file host=localhost type=SYSCALL msg=audit(1205003693.102:60): arch=40000003 syscall=5 success=no exit=-13 a0=bfe512ea a1=2 a2=1e a3=2 items=0 ppid=2870 pid=2954 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="npviewer.bin" exe="/usr/lib/nspluginwrapper/npviewer.bin" subj=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 key=(null) ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From arequipeno at gmail.com Mon Mar 10 11:54:56 2008 From: arequipeno at gmail.com (Ian Pilcher) Date: Mon, 10 Mar 2008 06:54:56 -0500 Subject: Starting stunnel from xinetd Message-ID: Running fully updated Fedora 8, trying to start stunnel from xinetd, and getting a couple of denials: type=AVC msg=audit(1205149512.996:2338): avc: denied { write } for pid=14322 comm="stunnel" name="random_seed" dev=md1 ino=819429 scontext=unconfined_u:system_r:stunnel_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:stunnel_etc_t:s0 tclass=file type=AVC msg=audit(1205149512.998:2339): avc: denied { name_bind } for pid=14322 comm="stunnel" src=2873 scontext=unconfined_u:system_r:stunnel_t:s0-s0:c0.c1023 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket Aren't these things that stunnel should be expected to do? -- ======================================================================== Ian Pilcher arequipeno at gmail.com ======================================================================== From dwalsh at redhat.com Mon Mar 10 13:15:28 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 10 Mar 2008 09:15:28 -0400 Subject: SELinux is preventing rsyslogd (syslogd_t) "read" to ./System.map-2.6.25-0.95.rc4.fc9 (system_map_t). In-Reply-To: <65600.98349.qm@web52611.mail.re2.yahoo.com> References: <65600.98349.qm@web52611.mail.re2.yahoo.com> Message-ID: <47D53470.8070001@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Antonio Olivares wrote: > Dear all, > > Upon installing the updates of rawhide Report > 20080308, I got the following from setroubleshooter. > > Suggestions/Comments are welcome. > > Regards, > > Antonio > > > Summary: > > SELinux is preventing rsyslogd (syslogd_t) "read" to > ./System.map-2.6.25-0.95.rc4.fc9 (system_map_t). > > Detailed Description: > > SELinux denied access requested by rsyslogd. It is not > expected that this access > is required by rsyslogd 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 > ./System.map-2.6.25-0.95.rc4.fc9, > > restorecon -v './System.map-2.6.25-0.95.rc4.fc9' > > 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:syslogd_t > Target Context > system_u:object_r:system_map_t > Target Objects > ./System.map-2.6.25-0.95.rc4.fc9 [ file ] > Source rsyslogd > Source Path /sbin/rsyslogd > Port > Host localhost > Source RPM Packages rsyslog-2.0.2-1.fc9 > Target RPM Packages > Policy RPM > selinux-policy-3.3.1-12.fc9 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name catchall_file > Host Name localhost > Platform Linux localhost > 2.6.25-0.95.rc4.fc9 #1 SMP Thu Mar > 6 01:17:49 EST 2008 i686 > athlon > Alert Count 1 > First Seen Sat 08 Mar 2008 07:58:10 > AM CST > Last Seen Sat 08 Mar 2008 07:58:10 > AM CST > Local ID > b9ac46d0-bfde-485c-8cec-2547c11a4daf > Line Numbers > > Raw Audit Messages > > host=localhost type=AVC msg=audit(1204984690.594:21): > avc: denied { read } for pid=2913 comm="rsyslogd" > name="System.map-2.6.25-0.95.rc4.fc9" dev=sda3 > ino=6052 scontext=unconfined_u:system_r:syslogd_t:s0 > tcontext=system_u:object_r:system_map_t:s0 tclass=file > > host=localhost type=SYSCALL > msg=audit(1204984690.594:21): arch=40000003 syscall=5 > success=no exit=-13 a0=1357c0 a1=0 a2=1b6 a3=0 items=0 > ppid=2912 pid=2913 auid=500 uid=0 gid=0 euid=0 suid=0 > fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 > comm="rsyslogd" exe="/sbin/rsyslogd" > subj=unconfined_u:system_r:syslogd_t:s0 key=(null) > > > > > > ____________________________________________________________________________________ > Never miss a thing. Make Yahoo your home page. > http://www.yahoo.com/r/hs > Please report as a bug for rsyslog. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfVNHAACgkQrlYvE4MpobPC0ACfXzPTL4v72CXA0ACi1z+NATIt deUAn1JMk8xmNX6xVVRvSFNRRB5r+oBr =rkOM -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Mar 10 13:15:45 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 10 Mar 2008 09:15:45 -0400 Subject: SELinux is preventing npviewer.bin (nsplugin_t) "write" to controlC0 (sound_device_t) In-Reply-To: <861425.73227.qm@web52607.mail.re2.yahoo.com> References: <861425.73227.qm@web52607.mail.re2.yahoo.com> Message-ID: <47D53481.8090006@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Antonio Olivares wrote: > npviewer again, how to fix this. > > Thanks in Advance(TIA) > > Regards, > > Antonio > > Summary: > > SELinux is preventing npviewer.bin (nsplugin_t) > "write" to controlC0 > (sound_device_t). > > Detailed Description: > > SELinux denied access requested by npviewer.bin. It is > not expected that this > access is required by npviewer.bin 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 controlC0, > > restorecon -v 'controlC0' > > 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:unconfined_r:nsplugin_t:SystemLow- > SystemHigh > Target Context > system_u:object_r:sound_device_t > Target Objects controlC0 [ chr_file ] > Source npviewer.bin > Source Path > /usr/lib/nspluginwrapper/npviewer.bin > Port > Host localhost > Source RPM Packages > nspluginwrapper-0.9.91.5-24.fc9 > Target RPM Packages > Policy RPM > selinux-policy-3.3.1-12.fc9 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name catchall_file > Host Name localhost > Platform Linux localhost > 2.6.25-0.95.rc4.fc9 #1 SMP Thu Mar > 6 01:17:49 EST 2008 i686 > athlon > Alert Count 38 > First Seen Sat 08 Mar 2008 01:14:52 > PM CST > Last Seen Sat 08 Mar 2008 01:14:53 > PM CST > Local ID > 9114420d-3aef-41ef-beec-bea0499d79df > Line Numbers > > Raw Audit Messages > > host=localhost type=AVC msg=audit(1205003693.102:60): > avc: denied { write } for pid=2954 > comm="npviewer.bin" name="controlC0" dev=tmpfs > ino=5307 > scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:sound_device_t:s0 > tclass=chr_file > > host=localhost type=SYSCALL > msg=audit(1205003693.102:60): arch=40000003 syscall=5 > success=no exit=-13 a0=bfe512ea a1=2 a2=1e a3=2 > items=0 ppid=2870 pid=2954 auid=500 uid=500 gid=500 > euid=500 suid=500 fsuid=500 egid=500 sgid=500 > fsgid=500 tty=(none) ses=1 comm="npviewer.bin" > exe="/usr/lib/nspluginwrapper/npviewer.bin" > subj=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 > key=(null) > > > > > > ____________________________________________________________________________________ > Looking for last minute shopping deals? > Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping > I will fix tonight. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfVNIAACgkQrlYvE4MpobOOZwCfbK6d3U7SmNgvrnkOtA8miDoF UEUAn17+wdkfidxRvXtIsKDkr7qarEO0 =r9g4 -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Mar 10 13:23:01 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 10 Mar 2008 09:23:01 -0400 Subject: Starting stunnel from xinetd In-Reply-To: References: Message-ID: <47D53635.9070104@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ian Pilcher wrote: > Running fully updated Fedora 8, trying to start stunnel from xinetd, and > getting a couple of denials: > > type=AVC msg=audit(1205149512.996:2338): avc: denied { write } for > pid=14322 comm="stunnel" name="random_seed" dev=md1 ino=819429 > scontext=unconfined_u:system_r:stunnel_t:s0-s0:c0.c1023 > tcontext=unconfined_u:object_r:stunnel_etc_t:s0 tclass=file Confined apps writing to /etc is frowned upon. /etc/ should be considered R/O. If you move this file to /var/run/stunnel and change the config, it should work. > > type=AVC msg=audit(1205149512.998:2339): avc: denied { name_bind } for > pid=14322 comm="stunnel" src=2873 > scontext=unconfined_u:system_r:stunnel_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket > > Aren't these things that stunnel should be expected to do? > You have to define ports that stunnel can listen to. semanage port -a -t stunnel_port_t -P tcp 2873 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfVNjUACgkQrlYvE4MpobOHyACZAYtrw4H3PQOpzV+81lIlGj8c 0CsAn3LczPcZsMvsLbW5zZxdxEc+vqQg =gKTI -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Mar 10 13:27:04 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 10 Mar 2008 09:27:04 -0400 Subject: Bash script problem [OT] - Solved In-Reply-To: <20080308130130.GA9853@localhost.localdomain> References: <20080308092242.GA8249@localhost.localdomain> <20080308130130.GA9853@localhost.localdomain> Message-ID: <47D53728.9080806@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Arthur Dent wrote: > On Sat, Mar 08, 2008 at 09:22:42AM +0000, Arthur Dent wrote: >> I have no idea why this doesn't work - environment variables perhaps? >> > > Well, I managed to fix this. > > What I did was to set up an "at" job for the future (which worked) > and then look at all the environment variables for the at job. Then, one > by one I tried them in my script until it worked from cron. > > The line that did it was: > > ${SHELL:-/bin/sh} << `(dd if=/dev/urandom count=200 bs=12>/dev/null|LC_ALL=C tr -d -c '[:alnum:]')` > > I have no idea what it does (if anyone would care to explain it to me I > would be interested) but all I know is it works! > > Thanks to all... > > Mark > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list setroubleshoot can be setup on a headless box to send email. And there is an interface (named pipe) to audit system where you can receive AVC messages as they happen. Just look at the setroubleshoot code since it is using this. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfVNygACgkQrlYvE4MpobNGCwCfYKNX/z0fBGE6Kfh85XXi69iC WGwAnA53zsRS+punNWZ+G4ji50VaZ4hP =grFF -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Mar 10 13:37:15 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 10 Mar 2008 09:37:15 -0400 Subject: New AVCs with today's rawhide.... (mostly xdm related) In-Reply-To: <4c4ba1530803081007gb1fb3een53eb26f2d48cbe80@mail.gmail.com> References: <4c4ba1530803081007gb1fb3een53eb26f2d48cbe80@mail.gmail.com> Message-ID: <47D5398B.9010003@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom London wrote: > Running rawhide, targeted. > > Had problems after today's rawhide update. > > Booting in permissive mode produced: > > > module localxdm 1.0; > > require { > type unconfined_t; > type security_t; > type xdm_var_lib_t; > type syslogd_t; > type unconfined_execmem_t; > type xdm_xserver_t; > type system_map_t; > type mono_t; > type xdm_t; > type mount_t; > class unix_stream_socket { read write }; > class x_property read; > class security { check_context compute_create compute_av }; > class file { read write getattr }; > class dir { write read mounton }; > } > > #============= mono_t ============== > allow mono_t unconfined_t:x_property read; > > #============= mount_t ============== > allow mount_t xdm_t:unix_stream_socket { read write }; > allow mount_t xdm_var_lib_t:dir { write read mounton }; > > #============= syslogd_t ============== > allow syslogd_t system_map_t:file { read getattr }; > > #============= unconfined_execmem_t ============== > allow unconfined_execmem_t unconfined_t:x_property read; > allow unconfined_execmem_t xdm_t:x_property read; > > #============= xdm_t ============== > allow xdm_t xdm_var_lib_t:dir mounton; > > #============= xdm_xserver_t ============== > allow xdm_xserver_t security_t:dir read; > allow xdm_xserver_t security_t:file { write read }; > allow xdm_xserver_t security_t:security { check_context compute_create > compute_av }; > > I'll attach the raw audit file below. > > In addition, there were two avcs produced in /var/log/messages before > the start of audit: > > Mar 8 09:49:52 localhost kernel: type=1400 audit(1204998591.798:3): > avc: denied { read } for pid=2257 comm="rsyslogd" > name="System.map-2.6.25-0.95.rc4.local2.fc9" dev=sda3 ino=6064 > scontext=system_u:system_r:syslogd_t:s0 > tcontext=system_u:object_r:system_map_t:s0 tclass=file > Mar 8 09:49:52 localhost kernel: type=1400 audit(1204998591.798:4): > avc: denied { getattr } for pid=2257 comm="rsyslogd" > path="/boot/System.map-2.6.25-0.95.rc4.local2.fc9" dev=sda3 ino=6064 > scontext=system_u:system_r:syslogd_t:s0 > tcontext=system_u:object_r:system_map_t:s0 tclass=file > > Not sure all of these need to be "allow", but "semodule -i > localxdm.pp" makes the system boot and run in enforcing mode. > > tom > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Tom are you saying the machine would not boot in enforcing mode without these changes? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfVOYsACgkQrlYvE4MpobP0eQCfVP90HanVNvfhas765qu+r8L8 DzMAoOqM3MPP3FaV2jSfogLp+MI9xiMQ =1Zde -----END PGP SIGNATURE----- From selinux at gmail.com Mon Mar 10 14:04:27 2008 From: selinux at gmail.com (Tom London) Date: Mon, 10 Mar 2008 07:04:27 -0700 Subject: New AVCs with today's rawhide.... (mostly xdm related) In-Reply-To: <47D5398B.9010003@redhat.com> References: <4c4ba1530803081007gb1fb3een53eb26f2d48cbe80@mail.gmail.com> <47D5398B.9010003@redhat.com> Message-ID: <4c4ba1530803100704t4d3f7109o4f47a5acc06ce248@mail.gmail.com> On Mon, Mar 10, 2008 at 6:37 AM, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Tom London wrote: > > Running rawhide, targeted. > > > > Had problems after today's rawhide update. > > > > Booting in permissive mode produced: > > > > > > module localxdm 1.0; > > > > require { > > type unconfined_t; > > type security_t; > > type xdm_var_lib_t; > > type syslogd_t; > > type unconfined_execmem_t; > > type xdm_xserver_t; > > type system_map_t; > > type mono_t; > > type xdm_t; > > type mount_t; > > class unix_stream_socket { read write }; > > class x_property read; > > class security { check_context compute_create compute_av }; > > class file { read write getattr }; > > class dir { write read mounton }; > > } > > > > #============= mono_t ============== > > allow mono_t unconfined_t:x_property read; > > > > #============= mount_t ============== > > allow mount_t xdm_t:unix_stream_socket { read write }; > > allow mount_t xdm_var_lib_t:dir { write read mounton }; > > > > #============= syslogd_t ============== > > allow syslogd_t system_map_t:file { read getattr }; > > > > #============= unconfined_execmem_t ============== > > allow unconfined_execmem_t unconfined_t:x_property read; > > allow unconfined_execmem_t xdm_t:x_property read; > > > > #============= xdm_t ============== > > allow xdm_t xdm_var_lib_t:dir mounton; > > > > #============= xdm_xserver_t ============== > > allow xdm_xserver_t security_t:dir read; > > allow xdm_xserver_t security_t:file { write read }; > > allow xdm_xserver_t security_t:security { check_context compute_create > > compute_av }; > > > > I'll attach the raw audit file below. > > > > In addition, there were two avcs produced in /var/log/messages before > > the start of audit: > > > > Mar 8 09:49:52 localhost kernel: type=1400 audit(1204998591.798:3): > > avc: denied { read } for pid=2257 comm="rsyslogd" > > name="System.map-2.6.25-0.95.rc4.local2.fc9" dev=sda3 ino=6064 > > scontext=system_u:system_r:syslogd_t:s0 > > tcontext=system_u:object_r:system_map_t:s0 tclass=file > > Mar 8 09:49:52 localhost kernel: type=1400 audit(1204998591.798:4): > > avc: denied { getattr } for pid=2257 comm="rsyslogd" > > path="/boot/System.map-2.6.25-0.95.rc4.local2.fc9" dev=sda3 ino=6064 > > scontext=system_u:system_r:syslogd_t:s0 > > tcontext=system_u:object_r:system_map_t:s0 tclass=file > > > > Not sure all of these need to be "allow", but "semodule -i > > localxdm.pp" makes the system boot and run in enforcing mode. > > > > tom > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Tom are you saying the machine would not boot in enforcing mode without > these changes? Uhhh.... please ignore the above. Not sure I understand, but except for the syslog_t ones, I no longer get these AVC when booting in enforcing. All is fine. Sorry for the false report. tom -- Tom London From paul at city-fan.org Mon Mar 10 14:15:53 2008 From: paul at city-fan.org (Paul Howarth) Date: Mon, 10 Mar 2008 14:15:53 +0000 Subject: getting denials when run from init script but not from command-line In-Reply-To: <47D01F68.4010904@gmail.com> References: <47CF2E12.10008@gmail.com> <47CFB4C5.1010208@city-fan.org> <47D01F68.4010904@gmail.com> Message-ID: <47D54299.205@city-fan.org> Johnny Tan wrote: > Paul Howarth wrote: >> Johnny Tan wrote: >>> I took the Fedora-8 SRPM for rsyslog 2.0.2 and rebuilt it for >>> CentOS-5 x86_64. After doing: >>> >>> # semanage fcontext -a -t syslogd_exec_t /sbin/rsyslogd >>> # semanage fcontext -a -t klogd_exec_t /sbin/rklogd >>> >>> I can do "service rsyslog start" and it works. >>> >>> >>> Then, I did the rebuild for rsyslog version 3.11.6. Had to tweak the >>> spec and conf files a bit, but got it packaged and installed. And >>> made sure the above contexts were retained (they were). >>> >>> However, when I go to run it "service rsyslog start" using the same >>> init script that worked with the 2.0.2 version, I get this: >>> >>> == >>> type=SYSCALL msg=audit(03/05/2008 17:43:26.966:224) : arch=x86_64 >>> syscall=bind success=yes exit=0 a0=1 a1=51b2ae0 a2=10 a3=7fffa9e3f63c >>> items=0 ppid=29717 pid=29718 auid=root uid=root gid=root euid=root >>> suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) >>> comm=rsyslogd exe=/sbin/rsyslogd subj=root:system_r:syslogd_t:s0 >>> key=(null) >>> type=AVC msg=audit(03/05/2008 17:43:26.966:224) : avc: denied { >>> node_bind } for pid=29718 comm=rsyslogd src=61514 >>> scontext=root:system_r:syslogd_t:s0 >>> tcontext=system_u:object_r:inaddr_any_node_t:s0 tclass=tcp_socket >>> == >>> >>> >>> BUT, when I run it directly from the command-line: >>> /sbin/rsyslogd >>> I do NOT get those denials. >>> >>> I know how to create the module to allow the above, but what I'm more >>> interested in is what allows me to run it from the command-line but >>> not from the init script. >>> >>> The line that starts the rsyslogd in the init script is: >>> daemon rsyslogd $SYSLOGD_OPTIONS >>> ("daemon" being a function sourced from /etc/init.d/functions) >>> >>> But even if I replace that line with a simple: >>> /sbin/rsyslogd >>> it still gives me the denials. >>> >>> >>> Anyone have ideas why? I don't want to just create the module and >>> sweep this under the rug. >> >> This is normal behaviour for confined daemons (those that policy has >> been written for); they transition to their own domain (syslogd_t in >> this case) and are confined to that domain when run from the >> initscript but don't transition and run unconfined if you start them >> directly from the command line. > > Thanks Paul. I guess what got me is that version 2.0.2 did not exhibit > this behavior, even when ran from the *same* init script. Shouldn't it > also have been confined and, hence, generate the same AVC denials? My guess is that this is new behaviour in 3.11.6 that wasn't there in 2.0.2, and hence no denials for the old version. > Secondly, so I guess if this is "normal" behavior, then I *should* be > creating and loading the module to allow the tcp_socket connect that's > currently being denied for the v3.11.6 daemon. Correct? I would say so, though I'd check the documentation for the new version to see what it's actually doing with this socket. Paul. From dwalsh at redhat.com Mon Mar 10 15:00:25 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 10 Mar 2008 11:00:25 -0400 Subject: New AVCs with today's rawhide.... (mostly xdm related) In-Reply-To: <4c4ba1530803100704t4d3f7109o4f47a5acc06ce248@mail.gmail.com> References: <4c4ba1530803081007gb1fb3een53eb26f2d48cbe80@mail.gmail.com> <47D5398B.9010003@redhat.com> <4c4ba1530803100704t4d3f7109o4f47a5acc06ce248@mail.gmail.com> Message-ID: <47D54D09.4060205@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom London wrote: > On Mon, Mar 10, 2008 at 6:37 AM, Daniel J Walsh wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> >> Tom London wrote: >> > Running rawhide, targeted. >> > >> > Had problems after today's rawhide update. >> > >> > Booting in permissive mode produced: >> > >> > >> > module localxdm 1.0; >> > >> > require { >> > type unconfined_t; >> > type security_t; >> > type xdm_var_lib_t; >> > type syslogd_t; >> > type unconfined_execmem_t; >> > type xdm_xserver_t; >> > type system_map_t; >> > type mono_t; >> > type xdm_t; >> > type mount_t; >> > class unix_stream_socket { read write }; >> > class x_property read; >> > class security { check_context compute_create compute_av }; >> > class file { read write getattr }; >> > class dir { write read mounton }; >> > } >> > >> > #============= mono_t ============== >> > allow mono_t unconfined_t:x_property read; >> > >> > #============= mount_t ============== >> > allow mount_t xdm_t:unix_stream_socket { read write }; >> > allow mount_t xdm_var_lib_t:dir { write read mounton }; >> > >> > #============= syslogd_t ============== >> > allow syslogd_t system_map_t:file { read getattr }; >> > >> > #============= unconfined_execmem_t ============== >> > allow unconfined_execmem_t unconfined_t:x_property read; >> > allow unconfined_execmem_t xdm_t:x_property read; >> > >> > #============= xdm_t ============== >> > allow xdm_t xdm_var_lib_t:dir mounton; >> > >> > #============= xdm_xserver_t ============== >> > allow xdm_xserver_t security_t:dir read; >> > allow xdm_xserver_t security_t:file { write read }; >> > allow xdm_xserver_t security_t:security { check_context compute_create >> > compute_av }; >> > >> > I'll attach the raw audit file below. >> > >> > In addition, there were two avcs produced in /var/log/messages before >> > the start of audit: >> > >> > Mar 8 09:49:52 localhost kernel: type=1400 audit(1204998591.798:3): >> > avc: denied { read } for pid=2257 comm="rsyslogd" >> > name="System.map-2.6.25-0.95.rc4.local2.fc9" dev=sda3 ino=6064 >> > scontext=system_u:system_r:syslogd_t:s0 >> > tcontext=system_u:object_r:system_map_t:s0 tclass=file >> > Mar 8 09:49:52 localhost kernel: type=1400 audit(1204998591.798:4): >> > avc: denied { getattr } for pid=2257 comm="rsyslogd" >> > path="/boot/System.map-2.6.25-0.95.rc4.local2.fc9" dev=sda3 ino=6064 >> > scontext=system_u:system_r:syslogd_t:s0 >> > tcontext=system_u:object_r:system_map_t:s0 tclass=file >> > >> > Not sure all of these need to be "allow", but "semodule -i >> > localxdm.pp" makes the system boot and run in enforcing mode. >> > >> > tom >> > >> > >> > >> > ------------------------------------------------------------------------ >> > >> > -- >> > fedora-selinux-list mailing list >> > fedora-selinux-list at redhat.com >> > https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> Tom are you saying the machine would not boot in enforcing mode without >> these changes? > > Uhhh.... please ignore the above. > > Not sure I understand, but except for the syslog_t ones, I no longer > get these AVC when booting in enforcing. All is fine. > > Sorry for the false report. > > tom > > No the X ones are being caused by booting in permissive mode. The system attempts to turn on X Controls, where as they are denied without a boolean setting in enforcing. getsebool xserver_object_manager I am not sure whether the syslog_t one is a bug or does it really need that access. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfVTQkACgkQrlYvE4MpobMVdQCg1Woz7b3eZ19AjmHC3BJ9WYbV mzgAnjjhNJ7eRsIT7F4OyAh5UEM+asSP =Z/5b -----END PGP SIGNATURE----- From selinux at gmail.com Mon Mar 10 15:06:55 2008 From: selinux at gmail.com (Tom London) Date: Mon, 10 Mar 2008 08:06:55 -0700 Subject: New AVCs with today's rawhide.... (mostly xdm related) In-Reply-To: <47D54D09.4060205@redhat.com> References: <4c4ba1530803081007gb1fb3een53eb26f2d48cbe80@mail.gmail.com> <47D5398B.9010003@redhat.com> <4c4ba1530803100704t4d3f7109o4f47a5acc06ce248@mail.gmail.com> <47D54D09.4060205@redhat.com> Message-ID: <4c4ba1530803100806l7d07a1fcpe75f5a6784bc480e@mail.gmail.com> On Mon, Mar 10, 2008 at 8:00 AM, Daniel J Walsh wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Tom London wrote: > > On Mon, Mar 10, 2008 at 6:37 AM, Daniel J Walsh wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> > >> > >> Tom London wrote: > >> > Running rawhide, targeted. > >> > > >> > Had problems after today's rawhide update. > >> > > >> > Booting in permissive mode produced: > >> > > >> > > >> > module localxdm 1.0; > >> > > >> > require { > >> > type unconfined_t; > >> > type security_t; > >> > type xdm_var_lib_t; > >> > type syslogd_t; > >> > type unconfined_execmem_t; > >> > type xdm_xserver_t; > >> > type system_map_t; > >> > type mono_t; > >> > type xdm_t; > >> > type mount_t; > >> > class unix_stream_socket { read write }; > >> > class x_property read; > >> > class security { check_context compute_create compute_av }; > >> > class file { read write getattr }; > >> > class dir { write read mounton }; > >> > } > >> > > >> > #============= mono_t ============== > >> > allow mono_t unconfined_t:x_property read; > >> > > >> > #============= mount_t ============== > >> > allow mount_t xdm_t:unix_stream_socket { read write }; > >> > allow mount_t xdm_var_lib_t:dir { write read mounton }; > >> > > >> > #============= syslogd_t ============== > >> > allow syslogd_t system_map_t:file { read getattr }; > >> > > >> > #============= unconfined_execmem_t ============== > >> > allow unconfined_execmem_t unconfined_t:x_property read; > >> > allow unconfined_execmem_t xdm_t:x_property read; > >> > > >> > #============= xdm_t ============== > >> > allow xdm_t xdm_var_lib_t:dir mounton; > >> > > >> > #============= xdm_xserver_t ============== > >> > allow xdm_xserver_t security_t:dir read; > >> > allow xdm_xserver_t security_t:file { write read }; > >> > allow xdm_xserver_t security_t:security { check_context compute_create > >> > compute_av }; > >> > > >> > I'll attach the raw audit file below. > >> > > >> > In addition, there were two avcs produced in /var/log/messages before > >> > the start of audit: > >> > > >> > Mar 8 09:49:52 localhost kernel: type=1400 audit(1204998591.798:3): > >> > avc: denied { read } for pid=2257 comm="rsyslogd" > >> > name="System.map-2.6.25-0.95.rc4.local2.fc9" dev=sda3 ino=6064 > >> > scontext=system_u:system_r:syslogd_t:s0 > >> > tcontext=system_u:object_r:system_map_t:s0 tclass=file > >> > Mar 8 09:49:52 localhost kernel: type=1400 audit(1204998591.798:4): > >> > avc: denied { getattr } for pid=2257 comm="rsyslogd" > >> > path="/boot/System.map-2.6.25-0.95.rc4.local2.fc9" dev=sda3 ino=6064 > >> > scontext=system_u:system_r:syslogd_t:s0 > >> > tcontext=system_u:object_r:system_map_t:s0 tclass=file > >> > > >> > Not sure all of these need to be "allow", but "semodule -i > >> > localxdm.pp" makes the system boot and run in enforcing mode. > >> > > >> > tom > >> > > >> > > >> > > >> > ------------------------------------------------------------------------ > >> > > >> > -- > >> > fedora-selinux-list mailing list > >> > fedora-selinux-list at redhat.com > >> > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > >> Tom are you saying the machine would not boot in enforcing mode without > >> these changes? > > > > Uhhh.... please ignore the above. > > > > Not sure I understand, but except for the syslog_t ones, I no longer > > get these AVC when booting in enforcing. All is fine. > > > > Sorry for the false report. > > > > tom > > > > > No the X ones are being caused by booting in permissive mode. The > system attempts to turn on X Controls, where as they are denied without > a boolean setting in enforcing. > > getsebool xserver_object_manager > > I am not sure whether the syslog_t one is a bug or does it really need > that access. > I'm booting/running with that access denied (at least the read one, only seem to get the getattr one in permissive mode). I did have one "funny enforcing reboot" just after the last update to syslog where a bunch of service croaked on startup (got ptrace AVCs from gdb, I think). I then rebooted in permissive and got the whole lot above (with all the services starting OK). I cannot reproduce the "funny reboot". Must be bad karma.... tom -- Tom London From arequipeno at gmail.com Mon Mar 10 22:37:53 2008 From: arequipeno at gmail.com (Ian Pilcher) Date: Mon, 10 Mar 2008 17:37:53 -0500 Subject: Starting stunnel from xinetd In-Reply-To: <47D53635.9070104@redhat.com> References: <47D53635.9070104@redhat.com> Message-ID: Daniel J Walsh wrote: > Confined apps writing to /etc is frowned upon. /etc/ should be > considered R/O. If you move this file to /var/run/stunnel and change > the config, it should work. Nope. type=AVC msg=audit(1205188277.824:2538): avc: denied { getattr } for pid=1696 comm="stunnel" path="/var/run/stunnel/random_seed" dev=md1 ino=36907 scontext=unconfined_u:system_r:stunnel_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=file (And shouldn't it really go under /var/lib/stunnel, since it's supposed to survive a reboot?) > You have to define ports that stunnel can listen to. > > semanage port -a -t stunnel_port_t -P tcp 2873 OK, that got me past the bind denial. Unfortunately, it looks like stunnel isn't allowed to access /usr/bin, so it can't start the rsync daemon: type=AVC msg=audit(1205188277.890:2539): avc: denied { search } for pid=1698 comm="stunnel" name="bin" dev=md1 ino=2686986 scontext=unconfined_u:system_r:stunnel_t:s0-s0:c0.c1023 tcontext=system_u:object_r:bin_t:s0 tclass=dir Thanks! -- ======================================================================== Ian Pilcher arequipeno at gmail.com ======================================================================== From olivares14031 at yahoo.com Mon Mar 10 23:50:41 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Mon, 10 Mar 2008 16:50:41 -0700 (PDT) Subject: SELinux is preventing rsyslogd (syslogd_t) "read" to ./System.map-2.6.25-0.95.rc4.fc9 (system_map_t). In-Reply-To: <47D53470.8070001@redhat.com> Message-ID: <614212.2743.qm@web52607.mail.re2.yahoo.com> --- Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Antonio Olivares wrote: > > Dear all, > > > > Upon installing the updates of rawhide Report > > 20080308, I got the following from > setroubleshooter. > > > > Suggestions/Comments are welcome. > > > > Regards, > > > > Antonio > > > > > > Summary: > > > > SELinux is preventing rsyslogd (syslogd_t) "read" > to > > ./System.map-2.6.25-0.95.rc4.fc9 (system_map_t). > > > > Detailed Description: > > > > SELinux denied access requested by rsyslogd. It is > not > > expected that this access > > is required by rsyslogd 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 > > ./System.map-2.6.25-0.95.rc4.fc9, > > > > restorecon -v './System.map-2.6.25-0.95.rc4.fc9' > > > > 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:syslogd_t > > Target Context > > system_u:object_r:system_map_t > > Target Objects > > ./System.map-2.6.25-0.95.rc4.fc9 [ file ] > > Source rsyslogd > > Source Path /sbin/rsyslogd > > Port > > Host localhost > > Source RPM Packages rsyslog-2.0.2-1.fc9 > > Target RPM Packages > > Policy RPM > > selinux-policy-3.3.1-12.fc9 > > Selinux Enabled True > > Policy Type targeted > > MLS Enabled True > > Enforcing Mode Enforcing > > Plugin Name catchall_file > > Host Name localhost > > Platform Linux localhost > > 2.6.25-0.95.rc4.fc9 #1 SMP Thu Mar > > 6 01:17:49 EST 2008 > i686 > > athlon > > Alert Count 1 > > First Seen Sat 08 Mar 2008 > 07:58:10 > > AM CST > > Last Seen Sat 08 Mar 2008 > 07:58:10 > > AM CST > > Local ID > > b9ac46d0-bfde-485c-8cec-2547c11a4daf > > Line Numbers > > > > Raw Audit Messages > > > > host=localhost type=AVC > msg=audit(1204984690.594:21): > > avc: denied { read } for pid=2913 > comm="rsyslogd" > > name="System.map-2.6.25-0.95.rc4.fc9" dev=sda3 > > ino=6052 > scontext=unconfined_u:system_r:syslogd_t:s0 > > tcontext=system_u:object_r:system_map_t:s0 > tclass=file > > > > host=localhost type=SYSCALL > > msg=audit(1204984690.594:21): arch=40000003 > syscall=5 > > success=no exit=-13 a0=1357c0 a1=0 a2=1b6 a3=0 > items=0 > > ppid=2912 pid=2913 auid=500 uid=0 gid=0 euid=0 > suid=0 > > fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 > > comm="rsyslogd" exe="/sbin/rsyslogd" > > subj=unconfined_u:system_r:syslogd_t:s0 key=(null) > > > > > > > > > > > > > ____________________________________________________________________________________ > > Never miss a thing. Make Yahoo your home page. > > http://www.yahoo.com/r/hs > > > Please report as a bug for rsyslog. Done! :) https://bugzilla.redhat.com/show_bug.cgi?id=436895 Regards. Antonio > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (GNU/Linux) > Comment: Using GnuPG with Fedora - > http://enigmail.mozdev.org > > iEYEARECAAYFAkfVNHAACgkQrlYvE4MpobPC0ACfXzPTL4v72CXA0ACi1z+NATIt > deUAn1JMk8xmNX6xVVRvSFNRRB5r+oBr > =rkOM > -----END PGP SIGNATURE----- > > -- > fedora-test-list mailing list > fedora-test-list at redhat.com > To unsubscribe: > https://www.redhat.com/mailman/listinfo/fedora-test-list > ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From selinux.list at troodos.demon.co.uk Tue Mar 11 12:05:17 2008 From: selinux.list at troodos.demon.co.uk (Arthur Dent) Date: Tue, 11 Mar 2008 12:05:17 +0000 Subject: Bash script problem [OT] - Solved In-Reply-To: <47D53728.9080806@redhat.com> References: <20080308092242.GA8249@localhost.localdomain> <20080308130130.GA9853@localhost.localdomain> <47D53728.9080806@redhat.com> Message-ID: <20080311120516.GA16674@troodos.org.uk> On Mon, Mar 10, 2008 at 09:27:04AM -0400, Daniel J Walsh wrote: > setroubleshoot can be setup on a headless box to send email. And there > is an interface (named pipe) to audit system where you can receive AVC > messages as they happen. Just look at the setroubleshoot code since it > is using this. Ooooo. That sounds interesting. I'm all for not re-inventing the wheel. Thing is, I looked at man sealert and I couldn't see how to do this. I am not much of a hacker, so looking at the code would probably not help me too much. Is there a configuration setting I can set somewhere? Thanks Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From valent.turkovic at gmail.com Tue Mar 11 12:13:11 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 11 Mar 2008 13:13:11 +0100 Subject: here a few issues I have Message-ID: <64b14b300803110513x5f009124m23eefaed4cb1cd6a@mail.gmail.com> Here are few issues I have in my selinux troubleshooter. I have tested wicd wireless manager instead of NM and that got selinux in a full alert mode... please check out fedora devel mailing for links to wich packages because they aren't still in fedora repositories. Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: updatedb_selinux_alert_01.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: updatedb_selinux_alert_02.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: selinux_alert_wicd_01.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: selinux_alert_wicd_02.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: selinux_alert_wicd_03.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: selinux_alert_wicd_04.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: selinux_alert_wicd_05.txt URL: From dwalsh at redhat.com Wed Mar 12 00:56:54 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 11 Mar 2008 20:56:54 -0400 Subject: here a few issues I have In-Reply-To: <64b14b300803110513x5f009124m23eefaed4cb1cd6a@mail.gmail.com> References: <64b14b300803110513x5f009124m23eefaed4cb1cd6a@mail.gmail.com> Message-ID: <47D72A56.3050008@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Valent Turkovic wrote: > Here are few issues I have in my selinux troubleshooter. > > I have tested wicd wireless manager instead of NM and that got selinux > in a full alert mode... please check out fedora devel mailing for > links to wich packages because they aren't still in fedora > repositories. > > Valent. > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list I will fix the fusefs in rawhide. The other ones have to be fixed via a dontaudit in a local policy module. You might want to convince wicd to put their log files in a more conventional location. The confined domains are having their stdout redirected to a file labeled usr_t. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfXKlYACgkQrlYvE4MpobP6dwCfdF0X0sRWrWGTr/8inxiuz2Dv ns4An2irw4s6FP3tXYdCl5RimRsjD5uX =hQ0o -----END PGP SIGNATURE----- From ttaylor at mitre.org Fri Mar 14 23:11:42 2008 From: ttaylor at mitre.org (ttaylor) Date: Fri, 14 Mar 2008 16:11:42 -0700 (PDT) Subject: Question on semanage fcontext -a Message-ID: <16058319.post@talk.nabble.com> Does anything special have to be done to cause SELinux to start using newly added local filecontexts? What I'm finding is that if I use semanage fcontext -a to add a local filecontext definition, it is not used by restorecon unless I specify the "-F" option. Without the "-F" option, restorecon -vv gives the following message: /sbin/restorecon: not reset customized by admin to but restorecon -vv -F gives this: /sbin/restorecon reset context -> I've also tried using /usr/sbin/semodule --build to try rebuilding (and reloading) the current policy, but that didn't change the behavior I'm seeing. Any suggestions would be greatly appreciated. - Tim -- View this message in context: http://www.nabble.com/Question-on-semanage-fcontext--a-tp15240526p16058319.html Sent from the Fedora SELinux List mailing list archive at Nabble.com. From selinux.list at troodos.demon.co.uk Sun Mar 16 18:55:44 2008 From: selinux.list at troodos.demon.co.uk (Arthur Dent) Date: Sun, 16 Mar 2008 18:55:44 +0000 Subject: Bash script problem [OT] - Solved In-Reply-To: <47D72AA3.8030502@redhat.com> References: <20080308092242.GA8249@localhost.localdomain> <20080308130130.GA9853@localhost.localdomain> <47D53728.9080806@redhat.com> <20080311120516.GA16674@troodos.org.uk> <47D72AA3.8030502@redhat.com> Message-ID: <20080316185544.GA4344@localhost.localdomain> On Tue, Mar 11, 2008 at 08:58:11PM -0400, Daniel J Walsh wrote: > > Arthur Dent wrote: > > On Mon, Mar 10, 2008 at 09:27:04AM -0400, Daniel J Walsh wrote: > >> setroubleshoot can be setup on a headless box to send email. And there > >> is an interface (named pipe) to audit system where you can receive AVC > >> messages as they happen. Just look at the setroubleshoot code since it > >> is using this. > > > > Ooooo. That sounds interesting. I'm all for not re-inventing the wheel. Thing > > is, I looked at man sealert and I couldn't see how to do this. I am not much > > of a hacker, so looking at the code would probably not help me too much. > > > > Is there a configuration setting I can set somewhere? > > > > Thanks > > > > Mark > > > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > vi /etc/setroubleshoot/setroubleshoot.cfg > > And search for email. Hi, Apologies for slow response. Thanks ever so much for this. Just what I was looking for! Just one small thing... When I tried this, editing /etc/setroubleshoot/setroubleshoot.cfg and creating a file /var/lib/setroubleshoot/email_alert_recipients it didn't work. I looked at this wiki entry http://fedoraproject.org/wiki/Docs/Drafts/SELinux/SETroubleShoot/UserFAQ#email-alerts and it said essentially exactly the same thing. It also said that that I could use the sealert GUI to set the mailing settings, so I SSH'd into my serving using a forwarded X server and tried that. It worked! The strange thing is that the wiki says that the GUI method simply modifies the same file (which makes sense), but I used a different email address and the old email address (which doesn't work) is still in that file with no sign of the new one (which works!). Ho hum... I suppose I goofed somewhere along the line. I'll look into it with a little more care when I get the chance. In the meantime, the important thing is it works! Thanks again, your help is greatly appreciated. Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From valent.turkovic at gmail.com Mon Mar 17 08:30:23 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Mon, 17 Mar 2008 09:30:23 +0100 Subject: firefox alert Message-ID: <64b14b300803170130o39a81779rf6fdb363f418f4de@mail.gmail.com> I opened http://jkeating.livejournal.com/56521.html in new tab and I got this alert. Any ideas why? Cheers, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: firefox_selinux_alert.txt URL: From valent.turkovic at gmail.com Mon Mar 17 09:18:37 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Mon, 17 Mar 2008 10:18:37 +0100 Subject: updatedb alert Message-ID: <64b14b300803170218r4f48cd2dj173fa129cc58f39b@mail.gmail.com> Here a few alerts I got when updatedb got started by cron. Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: updatedb_06_selinux_alert.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: updatedb_05_selinux_alert.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: updatedb_04_selinux_alert.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: updatedb_03_selinux_alert.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: updatedb_02_selinux_alert.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: updatedb_01_selinux_alert.txt URL: From lordmorgul at gmail.com Mon Mar 17 10:14:26 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Mon, 17 Mar 2008 03:14:26 -0700 Subject: rawhide yum denied for transition bootloader_t, two alerts Message-ID: <8b14d9940803170314p5a4f9bdm243bc461ab6ee8ea@mail.gmail.com> These happen on two machines during updates, I'm also noticing many %post scriptlets failing when these pop up, though I don't know if they are related or not. Summary: SELinux is preventing yum (bootloader_t) "transition" to /sbin/ldconfig (rpm_script_t). Detailed Description: SELinux denied access requested by yum. It is not expected that this access is required by yum 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 user_u:system_r:bootloader_t:s0 Target Context user_u:system_r:rpm_script_t:s0 Target Objects /sbin/ldconfig [ process ] Source yum Source Path /usr/bin/python Port Host durthangnix Source RPM Packages python-2.5.1-23.fc9 Target RPM Packages glibc-2.7.90-9 Policy RPM selinux-policy-3.3.1-14.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name durthangnix Platform Linux durthangnix 2.6.25-0.105.rc5.fc9 #1 SMP Mon Mar 10 20:59:23 EDT 2008 x86_64 x86_64 Alert Count 35 First Seen Thu 13 Mar 2008 11:19:15 PM PDT Last Seen Thu 13 Mar 2008 11:32:48 PM PDT Local ID 36d70abc-d12d-42f2-96bf-ab7250e29da1 Line Numbers Raw Audit Messages host=durthangnix type=AVC msg=audit(1205476368.460:1339): avc: denied { transition } for pid=28100 comm="yum" path="/sbin/ldconfig" dev=sda3 ino=858775 scontext=user_u:system_r:bootloader_t:s0 tcontext=user_u:system_r:rpm_script_t:s0 tclass=process host=durthangnix type=SYSCALL msg=audit(1205476368.460:1339): arch=c000003e syscall=59 success=no exit=-13 a0=7ff2034c2aca a1=7fff1bd22350 a2=7ff20aa927d0 a3=3b8896c9f0 items=0 ppid=27144 pid=28100 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=4 comm="yum" exe="/usr/bin/python" subj=user_u:system_r:bootloader_t:s0 key=(null) Summary: SELinux is preventing yum (bootloader_t) "transition" to /bin/bash (rpm_script_t). Detailed Description: SELinux denied access requested by yum. It is not expected that this access is required by yum 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 user_u:system_r:bootloader_t:s0 Target Context user_u:system_r:rpm_script_t:s0 Target Objects /bin/bash [ process ] Source rpm Source Path /bin/rpm Port Host durthangnix Source RPM Packages python-2.5.1-23.fc9 Target RPM Packages bash-3.2-21.fc9 Policy RPM selinux-policy-3.3.1-14.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name durthangnix Platform Linux durthangnix 2.6.25-0.105.rc5.fc9 #1 SMP Mon Mar 10 20:59:23 EDT 2008 x86_64 x86_64 Alert Count 48 First Seen Thu 13 Mar 2008 10:00:05 AM PDT Last Seen Thu 13 Mar 2008 11:32:48 PM PDT Local ID 75a34bf7-d467-444b-bfb4-9a931b3af238 Line Numbers Raw Audit Messages host=durthangnix type=AVC msg=audit(1205476368.64:1338): avc: denied { transition } for pid=28099 comm="yum" path="/bin/bash" dev=sda3 ino=835647 scontext=user_u:system_r:bootloader_t:s0 tcontext=user_u:system_r:rpm_script_t:s0 tclass=process host=durthangnix type=SYSCALL msg=audit(1205476368.64:1338): arch=c000003e syscall=59 success=no exit=-13 a0=7ff20063e90d a1=7fff1bd22350 a2=7ff20aa927d0 a3=3b8896c9f0 items=0 ppid=27144 pid=28099 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=4 comm="yum" exe="/usr/bin/python" subj=user_u:system_r:bootloader_t:s0 key=(null) -- -- Andrew Farris www.lordmorgul.net gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From paul at city-fan.org Mon Mar 17 11:31:05 2008 From: paul at city-fan.org (Paul Howarth) Date: Mon, 17 Mar 2008 11:31:05 +0000 Subject: Question on semanage fcontext -a In-Reply-To: <16058319.post@talk.nabble.com> References: <16058319.post@talk.nabble.com> Message-ID: <47DE5679.9060807@city-fan.org> ttaylor wrote: > Does anything special have to be done to cause SELinux to start using newly > added local filecontexts? What I'm finding is that if I use semanage > fcontext -a to add a local filecontext definition, it is not used by > restorecon unless I specify the "-F" option. Without the "-F" option, > restorecon -vv gives the following message: > > /sbin/restorecon: not reset customized by admin to > > > but restorecon -vv -F gives this: > > /sbin/restorecon reset context -> This is probably because is a customizable type like httpd_sys_content_t; objects with these types don't get reset by restorecon unless you use -F. I'm not sure how to find out which types are customizable off the top of my head though. Paul. From jkubin at redhat.com Mon Mar 17 11:25:43 2008 From: jkubin at redhat.com (Josef Kubin) Date: Mon, 17 Mar 2008 12:25:43 +0100 Subject: updatedb alert In-Reply-To: <64b14b300803170218r4f48cd2dj173fa129cc58f39b@mail.gmail.com> References: <64b14b300803170218r4f48cd2dj173fa129cc58f39b@mail.gmail.com> Message-ID: <47DE5537.3060504@redhat.com> It's labeling problem, maybe you have played with `# semodule -r module` , try to run: # restorecon -v /usr/bin/updatedb OR # fixfiles relabel OR # touch /.autorelabel; reboot Josef Valent Turkovic wrote: > Here a few alerts I got when updatedb got started by cron. > > Valent. > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From jkubin at redhat.com Mon Mar 17 11:29:55 2008 From: jkubin at redhat.com (Josef Kubin) Date: Mon, 17 Mar 2008 12:29:55 +0100 Subject: firefox alert In-Reply-To: <64b14b300803170130o39a81779rf6fdb363f418f4de@mail.gmail.com> References: <64b14b300803170130o39a81779rf6fdb363f418f4de@mail.gmail.com> Message-ID: <47DE5633.4030700@redhat.com> Relabel your system. Cheers, Josef. From sds at tycho.nsa.gov Mon Mar 17 12:07:03 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 17 Mar 2008 08:07:03 -0400 Subject: Question on semanage fcontext -a In-Reply-To: <47DE5679.9060807@city-fan.org> References: <16058319.post@talk.nabble.com> <47DE5679.9060807@city-fan.org> Message-ID: <1205755623.22912.116.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2008-03-17 at 11:31 +0000, Paul Howarth wrote: > ttaylor wrote: > > Does anything special have to be done to cause SELinux to start using newly > > added local filecontexts? What I'm finding is that if I use semanage > > fcontext -a to add a local filecontext definition, it is not used by > > restorecon unless I specify the "-F" option. Without the "-F" option, > > restorecon -vv gives the following message: > > > > /sbin/restorecon: not reset customized by admin to > > > > > > but restorecon -vv -F gives this: > > > > /sbin/restorecon reset context -> > > This is probably because is a customizable type like > httpd_sys_content_t; objects with these types don't get reset by > restorecon unless you use -F. I'm not sure how to find out which types > are customizable off the top of my head though. cat /etc/selinux/$SELINUXTYPE/contexts/customizable_types Dan - I thought we had discussed reducing that set significantly since it was originally to avoid clobbering locally-set types upon a filesystem relabel prior to the introduction of semanage, but with users now able to add local file contexts easily via semanage fcontext -a, it isn't as necessary. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Mon Mar 17 14:14:54 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 17 Mar 2008 10:14:54 -0400 Subject: Question on semanage fcontext -a In-Reply-To: <16058319.post@talk.nabble.com> References: <16058319.post@talk.nabble.com> Message-ID: <47DE7CDE.8020701@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ttaylor wrote: > Does anything special have to be done to cause SELinux to start using newly > added local filecontexts? What I'm finding is that if I use semanage > fcontext -a to add a local filecontext definition, it is not used by > restorecon unless I specify the "-F" option. Without the "-F" option, > restorecon -vv gives the following message: > > /sbin/restorecon: not reset customized by admin to > > > but restorecon -vv -F gives this: > > /sbin/restorecon reset context -> > > I've also tried using /usr/sbin/semodule --build to try rebuilding (and > reloading) the current policy, but that > didn't change the behavior I'm seeing. > > Any suggestions would be greatly appreciated. > > - Tim > The only time you should need the -F would be if the previous context was in /etc/selinux/targeted/contexts/customizable_types I believe. The most common of these are httpd. This file is an artifact of what we had to do before we had semanage. If the file context is not listed in this file and you still need the force, what is the the file context you are changing? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfefN4ACgkQrlYvE4MpobPlVgCcDsqC/AOjwJB6gBmW+jYloKpG JW4AoM0DPHRgUnbnTKSFD1JBVmBrAgbc =mSu/ -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Mar 17 14:27:20 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 17 Mar 2008 10:27:20 -0400 Subject: Question on semanage fcontext -a In-Reply-To: <1205755623.22912.116.camel@moss-spartans.epoch.ncsc.mil> References: <16058319.post@talk.nabble.com> <47DE5679.9060807@city-fan.org> <1205755623.22912.116.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <47DE7FC8.2060904@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Smalley wrote: > On Mon, 2008-03-17 at 11:31 +0000, Paul Howarth wrote: >> ttaylor wrote: >>> Does anything special have to be done to cause SELinux to start using newly >>> added local filecontexts? What I'm finding is that if I use semanage >>> fcontext -a to add a local filecontext definition, it is not used by >>> restorecon unless I specify the "-F" option. Without the "-F" option, >>> restorecon -vv gives the following message: >>> >>> /sbin/restorecon: not reset customized by admin to >>> >>> >>> but restorecon -vv -F gives this: >>> >>> /sbin/restorecon reset context -> >> This is probably because is a customizable type like >> httpd_sys_content_t; objects with these types don't get reset by >> restorecon unless you use -F. I'm not sure how to find out which types >> are customizable off the top of my head though. > > cat /etc/selinux/$SELINUXTYPE/contexts/customizable_types > > Dan - I thought we had discussed reducing that set significantly since > it was originally to avoid clobbering locally-set types upon a > filesystem relabel prior to the introduction of semanage, but with users > now able to add local file contexts easily via semanage fcontext -a, it > isn't as necessary. > Yes I have in Rawhide, but if you are using an Older OS, those files are still there. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfef8gACgkQrlYvE4MpobMIUgCeLkLGmqeGizf4Tgb/yy3wPhWM RPEAn2Ol8SrzueD2p3w7g0M7gcjLUc9E =bmbT -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Mar 17 14:29:07 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 17 Mar 2008 10:29:07 -0400 Subject: Bash script problem [OT] - Solved In-Reply-To: <20080316185544.GA4344@localhost.localdomain> References: <20080308092242.GA8249@localhost.localdomain> <20080308130130.GA9853@localhost.localdomain> <47D53728.9080806@redhat.com> <20080311120516.GA16674@troodos.org.uk> <47D72AA3.8030502@redhat.com> <20080316185544.GA4344@localhost.localdomain> Message-ID: <47DE8033.5010203@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Arthur Dent wrote: > On Tue, Mar 11, 2008 at 08:58:11PM -0400, Daniel J Walsh wrote: >> Arthur Dent wrote: >>> On Mon, Mar 10, 2008 at 09:27:04AM -0400, Daniel J Walsh wrote: >>>> setroubleshoot can be setup on a headless box to send email. And there >>>> is an interface (named pipe) to audit system where you can receive AVC >>>> messages as they happen. Just look at the setroubleshoot code since it >>>> is using this. >>> Ooooo. That sounds interesting. I'm all for not re-inventing the wheel. Thing >>> is, I looked at man sealert and I couldn't see how to do this. I am not much >>> of a hacker, so looking at the code would probably not help me too much. >>> >>> Is there a configuration setting I can set somewhere? >>> >>> Thanks >>> >>> Mark >>> >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> vi /etc/setroubleshoot/setroubleshoot.cfg >> >> And search for email. > > Hi, > > Apologies for slow response. Thanks ever so much for this. Just what I > was looking for! > > Just one small thing... > > When I tried this, editing /etc/setroubleshoot/setroubleshoot.cfg > and creating a file /var/lib/setroubleshoot/email_alert_recipients it > didn't work. I looked at this wiki entry > http://fedoraproject.org/wiki/Docs/Drafts/SELinux/SETroubleShoot/UserFAQ#email-alerts > and it said essentially exactly the same thing. It also said that that I > could use the sealert GUI to set the mailing settings, so I SSH'd into > my serving using a forwarded X server and tried that. It worked! > > The strange thing is that the wiki says that the GUI method simply > modifies the same file (which makes sense), but I used a different email > address and the old email address (which doesn't work) is still in that file with no sign of > the new one (which works!). > > Ho hum... I suppose I goofed somewhere along the line. I'll look into it > with a little more care when I get the chance. In the meantime, the > important thing is it works! > > Thanks again, your help is greatly appreciated. > > Mark > John could you help Mark out? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfegDMACgkQrlYvE4MpobP3aQCeJSywvkeDfiFOZ+8xR4LF90sc dtEAoMiuOasaxk/e1oIQNa5yELlhU6Ja =jShQ -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Mar 17 14:31:09 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 17 Mar 2008 10:31:09 -0400 Subject: firefox alert In-Reply-To: <64b14b300803170130o39a81779rf6fdb363f418f4de@mail.gmail.com> References: <64b14b300803170130o39a81779rf6fdb363f418f4de@mail.gmail.com> Message-ID: <47DE80AD.8010404@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Valent Turkovic wrote: > I opened http://jkeating.livejournal.com/56521.html in new tab and I > got this alert. > Any ideas why? > > Cheers, > Valent. > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list There could be something badly labeled in your homedir. restorecon -R -v ~ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfegK0ACgkQrlYvE4MpobOz9QCgstjjLuwj+bLKZQZCBAJPutq8 pN4AoMjMqbm3RheeFtl04dJ1wdJCG9qR =PGrR -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Mar 17 14:33:55 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 17 Mar 2008 10:33:55 -0400 Subject: rawhide yum denied for transition bootloader_t, two alerts In-Reply-To: <8b14d9940803170314p5a4f9bdm243bc461ab6ee8ea@mail.gmail.com> References: <8b14d9940803170314p5a4f9bdm243bc461ab6ee8ea@mail.gmail.com> Message-ID: <47DE8153.60809@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Farris wrote: > These happen on two machines during updates, I'm also noticing many > %post scriptlets failing when these pop up, though I don't know if > they are related or not. > > Summary: > > SELinux is preventing yum (bootloader_t) "transition" to /sbin/ldconfig > (rpm_script_t). > > Detailed Description: > > SELinux denied access requested by yum. It is not expected that this access is > required by yum 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 user_u:system_r:bootloader_t:s0 > Target Context user_u:system_r:rpm_script_t:s0 > Target Objects /sbin/ldconfig [ process ] > Source yum > Source Path /usr/bin/python > Port > Host durthangnix > Source RPM Packages python-2.5.1-23.fc9 > Target RPM Packages glibc-2.7.90-9 > Policy RPM selinux-policy-3.3.1-14.fc9 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name catchall > Host Name durthangnix > Platform Linux durthangnix 2.6.25-0.105.rc5.fc9 #1 SMP Mon > Mar 10 20:59:23 EDT 2008 x86_64 x86_64 > Alert Count 35 > First Seen Thu 13 Mar 2008 11:19:15 PM PDT > Last Seen Thu 13 Mar 2008 11:32:48 PM PDT > Local ID 36d70abc-d12d-42f2-96bf-ab7250e29da1 > Line Numbers > > Raw Audit Messages > > host=durthangnix type=AVC msg=audit(1205476368.460:1339): avc: denied > { transition } for pid=28100 comm="yum" path="/sbin/ldconfig" > dev=sda3 ino=858775 scontext=user_u:system_r:bootloader_t:s0 > tcontext=user_u:system_r:rpm_script_t:s0 tclass=process > > host=durthangnix type=SYSCALL msg=audit(1205476368.460:1339): > arch=c000003e syscall=59 success=no exit=-13 a0=7ff2034c2aca > a1=7fff1bd22350 a2=7ff20aa927d0 a3=3b8896c9f0 items=0 ppid=27144 > pid=28100 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 tty=pts1 ses=4 comm="yum" exe="/usr/bin/python" > subj=user_u:system_r:bootloader_t:s0 key=(null) > > > > Summary: > > SELinux is preventing yum (bootloader_t) "transition" to /bin/bash > (rpm_script_t). > > Detailed Description: > > SELinux denied access requested by yum. It is not expected that this access is > required by yum 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 user_u:system_r:bootloader_t:s0 > Target Context user_u:system_r:rpm_script_t:s0 > Target Objects /bin/bash [ process ] > Source rpm > Source Path /bin/rpm > Port > Host durthangnix > Source RPM Packages python-2.5.1-23.fc9 > Target RPM Packages bash-3.2-21.fc9 > Policy RPM selinux-policy-3.3.1-14.fc9 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name catchall > Host Name durthangnix > Platform Linux durthangnix 2.6.25-0.105.rc5.fc9 #1 SMP Mon > Mar 10 20:59:23 EDT 2008 x86_64 x86_64 > Alert Count 48 > First Seen Thu 13 Mar 2008 10:00:05 AM PDT > Last Seen Thu 13 Mar 2008 11:32:48 PM PDT > Local ID 75a34bf7-d467-444b-bfb4-9a931b3af238 > Line Numbers > > Raw Audit Messages > > host=durthangnix type=AVC msg=audit(1205476368.64:1338): avc: denied > { transition } for pid=28099 comm="yum" path="/bin/bash" dev=sda3 > ino=835647 scontext=user_u:system_r:bootloader_t:s0 > tcontext=user_u:system_r:rpm_script_t:s0 tclass=process > > host=durthangnix type=SYSCALL msg=audit(1205476368.64:1338): > arch=c000003e syscall=59 success=no exit=-13 a0=7ff20063e90d > a1=7fff1bd22350 a2=7ff20aa927d0 a3=3b8896c9f0 items=0 ppid=27144 > pid=28099 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 tty=pts1 ses=4 comm="yum" exe="/usr/bin/python" > subj=user_u:system_r:bootloader_t:s0 key=(null) > > > THis looks like you are logged in as bootloader_t? Something is very wrong with your system. What does id -Z Show? You might need to relabel. Are you using a different login program? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfegVMACgkQrlYvE4MpobMQ+ACeKCK06xKkMvhWR+QV640XbWtL +FMAoJrZ27X844vVZyPsk0s/w0ElCkHO =Nmcm -----END PGP SIGNATURE----- From ttaylor at mitre.org Mon Mar 17 20:16:51 2008 From: ttaylor at mitre.org (Tim Taylor) Date: Mon, 17 Mar 2008 16:16:51 -0400 Subject: Question on semanage fcontext -a In-Reply-To: <1205755623.22912.116.camel@moss-spartans.epoch.ncsc.mil> References: <16058319.post@talk.nabble.com> <47DE5679.9060807@city-fan.org> <1205755623.22912.116.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1205785011.4995.38.camel@mm143135-pc.mitre.org> On Mon, 2008-03-17 at 08:07 -0400, Stephen Smalley wrote: > > On Mon, 2008-03-17 at 11:31 +0000, Paul Howarth wrote: > > ttaylor wrote: > > > Does anything special have to be done to cause SELinux to start > using newly > > > added local filecontexts? What I'm finding is that if I use > semanage > > > fcontext -a to add a local filecontext definition, it is not used > by > > > restorecon unless I specify the "-F" option. Without the "-F" > option, > > > restorecon -vv gives the following message: > > > > > > /sbin/restorecon: not reset customized by admin to > > > > > > > > > but restorecon -vv -F gives this: > > > > > > /sbin/restorecon reset context > -> > > > > This is probably because is a customizable type > like > > httpd_sys_content_t; objects with these types don't get reset by > > restorecon unless you use -F. I'm not sure how to find out which > types > > are customizable off the top of my head though. > > cat /etc/selinux/$SELINUXTYPE/contexts/customizable_types > > Dan - I thought we had discussed reducing that set significantly since > it was originally to avoid clobbering locally-set types upon a > filesystem relabel prior to the introduction of semanage, but with > users > now able to add local file contexts easily via semanage fcontext -a, > it > isn't as necessary. This is exactly my situation. I am using Fedora 8 with all the latest updates. I had used semanage to add a filecontext which would cause particular directories to be labeled with the type httpd_sys_script_rw_t which is a customizable type. The directory I was trying to label was under /var/www which has a context of httpd_sys_content_t which is also a customizabile type. So why is it that new directories under /var/www are automatically labeled with the httpd_sys_content_t type, but things that match my added filecontext don't automatically get labeled with httpd_sys_script_rw_t, and require the use of restorecon -F? Here's the specifics: The command I used to add my local context: semanage fcontext -d -f -d -t httpd_sys_script_rw_t "/var/www/wikis/[^/]+/images" I then create a directory that matches the above pattern: mkdir -p /var/www/wikis/foo/images The directory is created, but has the type httpd_sys_content_t. Now I use restorecon to relabel: restorecon -vv /var/www/wikis/foo/images This gives me the following message: /sbin/restorecon: /var/www/wikis/foo/images not reset customized by admin to system_u:object_r:httpd_sys_content_t:s0 Now run restorecon with the force flag: restorecon -vv -F /var/www/wikis/foo/images Gives this message: restorecon reset /var/www/wikis/foo/images context system_u:object_r:httpd_sys_content_t:s0->system_u:object_r:httpd_sys_script_rw_t:s0 Since both types are in the customizable_types file, why is one automatically used, and the other only used when forced? - Tim > > -- > Stephen Smalley > National Security Agency > > > From lordmorgul at gmail.com Mon Mar 17 20:35:14 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Mon, 17 Mar 2008 13:35:14 -0700 Subject: rawhide yum denied for transition bootloader_t, two alerts In-Reply-To: <47DE8153.60809@redhat.com> References: <8b14d9940803170314p5a4f9bdm243bc461ab6ee8ea@mail.gmail.com> <47DE8153.60809@redhat.com> Message-ID: <8b14d9940803171335s422b8726y4d2a28cf90c09823@mail.gmail.com> On Mon, Mar 17, 2008 at 7:33 AM, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Andrew Farris wrote: > > These happen on two machines during updates, I'm also noticing many > > %post scriptlets failing when these pop up, though I don't know if > > they are related or not. > > Raw Audit Messages > > > > host=durthangnix type=AVC msg=audit(1205476368.460:1339): avc: denied > > { transition } for pid=28100 comm="yum" path="/sbin/ldconfig" > > dev=sda3 ino=858775 scontext=user_u:system_r:bootloader_t:s0 > > tcontext=user_u:system_r:rpm_script_t:s0 tclass=process > > > > host=durthangnix type=SYSCALL msg=audit(1205476368.460:1339): > > arch=c000003e syscall=59 success=no exit=-13 a0=7ff2034c2aca > > a1=7fff1bd22350 a2=7ff20aa927d0 a3=3b8896c9f0 items=0 ppid=27144 > > pid=28100 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > > fsgid=0 tty=pts1 ses=4 comm="yum" exe="/usr/bin/python" > > subj=user_u:system_r:bootloader_t:s0 key=(null) > > > > Raw Audit Messages > > > > host=durthangnix type=AVC msg=audit(1205476368.64:1338): avc: denied > > { transition } for pid=28099 comm="yum" path="/bin/bash" dev=sda3 > > ino=835647 scontext=user_u:system_r:bootloader_t:s0 > > tcontext=user_u:system_r:rpm_script_t:s0 tclass=process > > > > host=durthangnix type=SYSCALL msg=audit(1205476368.64:1338): > > arch=c000003e syscall=59 success=no exit=-13 a0=7ff20063e90d > > a1=7fff1bd22350 a2=7ff20aa927d0 a3=3b8896c9f0 items=0 ppid=27144 > > pid=28099 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > > fsgid=0 tty=pts1 ses=4 comm="yum" exe="/usr/bin/python" > > subj=user_u:system_r:bootloader_t:s0 key=(null) > > > > > > > THis looks like you are logged in as bootloader_t? Something is very > wrong with your system. > > What does > id -Z > > Show? On one system I am logged in as bootloader_t: My user id -Z: user_u:system_r:bootloader_t:s0 And root (su - from my user): user_u:system_r:bootloader_t:s0 On the other system I am not, instead I am: unconfined_u:unconfined_r:unconfined_t:SystemLow-SystemHigh The first is kernel-2.6.25-0.121.rc5.git4.fc9.x86_64 and look at this: 04:11:39 |root.durthangnix:1| |28 files:848K at yum| |0 jobs| - rpm -q selinux-policy-targeted package selinux-policy-targeted is not installed 04:12:00 |root.durthangnix:1| |28 files:848K at yum| |0 jobs| - rpm -qa | grep selinux libselinux-python-2.0.57-1.fc9.x86_64 libselinux-2.0.59-1.fc9.x86_64 selinux-policy-3.3.1-16.fc9.noarch selinux-policy-devel-3.3.1-16.fc9.noarch libselinux-2.0.57-1.fc9.x86_64 libselinux-python-2.0.59-1.fc9.x86_64 libselinux-2.0.59-1.fc9.i386 selinux-policy-3.3.1-14.fc9.noarch 04:12:08 |root.durthangnix:1| |28 files:848K at yum| |0 jobs| - yum list selinux-policy-targeted Loaded plugins: basearchonly, fastestmirror, fedorakmod, priorities, security, : versionlock Loading mirror speeds from cached hostfile * livna-development: mirrors.tummy.com * livna-development-debuginfo: mirrors.tummy.com * rawhide: limestone.uoregon.edu * upstart-debuginfo: notting.fedorapeople.org * upstart: notting.fedorapeople.org Reading version lock configuration Available Packages selinux-policy-targeted.noarch 3.3.1-16.fc9 rawhide 04:12:36 |root.durthangnix:1| |28 files:848K at yum| |0 jobs| - cat /etc/sysconfig/selinux # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=enforcing # SELINUXTYPE= can take one of these two values: # targeted - Targeted processes are protected, # mls - Multi Level Security protection. SELINUXTYPE=targeted # SETLOCALDEFS= Check local definition changes SETLOCALDEFS=0 So the configured policy is not even installed... it was previously, so I'm not sure where it went. This is from /var/log/yum.log: - cat /var/log/yum.log | grep selinux Mar 13 23:21:49 Updated: selinux-policy-3.3.1-16.fc9.noarch Mar 13 23:24:46 Updated: selinux-policy-targeted-3.3.1-16.fc9.noarch Mar 13 23:24:51 Updated: selinux-policy-devel-3.3.1-16.fc9.noarch Mar 13 23:31:17 selinux-policy-targeted: ts_done name in te is yum should be selinux-policy-targeted Mar 13 23:31:17 rpm: ts_done name in te is selinux-policy-targeted should be rpm Mar 13 23:31:20 selinux-policy-devel: ts_done name in te is totem-gstreamer should be selinux-policy-devel Mar 13 23:31:49 xulrunner-debuginfo: ts_done name in te is selinux-policy-devel should be xulrunner-debuginfo Mar 13 23:32:37 selinux-policy: ts_done name in te is mesa-libGL should be selinux-policy Mar 13 23:32:49 pulseaudio-module-gconf: ts_done name in te is selinux-policy should be pulseaudio-module-gconf The second system does have selinux-policy-targeted installed and thats the one chosen in config. This is the system that is logged in unconfined. > You might need to relabel. Are you using a different login program? Was logged in from gdm on both systems, AFTER a fresh autorelabel on both that I did yesterday. I'll try it again after I pull today's updates and autorelabel. -- Andrew Farris www.lordmorgul.net gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From dwalsh at redhat.com Mon Mar 17 21:26:34 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 17 Mar 2008 17:26:34 -0400 Subject: rawhide yum denied for transition bootloader_t, two alerts In-Reply-To: <8b14d9940803171335s422b8726y4d2a28cf90c09823@mail.gmail.com> References: <8b14d9940803170314p5a4f9bdm243bc461ab6ee8ea@mail.gmail.com> <47DE8153.60809@redhat.com> <8b14d9940803171335s422b8726y4d2a28cf90c09823@mail.gmail.com> Message-ID: <47DEE20A.1000204@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Farris wrote: > On Mon, Mar 17, 2008 at 7:33 AM, Daniel J Walsh wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> >> Andrew Farris wrote: >> > These happen on two machines during updates, I'm also noticing many >> > %post scriptlets failing when these pop up, though I don't know if >> > they are related or not. > >> > Raw Audit Messages >> > >> > host=durthangnix type=AVC msg=audit(1205476368.460:1339): avc: denied >> > { transition } for pid=28100 comm="yum" path="/sbin/ldconfig" >> > dev=sda3 ino=858775 scontext=user_u:system_r:bootloader_t:s0 >> > tcontext=user_u:system_r:rpm_script_t:s0 tclass=process >> > >> > host=durthangnix type=SYSCALL msg=audit(1205476368.460:1339): >> > arch=c000003e syscall=59 success=no exit=-13 a0=7ff2034c2aca >> > a1=7fff1bd22350 a2=7ff20aa927d0 a3=3b8896c9f0 items=0 ppid=27144 >> > pid=28100 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 >> > fsgid=0 tty=pts1 ses=4 comm="yum" exe="/usr/bin/python" >> > subj=user_u:system_r:bootloader_t:s0 key=(null) >> > > >> > Raw Audit Messages >> > >> > host=durthangnix type=AVC msg=audit(1205476368.64:1338): avc: denied >> > { transition } for pid=28099 comm="yum" path="/bin/bash" dev=sda3 >> > ino=835647 scontext=user_u:system_r:bootloader_t:s0 >> > tcontext=user_u:system_r:rpm_script_t:s0 tclass=process >> > >> > host=durthangnix type=SYSCALL msg=audit(1205476368.64:1338): >> > arch=c000003e syscall=59 success=no exit=-13 a0=7ff20063e90d >> > a1=7fff1bd22350 a2=7ff20aa927d0 a3=3b8896c9f0 items=0 ppid=27144 >> > pid=28099 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 >> > fsgid=0 tty=pts1 ses=4 comm="yum" exe="/usr/bin/python" >> > subj=user_u:system_r:bootloader_t:s0 key=(null) >> > >> > >> > >> THis looks like you are logged in as bootloader_t? Something is very >> wrong with your system. >> >> What does >> id -Z >> >> Show? > > On one system I am logged in as bootloader_t: > My user id -Z: user_u:system_r:bootloader_t:s0 > And root (su - from my user): user_u:system_r:bootloader_t:s0 > > On the other system I am not, instead I am: > unconfined_u:unconfined_r:unconfined_t:SystemLow-SystemHigh > > The first is kernel-2.6.25-0.121.rc5.git4.fc9.x86_64 and look at this: > > 04:11:39 |root.durthangnix:1| |28 files:848K at yum| |0 jobs| > - rpm -q selinux-policy-targeted > package selinux-policy-targeted is not installed > > 04:12:00 |root.durthangnix:1| |28 files:848K at yum| |0 jobs| > - rpm -qa | grep selinux > libselinux-python-2.0.57-1.fc9.x86_64 > libselinux-2.0.59-1.fc9.x86_64 > selinux-policy-3.3.1-16.fc9.noarch > selinux-policy-devel-3.3.1-16.fc9.noarch > libselinux-2.0.57-1.fc9.x86_64 > libselinux-python-2.0.59-1.fc9.x86_64 > libselinux-2.0.59-1.fc9.i386 > selinux-policy-3.3.1-14.fc9.noarch > > 04:12:08 |root.durthangnix:1| |28 files:848K at yum| |0 jobs| > - yum list selinux-policy-targeted > Loaded plugins: basearchonly, fastestmirror, fedorakmod, priorities, security, > : versionlock > Loading mirror speeds from cached hostfile > * livna-development: mirrors.tummy.com > * livna-development-debuginfo: mirrors.tummy.com > * rawhide: limestone.uoregon.edu > * upstart-debuginfo: notting.fedorapeople.org > * upstart: notting.fedorapeople.org > Reading version lock configuration > Available Packages > selinux-policy-targeted.noarch 3.3.1-16.fc9 rawhide > > 04:12:36 |root.durthangnix:1| |28 files:848K at yum| |0 jobs| > - cat /etc/sysconfig/selinux > > # This file controls the state of SELinux on the system. > # SELINUX= can take one of these three values: > # enforcing - SELinux security policy is enforced. > # permissive - SELinux prints warnings instead of enforcing. > # disabled - No SELinux policy is loaded. > SELINUX=enforcing > # SELINUXTYPE= can take one of these two values: > # targeted - Targeted processes are protected, > # mls - Multi Level Security protection. > SELINUXTYPE=targeted > # SETLOCALDEFS= Check local definition changes > SETLOCALDEFS=0 > > So the configured policy is not even installed... it was previously, > so I'm not sure where it went. This is from /var/log/yum.log: > - cat /var/log/yum.log | grep selinux > Mar 13 23:21:49 Updated: selinux-policy-3.3.1-16.fc9.noarch > Mar 13 23:24:46 Updated: selinux-policy-targeted-3.3.1-16.fc9.noarch > Mar 13 23:24:51 Updated: selinux-policy-devel-3.3.1-16.fc9.noarch > Mar 13 23:31:17 selinux-policy-targeted: ts_done name in te is yum > should be selinux-policy-targeted > Mar 13 23:31:17 rpm: ts_done name in te is selinux-policy-targeted should be rpm > Mar 13 23:31:20 selinux-policy-devel: ts_done name in te is > totem-gstreamer should be selinux-policy-devel > Mar 13 23:31:49 xulrunner-debuginfo: ts_done name in te is > selinux-policy-devel should be xulrunner-debuginfo > Mar 13 23:32:37 selinux-policy: ts_done name in te is mesa-libGL > should be selinux-policy > Mar 13 23:32:49 pulseaudio-module-gconf: ts_done name in te is > selinux-policy should be pulseaudio-module-gconf > > The second system does have selinux-policy-targeted installed and > thats the one chosen in config. This is the system that is logged in > unconfined. > >> You might need to relabel. Are you using a different login program? > > Was logged in from gdm on both systems, AFTER a fresh autorelabel on > both that I did yesterday. I'll try it again after I pull today's > updates and autorelabel. > Well install selinux-policy-targeted on both machine/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfe4goACgkQrlYvE4MpobOYKQCfSfrZO5FVfaHtv2b2qv3p1mRX 8FoAoOl2dMK7mOv9jVTEmETp63X7Y1y8 =u4SZ -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Mar 17 21:30:45 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 17 Mar 2008 17:30:45 -0400 Subject: Question on semanage fcontext -a In-Reply-To: <1205785011.4995.38.camel@mm143135-pc.mitre.org> References: <16058319.post@talk.nabble.com> <47DE5679.9060807@city-fan.org> <1205755623.22912.116.camel@moss-spartans.epoch.ncsc.mil> <1205785011.4995.38.camel@mm143135-pc.mitre.org> Message-ID: <47DEE305.9000903@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tim Taylor wrote: > On Mon, 2008-03-17 at 08:07 -0400, Stephen Smalley wrote: >> On Mon, 2008-03-17 at 11:31 +0000, Paul Howarth wrote: >>> ttaylor wrote: >>>> Does anything special have to be done to cause SELinux to start >> using newly >>>> added local filecontexts? What I'm finding is that if I use >> semanage >>>> fcontext -a to add a local filecontext definition, it is not used >> by >>>> restorecon unless I specify the "-F" option. Without the "-F" >> option, >>>> restorecon -vv gives the following message: >>>> >>>> /sbin/restorecon: not reset customized by admin to >>>> >>>> >>>> but restorecon -vv -F gives this: >>>> >>>> /sbin/restorecon reset context >> -> >>> This is probably because is a customizable type >> like >>> httpd_sys_content_t; objects with these types don't get reset by >>> restorecon unless you use -F. I'm not sure how to find out which >> types >>> are customizable off the top of my head though. >> cat /etc/selinux/$SELINUXTYPE/contexts/customizable_types >> >> Dan - I thought we had discussed reducing that set significantly since >> it was originally to avoid clobbering locally-set types upon a >> filesystem relabel prior to the introduction of semanage, but with >> users >> now able to add local file contexts easily via semanage fcontext -a, >> it >> isn't as necessary. > > This is exactly my situation. I am using Fedora 8 with all the latest > updates. I had used semanage to add a filecontext which would cause > particular directories to be labeled with the type httpd_sys_script_rw_t > which is a customizable type. > > The directory I was trying to label was under /var/www which has a > context of httpd_sys_content_t which is also a customizabile type. So > why is it that new directories under /var/www are automatically labeled > with the httpd_sys_content_t type, but things that match my added > filecontext don't automatically get labeled with httpd_sys_script_rw_t, > and require the use of restorecon -F? > > Here's the specifics: > > The command I used to add my local context: > semanage fcontext -d -f -d -t httpd_sys_script_rw_t > "/var/www/wikis/[^/]+/images" > > I then create a directory that matches the above pattern: > mkdir -p /var/www/wikis/foo/images > > The directory is created, but has the type httpd_sys_content_t. > > Now I use restorecon to relabel: > restorecon -vv /var/www/wikis/foo/images > > This gives me the following message: > /sbin/restorecon: /var/www/wikis/foo/images not reset customized by > admin to system_u:object_r:httpd_sys_content_t:s0 > > Now run restorecon with the force flag: > restorecon -vv -F /var/www/wikis/foo/images > > Gives this message: > restorecon reset /var/www/wikis/foo/images context > system_u:object_r:httpd_sys_content_t:s0->system_u:object_r:httpd_sys_script_rw_t:s0 > > Since both types are in the customizable_types file, why is one > automatically used, and the other only used when forced? > > - Tim New Files/Directories adopt the context of their parent directry by default. Unless the program is SELinux aware or a transition rule was written in policy dhcp_t creating files in directories labeled etc_t get a file context of net_conf_t. So since mkdir is not selinux aware and no policy rule has been defined, you create the directory with the same context as the parent. httpd_sys_content_t in both cases. restorecon reads the file context file and assigns the correct context after creation. >> -- >> Stephen Smalley >> National Security Agency >> >> >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEUEARECAAYFAkfe4wUACgkQrlYvE4MpobM3SwCeIdXCI4G4d7zPyV0sop/sepRe W8UAl21UT2Z2KpZPW/aFoO7Ft92UMaM= =nXDO -----END PGP SIGNATURE----- From lordmorgul at gmail.com Mon Mar 17 22:37:00 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Mon, 17 Mar 2008 15:37:00 -0700 Subject: rawhide yum denied for transition bootloader_t, two alerts In-Reply-To: <47DEE20A.1000204@redhat.com> References: <8b14d9940803170314p5a4f9bdm243bc461ab6ee8ea@mail.gmail.com> <47DE8153.60809@redhat.com> <8b14d9940803171335s422b8726y4d2a28cf90c09823@mail.gmail.com> <47DEE20A.1000204@redhat.com> Message-ID: <47DEF28C.2080703@gmail.com> Daniel J Walsh wrote: > Well install selinux-policy-targeted on both machine/ I already had the policy installed on one machine, it was only uninstalled from the second. I installed the targeted policy on the second machine, so both now have it. I rebooted and relabeled both. They both login as bootloader_t when logging in from gdm. On the other hand if I use startx I get logged in with unconfined_t, but no gnome settings daemon connection. -- Andrew Farris www.lordmorgul.net gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From lordmorgul at gmail.com Mon Mar 17 23:04:47 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Mon, 17 Mar 2008 16:04:47 -0700 Subject: rawhide yum denied for transition bootloader_t, two alerts In-Reply-To: <47DEF28C.2080703@gmail.com> References: <8b14d9940803170314p5a4f9bdm243bc461ab6ee8ea@mail.gmail.com> <47DE8153.60809@redhat.com> <8b14d9940803171335s422b8726y4d2a28cf90c09823@mail.gmail.com> <47DEE20A.1000204@redhat.com> <47DEF28C.2080703@gmail.com> Message-ID: <47DEF90F.6060400@gmail.com> Andrew Farris wrote: > Daniel J Walsh wrote: >> Well install selinux-policy-targeted on both machine/ > > I already had the policy installed on one machine, it was only > uninstalled from the second. > > I installed the targeted policy on the second machine, so both now have > it. I rebooted and relabeled both. They both login as bootloader_t > when logging in from gdm. > > On the other hand if I use startx I get logged in with unconfined_t, but > no gnome settings daemon connection. Let me add I am now seeing both systems behave the same way as above, gdm logins have context bootloader_t and that remains through /bin/su - root but startx logins have unconfined_t and remains unconfined through /bin/su - root. -- Andrew Farris www.lordmorgul.net gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From dwalsh at redhat.com Tue Mar 18 12:16:09 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 18 Mar 2008 08:16:09 -0400 Subject: rawhide yum denied for transition bootloader_t, two alerts In-Reply-To: <47DEF28C.2080703@gmail.com> References: <8b14d9940803170314p5a4f9bdm243bc461ab6ee8ea@mail.gmail.com> <47DE8153.60809@redhat.com> <8b14d9940803171335s422b8726y4d2a28cf90c09823@mail.gmail.com> <47DEE20A.1000204@redhat.com> <47DEF28C.2080703@gmail.com> Message-ID: <47DFB289.20706@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Farris wrote: > Daniel J Walsh wrote: >> Well install selinux-policy-targeted on both machine/ > > I already had the policy installed on one machine, it was only > uninstalled from the second. > > I installed the targeted policy on the second machine, so both now have > it. I rebooted and relabeled both. They both login as bootloader_t > when logging in from gdm. > > On the other hand if I use startx I get logged in with unconfined_t, but > no gnome settings daemon connection. > ps -eZ | grep gdm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkffsokACgkQrlYvE4MpobO98ACg1dCVQDwpnUdFtYLjJumRsCfG S2YAoOah1iYqKY9087V8+QHzAzIDe1O8 =iuKL -----END PGP SIGNATURE----- From sds at tycho.nsa.gov Tue Mar 18 13:45:00 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 18 Mar 2008 09:45:00 -0400 Subject: Question on semanage fcontext -a In-Reply-To: <1205785011.4995.38.camel@mm143135-pc.mitre.org> References: <16058319.post@talk.nabble.com> <47DE5679.9060807@city-fan.org> <1205755623.22912.116.camel@moss-spartans.epoch.ncsc.mil> <1205785011.4995.38.camel@mm143135-pc.mitre.org> Message-ID: <1205847900.6466.35.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2008-03-17 at 16:16 -0400, Tim Taylor wrote: > On Mon, 2008-03-17 at 08:07 -0400, Stephen Smalley wrote: > > > > On Mon, 2008-03-17 at 11:31 +0000, Paul Howarth wrote: > > > ttaylor wrote: > > > > Does anything special have to be done to cause SELinux to start > > using newly > > > > added local filecontexts? What I'm finding is that if I use > > semanage > > > > fcontext -a to add a local filecontext definition, it is not used > > by > > > > restorecon unless I specify the "-F" option. Without the "-F" > > option, > > > > restorecon -vv gives the following message: > > > > > > > > /sbin/restorecon: not reset customized by admin to > > > > > > > > > > > > but restorecon -vv -F gives this: > > > > > > > > /sbin/restorecon reset context > > -> > > > > > > This is probably because is a customizable type > > like > > > httpd_sys_content_t; objects with these types don't get reset by > > > restorecon unless you use -F. I'm not sure how to find out which > > types > > > are customizable off the top of my head though. > > > > cat /etc/selinux/$SELINUXTYPE/contexts/customizable_types > > > > Dan - I thought we had discussed reducing that set significantly since > > it was originally to avoid clobbering locally-set types upon a > > filesystem relabel prior to the introduction of semanage, but with > > users > > now able to add local file contexts easily via semanage fcontext -a, > > it > > isn't as necessary. > > This is exactly my situation. I am using Fedora 8 with all the latest > updates. I had used semanage to add a filecontext which would cause > particular directories to be labeled with the type httpd_sys_script_rw_t > which is a customizable type. > > The directory I was trying to label was under /var/www which has a > context of httpd_sys_content_t which is also a customizabile type. So > why is it that new directories under /var/www are automatically labeled > with the httpd_sys_content_t type, but things that match my added > filecontext don't automatically get labeled with httpd_sys_script_rw_t, > and require the use of restorecon -F? > > Here's the specifics: > > The command I used to add my local context: > semanage fcontext -d -f -d -t httpd_sys_script_rw_t > "/var/www/wikis/[^/]+/images" This adds the entry to your file contexts configuration, a mapping from pathname regexes to file security contexts that is used to determine the right security context for a file when it is first installed (e.g. by rpm) or when you want to reset the filesystem to its initial state (e.g. via restorecon or fixfiles relabel), but not at runtime by the kernel. > I then create a directory that matches the above pattern: > mkdir -p /var/www/wikis/foo/images > > The directory is created, but has the type httpd_sys_content_t. For runtime file creation, the kernel labels new files based on either: 1) a type transition rule in the policy if one exists for the creating process' domain, the parent directory type, and the new file's security class (object type - e.g. regular file, directory, symlink, device node), or 2) the parent directory's type if no type transition rule matches. The file contexts configuration is not used by the kernel and is only supposed to represent the initial install-time state of the filesystem. > Now I use restorecon to relabel: > restorecon -vv /var/www/wikis/foo/images restorecon does consult the file contexts configuration. > This gives me the following message: > /sbin/restorecon: /var/www/wikis/foo/images not reset customized by > admin to system_u:object_r:httpd_sys_content_t:s0 This is because the existing type on the file is a customizable type and thus may have been manually set by the admin via chcon - this approach predates the introduction of semanage and as Dan said, customizable types has been dropped in rawhide / Fedora 9, so you won't encounter this problem going forward there. > Now run restorecon with the force flag: > restorecon -vv -F /var/www/wikis/foo/images > > Gives this message: > restorecon reset /var/www/wikis/foo/images context > system_u:object_r:httpd_sys_content_t:s0->system_u:object_r:httpd_sys_script_rw_t:s0 > > Since both types are in the customizable_types file, why is one > automatically used, and the other only used when forced? If by automatically used, you mean at new file creation, neither file contexts nor customizable types has anything to do with that. If you mean by restorecon, the restorecon logic is simply to not relabel a file that has a customizable type since it may have been manually set by the admin. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Tue Mar 18 14:37:54 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 18 Mar 2008 10:37:54 -0400 Subject: Starting stunnel from xinetd In-Reply-To: References: <47D53635.9070104@redhat.com> Message-ID: <47DFD3C2.2010108@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ian Pilcher wrote: > Daniel J Walsh wrote: >> Confined apps writing to /etc is frowned upon. /etc/ should be >> considered R/O. If you move this file to /var/run/stunnel and change >> the config, it should work. > > Nope. > > type=AVC msg=audit(1205188277.824:2538): avc: denied { getattr } for > pid=1696 comm="stunnel" path="/var/run/stunnel/random_seed" dev=md1 > ino=36907 scontext=unconfined_u:system_r:stunnel_t:s0-s0:c0.c1023 > tcontext=unconfined_u:object_r:var_run_t:s0 tclass=file > > (And shouldn't it really go under /var/lib/stunnel, since it's > supposed to survive a reboot?) > >> You have to define ports that stunnel can listen to. >> >> semanage port -a -t stunnel_port_t -P tcp 2873 > > OK, that got me past the bind denial. Unfortunately, it looks like > stunnel isn't allowed to access /usr/bin, so it can't start the rsync > daemon: > > type=AVC msg=audit(1205188277.890:2539): avc: denied { search } for > pid=1698 comm="stunnel" name="bin" dev=md1 ino=2686986 > scontext=unconfined_u:system_r:stunnel_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:bin_t:s0 tclass=dir > > Thanks! > Ok, I have been avoiding this. I have never used stunnel. Is it common for stunnel to start the application that is going to run within the tunnel? Or do you just setup the tunnel and the user then runs tools like rsync or telnet? So do we need a rsync_domtrans(stunnel_t) to start the rsync server or does it just need to execute the client? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkff08IACgkQrlYvE4MpobNrjgCguH2v2eUJSLRNXakAF0YDTkcR JhoAn2frfnkfNq1FMOHvi9fEGmoOGO/p =1wMU -----END PGP SIGNATURE----- From arequipeno at gmail.com Tue Mar 18 16:55:29 2008 From: arequipeno at gmail.com (Ian Pilcher) Date: Tue, 18 Mar 2008 11:55:29 -0500 Subject: Starting stunnel from xinetd In-Reply-To: <47DFD3C2.2010108@redhat.com> References: <47D53635.9070104@redhat.com> <47DFD3C2.2010108@redhat.com> Message-ID: Daniel J Walsh wrote: > Ok, I have been avoiding this. I have never used stunnel. Is it common > for stunnel to start the application that is going to run within the > tunnel? Or do you just setup the tunnel and the user then runs tools > like rsync or telnet? On the server side, stunnel can start the application in the same manner as [x]inetd. So my rsync over SSL setup works like this: 1. Client - rsync connects to localhost:2873 2. Client - xinetd accepts connection on port 2873 and execs stunnel 3. Client - stunnel makes SSL connection to server:2873 4. Server - xinetd accepts connection on port 2873 and execs stunnel 5. Server - stunnel does SSL handshake with client and execs "rsync --daemon" > So do we need a rsync_domtrans(stunnel_t) to start the rsync server or > does it just need to execute the client? Here's what I think is needed (from the administrator's point of view): 1. A stunnel_var_lib_t for /var/lib/stunnel. FHS says that persistent state like a random seed goes in /var/lib. (This probably applies to most or all of the applications that use the OpenSSL libraries.) 2. A bunch of per-daemon booleans, stunnel_exec_foo. Each of these would enable filesystem access (/usr/bin or /usr/sbin) and execing the appropriate file type. The daemons should presumably run with the same context that they would if started by xinetd. To get a complete(?) list of the xinetd daemons in Fedora 8, I've done the following: yum install `yum provides '/etc/xinetd.d/*' | awk '{ print $1 }'` grep 'socket_type.*=.*stream' /etc/xinetd.d/* | awk '{ print $1 }' \ | sort -u I get: /etc/xinetd.d/apgd: /etc/xinetd.d/auth: /etc/xinetd.d/bitlbee: /etc/xinetd.d/chargen-stream: /etc/xinetd.d/cups-lpd: /etc/xinetd.d/cvs: /etc/xinetd.d/daytime-stream: /etc/xinetd.d/discard-stream: /etc/xinetd.d/echo-stream: /etc/xinetd.d/eklogin: /etc/xinetd.d/ekrb5-telnet: /etc/xinetd.d/finger: /etc/xinetd.d/git: /etc/xinetd.d/gssftp: /etc/xinetd.d/identtestd: /etc/xinetd.d/imap: /etc/xinetd.d/imaps: /etc/xinetd.d/ipop2: /etc/xinetd.d/ipop3: /etc/xinetd.d/klogin: /etc/xinetd.d/krb5-telnet: /etc/xinetd.d/kshell: /etc/xinetd.d/leafnode: /etc/xinetd.d/nuttcp: /etc/xinetd.d/pop3s: /etc/xinetd.d/pure-ftpd: /etc/xinetd.d/rexec: /etc/xinetd.d/rlogin: /etc/xinetd.d/rsh: /etc/xinetd.d/rsync: /etc/xinetd.d/swat: /etc/xinetd.d/tcpmux-server: /etc/xinetd.d/telnet: /etc/xinetd.d/time-stream: /etc/xinetd.d/uucp: /etc/xinetd.d/vncts: /etc/xinetd.d/xproftpd: Some of these can be ignored -- the Kerberized services and those that already provide SSL capability. I'm actually looking at doing this myself. If what I've said above makes sense, and you're willing to answer the occasional question (via this list), I'll take it on as a project. (Should be good practice for 429.) Thanks! -- ======================================================================== Ian Pilcher arequipeno at gmail.com ======================================================================== From dwalsh at redhat.com Tue Mar 18 18:22:07 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 18 Mar 2008 14:22:07 -0400 Subject: Starting stunnel from xinetd In-Reply-To: References: <47D53635.9070104@redhat.com> <47DFD3C2.2010108@redhat.com> Message-ID: <47E0084F.9090308@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ian Pilcher wrote: > Daniel J Walsh wrote: >> Ok, I have been avoiding this. I have never used stunnel. Is it common >> for stunnel to start the application that is going to run within the >> tunnel? Or do you just setup the tunnel and the user then runs tools >> like rsync or telnet? > > On the server side, stunnel can start the application in the same manner > as [x]inetd. So my rsync over SSL setup works like this: > > 1. Client - rsync connects to localhost:2873 > 2. Client - xinetd accepts connection on port 2873 and execs stunnel > 3. Client - stunnel makes SSL connection to server:2873 > 4. Server - xinetd accepts connection on port 2873 and execs stunnel > 5. Server - stunnel does SSL handshake with client and execs "rsync > --daemon" > >> So do we need a rsync_domtrans(stunnel_t) to start the rsync server or >> does it just need to execute the client? > > Here's what I think is needed (from the administrator's point of view): > > 1. A stunnel_var_lib_t for /var/lib/stunnel. FHS says that persistent > state like a random seed goes in /var/lib. (This probably applies > to most or all of the applications that use the OpenSSL libraries.) > > 2. A bunch of per-daemon booleans, stunnel_exec_foo. Each of these > would enable filesystem access (/usr/bin or /usr/sbin) and execing > the appropriate file type. The daemons should presumably run with > the same context that they would if started by xinetd. > > To get a complete(?) list of the xinetd daemons in Fedora 8, I've done > the following: > > yum install `yum provides '/etc/xinetd.d/*' | awk '{ print $1 }'` > grep 'socket_type.*=.*stream' /etc/xinetd.d/* | awk '{ print $1 }' \ > | sort -u > > I get: > > /etc/xinetd.d/apgd: > /etc/xinetd.d/auth: > /etc/xinetd.d/bitlbee: > /etc/xinetd.d/chargen-stream: > /etc/xinetd.d/cups-lpd: > /etc/xinetd.d/cvs: > /etc/xinetd.d/daytime-stream: > /etc/xinetd.d/discard-stream: > /etc/xinetd.d/echo-stream: > /etc/xinetd.d/eklogin: > /etc/xinetd.d/ekrb5-telnet: > /etc/xinetd.d/finger: > /etc/xinetd.d/git: > /etc/xinetd.d/gssftp: > /etc/xinetd.d/identtestd: > /etc/xinetd.d/imap: > /etc/xinetd.d/imaps: > /etc/xinetd.d/ipop2: > /etc/xinetd.d/ipop3: > /etc/xinetd.d/klogin: > /etc/xinetd.d/krb5-telnet: > /etc/xinetd.d/kshell: > /etc/xinetd.d/leafnode: > /etc/xinetd.d/nuttcp: > /etc/xinetd.d/pop3s: > /etc/xinetd.d/pure-ftpd: > /etc/xinetd.d/rexec: > /etc/xinetd.d/rlogin: > /etc/xinetd.d/rsh: > /etc/xinetd.d/rsync: > /etc/xinetd.d/swat: > /etc/xinetd.d/tcpmux-server: > /etc/xinetd.d/telnet: > /etc/xinetd.d/time-stream: > /etc/xinetd.d/uucp: > /etc/xinetd.d/vncts: > /etc/xinetd.d/xproftpd: > > Some of these can be ignored -- the Kerberized services and those that > already provide SSL capability. > > I'm actually looking at doing this myself. If what I've said above > makes sense, and you're willing to answer the occasional question (via > this list), I'll take it on as a project. (Should be good practice for > 429.) > > Thanks! > Ok so stunnel needs to be able to exec and transition to everything that inetd can. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfgCE8ACgkQrlYvE4MpobPmeQCgtLiVSWV0sjPktQQOYuUhVxtV ZTEAn0ogmiO7A9dtLbImLANAVihx1CdR =oAJo -----END PGP SIGNATURE----- From dwalsh at redhat.com Tue Mar 18 18:32:45 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 18 Mar 2008 14:32:45 -0400 Subject: Starting stunnel from xinetd In-Reply-To: References: Message-ID: <47E00ACD.6010707@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ian Pilcher wrote: > Running fully updated Fedora 8, trying to start stunnel from xinetd, and > getting a couple of denials: > > type=AVC msg=audit(1205149512.996:2338): avc: denied { write } for > pid=14322 comm="stunnel" name="random_seed" dev=md1 ino=819429 > scontext=unconfined_u:system_r:stunnel_t:s0-s0:c0.c1023 > tcontext=unconfined_u:object_r:stunnel_etc_t:s0 tclass=file > > type=AVC msg=audit(1205149512.998:2339): avc: denied { name_bind } for > pid=14322 comm="stunnel" src=2873 > scontext=unconfined_u:system_r:stunnel_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket > > Aren't these things that stunnel should be expected to do? > selinux-policy-3.0.8-95.fc8.src.rpm Adds stunnel_system_domain to inetd_system_domain, which will allow stunnel to transition to every domain that is defined as an inetd_system_domain. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfgCs0ACgkQrlYvE4MpobPsjwCcDRC7u94GGJrOHEgieZf9WM6Y KLwAmgLJc7GeLsdgipGk4npGvxTrEKgo =gH0I -----END PGP SIGNATURE----- From ttaylor at mitre.org Tue Mar 18 18:38:28 2008 From: ttaylor at mitre.org (Tim Taylor) Date: Tue, 18 Mar 2008 14:38:28 -0400 Subject: Question on semanage fcontext -a In-Reply-To: <1205847900.6466.35.camel@moss-spartans.epoch.ncsc.mil> References: <16058319.post@talk.nabble.com> <47DE5679.9060807@city-fan.org> <1205755623.22912.116.camel@moss-spartans.epoch.ncsc.mil> <1205785011.4995.38.camel@mm143135-pc.mitre.org> <1205847900.6466.35.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1205865508.5093.15.camel@mm143135-pc.mitre.org> On Tue, 2008-03-18 at 09:45 -0400, Stephen Smalley wrote: > > On Mon, 2008-03-17 at 16:16 -0400, Tim Taylor wrote: > > On Mon, 2008-03-17 at 08:07 -0400, Stephen Smalley wrote: > > > > > > On Mon, 2008-03-17 at 11:31 +0000, Paul Howarth wrote: > > > > ttaylor wrote: > > > > > Does anything special have to be done to cause SELinux to > start > > > using newly > > > > > added local filecontexts? What I'm finding is that if I use > > > semanage > > > > > fcontext -a to add a local filecontext definition, it is not > used > > > by > > > > > restorecon unless I specify the "-F" option. Without the "-F" > > > option, > > > > > restorecon -vv gives the following message: > > > > > > > > > > /sbin/restorecon: not reset customized by admin to > > > > > > > > > > > > > > > but restorecon -vv -F gives this: > > > > > > > > > > /sbin/restorecon reset context > > > -> > > > > > > > > This is probably because is a customizable > type > > > like > > > > httpd_sys_content_t; objects with these types don't get reset by > > > > restorecon unless you use -F. I'm not sure how to find out which > > > types > > > > are customizable off the top of my head though. > > > > > > cat /etc/selinux/$SELINUXTYPE/contexts/customizable_types > > > > > > Dan - I thought we had discussed reducing that set significantly > since > > > it was originally to avoid clobbering locally-set types upon a > > > filesystem relabel prior to the introduction of semanage, but with > > > users > > > now able to add local file contexts easily via semanage fcontext > -a, > > > it > > > isn't as necessary. > > > > This is exactly my situation. I am using Fedora 8 with all the > latest > > updates. I had used semanage to add a filecontext which would cause > > particular directories to be labeled with the type > httpd_sys_script_rw_t > > which is a customizable type. > > > > The directory I was trying to label was under /var/www which has a > > context of httpd_sys_content_t which is also a customizabile type. > So > > why is it that new directories under /var/www are automatically > labeled > > with the httpd_sys_content_t type, but things that match my added > > filecontext don't automatically get labeled with > httpd_sys_script_rw_t, > > and require the use of restorecon -F? > > > > Here's the specifics: > > > > The command I used to add my local context: > > semanage fcontext -d -f -d -t httpd_sys_script_rw_t > > "/var/www/wikis/[^/]+/images" > > This adds the entry to your file contexts configuration, a mapping > from > pathname regexes to file security contexts that is used to determine > the > right security context for a file when it is first installed (e.g. by > rpm) or when you want to reset the filesystem to its initial state > (e.g. > via restorecon or fixfiles relabel), but not at runtime by the kernel. > > > I then create a directory that matches the above pattern: > > mkdir -p /var/www/wikis/foo/images > > > > The directory is created, but has the type httpd_sys_content_t. > > For runtime file creation, the kernel labels new files based on > either: > 1) a type transition rule in the policy if one exists for the creating > process' domain, the parent directory type, and the new file's > security > class (object type - e.g. regular file, directory, symlink, device > node), or > 2) the parent directory's type if no type transition rule matches. > > The file contexts configuration is not used by the kernel and is only > supposed to represent the initial install-time state of the > filesystem. > > > Now I use restorecon to relabel: > > restorecon -vv /var/www/wikis/foo/images > > restorecon does consult the file contexts configuration. > > > This gives me the following message: > > /sbin/restorecon: /var/www/wikis/foo/images not reset customized by > > admin to system_u:object_r:httpd_sys_content_t:s0 > > This is because the existing type on the file is a customizable type > and > thus may have been manually set by the admin via chcon - this approach > predates the introduction of semanage and as Dan said, customizable > types has been dropped in rawhide / Fedora 9, so you won't encounter > this problem going forward there. > > > Now run restorecon with the force flag: > > restorecon -vv -F /var/www/wikis/foo/images > > > > Gives this message: > > restorecon reset /var/www/wikis/foo/images context > > > system_u:object_r:httpd_sys_content_t:s0->system_u:object_r:httpd_sys_script_rw_t:s0 > > > > Since both types are in the customizable_types file, why is one > > automatically used, and the other only used when forced? > > If by automatically used, you mean at new file creation, neither file > contexts nor customizable types has anything to do with that. If you > mean by restorecon, the restorecon logic is simply to not relabel a > file > that has a customizable type since it may have been manually set by > the > admin. Thanks. The feedback I've gotten has greatly clarified my understanding of how SELinux labeling works. - Tim From selinux at dylanwood.com Wed Mar 19 15:26:21 2008 From: selinux at dylanwood.com (selinux .) Date: Wed, 19 Mar 2008 10:26:21 -0500 Subject: problems using refpolicy Message-ID: I'm on fc8 and have recently installed refpolicy. However, I can't get KDE to work. It says that it was unable to get the network connections list and that it can't connect to dcopserver. There are a lot of error messages -- many about hotplug, which I don't think are relevant. There are some though, saying that selinux is preventing things from using potentially mislabeled files in the /tmp directory. I've done every combination of installation configurations and relabelings that I can think of. I don't know exactly what error messages are relevant, so I put dmesg output and the messages file (only containing one boot-up) on a website -- http://www.hostingsimplicity.net/ I made condensed versions of the dmesg and messages output, but put the full ones there to. Also, there is all the output from running sealert on the items listed in messages. I hate to ask someone to look at this for me, but if it is a common problem that I haven't found in the archives, or if you think you can help, please do... Sincerely, dylan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sds at tycho.nsa.gov Wed Mar 19 15:56:05 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 19 Mar 2008 11:56:05 -0400 Subject: problems using refpolicy In-Reply-To: References: Message-ID: <1205942165.6466.269.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-03-19 at 10:26 -0500, selinux . wrote: > I'm on fc8 and have recently installed refpolicy. Why? Fedora ships with a policy built from refpolicy already. Only reason to switch to upstream refpolicy is if you have a particular need that isn't being met by the default policy. And given that F8 policy merges targeted and strict together, you don't have to wholesale replace your policy to apply strict policy if that is your goal. > However, I can't get KDE to work. It says that it was unable to get > the network connections list and that it can't connect to dcopserver. > There are a lot of error messages -- many about hotplug, which I don't > think are relevant. There are some though, saying that selinux is > preventing things from using potentially mislabeled files in the /tmp > directory. I've done every combination of installation configurations > and relabelings that I can think of. > > I don't know exactly what error messages are relevant, so I put dmesg > output and the messages file (only containing one boot-up) on a > website -- http://www.hostingsimplicity.net/ I made condensed > versions of the dmesg and messages output, but put the full ones there > to. Also, there is all the output from running sealert on the items > listed in messages. > > I hate to ask someone to look at this for me, but if it is a common > problem that I haven't found in the archives, or if you think you can > help, please do... > > Sincerely, > > dylan > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -- Stephen Smalley National Security Agency From phosmane at ntis.gov Wed Mar 19 18:51:39 2008 From: phosmane at ntis.gov (pselinux) Date: Wed, 19 Mar 2008 11:51:39 -0700 (PDT) Subject: aduitd failing to start Message-ID: <16148276.post@talk.nabble.com> Hi, I am on Red Hat Linux enterprise 5 (Dell 1950). Auditing is failing to start. This is the message in messages file Mar 19 10:14:08 myhost kernel: input: USB HID v1.00 Keyboard [Silitek Standard USB Keyboard ] on usb-0000:00:1d.7-5.1 Mar 19 10:14:36 myhost restorecond: Will not restore a file with more than one hard link (/etc/resolv.conf) No such file or directory Mar 19 10:19:10 myhost restorecond: Will not restore a file with more than one hard link (/etc/resolv.conf) Invalid argument Mar 19 10:20:22 myhost restorecond: Will not restore a file with more than one hard link (/etc/resolv.conf) Invalid argument Mar 19 12:20:01 myhost dbus: Can't send to audit system: USER_AVC avc: received policyload notice (seqno=14) : exe="?" (sauid=81, hostname=?, addr=?, terminal=?) Mar 19 12:27:42 myhost kernel: audit(1205944062.921:39): avc: denied { getattr } for pid=32443 comm="auditd" path="/etc/resolv.conf" dev=sda3 ino=15124046 scontext=user_u:system_r:auditd_t:s0 tcontext=system_u:object_r:net_conf_t:s0 tclass=file Mar 19 12:27:42 myhost kernel: audit(1205944062.922:40): avc: denied { connect } for pid=32443 comm="auditd" scontext=user_u:system_r:auditd_t:s0 tcontext=user_u:system_r:auditd_t:s0 tclass=udp_socket Mar 19 12:27:42 myhost kernel: audit(1205944062.922:41): avc: denied { connect } for pid=32443 comm="auditd" scontext=user_u:system_r:auditd_t:s0 tcontext=user_u:system_r:auditd_t:s0 tclass=udp_socket Mar 19 12:27:42 myhost kernel: audit(1205944062.922:42): avc: denied { connect } for pid=32443 comm="auditd" scontext=user_u:system_r:auditd_t:s0 tcontext=user_u:system_r:auditd_t:s0 tclass=udp_socket Mar 19 12:27:42 myhost kernel: audit(1205944062.923:43): avc: denied { connect } for pid=32443 comm="auditd" scontext=user_u:system_r:auditd_t:s0 tcontext=user_u:system_r:auditd_t:s0 tclass=udp_socket Mar 19 12:27:42 myhost auditd: The audit daemon is exiting. then i did the following get auditd /var/log/messages|audit2allow -M auditsocket semodule -i auditsocket.pp i tried starting auditd again, it kept giving me messages for auditd denied, right now i see this Mar 19 14:05:37 myhost kernel: audit(1205949937.512:117): avc: denied { getattr } for pid=3899 comm="auditd" path="socket:[21080]" dev=sockfs ino=21080 scontext=user_u:system_ r:auditd_t:s0 tcontext=user_u:system_r:auditd_t:s0 tclass=udp_socket Mar 19 14:05:37 myhost kernel: audit(1205949937.512:118): avc: denied { read } for pid=3899 comm="auditd" laddr=xx.xx.xx.xx lport=32769 faddr=xx.xx.xx.xx fport=53 scontex t=user_u:system_r:auditd_t:s0 tcontext=user_u:system_r:auditd_t:s0 tclass=udp_socket Mar 19 14:05:37 myhost kernel: audit(1205949937.513:119): avc: denied { read } for pid=3899 comm="auditd" laddr=xx.xx.xx.xx lport=32769 faddr=xx.xx.xx.xx fport=53 scontex t=user_u:system_r:auditd_t:s0 tcontext=user_u:system_r:auditd_t:s0 tclass=udp_socket Mar 19 14:05:37 myhost kernel: audit(1205949937.514:120): avc: denied { read } for pid=3899 comm="auditd" laddr=xx.xx.xx.xx lport=32769 faddr=xx.xx.xx.xx fport=53 scontex t=user_u:system_r:auditd_t:s0 tcontext=user_u:system_r:auditd_t:s0 tclass=udp_socket Mar 19 14:05:37 myhost kernel: audit(1205949937.515:121): avc: denied { read } for pid=3899 comm="auditd" laddr=xx.xx.xx.xx lport=32769 faddr=xx.xx.xx.xx fport=53 scontex t=user_u:system_r:auditd_t:s0 tcontext=user_u:system_r:auditd_t:s0 tclass=udp_socket Mar 19 14:05:37 learn6 auditd: The audit daemon is exiting. I need help to resolve this above issue. Am i doing something wrong? Can someone help me please. i do not want to disable SELinux. Thanks in advance. -- View this message in context: http://www.nabble.com/aduitd-failing-to-start-tp16148276p16148276.html Sent from the Fedora SELinux List mailing list archive at Nabble.com. From linux_4ever at yahoo.com Wed Mar 19 19:26:36 2008 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 19 Mar 2008 12:26:36 -0700 (PDT) Subject: aduitd failing to start Message-ID: <798760.867.qm@web51506.mail.re2.yahoo.com> > I am on Red Hat Linux enterprise 5 (Dell 1950). Auditing is failing to > start. This is the message in messages file This looks like dns name resolution. Which auditd version are you running? Did you enable name_format = fqdin auditd.conf? You could temporarily change that setting to none orhostname. but maybe you should file a bz for this, too. -Steve ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From phosmane at ntis.gov Wed Mar 19 19:57:24 2008 From: phosmane at ntis.gov (Pad Hosmane) Date: Wed, 19 Mar 2008 15:57:24 -0400 Subject: aduitd failing to start In-Reply-To: <798760.867.qm@web51506.mail.re2.yahoo.com> References: <798760.867.qm@web51506.mail.re2.yahoo.com> Message-ID: <8647E63ABA86C941B70F1058189C22E5065BB1C6@ntis_exchange.ntis2.gov> > I am on Red Hat Linux enterprise 5 (Dell 1950). Auditing is failing to > start. This is the message in messages file This looks like dns name resolution. Which auditd version are you running? Did you enable name_format = fqdin auditd.conf? You could temporarily change that setting to none orhostname. but maybe you should file a bz for this, too. Hi steve, Thank you for the reply. Current version is audit-1.5.5-7.el5. Man pages for auditd.conf do not show name_format option. Anyway I tried both options name_format = none and name_format = hostname and still auditd fails to startup. Thanks From ekuns at kilroy.chi.il.us Thu Mar 20 00:42:55 2008 From: ekuns at kilroy.chi.il.us (Edward Kuns) Date: Wed, 19 Mar 2008 19:42:55 -0500 Subject: Current status of mailman and clamav selinux Message-ID: <1205973775.26916.264.camel@kilroy.chi.il.us> With current policies from RH8 updates, I removed the clamav policy I had in place to see what current AVCs I receive. All AVCs I receive regularly are related to mailman. I get a *lot* of this: host=kilroy.chi.il.us type=AVC msg=audit(1205972595.706:10245): avc: denied { read write } for pid=28531 comm="mailman" path="socket:[3905242]" dev=sockfs ino=3905242 scontext=system_u:system_r:mailman_mail_t:s0 tcontext=system_u:system_r:sendmail_t:s0 tclass=unix_stream_socket host=kilroy.chi.il.us type=SYSCALL msg=audit(1205972595.706:10245): arch=40000003 syscall=11 success=yes exit=0 a0=8845e78 a1=8845f48 a2=88454f8 a3=40 items=0 ppid=28530 pid=28531 auid=4294967295 uid=8 gid=12 euid=8 suid=8 fsuid=8 egid=41 sgid=41 fsgid=41 tty=(none) comm="mailman" exe="/usr/lib/mailman/mail/mailman" subj=system_u:system_r:mailman_mail_t:s0 key=(null) which I suspect is sendmail not closing a socket before it forks mailman, but I am not certain how to judge, nor how to get sendmail to address the issue. The one I get more rarely seems to occur once every time clamav finds a virus. I get the following collection of AVCs for each virus discovered by clamav: type=AVC msg=audit(1205970966.746:10166): avc: denied { append } for pid=26516 comm="sendmail" path="/var/log/clamd.milter" dev=dm-2 ino=327743 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:clamd_var_log_t:s0 tclass=file type=AVC msg=audit(1205970966.746:10166): avc: denied { append } for pid=26516 comm="sendmail" path="/var/log/clamd.milter" dev=dm-2 ino=327743 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:clamd_var_log_t:s0 tclass=file type=AVC msg=audit(1205970966.746:10166): avc: denied { read write } for pid=26516 comm="sendmail" path="socket:[3831091]" dev=sockfs ino=3831091 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:system_r:clamd_t:s0 tclass=unix_stream_socket type=AVC msg=audit(1205970966.746:10166): avc: denied { read write } for pid=26516 comm="sendmail" path="socket:[3855167]" dev=sockfs ino=3855167 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:system_r:clamd_t:s0 tclass=unix_stream_socket type=AVC msg=audit(1205970966.746:10166): avc: denied { read write } for pid=26516 comm="sendmail" path="/var/tmp/clamav-00c6b962e3f10e1caad8ced3cff4e084/msg.2Orwhh" dev=dm-2 ino=32843 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:clamd_tmp_t:s0 tclass=file host=kilroy.chi.il.us type=SYSCALL msg=audit(1205970966.746:10166): arch=40000003 syscall=11 success=yes exit=0 a0=89d56d0 a1=89d57a8 a2=89d4b98 a3=40 items=0 ppid=2867 pid=26516 auid=4294967295 uid=492 gid=486 euid=492 suid=492 fsuid=492 egid=51 sgid=51 fsgid=51 tty=(none) comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=system_u:system_r:system_mail_t:s0 key=(null) The setroubleshoot browser message associated with these AVCs is: "SELinux is preventing sendmail (system_mail_t) "append" to /var/log/clamd.milter (clamd_var_log_t)." For now I've created a new myclamav policy from the above AVCs (just the 2nd set listed). Eddie -- Eddie Kuns | Home: ekuns at kilroy.chi.il.us --------------/ URL: http://kilroy.chi.il.us/ "Ah, savory cheese puffs, made inedible by time and fate." -- The Tick From valent.turkovic at gmail.com Thu Mar 20 07:37:44 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 20 Mar 2008 08:37:44 +0100 Subject: firefox alert In-Reply-To: <47DE5633.4030700@redhat.com> References: <64b14b300803170130o39a81779rf6fdb363f418f4de@mail.gmail.com> <47DE5633.4030700@redhat.com> Message-ID: <64b14b300803200037s33283bcbic43db3ef5fc16731@mail.gmail.com> On Mon, Mar 17, 2008 at 12:29 PM, Josef Kubin wrote: > Relabel your system. > > Cheers, > Josef. > I relabeled it and it now works without alerts. Would there be a reason to relabel file system in cron job once a month? Cheers, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From valent.turkovic at gmail.com Thu Mar 20 07:40:37 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 20 Mar 2008 08:40:37 +0100 Subject: livecd-creator crashes setroubleshoot and makes lots of alerts Message-ID: <64b14b300803200040l5df18bs48325403d4b73eef@mail.gmail.com> Hi, I'm testing livecd-creator under rawhide and I see a lot of alerts and setroubleshoot service crashes. Here it grep setroubleshoot /var/log/audit/audit.log > setroubleshoot.log Cheers, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic -------------- next part -------------- A non-text attachment was scrubbed... Name: setroubleshoot.log Type: text/x-log Size: 10579 bytes Desc: not available URL: From lordmorgul at gmail.com Thu Mar 20 08:29:06 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Thu, 20 Mar 2008 01:29:06 -0700 Subject: firefox alert In-Reply-To: <64b14b300803200037s33283bcbic43db3ef5fc16731@mail.gmail.com> References: <64b14b300803170130o39a81779rf6fdb363f418f4de@mail.gmail.com> <47DE5633.4030700@redhat.com> <64b14b300803200037s33283bcbic43db3ef5fc16731@mail.gmail.com> Message-ID: <47E22052.6090209@gmail.com> Valent Turkovic wrote: > On Mon, Mar 17, 2008 at 12:29 PM, Josef Kubin wrote: >> Relabel your system. >> >> Cheers, >> Josef. >> > > I relabeled it and it now works without alerts. > > Would there be a reason to relabel file system in cron job once a month? In a test system I think its usually a good idea to touch /.autorelabel; reboot after every policy update, and I usually do it for every new kernel as well. Its probably not needed nearly this much but I think it has helped. (then again, I do have an abnormal number of weird selinux audits right now, like gdm setting my user to bootloader_t on login) -- Andrew Farris www.lordmorgul.net gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From sds at tycho.nsa.gov Thu Mar 20 12:36:42 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 20 Mar 2008 08:36:42 -0400 Subject: aduitd failing to start In-Reply-To: <16148276.post@talk.nabble.com> References: <16148276.post@talk.nabble.com> Message-ID: <1206016602.32000.24.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-03-19 at 11:51 -0700, pselinux wrote: > Hi, > I am on Red Hat Linux enterprise 5 (Dell 1950). Auditing is failing to > start. This is the message in messages file > > Mar 19 10:14:08 myhost kernel: input: USB HID v1.00 Keyboard [Silitek > Standard USB Keyboard ] on usb-0000:00:1d.7-5.1 > Mar 19 10:14:36 myhost restorecond: Will not restore a file with more than > one hard link (/etc/resolv.conf) No such file or directory > Mar 19 10:19:10 myhost restorecond: Will not restore a file with more than > one hard link (/etc/resolv.conf) Invalid argument > Mar 19 10:20:22 myhost restorecond: Will not restore a file with more than > one hard link (/etc/resolv.conf) Invalid argument > Mar 19 12:20:01 myhost dbus: Can't send to audit system: USER_AVC avc: > received policyload notice (seqno=14) : exe="?" (sauid=81, hostname=?, > addr=?, terminal=?) > Mar 19 12:27:42 myhost kernel: audit(1205944062.921:39): avc: denied { > getattr } for pid=32443 comm="auditd" path="/etc/resolv.conf" dev=sda3 > ino=15124046 scontext=user_u:system_r:auditd_t:s0 > tcontext=system_u:object_r:net_conf_t:s0 tclass=file > Mar 19 12:27:42 myhost kernel: audit(1205944062.922:40): avc: denied { > connect } for pid=32443 comm="auditd" scontext=user_u:system_r:auditd_t:s0 > tcontext=user_u:system_r:auditd_t:s0 tclass=udp_socket > Mar 19 12:27:42 myhost kernel: audit(1205944062.922:41): avc: denied { > connect } for pid=32443 comm="auditd" scontext=user_u:system_r:auditd_t:s0 > tcontext=user_u:system_r:auditd_t:s0 tclass=udp_socket > Mar 19 12:27:42 myhost kernel: audit(1205944062.922:42): avc: denied { > connect } for pid=32443 comm="auditd" scontext=user_u:system_r:auditd_t:s0 > tcontext=user_u:system_r:auditd_t:s0 tclass=udp_socket > Mar 19 12:27:42 myhost kernel: audit(1205944062.923:43): avc: denied { > connect } for pid=32443 comm="auditd" scontext=user_u:system_r:auditd_t:s0 > tcontext=user_u:system_r:auditd_t:s0 tclass=udp_socket > Mar 19 12:27:42 myhost auditd: The audit daemon is exiting. > > then i did the following > > get auditd /var/log/messages|audit2allow -M auditsocket > semodule -i auditsocket.pp > > i tried starting auditd again, it kept giving me messages for auditd denied, > right now i see this > > Mar 19 14:05:37 myhost kernel: audit(1205949937.512:117): avc: denied { > getattr } for pid=3899 comm="auditd" path="socket:[21080]" dev=sockfs > ino=21080 scontext=user_u:system_ > r:auditd_t:s0 tcontext=user_u:system_r:auditd_t:s0 tclass=udp_socket > Mar 19 14:05:37 myhost kernel: audit(1205949937.512:118): avc: denied { > read } for pid=3899 comm="auditd" laddr=xx.xx.xx.xx lport=32769 > faddr=xx.xx.xx.xx fport=53 scontex > t=user_u:system_r:auditd_t:s0 tcontext=user_u:system_r:auditd_t:s0 > tclass=udp_socket > Mar 19 14:05:37 myhost kernel: audit(1205949937.513:119): avc: denied { > read } for pid=3899 comm="auditd" laddr=xx.xx.xx.xx lport=32769 > faddr=xx.xx.xx.xx fport=53 scontex > t=user_u:system_r:auditd_t:s0 tcontext=user_u:system_r:auditd_t:s0 > tclass=udp_socket > Mar 19 14:05:37 myhost kernel: audit(1205949937.514:120): avc: denied { > read } for pid=3899 comm="auditd" laddr=xx.xx.xx.xx lport=32769 > faddr=xx.xx.xx.xx fport=53 scontex > t=user_u:system_r:auditd_t:s0 tcontext=user_u:system_r:auditd_t:s0 > tclass=udp_socket > Mar 19 14:05:37 myhost kernel: audit(1205949937.515:121): avc: denied { > read } for pid=3899 comm="auditd" laddr=xx.xx.xx.xx lport=32769 > faddr=xx.xx.xx.xx fport=53 scontex > t=user_u:system_r:auditd_t:s0 tcontext=user_u:system_r:auditd_t:s0 > tclass=udp_socket > Mar 19 14:05:37 learn6 auditd: The audit daemon is exiting. > > I need help to resolve this above issue. Am i doing something wrong? Can > someone help me please. > > i do not want to disable SELinux. So on the first attempt, auditd only got so far in its initialization before exiting and thus didn't generate the later set of audit messages. You can keep interatively generating new policy modules as you did above and inserting them until you get a working auditd, or you can just switch to permissive mode temporarily (setenforce 0), start auditd to generate the full set of audit messages, and generate the final policy module in one go. Then switch back to enforcing mode (setenforce 1). A finer-grained way of doing this is coming via permissive domains, where you can make a single domain permissive. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Thu Mar 20 13:07:44 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 20 Mar 2008 09:07:44 -0400 Subject: livecd-creator crashes setroubleshoot and makes lots of alerts In-Reply-To: <64b14b300803200040l5df18bs48325403d4b73eef@mail.gmail.com> References: <64b14b300803200040l5df18bs48325403d4b73eef@mail.gmail.com> Message-ID: <47E261A0.4040802@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Valent Turkovic wrote: > Hi, > I'm testing livecd-creator under rawhide and I see a lot of alerts and > setroubleshoot service crashes. > > Here it > grep setroubleshoot /var/log/audit/audit.log > setroubleshoot.log > > Cheers, > Valent. > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list livecd-creater is going to load a different policy than what you have on your host machine. THis will cause processes to loose their context and become unlabeled_t, sometimes files will loose their labels. The best way to use livecd-creator is setenforce 0 livecd-creator ... load_policy setenforce 1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfiYaAACgkQrlYvE4MpobMezwCgo1f3dEGDfzgTGciTT9p59KHj bOsAoLhozx3ewyZfycINQMacOoHHrWcA =JBoN -----END PGP SIGNATURE----- From dwalsh at redhat.com Thu Mar 20 13:08:53 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 20 Mar 2008 09:08:53 -0400 Subject: firefox alert In-Reply-To: <47E22052.6090209@gmail.com> References: <64b14b300803170130o39a81779rf6fdb363f418f4de@mail.gmail.com> <47DE5633.4030700@redhat.com> <64b14b300803200037s33283bcbic43db3ef5fc16731@mail.gmail.com> <47E22052.6090209@gmail.com> Message-ID: <47E261E5.5000605@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Farris wrote: > Valent Turkovic wrote: >> On Mon, Mar 17, 2008 at 12:29 PM, Josef Kubin wrote: >>> Relabel your system. >>> >>> Cheers, >>> Josef. >>> >> >> I relabeled it and it now works without alerts. >> >> Would there be a reason to relabel file system in cron job once a month? > > In a test system I think its usually a good idea to touch /.autorelabel; > reboot after every policy update, and I usually do it for every new > kernel as well. Its probably not needed nearly this much but I think it > has helped. (then again, I do have an abnormal number of weird selinux > audits right now, like gdm setting my user to bootloader_t on login) > By any change do you have seedit installed? If yes remove it. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfiYeUACgkQrlYvE4MpobPW2ACfYFGaqNEf0LtpbiYcHZRHblHO 7ckAn1qWyeSCuyJBPcGvC56uxSLnrQ7J =plnA -----END PGP SIGNATURE----- From dwalsh at redhat.com Thu Mar 20 13:48:43 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 20 Mar 2008 09:48:43 -0400 Subject: Current status of mailman and clamav selinux In-Reply-To: <1205973775.26916.264.camel@kilroy.chi.il.us> References: <1205973775.26916.264.camel@kilroy.chi.il.us> Message-ID: <47E26B3B.4090804@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Edward Kuns wrote: > With current policies from RH8 updates, I removed the clamav policy I > had in place to see what current AVCs I receive. All AVCs I receive > regularly are related to mailman. > > I get a *lot* of this: > > host=kilroy.chi.il.us type=AVC msg=audit(1205972595.706:10245): avc: > denied { read write } for pid=28531 comm="mailman" > path="socket:[3905242]" dev=sockfs ino=3905242 > scontext=system_u:system_r:mailman_mail_t:s0 > tcontext=system_u:system_r:sendmail_t:s0 tclass=unix_stream_socket > host=kilroy.chi.il.us type=SYSCALL msg=audit(1205972595.706:10245): > arch=40000003 syscall=11 success=yes exit=0 a0=8845e78 a1=8845f48 > a2=88454f8 a3=40 items=0 ppid=28530 pid=28531 auid=4294967295 uid=8 > gid=12 euid=8 suid=8 fsuid=8 egid=41 sgid=41 fsgid=41 tty=(none) > comm="mailman" exe="/usr/lib/mailman/mail/mailman" > subj=system_u:system_r:mailman_mail_t:s0 key=(null) > > which I suspect is sendmail not closing a socket before it forks > mailman, but I am not certain how to judge, nor how to get sendmail to > address the issue. > > > The one I get more rarely seems to occur once every time clamav finds a > virus. I get the following collection of AVCs for each virus discovered > by clamav: > > type=AVC msg=audit(1205970966.746:10166): avc: denied { append } for > pid=26516 comm="sendmail" path="/var/log/clamd.milter" dev=dm-2 > ino=327743 scontext=system_u:system_r:system_mail_t:s0 > tcontext=system_u:object_r:clamd_var_log_t:s0 tclass=file > type=AVC msg=audit(1205970966.746:10166): avc: denied { append } for > pid=26516 comm="sendmail" path="/var/log/clamd.milter" dev=dm-2 > ino=327743 scontext=system_u:system_r:system_mail_t:s0 > tcontext=system_u:object_r:clamd_var_log_t:s0 tclass=file > type=AVC msg=audit(1205970966.746:10166): avc: denied { read write } > for pid=26516 comm="sendmail" path="socket:[3831091]" dev=sockfs > ino=3831091 scontext=system_u:system_r:system_mail_t:s0 > tcontext=system_u:system_r:clamd_t:s0 tclass=unix_stream_socket > type=AVC msg=audit(1205970966.746:10166): avc: denied { read write } > for pid=26516 comm="sendmail" path="socket:[3855167]" dev=sockfs > ino=3855167 scontext=system_u:system_r:system_mail_t:s0 > tcontext=system_u:system_r:clamd_t:s0 tclass=unix_stream_socket > type=AVC msg=audit(1205970966.746:10166): avc: denied { read write } > for pid=26516 comm="sendmail" > path="/var/tmp/clamav-00c6b962e3f10e1caad8ced3cff4e084/msg.2Orwhh" > dev=dm-2 ino=32843 scontext=system_u:system_r:system_mail_t:s0 > tcontext=system_u:object_r:clamd_tmp_t:s0 tclass=file > host=kilroy.chi.il.us type=SYSCALL msg=audit(1205970966.746:10166): > arch=40000003 syscall=11 success=yes exit=0 a0=89d56d0 a1=89d57a8 > a2=89d4b98 a3=40 items=0 ppid=2867 pid=26516 auid=4294967295 uid=492 > gid=486 euid=492 suid=492 fsuid=492 egid=51 sgid=51 fsgid=51 tty=(none) > comm="sendmail" exe="/usr/sbin/sendmail.sendmail" > subj=system_u:system_r:system_mail_t:s0 key=(null) > > The setroubleshoot browser message associated with these AVCs is: > "SELinux is preventing sendmail (system_mail_t) "append" > to /var/log/clamd.milter (clamd_var_log_t)." For now I've created a new > myclamav policy from the above AVCs (just the 2nd set listed). > > Eddie > I will add append, actually I am just going to allow system_mail_t to append to all log files. The others all seem to be leaked file descriptors. audit2allow -i /tmp/t #============= mailman_mail_t ============== allow mailman_mail_t sendmail_t:unix_stream_socket { read write }; #============= system_mail_t ============== allow system_mail_t clamd_t:unix_stream_socket { read write }; allow system_mail_t clamd_tmp_t:file { read write }; I think clamd is leaking. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfiazsACgkQrlYvE4MpobNW7wCePJ7K2OGKrZcnLr3Xq3zBgB+T wjkAn3WBi3OcB/FWtl3MamaPxUVgd9Nm =R9XE -----END PGP SIGNATURE----- From phosmane at ntis.gov Thu Mar 20 15:02:29 2008 From: phosmane at ntis.gov (Pad Hosmane) Date: Thu, 20 Mar 2008 11:02:29 -0400 Subject: aduitd failing to start In-Reply-To: <1206016602.32000.24.camel@moss-spartans.epoch.ncsc.mil> References: <16148276.post@talk.nabble.com> <1206016602.32000.24.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <8647E63ABA86C941B70F1058189C22E5065BB1C9@ntis_exchange.ntis2.gov> > i tried starting auditd again, it kept giving me messages for auditd denied, > right now i see this > > Mar 19 14:05:37 myhost kernel: audit(1205949937.512:117): avc: denied { > getattr } for pid=3899 comm="auditd" path="socket:[21080]" dev=sockfs > ino=21080 scontext=user_u:system_ > r:auditd_t:s0 tcontext=user_u:system_r:auditd_t:s0 tclass=udp_socket > Mar 19 14:05:37 myhost kernel: audit(1205949937.512:118): avc: denied { > read } for pid=3899 comm="auditd" laddr=xx.xx.xx.xx lport=32769 > faddr=xx.xx.xx.xx fport=53 scontex > t=user_u:system_r:auditd_t:s0 tcontext=user_u:system_r:auditd_t:s0 > Mar 19 14:05:37 myhost kernel: audit(1205949937.515:121): avc: denied { > read } for pid=3899 comm="auditd" laddr=xx.xx.xx.xx lport=32769 > faddr=xx.xx.xx.xx fport=53 scontex > t=user_u:system_r:auditd_t:s0 tcontext=user_u:system_r:auditd_t:s0 > tclass=udp_socket > Mar 19 14:05:37 learn6 auditd: The audit daemon is exiting. > > I need help to resolve this above issue. Am i doing something wrong? Can > someone help me please. > > i do not want to disable SELinux. So on the first attempt, auditd only got so far in its initialization before exiting and thus didn't generate the later set of audit messages. You can keep interatively generating new policy modules as you did above and inserting them until you get a working auditd, or you can just switch to permissive mode temporarily (setenforce 0), start auditd to generate the full set of audit messages, and generate the final policy module in one go. Then switch back to enforcing mode (setenforce 1). A finer-grained way of doing this is coming via permissive domains, where you can make a single domain permissive. -- Stephen Smalley National Security Agency Hi Stephen, Thank you for the reply. I interactively generated the new policy modules and inserted it. I repeated 6 times. Now auditd do not start and no selinux related messages in the system logs. Only message I see is "The audit daemon is exiting". No messages in /var/log/audit either. I tried setting selinux in permissive mode, and auditd won't start in this mode. With out enabling audit I cannot put this server in production. Any input greatly appreciated. Thanks in advance. From sds at tycho.nsa.gov Thu Mar 20 15:55:40 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 20 Mar 2008 11:55:40 -0400 Subject: aduitd failing to start In-Reply-To: <8647E63ABA86C941B70F1058189C22E5065BB1C9@ntis_exchange.ntis2.gov> References: <16148276.post@talk.nabble.com> <1206016602.32000.24.camel@moss-spartans.epoch.ncsc.mil> <8647E63ABA86C941B70F1058189C22E5065BB1C9@ntis_exchange.ntis2.gov> Message-ID: <1206028540.32000.49.camel@moss-spartans.epoch.ncsc.mil> >>Hi Stephen, >> Thank you for the reply. I interactively generated the new policy >>modules and inserted it. I repeated 6 times. Now auditd do not start and >>no selinux related messages in the system logs. Only message I see is >>"The audit daemon is exiting". No messages in /var/log/audit either. >>I tried setting selinux in permissive mode, and auditd won't start in >>this mode. >>With out enabling audit I cannot put this server in production. Any >>input greatly appreciated. What precise output do you get upon: # /sbin/service auditd restart And what is your audit configuration (under /etc/audit)? No output in /var/log/audit/audit.log? -- Stephen Smalley National Security Agency From sundaram at fedoraproject.org Thu Mar 20 16:17:54 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 20 Mar 2008 21:47:54 +0530 Subject: Performance difference Message-ID: <47E28E32.8080203@fedoraproject.org> Hi, Is there any performance differences between having selinux disabled via a the configuration file vs disabling it in the bootloader? If so. is this considered a bug? Rahul From linux_4ever at yahoo.com Thu Mar 20 16:39:42 2008 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 20 Mar 2008 09:39:42 -0700 (PDT) Subject: aduitd failing to start Message-ID: <821705.85973.qm@web51507.mail.re2.yahoo.com> > Thank you for the reply. Current version is audit-1.5.5-7.el5. OK, I thought you were running something newer from 5.2 beta. This uses the old event dispatcher which doesn't do anything fancy. Maybe you would want to try disabling the dispatcher and see if you are still having a problem. Add a # at the beginning of the line for dispatcher= in /etc/audit/auditd.conf. This will affect setroubleshoot, though. But I got to admit that I haven't seen this kind of behavior before for the older software. Do you have auditd.conf setup to send email alerts? Also, avcs don't tell you the whole story alone. You may need to temporarily add a simple rule like, "-w /etc/shadow -p w", to /etc/audit/audit.rules to trigger more detailed information. This sounds like a program that is being run from auditd doesn't have an auto transition and therefore appears as if it were auditd_t. > Man pages for auditd.conf do not show name_format option. Anyway I tried > both options name_format = none and name_format = hostname and still > auditd fails to startup. Yeah, that's for the newer 5.2 version. -Steve ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From phosmane at ntis.gov Thu Mar 20 16:42:19 2008 From: phosmane at ntis.gov (Pad Hosmane) Date: Thu, 20 Mar 2008 12:42:19 -0400 Subject: aduitd failing to start In-Reply-To: <1206028540.32000.49.camel@moss-spartans.epoch.ncsc.mil> References: <16148276.post@talk.nabble.com> <1206016602.32000.24.camel@moss-spartans.epoch.ncsc.mil> <8647E63ABA86C941B70F1058189C22E5065BB1C9@ntis_exchange.ntis2.gov> <1206028540.32000.49.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <8647E63ABA86C941B70F1058189C22E5065BB1CA@ntis_exchange.ntis2.gov> >>Hi Stephen, >> Thank you for the reply. I interactively generated the new policy >>modules and inserted it. I repeated 6 times. Now auditd do not start and >>no selinux related messages in the system logs. Only message I see is >>"The audit daemon is exiting". No messages in /var/log/audit either. >>I tried setting selinux in permissive mode, and auditd won't start in >>this mode. >>With out enabling audit I cannot put this server in production. Any >>input greatly appreciated. What precise output do you get upon: # /sbin/service auditd restart Output I get is Starting auditd: [FAILED] And what is your audit configuration (under /etc/audit)? Below is the content of /etc/audit/auditd.conf file # # This file controls the configuration of the audit daemon # log_file = /var/log/audit/audit.log log_format = RAW priority_boost = 3 flush = INCREMENTAL freq = 20 num_logs = 4 dispatcher = /sbin/audispd disp_qos = lossy max_log_file = 30 max_log_file_action = ROTATE space_left = 75 #space_left_action = SYSLOG space_left_action = email action_mail_acct = scook at ntis.gov admin_space_left = 50 admin_space_left_action = SUSPEND disk_full_action = SUSPEND disk_error_action = SUSPEND No output in /var/log/audit/audit.log? No entry gets logged into /var/log/audit/audit.log BTW I forgot to mention this in my earlier emails...sorry....sorry, I hope this might help. Audit used to work and stopped working, this is the sequence of events happened before audit stopped. 1. I set SELinux to disabled (I think, no sure about permissive), since apache and java app was causing lot of issues while startup. To debug this issue I had to disable selinux. 2. Finally I figured it was something else that caused apache and java app errors. 3. Then I enabled SELinux and created /.autorelabel and rebooted it. When I was going through system check list then I found out that audit was starting. Here is the last couple of entries (on Feb 29th, 08) in /var/log/audit.log type=CWD msg=audit(1204313263.896:1829993): cwd="/" type=PATH msg=audit(1204313263.896:1829993): item=0 name="/usr/lib/locale/locale-archive" inode=12838402 dev=08:03 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:locale_t:s0 type=SYSCALL msg=audit(1204313263.896:1829994): arch=40000003 syscall=5 success=yes exit=3 a0=9c0bce8 a1=8000 a2=0 a3=8000 items=1 ppid=10587 pid=10597 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="id" exe="/usr/bin/id" subj=system_u:system_r:initrc_t:s0 key=(null) type=CWD msg=audit(1204313263.896:1829994): cwd="/" type=PATH msg=audit(1204313263.896:1829994): item=0 name="/proc/self/task/10597/attr/current" inode=694485046 dev=00:03 mode=0100666 ouid=0 ogid=0 rdev=00:00 obj=system_u:system_r:initrc_t:s0 type=SYSCALL msg=audit(1204313263.896:1829995): arch=40000003 syscall=5 success=yes exit=6 a0=91c9630 a1=8000 a2=0 a3=8000 items=1 ppid=1 pid=2278 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="mcstransd" exe="/sbin/mcstransd" subj=system_u:system_r:setrans_t:s0-s0:c0.c1023 key=(null) type=CWD msg=audit(1204313263.896:1829995): cwd="/" type=PATH msg=audit(1204313263.896:1829995): item=0 name="/proc/10597/attr/current" inode=694485016 dev=00:03 mode=0100666 ouid=0 ogid=0 rdev=00:00 obj=system_u:system_r:initrc_t:s0 type=SYSCALL msg=audit(1204313263.897:1829996): arch=40000003 syscall=5 success=yes exit=3 a0=4424fb77 a1=0 a2=0 a3=ffffffff items=1 ppid=10587 pid=10598 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="selinuxenabled" exe="/usr/sbin/selinuxenabled" subj=system_u:system_r:initrc_t:s0 key=(null) type=CWD msg=audit(1204313263.897:1829996): cwd="/" 4. I once manually ran fixfiles. When did I run this? I don't remember the sequence. Thank for the help. From sds at tycho.nsa.gov Thu Mar 20 16:42:14 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 20 Mar 2008 12:42:14 -0400 Subject: Performance difference In-Reply-To: <47E28E32.8080203@fedoraproject.org> References: <47E28E32.8080203@fedoraproject.org> Message-ID: <1206031334.32000.74.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2008-03-20 at 21:47 +0530, Rahul Sundaram wrote: > Hi, > > Is there any performance differences between having selinux disabled via > a the configuration file vs disabling it in the bootloader? If so. is > this considered a bug? There shouldn't be any difference - the late disable unregisters the SELinux LSM hooks and NetFilter hooks altogether, so SELinux is no longer on the code path for the kernel operations. Back in Fedora Core 2 days, there was a big difference, because the /etc/sysconfig/selinux disable wasn't a real disable - it just booted permissive with no policy loaded. The runtime disable support in the kernel came later and was included in Fedora Core 3 and later. -- Stephen Smalley National Security Agency From linux_4ever at yahoo.com Thu Mar 20 17:04:22 2008 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 20 Mar 2008 10:04:22 -0700 (PDT) Subject: aduitd failing to start Message-ID: <593441.30383.qm@web51508.mail.re2.yahoo.com> > space_left = 75 > #space_left_action = SYSLOG > space_left_action = email > action_mail_acct = scook at ntis.gov ^^^ This is where you are getting the DNS issues running from a child. But auditd should write to syslog why it was exiting. My guess is disk is full. -Steve ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From linux_4ever at yahoo.com Thu Mar 20 17:44:13 2008 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 20 Mar 2008 10:44:13 -0700 (PDT) Subject: aduitd failing to start Message-ID: <811345.35794.qm@web51507.mail.re2.yahoo.com> > space_left = 75 > > #space_left_action = SYSLOG > > space_left_action = email > > action_mail_acct = scook at ntis.gov > > ^^^ > This is where you are getting the DNS issues running from a child. To be a little more concrete, it would seem that policy is missing a transition from auditd_t to sendmail's context and this is causing your avcs. But the reason this is happening in the first place is that your audit partition is likely full. Besides clearing space, you might want to change from email notification to something else until a new policy can be made with the auto transition. -Steve ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From phosmane at ntis.gov Thu Mar 20 17:46:15 2008 From: phosmane at ntis.gov (Pad Hosmane) Date: Thu, 20 Mar 2008 13:46:15 -0400 Subject: aduitd failing to start In-Reply-To: <593441.30383.qm@web51508.mail.re2.yahoo.com> References: <593441.30383.qm@web51508.mail.re2.yahoo.com> Message-ID: <8647E63ABA86C941B70F1058189C22E5065BB1CD@ntis_exchange.ntis2.gov> > space_left = 75 > #space_left_action = SYSLOG > space_left_action = email > action_mail_acct = XXXXXXXXXX ^^^ This is where you are getting the DNS issues running from a child. But auditd should write to syslog why it was exiting. My guess is disk is full. -Steve Hi Steve, Thank you for the quick response. Audit is now starting. I changed space_left_action = SYSLOG and audit started working. Space was not an issue; 60 GB still available. Can I know why email option is not working? Thank you all for helping me to resolve the issue. Cheers to SELinux!!!!! From linux_4ever at yahoo.com Thu Mar 20 19:01:48 2008 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 20 Mar 2008 12:01:48 -0700 (PDT) Subject: aduitd failing to start Message-ID: <172040.82349.qm@web51504.mail.re2.yahoo.com> > Can I know why email option is not working? The email option should work assuming that SE Linux policy allows it. I just checked the source code. If the email address has a '@' symbol, auditd calls gethostbyname to make sure that you don't have a typo in the email address and it can't send an email when it needs to. Since SE Linux policy fails that, it rejects that address and then in turn fails the startup to let you know that you have something wrong in the configuration. There's possibly a workaround where you use a local alias that sendmail/postfix resolves into your real email address. This way you do not need an email address with a '@' in it. This should be temporary until policy is fixed. Also, when it does come time for auditd to send its first email, we still need a transition from auditd to a mta domain. Auditd calls /usr/lib/sendmail if that matters to anyone. -Steve ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From phosmane at ntis.gov Thu Mar 20 19:18:58 2008 From: phosmane at ntis.gov (Pad Hosmane) Date: Thu, 20 Mar 2008 15:18:58 -0400 Subject: aduitd failing to start In-Reply-To: <172040.82349.qm@web51504.mail.re2.yahoo.com> References: <172040.82349.qm@web51504.mail.re2.yahoo.com> Message-ID: <8647E63ABA86C941B70F1058189C22E5065BB1CF@ntis_exchange.ntis2.gov> > Can I know why email option is not working? The email option should work assuming that SE Linux policy allows it. I just checked the source code. If the email address has a '@' symbol, auditd calls gethostbyname to make sure that you don't have a typo in the email address and it can't send an email when it needs to. Since SE Linux policy fails that, it rejects that address and then in turn fails the startup to let you know that you have something wrong in the configuration. There's possibly a workaround where you use a local alias that sendmail/postfix resolves into your real email address. This way you do not need an email address with a '@' in it. This should be temporary until policy is fixed. Also, when it does come time for auditd to send its first email, we still need a transition from auditd to a mta domain. Auditd calls /usr/lib/sendmail if that matters to anyone. -Steve Hi Steve, Thanks a lot for all the help. I truly appreciate your help and all others who helped me to resolve the issue. Thanks. From dwalsh at redhat.com Thu Mar 20 20:28:37 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 20 Mar 2008 16:28:37 -0400 Subject: aduitd failing to start In-Reply-To: <8647E63ABA86C941B70F1058189C22E5065BB1CF@ntis_exchange.ntis2.gov> References: <172040.82349.qm@web51504.mail.re2.yahoo.com> <8647E63ABA86C941B70F1058189C22E5065BB1CF@ntis_exchange.ntis2.gov> Message-ID: <47E2C8F5.6040608@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pad Hosmane wrote: > >> Can I know why email option is not working? > > The email option should work assuming that SE Linux policy allows it. I > just checked the source code. If the email address has a '@' symbol, > auditd calls gethostbyname to make sure that you don't have a typo in > the email address and it can't send an email when it needs to. Since SE > Linux policy fails that, it rejects that address and then in turn fails > the startup to let you know that you have something wrong in the > configuration. > > There's possibly a workaround where you use a local alias that > sendmail/postfix resolves into your real email address. This way you do > not need an email address with a '@' in it. This should be temporary > until policy is fixed. > > Also, when it does come time for auditd to send its first email, we > still need a transition from auditd to a mta domain. Auditd calls > /usr/lib/sendmail if that matters to anyone. > > -Steve > > > Hi Steve, > Thanks a lot for all the help. I truly appreciate your help and all > others who helped me to resolve the issue. > > Thanks. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Current audit policy allows the transition to an mta (mta_send_mail(auditd_t) It did not however allow the communications with dns, as you stated. Fixes in selinux-policy-2.4.6-126.el5 selinux-policy-3.0.8-95.fc8 selinux-policy-3.3.1-22.fc9 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfiyPUACgkQrlYvE4MpobPejgCfe+GB7VG9gT639fFLesl0bBht v6MAn2FyU5be/TXTQrHJ4TcqjBQIv6pV =bh9N -----END PGP SIGNATURE----- From valent.turkovic at gmail.com Fri Mar 21 11:36:50 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 21 Mar 2008 12:36:50 +0100 Subject: gconf alert Message-ID: <64b14b300803210436s4042e579n9519c9d211a87dba@mail.gmail.com> Hi. I'm seeing lots of these alerts in rawhide. Is this "normal" or is it a gnome or selinux issue or is my system problematic? Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gconfd-selinux_alert.txt URL: From cra at WPI.EDU Fri Mar 21 19:42:42 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 21 Mar 2008 15:42:42 -0400 Subject: F9 dhcp client cannot backup resolv.conf, nor write ntp.conf Message-ID: <20080321194242.GM25428@angus.ind.WPI.EDU> It seems the policy needs an update to allow the dhclient-script to work properly: type=1400 audit(1206128117.122:4): avc: denied { write } for pid=2475 comm="cp" name="resolv.conf.predhclient.eth3" dev=dm-0 ino=26088 scontext=system_u:system_r:dhcpc_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file type=1400 audit(1206128117.122:5): avc: denied { unlink } for pid=2475 comm="cp" name="resolv.conf.predhclient.eth3" dev=dm-0 ino=26088 scontext=system_u:system_r:dhcpc_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file type=1400 audit(1206128117.252:6): avc: denied { rename } for pid=2485 comm="mv" name="ntp.conf" dev=dm-0 ino=26089 scontext=system_u:system_r:dhcpc_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file type=1400 audit(1206128117.255:7): avc: denied { write } for pid=2486 comm="dhclient-script" name="ntp.conf" dev=dm-0 ino=26089 scontext=system_u:system_r:dhcpc_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file type=1400 audit(1206128117.255:8): avc: denied { write } for pid=2486 comm="dhclient-script" name="ntp.conf" dev=dm-0 ino=26089 scontext=system_u:system_r:dhcpc_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file type=1400 audit(1206128117.256:9): avc: denied { append } for pid=2434 comm="dhclient-script" name="ntp.conf" dev=dm-0 ino=26089 scontext=system_u:system_r:dhcpc_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file type=1400 audit(1206128117.257:10): avc: denied { append } for pid=2434 comm="dhclient-script" name="ntp.conf" dev=dm-0 ino=26089 scontext=system_u:system_r:dhcpc_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file type=1400 audit(1206128117.257:11): avc: denied { append } for pid=2434 comm="dhclient-script" name="ntp.conf" dev=dm-0 ino=26089 scontext=system_u:system_r:dhcpc_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file type=1400 audit(1206128117.257:12): avc: denied { append } for pid=2434 comm="dhclient-script" name="ntp.conf" dev=dm-0 ino=26089 scontext=system_u:system_r:dhcpc_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file type=1400 audit(1206128117.258:13): avc: denied { append } for pid=2434 comm="dhclient-script" name="ntp.conf" dev=dm-0 ino=26089 scontext=system_u:system_r:dhcpc_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file # audit2allow -R < audit.log require { type var_run_t; type dhcpc_t; type hald_acl_t; type etc_t; class dir write; class file { write rename unlink append }; } #============= dhcpc_t ============== allow dhcpc_t etc_t:file { write rename unlink append }; #============= hald_acl_t ============== allow hald_acl_t var_run_t:dir write; From dwalsh at redhat.com Fri Mar 21 23:17:14 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 21 Mar 2008 19:17:14 -0400 Subject: F9 dhcp client cannot backup resolv.conf, nor write ntp.conf In-Reply-To: <20080321194242.GM25428@angus.ind.WPI.EDU> References: <20080321194242.GM25428@angus.ind.WPI.EDU> Message-ID: <47E441FA.4030205@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chuck Anderson wrote: > It seems the policy needs an update to allow the dhclient-script to > work properly: > > type=1400 audit(1206128117.122:4): avc: denied { write } for > pid=2475 comm="cp" name="resolv.conf.predhclient.eth3" dev=dm-0 > ino=26088 scontext=system_u:system_r:dhcpc_t:s0 > tcontext=unconfined_u:object_r:etc_t:s0 tclass=file > type=1400 audit(1206128117.122:5): avc: denied { unlink } for > pid=2475 comm="cp" name="resolv.conf.predhclient.eth3" dev=dm-0 > ino=26088 scontext=system_u:system_r:dhcpc_t:s0 > tcontext=unconfined_u:object_r:etc_t:s0 tclass=file > type=1400 audit(1206128117.252:6): avc: denied { rename } for > pid=2485 comm="mv" name="ntp.conf" dev=dm-0 ino=26089 > scontext=system_u:system_r:dhcpc_t:s0 > tcontext=unconfined_u:object_r:etc_t:s0 tclass=file > type=1400 audit(1206128117.255:7): avc: denied { write } for > pid=2486 comm="dhclient-script" name="ntp.conf" dev=dm-0 ino=26089 > scontext=system_u:system_r:dhcpc_t:s0 > tcontext=unconfined_u:object_r:etc_t:s0 tclass=file > type=1400 audit(1206128117.255:8): avc: denied { write } for > pid=2486 comm="dhclient-script" name="ntp.conf" dev=dm-0 ino=26089 > scontext=system_u:system_r:dhcpc_t:s0 > tcontext=unconfined_u:object_r:etc_t:s0 tclass=file > type=1400 audit(1206128117.256:9): avc: denied { append } for > pid=2434 comm="dhclient-script" name="ntp.conf" dev=dm-0 ino=26089 > scontext=system_u:system_r:dhcpc_t:s0 > tcontext=unconfined_u:object_r:etc_t:s0 tclass=file > type=1400 audit(1206128117.257:10): avc: denied { append } for > pid=2434 comm="dhclient-script" name="ntp.conf" dev=dm-0 ino=26089 > scontext=system_u:system_r:dhcpc_t:s0 > tcontext=unconfined_u:object_r:etc_t:s0 tclass=file > type=1400 audit(1206128117.257:11): avc: denied { append } for > pid=2434 comm="dhclient-script" name="ntp.conf" dev=dm-0 ino=26089 > scontext=system_u:system_r:dhcpc_t:s0 > tcontext=unconfined_u:object_r:etc_t:s0 tclass=file > type=1400 audit(1206128117.257:12): avc: denied { append } for > pid=2434 comm="dhclient-script" name="ntp.conf" dev=dm-0 ino=26089 > scontext=system_u:system_r:dhcpc_t:s0 > tcontext=unconfined_u:object_r:etc_t:s0 tclass=file > type=1400 audit(1206128117.258:13): avc: denied { append } for > pid=2434 comm="dhclient-script" name="ntp.conf" dev=dm-0 ino=26089 > scontext=system_u:system_r:dhcpc_t:s0 > tcontext=unconfined_u:object_r:etc_t:s0 tclass=file > > > # audit2allow -R < audit.log > > require { > type var_run_t; > type dhcpc_t; > type hald_acl_t; > type etc_t; > class dir write; > class file { write rename unlink append }; > } > > #============= dhcpc_t ============== > allow dhcpc_t etc_t:file { write rename unlink append }; > > #============= hald_acl_t ============== > allow hald_acl_t var_run_t:dir write; > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Someone/thing mislabeled your resolv.conf restorecon /etc/resolv.conf The hald_acl will be fixed tonight. Your policy module is dangerous -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfkQfoACgkQrlYvE4MpobMyTQCgscWfhHGmNZjFg5Gnrggg/uaU cJQAoMeTOEm3m7YUvfsebWXfVnlEohs4 =MBe5 -----END PGP SIGNATURE----- From dwalsh at redhat.com Fri Mar 21 23:20:48 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 21 Mar 2008 19:20:48 -0400 Subject: gconf alert In-Reply-To: <64b14b300803210436s4042e579n9519c9d211a87dba@mail.gmail.com> References: <64b14b300803210436s4042e579n9519c9d211a87dba@mail.gmail.com> Message-ID: <47E442D0.3020809@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Valent Turkovic wrote: > Hi. > > I'm seeing lots of these alerts in rawhide. > Is this "normal" or is it a gnome or selinux issue or is my system problematic? > > Valent. > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Well you are logging in as root via XWindows which is not a good idea and we do not plan to fix the policy for this. Since it is such a bad idea, and would break any security we have tried to add to SELinux to eliminate the AVC. You also setup the user to login via user_t? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfkQtAACgkQrlYvE4MpobMhRACeJ9srkML85WxzUU6DVBtEPMS9 Uw0AoLqLWJUxIzTk79o7Tn4ybDSKRsE8 =z7RQ -----END PGP SIGNATURE----- From valent.turkovic at gmail.com Sat Mar 22 10:17:07 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sat, 22 Mar 2008 11:17:07 +0100 Subject: gconf alert In-Reply-To: <47E442D0.3020809@redhat.com> References: <64b14b300803210436s4042e579n9519c9d211a87dba@mail.gmail.com> <47E442D0.3020809@redhat.com> Message-ID: <64b14b300803220317tf341660kd198fd43ee42b8e9@mail.gmail.com> On Sat, Mar 22, 2008 at 12:20 AM, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Valent Turkovic wrote: > > Hi. > > > > I'm seeing lots of these alerts in rawhide. > > Is this "normal" or is it a gnome or selinux issue or is my system problematic? > > > > Valent. > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Well you are logging in as root via XWindows which is not a good idea > and we do not plan to fix the policy for this. Since it is such a bad > idea, and would break any security we have tried to add to SELinux to > eliminate the AVC. You also setup the user to login via user_t? > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkfkQtAACgkQrlYvE4MpobMhRACeJ9srkML85WxzUU6DVBtEPMS9 > Uw0AoLqLWJUxIzTk79o7Tn4ybDSKRsE8 > =z7RQ > -----END PGP SIGNATURE----- > I'm not logging in as root to gnome. Valent . -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From dwalsh at redhat.com Sat Mar 22 11:14:08 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sat, 22 Mar 2008 07:14:08 -0400 Subject: gconf alert In-Reply-To: <64b14b300803220317tf341660kd198fd43ee42b8e9@mail.gmail.com> References: <64b14b300803210436s4042e579n9519c9d211a87dba@mail.gmail.com> <47E442D0.3020809@redhat.com> <64b14b300803220317tf341660kd198fd43ee42b8e9@mail.gmail.com> Message-ID: <47E4EA00.8020207@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Valent Turkovic wrote: > On Sat, Mar 22, 2008 at 12:20 AM, Daniel J Walsh wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> Valent Turkovic wrote: >> > Hi. >> > >> > I'm seeing lots of these alerts in rawhide. >> > Is this "normal" or is it a gnome or selinux issue or is my system problematic? >> > >> > Valent. >> > >> > >> > >> > ------------------------------------------------------------------------ >> > >> > -- >> > fedora-selinux-list mailing list >> > fedora-selinux-list at redhat.com >> > https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> Well you are logging in as root via XWindows which is not a good idea >> and we do not plan to fix the policy for this. Since it is such a bad >> idea, and would break any security we have tried to add to SELinux to >> eliminate the AVC. You also setup the user to login via user_t? >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.8 (GNU/Linux) >> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org >> >> iEYEARECAAYFAkfkQtAACgkQrlYvE4MpobMhRACeJ9srkML85WxzUU6DVBtEPMS9 >> Uw0AoLqLWJUxIzTk79o7Tn4ybDSKRsE8 >> =z7RQ >> -----END PGP SIGNATURE----- >> > > > I'm not logging in as root to gnome. > > Valent > . > Well the AVC says host=valent.lan type=AVC msg=audit(1206099072.482:443): avc: denied { rename } for pid=13738 comm="gconfd-2" name="saved_state.tmp" dev=sda9 ino=865370 scontext=user_u:user_r:user_t:s0 tcontext=user_u:object_r:admin_home_t:s0 tclass=file host=valent.lan type=SYSCALL msg=audit(1206099072.482:443): arch=40000003 syscall=38 success=yes exit=0 a0=9f59b20 a1=9f57118 a2=0 a3=5 items=0 ppid=1 pid=13738 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4 comm="gconfd-2" exe="/usr/libexec/gconfd-2" subj=user_u:user_r:user_t:s0 key=(null) admin_home_t is the label of /root So either you have a labeling problem or you have gconfd-2 trying to relabel saved_state.tmp which is labeled the root directory label admin_home_t -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfk6gAACgkQrlYvE4MpobMAXwCg2YpVaswVCQVI7kSuOUk+CgDN JWMAoIHx0BNqxOdbUKGsA1ruGBTlYvin =F+6B -----END PGP SIGNATURE----- From valent.turkovic at gmail.com Sat Mar 22 12:55:08 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sat, 22 Mar 2008 13:55:08 +0100 Subject: gconf alert In-Reply-To: <47E4EA00.8020207@redhat.com> References: <64b14b300803210436s4042e579n9519c9d211a87dba@mail.gmail.com> <47E442D0.3020809@redhat.com> <64b14b300803220317tf341660kd198fd43ee42b8e9@mail.gmail.com> <47E4EA00.8020207@redhat.com> Message-ID: <64b14b300803220555iba954b7h4d24253d3f9e513e@mail.gmail.com> On Sat, Mar 22, 2008 at 12:14 PM, Daniel J Walsh wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Valent Turkovic wrote: > > On Sat, Mar 22, 2008 at 12:20 AM, Daniel J Walsh wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> > >> Valent Turkovic wrote: > >> > Hi. > >> > > >> > I'm seeing lots of these alerts in rawhide. > >> > Is this "normal" or is it a gnome or selinux issue or is my system problematic? > >> > > >> > Valent. > >> > > >> > > >> > > >> > ------------------------------------------------------------------------ > >> > > >> > -- > >> > fedora-selinux-list mailing list > >> > fedora-selinux-list at redhat.com > >> > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > >> Well you are logging in as root via XWindows which is not a good idea > >> and we do not plan to fix the policy for this. Since it is such a bad > >> idea, and would break any security we have tried to add to SELinux to > >> eliminate the AVC. You also setup the user to login via user_t? > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG v1.4.8 (GNU/Linux) > >> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > >> > >> iEYEARECAAYFAkfkQtAACgkQrlYvE4MpobMhRACeJ9srkML85WxzUU6DVBtEPMS9 > >> Uw0AoLqLWJUxIzTk79o7Tn4ybDSKRsE8 > >> =z7RQ > >> -----END PGP SIGNATURE----- > >> > > > > > > I'm not logging in as root to gnome. > > > > Valent > > . > > > Well the AVC says > > host=valent.lan type=AVC msg=audit(1206099072.482:443): avc: denied { > rename } for pid=13738 comm="gconfd-2" name="saved_state.tmp" dev=sda9 > ino=865370 scontext=user_u:user_r:user_t:s0 > tcontext=user_u:object_r:admin_home_t:s0 tclass=file > > host=valent.lan type=SYSCALL msg=audit(1206099072.482:443): > arch=40000003 syscall=38 success=yes exit=0 a0=9f59b20 a1=9f57118 a2=0 > a3=5 items=0 ppid=1 pid=13738 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 > egid=0 sgid=0 fsgid=0 tty=(none) ses=4 comm="gconfd-2" > exe="/usr/libexec/gconfd-2" subj=user_u:user_r:user_t:s0 key=(null) > > > admin_home_t is the label of /root > > So either you have a labeling problem or you have gconfd-2 trying to > relabel saved_state.tmp which is labeled the root directory label > admin_home_t > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkfk6gAACgkQrlYvE4MpobMAXwCg2YpVaswVCQVI7kSuOUk+CgDN > JWMAoIHx0BNqxOdbUKGsA1ruGBTlYvin > =F+6B > -----END PGP SIGNATURE----- > I relabeled my system 2 times in last few days and I'm not running as gmome as root. I don't know why I'm seeing this alert and that is why I'm sending you this email. Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From valent.turkovic at gmail.com Sat Mar 22 12:55:08 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sat, 22 Mar 2008 13:55:08 +0100 Subject: gconf alert In-Reply-To: <47E4EA00.8020207@redhat.com> References: <64b14b300803210436s4042e579n9519c9d211a87dba@mail.gmail.com> <47E442D0.3020809@redhat.com> <64b14b300803220317tf341660kd198fd43ee42b8e9@mail.gmail.com> <47E4EA00.8020207@redhat.com> Message-ID: <64b14b300803220555iba954b7h4d24253d3f9e513e@mail.gmail.com> On Sat, Mar 22, 2008 at 12:14 PM, Daniel J Walsh wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Valent Turkovic wrote: > > On Sat, Mar 22, 2008 at 12:20 AM, Daniel J Walsh wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> > >> Valent Turkovic wrote: > >> > Hi. > >> > > >> > I'm seeing lots of these alerts in rawhide. > >> > Is this "normal" or is it a gnome or selinux issue or is my system problematic? > >> > > >> > Valent. > >> > > >> > > >> > > >> > ------------------------------------------------------------------------ > >> > > >> > -- > >> > fedora-selinux-list mailing list > >> > fedora-selinux-list at redhat.com > >> > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > >> Well you are logging in as root via XWindows which is not a good idea > >> and we do not plan to fix the policy for this. Since it is such a bad > >> idea, and would break any security we have tried to add to SELinux to > >> eliminate the AVC. You also setup the user to login via user_t? > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG v1.4.8 (GNU/Linux) > >> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > >> > >> iEYEARECAAYFAkfkQtAACgkQrlYvE4MpobMhRACeJ9srkML85WxzUU6DVBtEPMS9 > >> Uw0AoLqLWJUxIzTk79o7Tn4ybDSKRsE8 > >> =z7RQ > >> -----END PGP SIGNATURE----- > >> > > > > > > I'm not logging in as root to gnome. > > > > Valent > > . > > > Well the AVC says > > host=valent.lan type=AVC msg=audit(1206099072.482:443): avc: denied { > rename } for pid=13738 comm="gconfd-2" name="saved_state.tmp" dev=sda9 > ino=865370 scontext=user_u:user_r:user_t:s0 > tcontext=user_u:object_r:admin_home_t:s0 tclass=file > > host=valent.lan type=SYSCALL msg=audit(1206099072.482:443): > arch=40000003 syscall=38 success=yes exit=0 a0=9f59b20 a1=9f57118 a2=0 > a3=5 items=0 ppid=1 pid=13738 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 > egid=0 sgid=0 fsgid=0 tty=(none) ses=4 comm="gconfd-2" > exe="/usr/libexec/gconfd-2" subj=user_u:user_r:user_t:s0 key=(null) > > > admin_home_t is the label of /root > > So either you have a labeling problem or you have gconfd-2 trying to > relabel saved_state.tmp which is labeled the root directory label > admin_home_t > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkfk6gAACgkQrlYvE4MpobMAXwCg2YpVaswVCQVI7kSuOUk+CgDN > JWMAoIHx0BNqxOdbUKGsA1ruGBTlYvin > =F+6B > -----END PGP SIGNATURE----- > I relabeled my system 2 times in last few days and I'm not running as gmome as root. I don't know why I'm seeing this alert and that is why I'm sending you this email. Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From valent.turkovic at gmail.com Sat Mar 22 12:55:51 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sat, 22 Mar 2008 13:55:51 +0100 Subject: gconf alert In-Reply-To: <64b14b300803220555iba954b7h4d24253d3f9e513e@mail.gmail.com> References: <64b14b300803210436s4042e579n9519c9d211a87dba@mail.gmail.com> <47E442D0.3020809@redhat.com> <64b14b300803220317tf341660kd198fd43ee42b8e9@mail.gmail.com> <47E4EA00.8020207@redhat.com> <64b14b300803220555iba954b7h4d24253d3f9e513e@mail.gmail.com> Message-ID: <64b14b300803220555t242524b5n7d2b13afe66861df@mail.gmail.com> On Sat, Mar 22, 2008 at 1:55 PM, Valent Turkovic wrote: > > On Sat, Mar 22, 2008 at 12:14 PM, Daniel J Walsh wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Valent Turkovic wrote: > > > On Sat, Mar 22, 2008 at 12:20 AM, Daniel J Walsh wrote: > > >> -----BEGIN PGP SIGNED MESSAGE----- > > >> Hash: SHA1 > > >> > > >> > > >> Valent Turkovic wrote: > > >> > Hi. > > >> > > > >> > I'm seeing lots of these alerts in rawhide. > > >> > Is this "normal" or is it a gnome or selinux issue or is my system problematic? > > >> > > > >> > Valent. > > >> > > > >> > > > >> > > > >> > ------------------------------------------------------------------------ > > >> > > > >> > -- > > >> > fedora-selinux-list mailing list > > >> > fedora-selinux-list at redhat.com > > >> > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > >> Well you are logging in as root via XWindows which is not a good idea > > >> and we do not plan to fix the policy for this. Since it is such a bad > > >> idea, and would break any security we have tried to add to SELinux to > > >> eliminate the AVC. You also setup the user to login via user_t? > > >> -----BEGIN PGP SIGNATURE----- > > >> Version: GnuPG v1.4.8 (GNU/Linux) > > >> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > >> > > >> iEYEARECAAYFAkfkQtAACgkQrlYvE4MpobMhRACeJ9srkML85WxzUU6DVBtEPMS9 > > >> Uw0AoLqLWJUxIzTk79o7Tn4ybDSKRsE8 > > >> =z7RQ > > >> -----END PGP SIGNATURE----- > > >> > > > > > > > > > I'm not logging in as root to gnome. > > > > > > Valent > > > . > > > > > Well the AVC says > > > > host=valent.lan type=AVC msg=audit(1206099072.482:443): avc: denied { > > rename } for pid=13738 comm="gconfd-2" name="saved_state.tmp" dev=sda9 > > ino=865370 scontext=user_u:user_r:user_t:s0 > > tcontext=user_u:object_r:admin_home_t:s0 tclass=file > > > > host=valent.lan type=SYSCALL msg=audit(1206099072.482:443): > > arch=40000003 syscall=38 success=yes exit=0 a0=9f59b20 a1=9f57118 a2=0 > > a3=5 items=0 ppid=1 pid=13738 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 > > egid=0 sgid=0 fsgid=0 tty=(none) ses=4 comm="gconfd-2" > > exe="/usr/libexec/gconfd-2" subj=user_u:user_r:user_t:s0 key=(null) > > > > > > admin_home_t is the label of /root > > > > So either you have a labeling problem or you have gconfd-2 trying to > > relabel saved_state.tmp which is labeled the root directory label > > admin_home_t > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.8 (GNU/Linux) > > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > > > iEYEARECAAYFAkfk6gAACgkQrlYvE4MpobMAXwCg2YpVaswVCQVI7kSuOUk+CgDN > > JWMAoIHx0BNqxOdbUKGsA1ruGBTlYvin > > =F+6B > > -----END PGP SIGNATURE----- > > > > > I relabeled my system 2 times in last few days and I'm not running as > gmome as root. I don't know why I'm seeing this alert and that is why > I'm sending you this email. > > > > Valent. > > -- > http://kernelreloaded.blog385.com/ > linux, blog, anime, spirituality, windsurf, wireless > registered as user #367004 with the Linux Counter, http://counter.li.org. > ICQ: 2125241, Skype: valent.turkovic > I'm seeing it in F8 and also in F9 Beta . -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From valent.turkovic at gmail.com Sat Mar 22 12:59:35 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sat, 22 Mar 2008 13:59:35 +0100 Subject: gconf alert In-Reply-To: <64b14b300803220555t242524b5n7d2b13afe66861df@mail.gmail.com> References: <64b14b300803210436s4042e579n9519c9d211a87dba@mail.gmail.com> <47E442D0.3020809@redhat.com> <64b14b300803220317tf341660kd198fd43ee42b8e9@mail.gmail.com> <47E4EA00.8020207@redhat.com> <64b14b300803220555iba954b7h4d24253d3f9e513e@mail.gmail.com> <64b14b300803220555t242524b5n7d2b13afe66861df@mail.gmail.com> Message-ID: <64b14b300803220559l4aa8c33clb88c66c1f356a205@mail.gmail.com> Here are the latest ones from F8. I'll reboot to F9 beta and send those also. Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gconfd-2_selinux_alert-02.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gconfd-2_selinux_alert.txt URL: From cra at WPI.EDU Sat Mar 22 22:15:17 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Sat, 22 Mar 2008 18:15:17 -0400 Subject: F9 dhcp client cannot backup resolv.conf, nor write ntp.conf In-Reply-To: <47E441FA.4030205@redhat.com> References: <20080321194242.GM25428@angus.ind.WPI.EDU> <47E441FA.4030205@redhat.com> Message-ID: <20080322221517.GA7764@angus.ind.WPI.EDU> On Fri, Mar 21, 2008 at 07:17:14PM -0400, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Chuck Anderson wrote: > > It seems the policy needs an update to allow the dhclient-script to > > work properly: > > > > type=1400 audit(1206128117.122:4): avc: denied { write } for > > pid=2475 comm="cp" name="resolv.conf.predhclient.eth3" dev=dm-0 > Someone/thing mislabeled your resolv.conf > > restorecon /etc/resolv.conf The hald_acl will be fixed tonight. Your > policy module is dangerous This was on the very first boot of a fresh install of rawhide. From lordmorgul at gmail.com Sun Mar 23 05:15:56 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sat, 22 Mar 2008 22:15:56 -0700 Subject: rawhide yum denied for transition bootloader_t, two alerts In-Reply-To: <47DEF90F.6060400@gmail.com> References: <8b14d9940803170314p5a4f9bdm243bc461ab6ee8ea@mail.gmail.com> <47DE8153.60809@redhat.com> <8b14d9940803171335s422b8726y4d2a28cf90c09823@mail.gmail.com> <47DEE20A.1000204@redhat.com> <47DEF28C.2080703@gmail.com> <47DEF90F.6060400@gmail.com> Message-ID: <47E5E78C.5020403@gmail.com> Andrew Farris wrote: > Let me add I am now seeing both systems behave the same way as above, > gdm logins have context bootloader_t and that remains through /bin/su - > root but startx logins have unconfined_t and remains unconfined through > /bin/su - root. > Problem has resolved itself on one machine, I'm away from the other and cannot check yet but I would expect with the same updates it will be fixed as well. I've got selinux-policy-targeted-3.3.1-22 and gdm-2.21.10-0.2008.03.18.2 and logged in with normal unconfined contexts. -- Andrew Farris www.lordmorgul.net gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From dwalsh at redhat.com Sun Mar 23 11:34:25 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sun, 23 Mar 2008 07:34:25 -0400 Subject: gconf alert In-Reply-To: <64b14b300803220559l4aa8c33clb88c66c1f356a205@mail.gmail.com> References: <64b14b300803210436s4042e579n9519c9d211a87dba@mail.gmail.com> <47E442D0.3020809@redhat.com> <64b14b300803220317tf341660kd198fd43ee42b8e9@mail.gmail.com> <47E4EA00.8020207@redhat.com> <64b14b300803220555iba954b7h4d24253d3f9e513e@mail.gmail.com> <64b14b300803220555t242524b5n7d2b13afe66861df@mail.gmail.com> <64b14b300803220559l4aa8c33clb88c66c1f356a205@mail.gmail.com> Message-ID: <47E64041.1040909@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Valent Turkovic wrote: > Here are the latest ones from F8. > > I'll reboot to F9 beta and send those also. > > Valent. > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list I believe you have some stuff out in /tmp that is causing this. /tmp is not cleaned up on a relabel. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfmQEEACgkQrlYvE4MpobPYdQCfT49WOHkI/znmW+6RyXTM+GbO v04AoNqxXJCrT36PwV0t63ZZBXv7tknB =b2o1 -----END PGP SIGNATURE----- From dwalsh at redhat.com Sun Mar 23 11:36:17 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sun, 23 Mar 2008 07:36:17 -0400 Subject: F9 dhcp client cannot backup resolv.conf, nor write ntp.conf In-Reply-To: <20080322221517.GA7764@angus.ind.WPI.EDU> References: <20080321194242.GM25428@angus.ind.WPI.EDU> <47E441FA.4030205@redhat.com> <20080322221517.GA7764@angus.ind.WPI.EDU> Message-ID: <47E640B1.1060302@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chuck Anderson wrote: > On Fri, Mar 21, 2008 at 07:17:14PM -0400, Daniel J Walsh wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Chuck Anderson wrote: >>> It seems the policy needs an update to allow the dhclient-script to >>> work properly: >>> >>> type=1400 audit(1206128117.122:4): avc: denied { write } for >>> pid=2475 comm="cp" name="resolv.conf.predhclient.eth3" dev=dm-0 > >> Someone/thing mislabeled your resolv.conf >> >> restorecon /etc/resolv.conf The hald_acl will be fixed tonight. Your >> policy module is dangerous > > This was on the very first boot of a fresh install of rawhide. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Then rawhide has a bug in the creation of resolv.conf. Please open a bugzilla, on anaconda and CC me. Did you do anything special in firstboot? Anything special in your network setup? Please report any of this info in your bugzilla -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfmQLEACgkQrlYvE4MpobM/NwCeIbo1Lm+b1O5fkWVWsYteJL+P t2IAoL8hx23NowMe9PhT3L3YYejdKVQM =gl0m -----END PGP SIGNATURE----- From cra at WPI.EDU Sun Mar 23 14:52:00 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Sun, 23 Mar 2008 10:52:00 -0400 Subject: F9 dhcp client cannot backup resolv.conf, nor write ntp.conf In-Reply-To: <47E640B1.1060302@redhat.com> References: <20080321194242.GM25428@angus.ind.WPI.EDU> <47E441FA.4030205@redhat.com> <20080322221517.GA7764@angus.ind.WPI.EDU> <47E640B1.1060302@redhat.com> Message-ID: <20080323145200.GA19076@angus.ind.WPI.EDU> On Sun, Mar 23, 2008 at 07:36:17AM -0400, Daniel J Walsh wrote: > > This was on the very first boot of a fresh install of rawhide. > Then rawhide has a bug in the creation of resolv.conf. Please open a > bugzilla, on anaconda and CC me. Did you do anything special in > firstboot? Anything special in your network setup? Please report any > of this info in your bugzilla Ok, I'll try to reproduce it with a new reinstall. This was an X-less install, and I booted into runlevel 3 from grub on the first boot, so firstboot didn't run. I also noticed that the network service was turned off, so I started networking manually the first time: service network start Perhaps that's why this happened, but I should try it again to be sure I have the exact steps to reproduce this. From arequipeno at gmail.com Sun Mar 23 22:43:46 2008 From: arequipeno at gmail.com (Ian Pilcher) Date: Sun, 23 Mar 2008 17:43:46 -0500 Subject: Starting stunnel from xinetd In-Reply-To: <47E00ACD.6010707@redhat.com> References: <47E00ACD.6010707@redhat.com> Message-ID: Daniel J Walsh wrote: > > selinux-policy-3.0.8-95.fc8.src.rpm > > > Adds stunnel_system_domain to inetd_system_domain, which will allow > stunnel to transition to every domain that is defined as an > inetd_system_domain. Progress. Now getting a denial when rsync tries to read/write to the socket it gets from stunnel: host=f8.example.com type=AVC msg=audit(1206311825.570:66): avc: denied { read write } for pid=2962 comm="rsync" name="[11108]" dev=sockfs ino=11108 scontext=system_u:system_r:rsync_t:s0-s0:c0.c1023 tcontext=system_u:system_r:stunnel_t:s0-s0:c0.c1023 tclass=tcp_socket Thanks! -- ======================================================================== Ian Pilcher arequipeno at gmail.com ======================================================================== From eparis at redhat.com Mon Mar 24 12:04:39 2008 From: eparis at redhat.com (Eric Paris) Date: Mon, 24 Mar 2008 08:04:39 -0400 Subject: gconf alert In-Reply-To: <47E64041.1040909@redhat.com> References: <64b14b300803210436s4042e579n9519c9d211a87dba@mail.gmail.com> <47E442D0.3020809@redhat.com> <64b14b300803220317tf341660kd198fd43ee42b8e9@mail.gmail.com> <47E4EA00.8020207@redhat.com> <64b14b300803220555iba954b7h4d24253d3f9e513e@mail.gmail.com> <64b14b300803220555t242524b5n7d2b13afe66861df@mail.gmail.com> <64b14b300803220559l4aa8c33clb88c66c1f356a205@mail.gmail.com> <47E64041.1040909@redhat.com> Message-ID: <1206360279.3192.0.camel@localhost.localdomain> On Sun, 2008-03-23 at 07:34 -0400, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Valent Turkovic wrote: > > Here are the latest ones from F8. > > > > I'll reboot to F9 beta and send those also. > > > > Valent. > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > I believe you have some stuff out in /tmp that is causing this. /tmp is > not cleaned up on a relabel. /me had great trouble with this in the past. Any way /.autorelabel can just blow away /tmp/* altogether? Didn't it do that once upon a time? -Eric From phosmane at ntis.gov Mon Mar 24 13:50:00 2008 From: phosmane at ntis.gov (Pad Hosmane) Date: Mon, 24 Mar 2008 09:50:00 -0400 Subject: setroubleshoot exiting on AVC's Message-ID: <8647E63ABA86C941B70F1058189C22E5065BB1E0@ntis_exchange.ntis2.gov> Hi, I am on Red Hat enterprise 5. setroubleshoot is exiting and I cannot run sealert. I see below messages in logs. Any help in this regard would be of great help. Mar 22 11:17:52 myhost setroubleshoot: SELinux is preventing /usr/sbin/automount (automount_t) "search" access to /proc/142/cmdline (kernel_t). For complete SELinux messages. run sealert -l c7e49db5-9d5f-4ffb-afdc-82708db53ee4 Mar 22 11:17:53 myhost setroubleshoot: 2008-03-22 11:17:52,416 [program.ERROR] Can not handle AVC'S related to dispatcher. exiting setroubleshoot context=system_u:system_r:setroubleshootd_t:s0, AVC scontext=system_u:system_r:setroubleshootd_t:s0 Mar 22 11:17:52 myhost setroubleshoot: SELinux is preventing /usr/sbin/automount (automount_t) "search" access to /proc/145/cmdline (kernel_t). For complete SELinux messages. run sealert -l 89399382-a3bf-4efd-9bfa-51ebdc28217d Mar 22 11:17:53 myhost setroubleshoot: 2008-03-22 11:17:52,462 [program.ERROR] Can not handle AVC'S related to dispatcher. exiting setroubleshoot context=system_u:system_r:setroubleshootd_t:s0, AVC scontext=system_u:system_r:setroubleshootd_t:s0 Mar 22 11:17:53 myhost setroubleshoot: 2008-03-22 11:17:52,475 [program.ERROR] Can not handle AVC'S related to dispatcher. exiting setroubleshoot context=system_u:system_r:setroubleshootd_t:s0, AVC scontext=system_u:system_r:setroubleshootd_t:s0 Mar 22 11:17:52 myhost : SELinux is preventing /usr/sbin/automount (automount_t) "search" access to /proc/25/cmdline (kernel_t). For complete SELinux messages. run sealert -l 4db5f9d7-949a-4fb6-b7eb-3a3762d35684 Mar 22 11:17:52 myhost audispd: Socket error (32, 'Broken pipe') Mar 22 11:18:08 myhost gpm[3069]: *** info [startup.c(95)]: Mar 22 11:18:08 myhost gpm[3069]: Started gpm successfully. Entered daemon mode. Mar 22 11:18:11 myhost rhnsd[3154]: Red Hat Network Services Daemon starting up. Mar 22 12:18:29 myhost dbus: Can't send to audit system: USER_AVC avc: received policyload notice (seqno=2) : exe="?" (sauid=81, hostname=?, addr=?, terminal=?) Mar 22 12:18:30 myhost setsebool: The httpd_enable_homedirs policy boolean was changed to true by root Mar 22 12:19:23 myhost auditd[2494]: dispatch err (pipe full) event lost Mar 22 12:22:20 myhost dbus: Can't send to audit system: USER_AVC avc: received policyload notice (seqno=3) : exe="?" (sauid=81, hostname=?, addr=?, terminal=?) Mar 22 12:22:21 myhost setsebool: The use_nfs_home_dirs policy boolean was changed to 1 by root Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdennis at redhat.com Mon Mar 24 16:05:47 2008 From: jdennis at redhat.com (John Dennis) Date: Mon, 24 Mar 2008 12:05:47 -0400 Subject: setroubleshoot exiting on AVC's In-Reply-To: <8647E63ABA86C941B70F1058189C22E5065BB1E0@ntis_exchange.ntis2.gov> References: <8647E63ABA86C941B70F1058189C22E5065BB1E0@ntis_exchange.ntis2.gov> Message-ID: <47E7D15B.90101@redhat.com> Pad Hosmane wrote: > Hi, > > I am on Red Hat enterprise 5. setroubleshoot is exiting and I cannot > run sealert. I see below messages in logs. Any help in this regard would > be of great help. These types of errors are usually indicative of a mislabeled filesystem. Try relabeling and see if the problems resolve themselves. To relabel: touch /.autorelabel; reboot -- John Dennis From phosmane at ntis.gov Mon Mar 24 16:13:53 2008 From: phosmane at ntis.gov (Pad Hosmane) Date: Mon, 24 Mar 2008 12:13:53 -0400 Subject: setroubleshoot exiting on AVC's In-Reply-To: <47E7D15B.90101@redhat.com> References: <8647E63ABA86C941B70F1058189C22E5065BB1E0@ntis_exchange.ntis2.gov> <47E7D15B.90101@redhat.com> Message-ID: <8647E63ABA86C941B70F1058189C22E5065BB1E6@ntis_exchange.ntis2.gov> > run sealert. I see below messages in logs. Any help in this regard would > be of great help. These types of errors are usually indicative of a mislabeled filesystem. Try relabeling and see if the problems resolve themselves. To relabel: touch /.autorelabel; reboot -- John Dennis Hi John, Thank you for the reply. I have already relabeled two times with "touch /.autorelabel"; reboot". Thanks. From lordmorgul at gmail.com Mon Mar 24 18:59:14 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Mon, 24 Mar 2008 11:59:14 -0700 Subject: gconf alert In-Reply-To: <1206360279.3192.0.camel@localhost.localdomain> References: <64b14b300803210436s4042e579n9519c9d211a87dba@mail.gmail.com> <47E442D0.3020809@redhat.com> <64b14b300803220317tf341660kd198fd43ee42b8e9@mail.gmail.com> <47E4EA00.8020207@redhat.com> <64b14b300803220555iba954b7h4d24253d3f9e513e@mail.gmail.com> <64b14b300803220555t242524b5n7d2b13afe66861df@mail.gmail.com> <64b14b300803220559l4aa8c33clb88c66c1f356a205@mail.gmail.com> <47E64041.1040909@redhat.com> <1206360279.3192.0.camel@localhost.localdomain> Message-ID: <47E7FA02.1080508@gmail.com> Eric Paris wrote: > /me had great trouble with this in the past. Any way /.autorelabel can > just blow away /tmp/* altogether? Didn't it do that once upon a time? After suggestion from Dan in another thread I've changed my rawhide systems to use tmpfs for /tmp and its working very nicely. I have had no problems with it other than needing to manually define a tmp location for nautilus-burner (I used /opt); the basic tmpfs setup leaves tmp too small for burning big images, but that is the only thing I've needed a huge tmp for so far. I'm using: tmpfs /tmp tmpfs defaults 0 0 -- Andrew Farris www.lordmorgul.net gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From ercrokan at gmail.com Wed Mar 26 20:18:27 2008 From: ercrokan at gmail.com (Pedro Jose) Date: Wed, 26 Mar 2008 21:18:27 +0100 Subject: Problem with SELinux and rkhunter on Fedora 8 Message-ID: Hello: I'm a spanish user of Fedora 8, a great distribution. I send this mail because I see a alert of SElinux troubleshooter with rkhunter. I have received two alerts: Res?menSELinux is preventing sendmail (system_mail_t) "append" to /var/rkhunter/tmp/rkhcronlog.mFxQaF5049 (var_t). Descripci?n DetalladaSELinux denied access requested by sendmail. It is not expected that this access is required by sendmail 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. Permitiendo AccesoSometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /var/rkhunter/tmp/rkhcronlog.mFxQaF5049, restorecon -v '/var/rkhunter/tmp/rkhcronlog.mFxQaF5049' 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 Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report against this package. Informaci?n AdicionalContexto Fuente: system_u:system_r:system_mail_t:s0Contexto Destino: system_u:object_r:var_t:s0Objetos Destino: /var/rkhunter/tmp/rkhcronlog.mFxQaF5049 [ file ]Source: sendmailSource Path: /usr/sbin/sendmail.sendmailPort: Host: localhost.localdomainSource RPM Packages: sendmail-8.14.2-1.fc8Target RPM Packages: RPM de Pol?ticas: selinux-policy-3.0.8-93.fc8SELinux Activado: TrueTipo de Pol?tica: targetedMLS Activado: TrueModo Obediente: EnforcingNombre de Plugin: catchall_fileNombre de Equipo: localhost.localdomainPlataforma: Linux localhost.localdomain 2.6.24.3-34.fc8 #1 SMP Wed Mar 12 18:17:20 EDT 2008 i686 i686Cantidad de Alertas: 1First Seen: mi? 26 mar 2008 18:47:43 CETLast Seen: mi? 26 mar 2008 18:47:43 CETLocal ID: 65abd64d-1a3f-4d68-a9b0-5ea5cf268d85N?meros de L?nea: Mensajes de Auditor?a Crudos :host=localhost.localdomain type=AVC msg=audit(1206553663.4:30): avc: denied { append } for pid=21759 comm="sendmail" path="/var/rkhunter/tmp/rkhcronlog.mFxQaF5049" dev=sda6 ino=1766018 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=file host=localhost.localdomain type=SYSCALL msg=audit(1206553663.4:30): arch=40000003 syscall=11 success=yes exit=0 a0=805848b a1=956760c a2=bfc98a58 a3=956760c items=0 ppid=21758 pid=21759 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=51 sgid=51 fsgid=51 tty=(none) comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=system_u:system_r:system_mail_t:s0 key=(null) The second alert it's same, because change the destiny file. How do I solve it? Sorry, because my english is very bad. -- Saludos, Pedro From ercrokan at gmail.com Wed Mar 26 20:20:37 2008 From: ercrokan at gmail.com (Pedro Jose) Date: Wed, 26 Mar 2008 21:20:37 +0100 Subject: Problem with SELinux and rkhunter on Fedora 8 In-Reply-To: References: Message-ID: Forgiveness, not paste good warning. Here, have a more readable Thanks. Res?men: SELinux is preventing sendmail (system_mail_t) "append" to /var/rkhunter/tmp/rkhcronlog.mFxQaF5049 (var_t). Descripci?n Detallada: SELinux denied access requested by sendmail. It is not expected that this access is required by sendmail 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. Permitiendo Acceso: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /var/rkhunter/tmp/rkhcronlog.mFxQaF5049, restorecon -v '/var/rkhunter/tmp/rkhcronlog.mFxQaF5049' 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. Informaci?n Adicional: Contexto Fuente system_u:system_r:system_mail_t:s0 Contexto Destino system_u:object_r:var_t:s0 Objetos Destino /var/rkhunter/tmp/rkhcronlog.mFxQaF5049 [ file ] Source sendmail Source Path /usr/sbin/sendmail.sendmail Port Host localhost.localdomain Source RPM Packages sendmail-8.14.2-1.fc8 Target RPM Packages RPM de Pol?ticas selinux-policy-3.0.8-93.fc8 SELinux Activado True Tipo de Pol?tica targeted MLS Activado True Modo Obediente Enforcing Nombre de Plugin catchall_file Nombre de Equipo localhost.localdomain Plataforma Linux localhost.localdomain 2.6.24.3-34.fc8 #1 SMP Wed Mar 12 18:17:20 EDT 2008 i686 i686 Cantidad de Alertas 1 First Seen mi? 26 mar 2008 18:47:43 CET Last Seen mi? 26 mar 2008 18:47:43 CET Local ID 65abd64d-1a3f-4d68-a9b0-5ea5cf268d85 N?meros de L?nea Mensajes de Auditor?a Crudos host=localhost.localdomain type=AVC msg=audit(1206553663.4:30): avc: denied { append } for pid=21759 comm="sendmail" path="/var/rkhunter/tmp/rkhcronlog.mFxQaF5049" dev=sda6 ino=1766018 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=file host=localhost.localdomain type=SYSCALL msg=audit(1206553663.4:30): arch=40000003 syscall=11 success=yes exit=0 a0=805848b a1=956760c a2=bfc98a58 a3=956760c items=0 ppid=21758 pid=21759 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=51 sgid=51 fsgid=51 tty=(none) comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=system_u:system_r:system_mail_t:s0 key=(null) From ercrokan at gmail.com Wed Mar 26 20:24:15 2008 From: ercrokan at gmail.com (Pedro Jose) Date: Wed, 26 Mar 2008 21:24:15 +0100 Subject: SELinux problem whith totem. Message-ID: Hello, I received this warning after installing totem-xine and run this for the first time. I am concerned because the solution will affect all applications on the system. (SELinux warning). This is: Res?men: SELinux is preventing totem from changing the access protection of memory on the heap. Descripci?n Detallada: The totem application attempted to change the access protection of memory on the heap (e.g., allocated using malloc). This is a potential security problem. Applications should not be doing this. Applications are sometimes coded incorrectly and request this permission. The SELinux Memory Protection Tests (http://people.redhat.com/drepper/selinux-mem.html) web page explains how to remove this requirement. If totem does not work and you need it to work, you can configure SELinux temporarily to allow this access until the application is fixed. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Permitiendo Acceso: If you want totem to continue, you must turn on the allow_execheap boolean. Note: This boolean will affect all applications on the system. El siguiente comando permitir? este acceso: setsebool -P allow_execheap=1 Informaci?n Adicional: Contexto Fuente system_u:system_r:unconfined_t:s0 Contexto Destino system_u:system_r:unconfined_t:s0 Objetos Destino None [ process ] Source totem Source Path /usr/bin/totem Port Host localhost.localdomain Source RPM Packages totem-xine-2.20.1-1.lvn8 Target RPM Packages RPM de Pol?ticas selinux-policy-3.0.8-93.fc8 SELinux Activado True Tipo de Pol?tica targeted MLS Activado True Modo Obediente Enforcing Nombre de Plugin allow_execheap Nombre de Equipo localhost.localdomain Plataforma Linux localhost.localdomain 2.6.24.3-34.fc8 #1 SMP Wed Mar 12 18:17:20 EDT 2008 i686 i686 Cantidad de Alertas 2 First Seen lun 24 mar 2008 22:26:42 CET Last Seen lun 24 mar 2008 22:26:42 CET Local ID c06e8b85-a4b1-4b69-8672-76e95d189cf9 N?meros de L?nea Mensajes de Auditor?a Crudos host=localhost.localdomain type=AVC msg=audit(1206394002.429:87): avc: denied { execheap } for pid=5071 comm="totem" scontext=system_u:system_r:unconfined_t:s0 tcontext=system_u:system_r:unconfined_t:s0 tclass=process host=localhost.localdomain type=SYSCALL msg=audit(1206394002.429:87): arch=40000003 syscall=125 success=no exit=-13 a0=808f000 a1=ad4000 a2=5 a3=bfe0eff0 items=0 ppid=1 pid=5071 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="totem" exe="/usr/bin/totem" subj=system_u:system_r:unconfined_t:s0 key=(null) How can I do? Thanks -- Saludos, Pedro From csellers at tresys.com Wed Mar 26 22:37:19 2008 From: csellers at tresys.com (Chad Sellers) Date: Wed, 26 Mar 2008 18:37:19 -0400 Subject: mailman not confined Message-ID: On F8 (as well as RHEL5 from the looks of things), it seems that mailman is not actually confined. The policy for it is compiled into the base module, but the transition never happens. So, mailmanctl and qrunner run in initrc_t. This looks like it is due to the fact that the default init script for mailman calls "/usr/bin/python /usr/lib/mailman/bin/mailmanctl" and "/usr/bin/python /usr/lib/mailman/bin/qrunner" rather than executing the scripts directly. The simple fix is to remove python from the init script. Anyone else noticing this problem? Any other ideas for a fix? Thanks, Chad Sellers From ashokharnal at yahoo.com Thu Mar 27 05:57:24 2008 From: ashokharnal at yahoo.com (ashok harnal) Date: Thu, 27 Mar 2008 11:27:24 +0530 (IST) Subject: Content type in public_html/DocumentRoot folder Message-ID: <536009.24346.qm@web94912.mail.in2.yahoo.com> Dear Gentlemen, Should web pages in public_html or DocumentRoot folder be of type user_t or httpd_sys_content_t or httpd_user_content_t? phpMyAdmin on installation from RPM package has contents of type user_t, drupal on installation from rpm package has contents of type httpd_sys_content_t. I am not clear about it? Is it possible to please clarify? Thanks, Ashok Harnal Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/ From valent.turkovic at gmail.com Thu Mar 27 10:08:19 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 27 Mar 2008 11:08:19 +0100 Subject: gconf alert In-Reply-To: <64b14b300803250251p698a8cc6wb679ddebcc320133@mail.gmail.com> References: <64b14b300803210436s4042e579n9519c9d211a87dba@mail.gmail.com> <64b14b300803220317tf341660kd198fd43ee42b8e9@mail.gmail.com> <47E4EA00.8020207@redhat.com> <64b14b300803220555iba954b7h4d24253d3f9e513e@mail.gmail.com> <64b14b300803220555t242524b5n7d2b13afe66861df@mail.gmail.com> <64b14b300803220559l4aa8c33clb88c66c1f356a205@mail.gmail.com> <47E5E673.7070700@gmail.com> <64b14b300803250211k79223cbfvb82853eba2fdfa6a@mail.gmail.com> <64b14b300803250234l6393f54bs9b0ae63322bfe52c@mail.gmail.com> <64b14b300803250251p698a8cc6wb679ddebcc320133@mail.gmail.com> Message-ID: <64b14b300803270308g1dd84d2av247ed1f3ba31e651@mail.gmail.com> On Tue, Mar 25, 2008 at 10:51 AM, Valent Turkovic wrote: > On Tue, Mar 25, 2008 at 10:34 AM, Valent Turkovic > > wrote: > > On Tue, Mar 25, 2008 at 10:11 AM, Valent Turkovic > > > > wrote: > > > > > On Sun, Mar 23, 2008 at 6:11 AM, Andrew Farris wrote: > > > > Valent Turkovic wrote: > > > > > Here are the latest ones from F8. > > > > > > > > > > I'll reboot to F9 beta and send those also. > > > > > > > > > > Valent. > > > > > > > > Can you try logging in via startx rather than GDM and see if it keeps happening? > > > > I'd be interested to know. My recent problem with GDM logging my user in as > > > > bootloader_t has just disappeared and I'm not sure why (although there was a > > > > policy and gdm version update, so it could have been fixed accidentally). > > > > > I updated gdm today and I still see issues, just look at my > > atachement. I deleted /tmp completely and relabeled my rawhide > > againg, and just look at the number of alerts I get! > > > > I'll try startx now to see if it helps. > > I went to VT1 and did init 3 as root and in VT2 as regular users I > started gnome with startx command. Before that I deleted all selinux > alerts and these are the alerts I get from logging to gnome only. If > you want or need some specific alert just tell me which one and I'll > send it to you. > > Please look at the attachement. > > > > Cheers, > Valent. > Has anybody taken a look at this? I'm seeing hundreds of selinux alerts with each command I start be it as root (yum install... ) or just as a regular user (firefox, gnome-terminal ...) Any idea why is this happening? Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From valent.turkovic at gmail.com Thu Mar 27 10:39:20 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 27 Mar 2008 11:39:20 +0100 Subject: gconf alert In-Reply-To: <64b14b300803270308g1dd84d2av247ed1f3ba31e651@mail.gmail.com> References: <64b14b300803210436s4042e579n9519c9d211a87dba@mail.gmail.com> <47E4EA00.8020207@redhat.com> <64b14b300803220555iba954b7h4d24253d3f9e513e@mail.gmail.com> <64b14b300803220555t242524b5n7d2b13afe66861df@mail.gmail.com> <64b14b300803220559l4aa8c33clb88c66c1f356a205@mail.gmail.com> <47E5E673.7070700@gmail.com> <64b14b300803250211k79223cbfvb82853eba2fdfa6a@mail.gmail.com> <64b14b300803250234l6393f54bs9b0ae63322bfe52c@mail.gmail.com> <64b14b300803250251p698a8cc6wb679ddebcc320133@mail.gmail.com> <64b14b300803270308g1dd84d2av247ed1f3ba31e651@mail.gmail.com> Message-ID: <64b14b300803270339m79ba848x44b6d949c598651e@mail.gmail.com> On Thu, Mar 27, 2008 at 11:08 AM, Valent Turkovic wrote: > On Tue, Mar 25, 2008 at 10:51 AM, Valent Turkovic > > > wrote: > > On Tue, Mar 25, 2008 at 10:34 AM, Valent Turkovic > > > > wrote: > > > On Tue, Mar 25, 2008 at 10:11 AM, Valent Turkovic > > > > > > wrote: > > > > > > > On Sun, Mar 23, 2008 at 6:11 AM, Andrew Farris wrote: > > > > > Valent Turkovic wrote: > > > > > > Here are the latest ones from F8. > > > > > > > > > > > > I'll reboot to F9 beta and send those also. > > > > > > > > > > > > Valent. > > > > > > > > > > Can you try logging in via startx rather than GDM and see if it keeps happening? > > > > > I'd be interested to know. My recent problem with GDM logging my user in as > > > > > bootloader_t has just disappeared and I'm not sure why (although there was a > > > > > policy and gdm version update, so it could have been fixed accidentally). > > > > > > > I updated gdm today and I still see issues, just look at my > > > atachement. I deleted /tmp completely and relabeled my rawhide > > > againg, and just look at the number of alerts I get! > > > > > > I'll try startx now to see if it helps. > > > > I went to VT1 and did init 3 as root and in VT2 as regular users I > > started gnome with startx command. Before that I deleted all selinux > > alerts and these are the alerts I get from logging to gnome only. If > > you want or need some specific alert just tell me which one and I'll > > send it to you. > > > > Please look at the attachement. > > > > > > > > Cheers, > > Valent. > > > > Has anybody taken a look at this? I'm seeing hundreds of selinux > alerts with each command I start be it as root (yum install... ) or > just as a regular user (firefox, gnome-terminal ...) > > Any idea why is this happening? > > > > Valent. I'm creating live cds under rawhide and I have selinux in permissive mode, could that be reason I'm seeing these hundreds of alerts? Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From jkubin at redhat.com Thu Mar 27 11:44:14 2008 From: jkubin at redhat.com (Josef Kubin) Date: Thu, 27 Mar 2008 12:44:14 +0100 Subject: Problem with SELinux and rkhunter on Fedora 8 In-Reply-To: References: Message-ID: <47EB888E.1060808@redhat.com> Hello, it needs a new SELinux policy for rkhunter: I'm currently working on it ... Relational thing is https://bugzilla.redhat.com/show_bug.cgi?id=438576 Josef From jdennis at redhat.com Thu Mar 27 17:36:40 2008 From: jdennis at redhat.com (John Dennis) Date: Thu, 27 Mar 2008 13:36:40 -0400 Subject: gconf alert In-Reply-To: <64b14b300803270339m79ba848x44b6d949c598651e@mail.gmail.com> References: <64b14b300803210436s4042e579n9519c9d211a87dba@mail.gmail.com> <47E4EA00.8020207@redhat.com> <64b14b300803220555iba954b7h4d24253d3f9e513e@mail.gmail.com> <64b14b300803220555t242524b5n7d2b13afe66861df@mail.gmail.com> <64b14b300803220559l4aa8c33clb88c66c1f356a205@mail.gmail.com> <47E5E673.7070700@gmail.com> <64b14b300803250211k79223cbfvb82853eba2fdfa6a@mail.gmail.com> <64b14b300803250234l6393f54bs9b0ae63322bfe52c@mail.gmail.com> <64b14b300803250251p698a8cc6wb679ddebcc320133@mail.gmail.com> <64b14b300803270308g1dd84d2av247ed1f3ba31e651@mail.gmail.com> <64b14b300803270339m79ba848x44b6d949c598651e@mail.gmail.com> Message-ID: <47EBDB28.5070302@redhat.com> Valent Turkovic wrote: > I'm creating live cds under rawhide and I have selinux in permissive > mode, could that be reason I'm seeing these hundreds of alerts? https://www.redhat.com/archives/fedora-selinux-list/2008-March/msg00130.html -- John Dennis From dwalsh at redhat.com Fri Mar 28 06:08:14 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 28 Mar 2008 07:08:14 +0100 Subject: mailman not confined In-Reply-To: References: Message-ID: <47EC8B4E.7020700@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chad Sellers wrote: > On F8 (as well as RHEL5 from the looks of things), it seems that mailman is > not actually confined. The policy for it is compiled into the base module, > but the transition never happens. So, mailmanctl and qrunner run in > initrc_t. This looks like it is due to the fact that the default init script > for mailman calls "/usr/bin/python /usr/lib/mailman/bin/mailmanctl" and > "/usr/bin/python /usr/lib/mailman/bin/qrunner" rather than executing the > scripts directly. The simple fix is to remove python from the init script. > Anyone else noticing this problem? Any other ideas for a fix? > > Thanks, > Chad Sellers > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Please open a bugzilla on it. Looks like it is correct in rawhide grep MAILMANCTL mailman MAILMANCTL=$MAILMANHOME/bin/mailmanctl daemon $MAILMANCTL -s -q start daemon $MAILMANCTL -q stop $MAILMANCTL -q -u status $MAILMANCTL -u status -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfsi04ACgkQrlYvE4MpobMYlgCgr7Dj/QkIGAWgsPGtcB0K3Fe5 Jy4AoMcLbM/5KrXnjIAdX59Qau3TxmY6 =h9NM -----END PGP SIGNATURE----- From valent.turkovic at gmail.com Fri Mar 28 11:47:19 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 28 Mar 2008 12:47:19 +0100 Subject: gconf alert In-Reply-To: <47EBDB28.5070302@redhat.com> References: <64b14b300803210436s4042e579n9519c9d211a87dba@mail.gmail.com> <64b14b300803220555t242524b5n7d2b13afe66861df@mail.gmail.com> <64b14b300803220559l4aa8c33clb88c66c1f356a205@mail.gmail.com> <47E5E673.7070700@gmail.com> <64b14b300803250211k79223cbfvb82853eba2fdfa6a@mail.gmail.com> <64b14b300803250234l6393f54bs9b0ae63322bfe52c@mail.gmail.com> <64b14b300803250251p698a8cc6wb679ddebcc320133@mail.gmail.com> <64b14b300803270308g1dd84d2av247ed1f3ba31e651@mail.gmail.com> <64b14b300803270339m79ba848x44b6d949c598651e@mail.gmail.com> <47EBDB28.5070302@redhat.com> Message-ID: <64b14b300803280447w18c862bcnac23b26617c86056@mail.gmail.com> On Thu, Mar 27, 2008 at 6:36 PM, John Dennis wrote: > Valent Turkovic wrote: > > I'm creating live cds under rawhide and I have selinux in permissive > > mode, could that be reason I'm seeing these hundreds of alerts? > > https://www.redhat.com/archives/fedora-selinux-list/2008-March/msg00130.html > > -- > John Dennis > Ok, I'm an idiot :) I got so much going on at once (work, moving to new apartment, etc...) that I totally forgot I got this replied already. But I want to keep in permissive an not enforcing mode so is just "load_policy" enough ? Cheers, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From csellers at tresys.com Fri Mar 28 14:46:46 2008 From: csellers at tresys.com (Chad Sellers) Date: Fri, 28 Mar 2008 10:46:46 -0400 Subject: mailman not confined In-Reply-To: <47EC8B4E.7020700@redhat.com> Message-ID: On 3/28/08 2:08 AM, "Daniel J Walsh" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Chad Sellers wrote: >> On F8 (as well as RHEL5 from the looks of things), it seems that mailman is >> not actually confined. The policy for it is compiled into the base module, >> but the transition never happens. So, mailmanctl and qrunner run in >> initrc_t. This looks like it is due to the fact that the default init script >> for mailman calls "/usr/bin/python /usr/lib/mailman/bin/mailmanctl" and >> "/usr/bin/python /usr/lib/mailman/bin/qrunner" rather than executing the >> scripts directly. The simple fix is to remove python from the init script. >> Anyone else noticing this problem? Any other ideas for a fix? >> >> Thanks, >> Chad Sellers >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Please open a bugzilla on it. > > Looks like it is correct in rawhide > > > grep MAILMANCTL mailman > MAILMANCTL=$MAILMANHOME/bin/mailmanctl > daemon $MAILMANCTL -s -q start > daemon $MAILMANCTL -q stop > $MAILMANCTL -q -u status > $MAILMANCTL -u status Hmmm, guess I should have checked bugzilla first. Looks like there's already a resolved bug (#350461) for this, which is why it's resolved in rawhide. I don't suppose this will get backported to RHEL5 in an update? Thanks, Chad From dwalsh at redhat.com Fri Mar 28 20:31:44 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 28 Mar 2008 21:31:44 +0100 Subject: mailman not confined In-Reply-To: References: Message-ID: <47ED55B0.1060407@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chad Sellers wrote: > On 3/28/08 2:08 AM, "Daniel J Walsh" wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Chad Sellers wrote: >>> On F8 (as well as RHEL5 from the looks of things), it seems that mailman is >>> not actually confined. The policy for it is compiled into the base module, >>> but the transition never happens. So, mailmanctl and qrunner run in >>> initrc_t. This looks like it is due to the fact that the default init script >>> for mailman calls "/usr/bin/python /usr/lib/mailman/bin/mailmanctl" and >>> "/usr/bin/python /usr/lib/mailman/bin/qrunner" rather than executing the >>> scripts directly. The simple fix is to remove python from the init script. >>> Anyone else noticing this problem? Any other ideas for a fix? >>> >>> Thanks, >>> Chad Sellers >>> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> Please open a bugzilla on it. >> >> Looks like it is correct in rawhide >> >> >> grep MAILMANCTL mailman >> MAILMANCTL=$MAILMANHOME/bin/mailmanctl >> daemon $MAILMANCTL -s -q start >> daemon $MAILMANCTL -q stop >> $MAILMANCTL -q -u status >> $MAILMANCTL -u status > > Hmmm, guess I should have checked bugzilla first. Looks like there's already > a resolved bug (#350461) for this, which is why it's resolved in rawhide. I > don't suppose this will get backported to RHEL5 in an update? > > Thanks, > Chad > A customer Bugzilla is required to get it backported. So open a bugzilla and ask. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkftVbAACgkQrlYvE4MpobP+uQCg2nsDEnpKzZmqSPxV5cBpJ8Aa A1cAnAige1IaYU9zfSemRkR+QBPv/xBq =m1xk -----END PGP SIGNATURE----- From dwalsh at redhat.com Sat Mar 29 16:47:45 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sat, 29 Mar 2008 17:47:45 +0100 Subject: Starting stunnel from xinetd In-Reply-To: References: <47E00ACD.6010707@redhat.com> Message-ID: <47EE72B1.7040304@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ian Pilcher wrote: > Daniel J Walsh wrote: >> selinux-policy-3.0.8-95.fc8.src.rpm >> >> >> Adds stunnel_system_domain to inetd_system_domain, which will allow >> stunnel to transition to every domain that is defined as an >> inetd_system_domain. > > Progress. Now getting a denial when rsync tries to read/write to the > socket it gets from stunnel: > > host=f8.example.com type=AVC msg=audit(1206311825.570:66): avc: denied > { read write } for pid=2962 comm="rsync" name="[11108]" dev=sockfs > ino=11108 scontext=system_u:system_r:rsync_t:s0-s0:c0.c1023 > tcontext=system_u:system_r:stunnel_t:s0-s0:c0.c1023 tclass=tcp_socket > > Thanks! > Added in selinux-policy-3.0.8-97. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfucrEACgkQrlYvE4MpobPnOgCg61yGmR0UtfpSLMUFr3ABkBjM R00AoJzBdBdasPofGhplwR1MOW7QbH7V =MtZX -----END PGP SIGNATURE----- From dwalsh at redhat.com Sat Mar 29 16:55:48 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sat, 29 Mar 2008 17:55:48 +0100 Subject: gconf alert In-Reply-To: <64b14b300803280447w18c862bcnac23b26617c86056@mail.gmail.com> References: <64b14b300803210436s4042e579n9519c9d211a87dba@mail.gmail.com> <64b14b300803220555t242524b5n7d2b13afe66861df@mail.gmail.com> <64b14b300803220559l4aa8c33clb88c66c1f356a205@mail.gmail.com> <47E5E673.7070700@gmail.com> <64b14b300803250211k79223cbfvb82853eba2fdfa6a@mail.gmail.com> <64b14b300803250234l6393f54bs9b0ae63322bfe52c@mail.gmail.com> <64b14b300803250251p698a8cc6wb679ddebcc320133@mail.gmail.com> <64b14b300803270308g1dd84d2av247ed1f3ba31e651@mail.gmail.com> <64b14b300803270339m79ba848x44b6d949c598651e@mail.gmail.com> <47EBDB28.5070302@redhat.com> <64b14b300803280447w18c862bcnac23b26617c86056@mail.gmail.com> Message-ID: <47EE7494.3040609@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Valent Turkovic wrote: > On Thu, Mar 27, 2008 at 6:36 PM, John Dennis wrote: >> Valent Turkovic wrote: >> > I'm creating live cds under rawhide and I have selinux in permissive >> > mode, could that be reason I'm seeing these hundreds of alerts? >> >> https://www.redhat.com/archives/fedora-selinux-list/2008-March/msg00130.html >> >> -- >> John Dennis >> > > Ok, I'm an idiot :) I got so much going on at once (work, moving to > new apartment, etc...) that I totally forgot I got this replied > already. > > But I want to keep in permissive an not enforcing mode so is just > "load_policy" enough ? > > Cheers, > Valent. > load_policy and you might need to kill any processes that are running as unlabeled_t. Potentially you could have files that are mislabeled. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfudJQACgkQrlYvE4MpobMfuACcDhnRsx5dXJJoS3HGf5J4YFqp ipMAoInLsgUWE9688LhmKhbLwkbxjBL9 =WeE3 -----END PGP SIGNATURE----- From dwalsh at redhat.com Sat Mar 29 17:07:53 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sat, 29 Mar 2008 18:07:53 +0100 Subject: Problem with SELinux and rkhunter on Fedora 8 In-Reply-To: <47EB888E.1060808@redhat.com> References: <47EB888E.1060808@redhat.com> Message-ID: <47EE7769.8020602@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Josef Kubin wrote: > Hello, it needs a new SELinux policy for rkhunter: > I'm currently working on it ... > Relational thing is https://bugzilla.redhat.com/show_bug.cgi?id=438576 > > Josef > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Joseph and I played around with a policy for rkhunter and quickly found it to be too cumbersome to confine. Pretty much needs unconfined_domain to do its thing. rkhunter package is moving it's log files to /var/log and other files to /var/run, We can then make policy for sendmail to dontaudit writes. This is a perfect example of allowing sendmail Read/Write but no Open. Pedro, you can allow this access by executing # grep mail /var/log/audit/audit.log | audit2allow -M myrkhunter # semodule -i myrkhunter.pp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfud2kACgkQrlYvE4MpobP0NACghVmyJZHkrZXjhZfkU1PvJzTz EpwAniKVdm6r34QiHcS6sq5OVttSiBwZ =ee01 -----END PGP SIGNATURE----- From dwalsh at redhat.com Sat Mar 29 17:10:57 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sat, 29 Mar 2008 18:10:57 +0100 Subject: SELinux problem whith totem. In-Reply-To: References: Message-ID: <47EE7821.8010903@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pedro Jose wrote: > Hello, I received this warning after installing totem-xine and run > this for the first time. I am concerned because the solution will > affect all applications on the system. (SELinux warning). > > This is: > > > Res?men: > > SELinux is preventing totem from changing the access protection of memory on the > heap. > > Descripci?n Detallada: > > The totem application attempted to change the access protection of memory on the > heap (e.g., allocated using malloc). This is a potential security problem. > Applications should not be doing this. Applications are sometimes coded > incorrectly and request this permission. The SELinux Memory Protection Tests > (http://people.redhat.com/drepper/selinux-mem.html) web page explains how to > remove this requirement. If totem does not work and you need it to work, you can > configure SELinux temporarily to allow this access until the application is > fixed. Please file a bug report > (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. > > Permitiendo Acceso: > > If you want totem to continue, you must turn on the allow_execheap boolean. > Note: This boolean will affect all applications on the system. > > El siguiente comando permitir? este acceso: > > setsebool -P allow_execheap=1 > > Informaci?n Adicional: > > Contexto Fuente system_u:system_r:unconfined_t:s0 > Contexto Destino system_u:system_r:unconfined_t:s0 > Objetos Destino None [ process ] > Source totem > Source Path /usr/bin/totem > Port > Host localhost.localdomain > Source RPM Packages totem-xine-2.20.1-1.lvn8 > Target RPM Packages > RPM de Pol?ticas selinux-policy-3.0.8-93.fc8 > SELinux Activado True > Tipo de Pol?tica targeted > MLS Activado True > Modo Obediente Enforcing > Nombre de Plugin allow_execheap > Nombre de Equipo localhost.localdomain > Plataforma Linux localhost.localdomain 2.6.24.3-34.fc8 #1 SMP > Wed Mar 12 18:17:20 EDT 2008 i686 i686 > Cantidad de Alertas 2 > First Seen lun 24 mar 2008 22:26:42 CET > Last Seen lun 24 mar 2008 22:26:42 CET > Local ID c06e8b85-a4b1-4b69-8672-76e95d189cf9 > N?meros de L?nea > > Mensajes de Auditor?a Crudos > > host=localhost.localdomain type=AVC msg=audit(1206394002.429:87): avc: > denied { execheap } for pid=5071 comm="totem" > scontext=system_u:system_r:unconfined_t:s0 > tcontext=system_u:system_r:unconfined_t:s0 tclass=process > > host=localhost.localdomain type=SYSCALL msg=audit(1206394002.429:87): > arch=40000003 syscall=125 success=no exit=-13 a0=808f000 a1=ad4000 > a2=5 a3=bfe0eff0 items=0 ppid=1 pid=5071 auid=500 uid=500 gid=500 > euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) > comm="totem" exe="/usr/bin/totem" > subj=system_u:system_r:unconfined_t:s0 key=(null) > > > How can I do? > > Thanks > You are trying to run a program that is doing something dangerous. I am pretty sure this is caused by a badly coded codec. You can either not run the codec, or execute # setsebool -P allow_execheap 1 Like the message told you. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfueCEACgkQrlYvE4MpobNhfwCbBRzkqtUp/2+6CkCuO6UWCKtl StwAoOu+Ozzr7UPoFzGUgTwXAHsUXbzV =m16G -----END PGP SIGNATURE----- From dwalsh at redhat.com Sat Mar 29 17:12:42 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sat, 29 Mar 2008 18:12:42 +0100 Subject: Content type in public_html/DocumentRoot folder In-Reply-To: <536009.24346.qm@web94912.mail.in2.yahoo.com> References: <536009.24346.qm@web94912.mail.in2.yahoo.com> Message-ID: <47EE788A.8000806@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ashok harnal wrote: > Dear Gentlemen, > > Should web pages in public_html or DocumentRoot folder be of type user_t or httpd_sys_content_t or httpd_user_content_t? > user_t is the type of a process httpd_sys_content_t is for the system content of apache. httpd_user_content_t is for user content used by apache. > phpMyAdmin on installation from RPM package has contents of type user_t, drupal on installation > from rpm package has contents of type httpd_sys_content_t. > > I am not clear about it? Is it possible to please clarify? > You should not have any files labeled user_t. man httpd_selinux Also has some information. > Thanks, > > Ashok Harnal > > > > Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/ > > > -- > 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 iEYEARECAAYFAkfueIoACgkQrlYvE4MpobM93gCdFYtINWUlAXx3ZCO6TpmN1rm1 /icAn099WCB1i9czroxMz0eAoVWDmWyS =mHez -----END PGP SIGNATURE-----