From lance at spitzner.net Tue Jan 1 17:47:40 2008 From: lance at spitzner.net (Lance Spitzner) Date: Tue, 1 Jan 2008 11:47:40 -0600 Subject: Beginner question deciphering SELinux logs In-Reply-To: <1199115888.3197.1.camel@choeger4> References: <1199115888.3197.1.camel@choeger4> Message-ID: <187C1419-D7E2-4C8F-B505-5119DDBC2582@spitzner.net> I'm very excited to learn more about SELinux as I jump in configuring this amazing tool. So I hope you folks don't mind a beginner question or two. Right now I'm attempting to better understand AVC logs. I've got SAMBA setup to do standard file sharing on CentOS 5.1. Default targeted policy is set in enforcing mode. When set to permissive, no problem. However, enforcing is giving me the following error below. I've already set the following booleans to 1, which has not helped. samba_enable_home_dirs on use_samba_home_dirs on Could a kind soul share with me what the log below is telling me? Thanks! lance PS: Is there anyway to configure SELinux/auditd to use regular dates, as sylogd does? type=AVC msg=audit(1199209100.230:984): avc: denied { read } for pid=26929 comm="smbd" name="home" dev=sdb1 ino=92504065 scontext=user_u:system_r:smbd_t:s0 tcontext=system_u:object_r:home_root_t:s0 tclass=dir type=SYSCALL msg=audit(1199209100.230:984): arch=40000003 syscall=5 success=no exit=-13 a0=93f9288 a1=18800 a2=bf85dccc a3=93f9268 items=0 ppid=22310 pid=26929 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=user_u:system_r:smbd_t:s0 key=(null) From lance at spitzner.net Tue Jan 1 19:45:17 2008 From: lance at spitzner.net (Lance Spitzner) Date: Tue, 1 Jan 2008 13:45:17 -0600 Subject: Beginner question deciphering SELinux logs In-Reply-To: <187C1419-D7E2-4C8F-B505-5119DDBC2582@spitzner.net> References: <1199115888.3197.1.camel@choeger4> <187C1419-D7E2-4C8F-B505-5119DDBC2582@spitzner.net> Message-ID: Thanks for the tremendous feedback so far, I appreciate it! I hope this is not bad form, but I would like to answer my own question, but then I have more questions. The error below shows that Samba SMB service could not access 'home' which turns out to be /home. System #ls -ldZ /home drwxr-xr-x root root system_u:object_r:home_root_t /home For some reason smbd_t cannot access home_root_t. So I did a chcon on /home which fixed the problem. My question is, by fixing the error have I made Samba more insecure, was this a bug, is there something I could do instead? chcon system_u:object_r:user_home_dir_t /home Thanks! lance > type=AVC msg=audit(1199209100.230:984): avc: denied { read } for > pid=26929 comm="smbd" name="home" dev=sdb1 ino=92504065 > scontext=user_u:system_r:smbd_t:s0 > tcontext=system_u:object_r:home_root_t:s0 tclass=dir > > type=SYSCALL msg=audit(1199209100.230:984): arch=40000003 syscall=5 > success=no exit=-13 a0=93f9288 a1=18800 a2=bf85dccc a3=93f9268 > items=0 ppid=22310 pid=26929 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=user_u:system_r:smbd_t:s0 key=(null) From leo.prasath at gmail.com Tue Jan 1 23:30:12 2008 From: leo.prasath at gmail.com (Leo Prasath) Date: Wed, 2 Jan 2008 05:00:12 +0530 Subject: Is SELinux support as a kernel module possible ?? Message-ID: <84c69f3a0801011530g7b34fc19x2ff3d66989d028d1@mail.gmail.com> Hi guys, I have a need to install SELinux on a sytem running with a kernel without SELinux built into it. However, I cannot reinstall a custom kernel with the SELinux built into it. So, I am looking at building a kernel module for SELinux and load it. I tried compiling the kernel with config option CONFIG_SECURITY_SELINUX=m and i got this error: .config:984:warning: symbol value 'm' invalid for SECURITY_SELINUX Is it possible to load SELinux as a kernel module ? Has anyone tried this ? Any help is appreciated Thanks, Leo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eparis at redhat.com Wed Jan 2 02:34:49 2008 From: eparis at redhat.com (Eric Paris) Date: Tue, 01 Jan 2008 21:34:49 -0500 Subject: Beginner question deciphering SELinux logs In-Reply-To: <187C1419-D7E2-4C8F-B505-5119DDBC2582@spitzner.net> References: <1199115888.3197.1.camel@choeger4> <187C1419-D7E2-4C8F-B505-5119DDBC2582@spitzner.net> Message-ID: <1199241290.3716.9.camel@localhost.localdomain> On Tue, 2008-01-01 at 11:47 -0600, Lance Spitzner wrote: > PS: Is there anyway to configure SELinux/auditd to use regular dates, > as sylogd does? Stop looking at audit logs directly. (I'll leave the policy questions to the policy people, sorry) ausearch -m AVC -i -Eric From eparis at redhat.com Wed Jan 2 02:36:15 2008 From: eparis at redhat.com (Eric Paris) Date: Tue, 01 Jan 2008 21:36:15 -0500 Subject: Is SELinux support as a kernel module possible ?? In-Reply-To: <84c69f3a0801011530g7b34fc19x2ff3d66989d028d1@mail.gmail.com> References: <84c69f3a0801011530g7b34fc19x2ff3d66989d028d1@mail.gmail.com> Message-ID: <1199241375.3716.12.camel@localhost.localdomain> No, it is not possible. Sorry. There is no work to make it possible nor will there be. There is actually work going on to remove most of the modular (but unusable/broken) infrastructure in LSM code. -Eric On Wed, 2008-01-02 at 05:00 +0530, Leo Prasath wrote: > Hi guys, > > I have a need to install SELinux on a sytem running with a kernel > without SELinux built into it. However, I cannot reinstall a custom > kernel with the SELinux built into it. > > So, I am looking at building a kernel module for SELinux and load it. > I tried compiling the kernel with config option > CONFIG_SECURITY_SELINUX=m and i got this error: > > .config:984:warning: symbol value 'm' invalid for SECURITY_SELINUX > > Is it possible to load SELinux as a kernel module ? Has anyone tried > this ? > > Any help is appreciated > > Thanks, > Leo. > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From lance at spitzner.net Wed Jan 2 02:59:18 2008 From: lance at spitzner.net (Lance Spitzner) Date: Tue, 1 Jan 2008 20:59:18 -0600 Subject: Beginner question deciphering SELinux logs In-Reply-To: <1199241290.3716.9.camel@localhost.localdomain> References: <1199115888.3197.1.camel@choeger4> <187C1419-D7E2-4C8F-B505-5119DDBC2582@spitzner.net> <1199241290.3716.9.camel@localhost.localdomain> Message-ID: <0C93B236-4F03-4073-94B5-93B07F64207C@spitzner.net> > >> PS: Is there anyway to configure SELinux/auditd to use regular dates, >> as sylogd does? > > Stop looking at audit logs directly. (I'll leave the policy questions > to the policy people, sorry) > > ausearch -m AVC -i Very cool, thanks! One other outstanding suggestion I received was the RPM pkg 'setroubleshoot'. It does a mind blowing / amazing job of taking AVC error messages and explaining to you exactly what they mean and suggested actions. Not only does it help troubleshooting, but it helps to better understand SElinux in general. Now only if there was such a utlity for the rest of Linux logging (dmesg anyone? :). Thanks! lance Summary SELinux is preventing /usr/sbin/named (named_t) "getattr" access to /dev/random (tmpfs_t). Detailed Description SELinux denied access requested by /usr/sbin/named. It is not expected that this access is required by /usr/sbin/named 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. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Allowing Access Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /dev/random, restorecon -v /dev/random. 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 entirely for the application. Disabling SELinux protection is not recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Changing the "named_disable_trans" boolean to true will disable SELinux protection this application: "setsebool -P named_disable_trans=1." The following command will allow this access: setsebool -P named_disable_trans=1 Additional Information Source Context user_u:system_r:named_t Target Context system_u:object_r:tmpfs_t Target Objects /dev/random [ chr_file ] Affected RPM Packages Policy RPM Selinux Enabled Policy Type MLS Enabled Enforcing Mode Plugin Name plugins.disable_trans Host Name Platform Alert Count 1 Line Numbers 1689,1690 Raw Audit Messages avc: denied { getattr } for comm="named" dev=sdb1 egid=25 euid=25 exe="/usr/sbin/named" exit=-13 fsgid=25 fsuid=25 gid=25 items=0 path="/dev/random" pid=10791 scontext=user_u:system_r:named_t:s0 sgid=25 subj=user_u:system_r:named_t:s0 suid=25 tclass=chr_file tcontext=system_u:object_r:tmpfs_t:s0 tty=(none) uid=25 From eparis at redhat.com Wed Jan 2 16:02:31 2008 From: eparis at redhat.com (Eric Paris) Date: Wed, 02 Jan 2008 11:02:31 -0500 Subject: Beginner question deciphering SELinux logs In-Reply-To: <0C93B236-4F03-4073-94B5-93B07F64207C@spitzner.net> References: <1199115888.3197.1.camel@choeger4> <187C1419-D7E2-4C8F-B505-5119DDBC2582@spitzner.net> <1199241290.3716.9.camel@localhost.localdomain> <0C93B236-4F03-4073-94B5-93B07F64207C@spitzner.net> Message-ID: <1199289751.3716.18.camel@localhost.localdomain> On Tue, 2008-01-01 at 20:59 -0600, Lance Spitzner wrote: > > > >> PS: Is there anyway to configure SELinux/auditd to use regular dates, > >> as sylogd does? > > > > Stop looking at audit logs directly. (I'll leave the policy questions > > to the policy people, sorry) > > > > ausearch -m AVC -i > > Very cool, thanks! One other outstanding suggestion I received was > the RPM pkg 'setroubleshoot'. It does a mind blowing / amazing job of > taking AVC error messages and explaining to you exactly what they mean > and suggested actions. Not only does it help troubleshooting, but it > helps to better understand SElinux in general. Now only if there was > such a utlity for the rest of Linux logging (dmesg anyone? :). > > Thanks! > > lance > > Summary > SELinux is preventing /usr/sbin/named (named_t) "getattr" access to > /dev/random (tmpfs_t). ummm, how did it get mislabled? hmmm, anyway, if you followed the restorecon suggestion i assume it started working.... -Eric From paul at city-fan.org Wed Jan 2 17:05:04 2008 From: paul at city-fan.org (Paul Howarth) Date: Wed, 02 Jan 2008 17:05:04 +0000 Subject: Sendmail milters in Fedora 8 Message-ID: <477BC440.9000809@city-fan.org> Since upgrading my mail server from Fedora 7 to Fedora 8, I've come across some problems with the sockets used for communication between sendmail and two of the "milter" plugins I'm using with it, namely milter-regex and spamass-milter. It's very likely that other milters will have similar issues. The sockets used are created when the milter starts, as follows: milter-regex: /var/spool/milter-regex/sock (var_spool_t, inherited from parent directory) spamass-milter: /var/run/spamass-milter/spamass-milter.sock (spamd_var_run_t, in policy) These are pretty well the upstream locations, though I'm open to moving the milter-regex socket from /var/spool to /var/run or elsewhere for consistency. Since moving to Fedora 8, I've had to add the following to local policy to get these milters working: allow sendmail_t spamd_var_run_t:dir { search getattr }; allow sendmail_t spamd_var_run_t:sock_file { getattr write }; allow sendmail_t var_spool_t:sock_file { getattr write }; allow sendmail_t initrc_t:unix_stream_socket { read write connectto }; The last of these is the strangest, and relates to Bug #425958 (https://bugzilla.redhat.com/show_bug.cgi?id=425958). Whilst the socket file itself has the context listed above, the unix domain socket that sendmail connects to is still initrc_t, as can be seen from the output of "netstat -lpZ": ... unix 2 [ ACC ] STREAM LISTENING 14142 5853/spamass-milter system_u:system_r:initrc_t:s0 /var/run/spamass-milter/spamass-milter.sock unix 2 [ ACC ] STREAM LISTENING 13794 5779/milter-regex system_u:system_r:initrc_t:s0 /var/spool/milter-regex/sock ... So, my questions are: 1. Why are the sockets still initrc_t? 2. Is this a kernel issue or a userspace issue that should be fixed in the milters? 3. Should there be a standard place for milter sockets to live, and if so, where? 4. How come this worked OK in Fedora 7 and previous releases? Paul. From wingc at umich.edu Thu Jan 3 04:10:49 2008 From: wingc at umich.edu (Christopher Allen Wing) Date: Wed, 2 Jan 2008 23:10:49 -0500 (EST) Subject: question re: mount_t context and network I/O Message-ID: Hello, I have a question regarding the mount_t context on RHEL5 (but for my purposes the recent Fedora SELinux policies are equally relevant). I am having a problem where occasionally the 'umount' binary hangs because the filesystem being unmounted (OpenAFS) tries to do network I/O as part of the kernel code path triggered by the umount() system call. The actual audit messages in the log look like this: audit(1199237877.841:1837): avc: denied { write } for pid=29174 comm="umount" lport=7001 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=udp_socket What's happening here, as far as I can tell, is that the openafs filesystem (kernel code) tries to do some network I/O from inside the umount() system call. Because this happens in the context of the umount process itself, SELinux applies the same restrictions that it would have if umount had deliberately used sockets itself. (The UDP socket in question, bound to port 7001, would have been created at the time that the openafs filesystem was initialized) My question is: What does the current SELinux policy (e.g. targeted policy) on Fedora do for the case of NFS and cifs, for the mount_t context? Can mount/umount perform any network I/O, or is this restricted? Thanks, Chris Wing wingc at umich.edu From selinux at gmail.com Thu Jan 3 14:51:16 2008 From: selinux at gmail.com (Tom London) Date: Thu, 3 Jan 2008 06:51:16 -0800 Subject: depmod_t failure again..... sigh Message-ID: <4c4ba1530801030651t3635c53cx70e04ee9334bd454@mail.gmail.com> Today's yum update of kernel reports (in targeted/enforcing): Installing: kernel ####################### [10/60] WARNING: Couldn't open directory /tmp/initrd.fu5084/lib/modules/2.6.24-0.133.rc6.git8.fc9: Permission denied FATAL: Could not open /tmp/initrd.fu5084/lib/modules/2.6.24-0.133.rc6.git8.fc9/modules.dep.temp for writing: Permission denied Here is the raw AVC: type=AVC msg=audit(1199371409.130:30): avc: denied { search } for pid=7185 comm="depmod" name="tmp" dev=dm-0 ino=2686977 scontext=unconfined_u:system_r:depmod_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir type=SYSCALL msg=audit(1199371409.130:30): arch=40000003 syscall=5 success=no exit=-13 a0=8941070 a1=98800 a2=2e646f6d a3=8941110 items=0 ppid=4720 pid=7185 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="depmod" exe="/sbin/depmod" subj=unconfined_u:system_r:depmod_t:s0 key=(null) type=AVC msg=audit(1199371409.130:31): avc: denied { search } for pid=7185 comm="depmod" name="tmp" dev=dm-0 ino=2686977 scontext=unconfined_u:system_r:depmod_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir type=SYSCALL msg=audit(1199371409.130:31): arch=40000003 syscall=5 success=no exit=-13 a0=bfb012b0 a1=241 a2=1b6 a3=895d480 items=0 ppid=4720 pid=7185 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="depmod" exe="/sbin/depmod" subj=unconfined_u:system_r:depmod_t:s0 key=(null) Removing kernel package, and rerunning in permissive mode yields: type=AVC msg=audit(1199371729.926:38): avc: denied { search } for pid=10294 comm="depmod" name="tmp" dev=dm-0 ino=2686977 scontext=unconfined_u:system_r:depmod_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir type=AVC msg=audit(1199371729.926:38): avc: denied { search } for pid=10294 comm="depmod" name="initrd.qF8194" dev=dm-0 ino=2687511 scontext=unconfined_u:system_r:depmod_t:s0 tcontext=unconfined_u:object_r:rpm_script_tmp_t:s0 tclass=dir type=AVC msg=audit(1199371729.926:38): avc: denied { read } for pid=10294 comm="depmod" name="2.6.24-0.133.rc6.git8.fc9" dev=dm-0 ino=2687516 scontext=unconfined_u:system_r:depmod_t:s0 tcontext=unconfined_u:object_r:rpm_script_tmp_t:s0 tclass=dir type=SYSCALL msg=audit(1199371729.926:38): arch=40000003 syscall=5 success=yes exit=3 a0=8ac5070 a1=98800 a2=2e646f6d a3=8ac5110 items=0 ppid=7830 pid=10294 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="depmod" exe="/sbin/depmod" subj=unconfined_u:system_r:depmod_t:s0 key=(null) type=AVC msg=audit(1199371729.927:39): avc: denied { getattr } for pid=10294 comm="depmod" path="/tmp/initrd.qF8194/lib/modules/2.6.24-0.133.rc6.git8.fc9" dev=dm-0 ino=2687516 scontext=unconfined_u:system_r:depmod_t:s0 tcontext=unconfined_u:object_r:rpm_script_tmp_t:s0 tclass=dir type=SYSCALL msg=audit(1199371729.927:39): arch=40000003 syscall=197 success=yes exit=0 a0=3 a1=bfd6253c a2=950ff4 a3=3 items=0 ppid=7830 pid=10294 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="depmod" exe="/sbin/depmod" subj=unconfined_u:system_r:depmod_t:s0 key=(null) type=AVC msg=audit(1199371729.927:40): avc: denied { read } for pid=10294 comm="depmod" name="scsi_mod.ko" dev=dm-0 ino=2687575 scontext=unconfined_u:system_r:depmod_t:s0 tcontext=unconfined_u:object_r:rpm_script_tmp_t:s0 tclass=file type=SYSCALL msg=audit(1199371729.927:40): arch=40000003 syscall=5 success=yes exit=4 a0=8ae2514 a1=0 a2=1b6 a3=8ae8c20 items=0 ppid=7830 pid=10294 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="depmod" exe="/sbin/depmod" subj=unconfined_u:system_r:depmod_t:s0 key=(null) type=AVC msg=audit(1199371729.927:41): avc: denied { getattr } for pid=10294 comm="depmod" path="/tmp/initrd.qF8194/lib/modules/2.6.24-0.133.rc6.git8.fc9/scsi_mod.ko" dev=dm-0 ino=2687575 scontext=unconfined_u:system_r:depmod_t:s0 tcontext=unconfined_u:object_r:rpm_script_tmp_t:s0 tclass=file type=SYSCALL msg=audit(1199371729.927:41): arch=40000003 syscall=197 success=yes exit=0 a0=4 a1=bfd6228c a2=950ff4 a3=8ae8c20 items=0 ppid=7830 pid=10294 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="depmod" exe="/sbin/depmod" subj=unconfined_u:system_r:depmod_t:s0 key=(null) type=AVC msg=audit(1199371729.931:42): avc: denied { write } for pid=10294 comm="depmod" name="2.6.24-0.133.rc6.git8.fc9" dev=dm-0 ino=2687516 scontext=unconfined_u:system_r:depmod_t:s0 tcontext=unconfined_u:object_r:rpm_script_tmp_t:s0 tclass=dir type=AVC msg=audit(1199371729.931:42): avc: denied { add_name } for pid=10294 comm="depmod" name="modules.dep.temp" scontext=unconfined_u:system_r:depmod_t:s0 tcontext=unconfined_u:object_r:rpm_script_tmp_t:s0 tclass=dir type=AVC msg=audit(1199371729.931:42): avc: denied { create } for pid=10294 comm="depmod" name="modules.dep.temp" scontext=unconfined_u:system_r:depmod_t:s0 tcontext=unconfined_u:object_r:rpm_script_tmp_t:s0 tclass=file type=AVC msg=audit(1199371729.931:42): avc: denied { write } for pid=10294 comm="depmod" name="modules.dep.temp" dev=dm-0 ino=2687612 scontext=unconfined_u:system_r:depmod_t:s0 tcontext=unconfined_u:object_r:rpm_script_tmp_t:s0 tclass=file type=SYSCALL msg=audit(1199371729.931:42): arch=40000003 syscall=5 success=yes exit=3 a0=bfd62510 a1=241 a2=1b6 a3=8b3b1e0 items=0 ppid=7830 pid=10294 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="depmod" exe="/sbin/depmod" subj=unconfined_u:system_r:depmod_t:s0 key=(null) type=AVC msg=audit(1199371729.932:43): avc: denied { remove_name } for pid=10294 comm="depmod" name="modules.dep.temp" dev=dm-0 ino=2687612 scontext=unconfined_u:system_r:depmod_t:s0 tcontext=unconfined_u:object_r:rpm_script_tmp_t:s0 tclass=dir type=AVC msg=audit(1199371729.932:43): avc: denied { rename } for pid=10294 comm="depmod" name="modules.dep.temp" dev=dm-0 ino=2687612 scontext=unconfined_u:system_r:depmod_t:s0 tcontext=unconfined_u:object_r:rpm_script_tmp_t:s0 tclass=file type=SYSCALL msg=audit(1199371729.932:43): arch=40000003 syscall=38 success=yes exit=0 a0=bfd62510 a1=bfd62570 a2=8b3b1e0 a3=bfd62510 items=0 ppid=7830 pid=10294 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="depmod" exe="/sbin/depmod" subj=unconfined_u:system_r:depmod_t:s0 key=(null) or #============= depmod_t ============== allow depmod_t rpm_script_tmp_t:dir { write search read remove_name getattr add_name }; allow depmod_t rpm_script_tmp_t:file { read write getattr create rename }; allow depmod_t tmp_t:dir search; tom -- Tom London From selinux at gmail.com Thu Jan 3 15:29:35 2008 From: selinux at gmail.com (Tom London) Date: Thu, 3 Jan 2008 07:29:35 -0800 Subject: /var/log/btmp getting mislabeled? Message-ID: <4c4ba1530801030729t49245d39g79a73da71d52e813@mail.gmail.com> I just got this one logging in. Looks like /var/log/btmp is getting mislabeled Summary SELinux is preventing gdm-simple-slav(/usr/libexec/gdm-simple-slave) (xdm_t) "write" to (var_log_t). Detailed Description SELinux is preventing gdm-simple-slav(/usr/libexec/gdm-simple-slave) (xdm_t) "write" to (var_log_t). The SELinux type var_log_t, is a generic type for all files in the directory and very few processes (SELinux Domains) are allowed to write to this SELinux type. This type of denial usual indicates a mislabeled file. By default a file created in a directory has the gets the context of the parent directory, but SELinux policy has rules about the creation of directories, that say if a process running in one SELinux Domain (D1) creates a file in a directory with a particular SELinux File Context (F1) the file gets a different File Context (F2). The policy usually allows the SELinux Domain (D1) the ability to write, unlink, and append on (F2). But if for some reason a file () was created with the wrong context, this domain will be denied. The usual solution to this problem is to reset the file context on the target file, restorecon -v . If the file context does not change from var_log_t, then this is probably a bug in policy. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against the selinux-policy package. If it does change, you can try your application again to see if it works. The file context could have been mislabeled by editing the file or moving the file from a different directory, if the file keeps getting mislabeled, check the init scripts to see if they are doing something to mislabel the file. Allowing Access You can attempt to fix file context by executing restorecon -v The following command will allow this access: restorecon <Unknown> Additional Information Source Context system_u:system_r:xdm_t:SystemLow-SystemHigh Target Context system_u:object_r:var_log_t Target Objects None [ file ] Source gdm-simple-slav(/usr/libexec/gdm-simple-slave) Port Host localhost.localdomain Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.2.5-7.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name mislabeled_file Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.24-0.133.rc6.git8.fc9 #1 SMP Wed Jan 2 18:40:29 EST 2008 i686 i686 Alert Count 1 First Seen Thu 03 Jan 2008 07:19:37 AM PST Last Seen Thu 03 Jan 2008 07:19:37 AM PST Local ID f5de46fe-618f-4bc4-9bae-e0a5c22c3343 Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1199373577.824:19): avc: denied { write } for pid=2544 comm="gdm-simple-slav" name="btmp" dev=dm-0 ino=66570 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=file host=localhost.localdomain type=SYSCALL msg=audit(1199373577.824:19): arch=40000003 syscall=5 success=no exit=-13 a0=8060c66 a1=8001 a2=0 a3=8060c70 items=0 ppid=2484 pid=2544 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="gdm-simple-slav" exe="/usr/libexec/gdm-simple-slave" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) --------- [root at localhost log]# restorecon -v -R /var/log restorecon reset /var/log/btmp context system_u:object_r:var_log_t:s0->system_u:object_r:faillog_t:s0 restorecon reset /var/log/rpmpkgs context system_u:object_r:cron_log_t:s0->system_u:object_r:rpm_log_t:s0 [root at localhost log]# -- Tom London From paul at city-fan.org Thu Jan 3 15:43:08 2008 From: paul at city-fan.org (Paul Howarth) Date: Thu, 03 Jan 2008 15:43:08 +0000 Subject: /var/log/btmp getting mislabeled? In-Reply-To: <4c4ba1530801030729t49245d39g79a73da71d52e813@mail.gmail.com> References: <4c4ba1530801030729t49245d39g79a73da71d52e813@mail.gmail.com> Message-ID: <477D028C.70300@city-fan.org> Tom London wrote: > I just got this one logging in. Looks like /var/log/btmp is getting mislabeled > > Summary > > SELinux is preventing gdm-simple-slav(/usr/libexec/gdm-simple-slave) (xdm_t) > "write" to (var_log_t). https://bugzilla.redhat.com/show_bug.cgi?id=427274 Paul. From eparis at redhat.com Thu Jan 3 16:18:50 2008 From: eparis at redhat.com (Eric Paris) Date: Thu, 03 Jan 2008 11:18:50 -0500 Subject: depmod_t failure again..... sigh In-Reply-To: <4c4ba1530801030651t3635c53cx70e04ee9334bd454@mail.gmail.com> References: <4c4ba1530801030651t3635c53cx70e04ee9334bd454@mail.gmail.com> Message-ID: <1199377130.3716.26.camel@localhost.localdomain> Dan knows and he has it fixed on his local system, he will push it rawhide soonish -Eric On Thu, 2008-01-03 at 06:51 -0800, Tom London wrote: > Today's yum update of kernel reports (in targeted/enforcing): > > Installing: kernel ####################### [10/60] > WARNING: Couldn't open directory > /tmp/initrd.fu5084/lib/modules/2.6.24-0.133.rc6.git8.fc9: Permission > denied > FATAL: Could not open > /tmp/initrd.fu5084/lib/modules/2.6.24-0.133.rc6.git8.fc9/modules.dep.temp > for writing: Permission denied > > Here is the raw AVC: > > type=AVC msg=audit(1199371409.130:30): avc: denied { search } for > pid=7185 comm="depmod" name="tmp" dev=dm-0 ino=2686977 > scontext=unconfined_u:system_r:depmod_t:s0 > tcontext=system_u:object_r:tmp_t:s0 tclass=dir > type=SYSCALL msg=audit(1199371409.130:30): arch=40000003 syscall=5 > success=no exit=-13 a0=8941070 a1=98800 a2=2e646f6d a3=8941110 items=0 > ppid=4720 pid=7185 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=pts0 comm="depmod" exe="/sbin/depmod" > subj=unconfined_u:system_r:depmod_t:s0 key=(null) > type=AVC msg=audit(1199371409.130:31): avc: denied { search } for > pid=7185 comm="depmod" name="tmp" dev=dm-0 ino=2686977 > scontext=unconfined_u:system_r:depmod_t:s0 > tcontext=system_u:object_r:tmp_t:s0 tclass=dir > type=SYSCALL msg=audit(1199371409.130:31): arch=40000003 syscall=5 > success=no exit=-13 a0=bfb012b0 a1=241 a2=1b6 a3=895d480 items=0 > ppid=4720 pid=7185 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=pts0 comm="depmod" exe="/sbin/depmod" > subj=unconfined_u:system_r:depmod_t:s0 key=(null) > > Removing kernel package, and rerunning in permissive mode yields: > > type=AVC msg=audit(1199371729.926:38): avc: denied { search } for > pid=10294 comm="depmod" name="tmp" dev=dm-0 ino=2686977 > scontext=unconfined_u:system_r:depmod_t:s0 > tcontext=system_u:object_r:tmp_t:s0 tclass=dir > type=AVC msg=audit(1199371729.926:38): avc: denied { search } for > pid=10294 comm="depmod" name="initrd.qF8194" dev=dm-0 ino=2687511 > scontext=unconfined_u:system_r:depmod_t:s0 > tcontext=unconfined_u:object_r:rpm_script_tmp_t:s0 tclass=dir > type=AVC msg=audit(1199371729.926:38): avc: denied { read } for > pid=10294 comm="depmod" name="2.6.24-0.133.rc6.git8.fc9" dev=dm-0 > ino=2687516 scontext=unconfined_u:system_r:depmod_t:s0 > tcontext=unconfined_u:object_r:rpm_script_tmp_t:s0 tclass=dir > type=SYSCALL msg=audit(1199371729.926:38): arch=40000003 syscall=5 > success=yes exit=3 a0=8ac5070 a1=98800 a2=2e646f6d a3=8ac5110 items=0 > ppid=7830 pid=10294 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=pts0 comm="depmod" exe="/sbin/depmod" > subj=unconfined_u:system_r:depmod_t:s0 key=(null) > type=AVC msg=audit(1199371729.927:39): avc: denied { getattr } for > pid=10294 comm="depmod" > path="/tmp/initrd.qF8194/lib/modules/2.6.24-0.133.rc6.git8.fc9" > dev=dm-0 ino=2687516 scontext=unconfined_u:system_r:depmod_t:s0 > tcontext=unconfined_u:object_r:rpm_script_tmp_t:s0 tclass=dir > type=SYSCALL msg=audit(1199371729.927:39): arch=40000003 syscall=197 > success=yes exit=0 a0=3 a1=bfd6253c a2=950ff4 a3=3 items=0 ppid=7830 > pid=10294 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 tty=pts0 comm="depmod" exe="/sbin/depmod" > subj=unconfined_u:system_r:depmod_t:s0 key=(null) > type=AVC msg=audit(1199371729.927:40): avc: denied { read } for > pid=10294 comm="depmod" name="scsi_mod.ko" dev=dm-0 ino=2687575 > scontext=unconfined_u:system_r:depmod_t:s0 > tcontext=unconfined_u:object_r:rpm_script_tmp_t:s0 tclass=file > type=SYSCALL msg=audit(1199371729.927:40): arch=40000003 syscall=5 > success=yes exit=4 a0=8ae2514 a1=0 a2=1b6 a3=8ae8c20 items=0 ppid=7830 > pid=10294 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 tty=pts0 comm="depmod" exe="/sbin/depmod" > subj=unconfined_u:system_r:depmod_t:s0 key=(null) > type=AVC msg=audit(1199371729.927:41): avc: denied { getattr } for > pid=10294 comm="depmod" > path="/tmp/initrd.qF8194/lib/modules/2.6.24-0.133.rc6.git8.fc9/scsi_mod.ko" > dev=dm-0 ino=2687575 scontext=unconfined_u:system_r:depmod_t:s0 > tcontext=unconfined_u:object_r:rpm_script_tmp_t:s0 tclass=file > type=SYSCALL msg=audit(1199371729.927:41): arch=40000003 syscall=197 > success=yes exit=0 a0=4 a1=bfd6228c a2=950ff4 a3=8ae8c20 items=0 > ppid=7830 pid=10294 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=pts0 comm="depmod" exe="/sbin/depmod" > subj=unconfined_u:system_r:depmod_t:s0 key=(null) > type=AVC msg=audit(1199371729.931:42): avc: denied { write } for > pid=10294 comm="depmod" name="2.6.24-0.133.rc6.git8.fc9" dev=dm-0 > ino=2687516 scontext=unconfined_u:system_r:depmod_t:s0 > tcontext=unconfined_u:object_r:rpm_script_tmp_t:s0 tclass=dir > type=AVC msg=audit(1199371729.931:42): avc: denied { add_name } for > pid=10294 comm="depmod" name="modules.dep.temp" > scontext=unconfined_u:system_r:depmod_t:s0 > tcontext=unconfined_u:object_r:rpm_script_tmp_t:s0 tclass=dir > type=AVC msg=audit(1199371729.931:42): avc: denied { create } for > pid=10294 comm="depmod" name="modules.dep.temp" > scontext=unconfined_u:system_r:depmod_t:s0 > tcontext=unconfined_u:object_r:rpm_script_tmp_t:s0 tclass=file > type=AVC msg=audit(1199371729.931:42): avc: denied { write } for > pid=10294 comm="depmod" name="modules.dep.temp" dev=dm-0 ino=2687612 > scontext=unconfined_u:system_r:depmod_t:s0 > tcontext=unconfined_u:object_r:rpm_script_tmp_t:s0 tclass=file > type=SYSCALL msg=audit(1199371729.931:42): arch=40000003 syscall=5 > success=yes exit=3 a0=bfd62510 a1=241 a2=1b6 a3=8b3b1e0 items=0 > ppid=7830 pid=10294 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=pts0 comm="depmod" exe="/sbin/depmod" > subj=unconfined_u:system_r:depmod_t:s0 key=(null) > type=AVC msg=audit(1199371729.932:43): avc: denied { remove_name } > for pid=10294 comm="depmod" name="modules.dep.temp" dev=dm-0 > ino=2687612 scontext=unconfined_u:system_r:depmod_t:s0 > tcontext=unconfined_u:object_r:rpm_script_tmp_t:s0 tclass=dir > type=AVC msg=audit(1199371729.932:43): avc: denied { rename } for > pid=10294 comm="depmod" name="modules.dep.temp" dev=dm-0 ino=2687612 > scontext=unconfined_u:system_r:depmod_t:s0 > tcontext=unconfined_u:object_r:rpm_script_tmp_t:s0 tclass=file > type=SYSCALL msg=audit(1199371729.932:43): arch=40000003 syscall=38 > success=yes exit=0 a0=bfd62510 a1=bfd62570 a2=8b3b1e0 a3=bfd62510 > items=0 ppid=7830 pid=10294 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 > egid=0 sgid=0 fsgid=0 tty=pts0 comm="depmod" exe="/sbin/depmod" > subj=unconfined_u:system_r:depmod_t:s0 key=(null) > > or > #============= depmod_t ============== > allow depmod_t rpm_script_tmp_t:dir { write search read remove_name > getattr add_name }; > allow depmod_t rpm_script_tmp_t:file { read write getattr create rename }; > allow depmod_t tmp_t:dir search; > > > tom From flyingboxcutter at yahoo.com Thu Jan 3 19:15:19 2008 From: flyingboxcutter at yahoo.com (Harley Race) Date: Thu, 3 Jan 2008 11:15:19 -0800 (PST) Subject: Sendmail 8.14 selinux In-Reply-To: <47795499.2040205@redhat.com> Message-ID: <361707.80289.qm@web60216.mail.yahoo.com> --- Daniel J Walsh wrote: > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > I will add this to the next upgrade of selinux > policy. > > You can add it yourself by executing > > # grep signull /var/log/audit/audit.log | > audit2allow -M mysendmail > # semodule -i mysendmail.pp > > Fixed in selinux-policy-3.0.8-73 Thank you very much for your swift response. I went ahead and did as you instructed. No problems thus far. ____________________________________________________________________________________ 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 Thu Jan 3 19:51:25 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Thu, 3 Jan 2008 11:51:25 -0800 (PST) Subject: SELinux is preventing dbus-daemon Message-ID: <156502.12799.qm@web52609.mail.re2.yahoo.com> Summary SELinux is preventing dbus-daemon(/bin/dbus-daemon) (xdm_dbusd_t) "search" to (xdm_var_lib_t). Detailed Description SELinux denied access requested by dbus-daemon(/bin/dbus-daemon). It is not expected that this access is required by dbus-daemon(/bin/dbus-daemon) 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 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:xdm_dbusd_t:SystemLow-SystemHigh Target Context system_u:object_r:xdm_var_lib_t Target Objects None [ dir ] Source dbus-daemon(/bin/dbus-daemon) Port Host localhost Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.2.5-7.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.24-0.115.rc5.git5.fc9 #1 SMP Tue Dec 18 23:57:17 EST 2007 i686 athlon Alert Count 1 First Seen Thu 03 Jan 2008 01:40:06 PM CST Last Seen Thu 03 Jan 2008 01:40:06 PM CST Local ID dd947e49-faa9-4afc-8018-1006b011d0c9 Line Numbers Raw Audit Messages host=localhost type=AVC msg=audit(1199389206.974:13): avc: denied { search } for pid=2372 comm="dbus-daemon" name="gdm" dev=dm-0 ino=3342356 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:xdm_var_lib_t:s0 tclass=dir host=localhost type=SYSCALL msg=audit(1199389206.974:13): arch=40000003 syscall=5 success=no exit=-13 a0=b89072a0 a1=98800 a2=0 a3=0 items=0 ppid=2371 pid=2372 auid=4294967295 uid=42 gid=42 euid=42 suid=42 fsuid=42 egid=42 sgid=42 fsgid=42 tty=(none) comm="dbus-daemon" exe="/bin/dbus-daemon" subj=system_u:system_r:xdm_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 Thu Jan 3 19:52:04 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Thu, 3 Jan 2008 11:52:04 -0800 (PST) Subject: SELinux is preventing firefox(/usr/lib/firefox-3.0b3pre/firefox) Message-ID: <974536.20041.qm@web52611.mail.re2.yahoo.com> Summary SELinux is preventing firefox(/usr/lib/firefox-3.0b3pre/firefox) from making the program stack executable. Detailed Description The firefox(/usr/lib/firefox-3.0b3pre/firefox) application attempted to make its stack executable. This is a potential security problem. This should never ever be necessary. Stack memory is not executable on most OSes these days and this will not change. Executable stack memory is one of the biggest security problems. An execstack error might in fact be most likely raised by malicious code. 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 firefox(/usr/lib/firefox-3.0b3pre/firefox) 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. Allowing Access Sometimes a library is accidentally marked with the execstack flag, if you find a library with this flag you can clear it with the execstack -c LIBRARY_PATH. Then retry your application. If the app continues to not work, you can turn the flag back on with execstack -s LIBRARY_PATH. Otherwise, if you trust firefox(/usr/lib/firefox-3.0b3pre/firefox) to run correctly, you can change the context of the executable to unconfined_execmem_exec_t. "chcon -t unconfined_execmem_exec_t firefox(/usr/lib/firefox-3.0b3pre/firefox)" You must also change the default file context files on the system in order to preserve them even on a full relabel. "semanage fcontext -a -t unconfined_execmem_exec_t firefox(/usr/lib/firefox-3.0b3pre/firefox)" The following command will allow this access: chcon -t unconfined_execmem_exec_t firefox(/usr/lib/firefox-3.0b3pre/firefox) Additional Information Source Context unconfined_u:unconfined_r:unconfined_t:SystemLow- SystemHigh Target Context unconfined_u:unconfined_r:unconfined_t:SystemLow- SystemHigh Target Objects None [ process ] Source firefox(/usr/lib/firefox-3.0b3pre/firefox) Port Host localhost Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.2.5-7.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name allow_execstack Host Name localhost Platform Linux localhost 2.6.24-0.115.rc5.git5.fc9 #1 SMP Tue Dec 18 23:57:17 EST 2007 i686 athlon Alert Count 2 First Seen Thu 03 Jan 2008 01:43:26 PM CST Last Seen Thu 03 Jan 2008 01:43:26 PM CST Local ID 34b8cafb-76b2-4a09-9515-0287ddf573b3 Line Numbers Raw Audit Messages host=localhost type=AVC msg=audit(1199389406.998:23): avc: denied { execstack } for pid=2751 comm="firefox" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process host=localhost type=SYSCALL msg=audit(1199389406.998:23): arch=40000003 syscall=125 success=no exit=-13 a0=bfa16000 a1=1000 a2=1000007 a3=fffff000 items=0 ppid=1 pid=2751 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="firefox" exe="/usr/lib/firefox-3.0b3pre/firefox" subj=unconfined_u:unconfined_r:unconfined_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 olivares14031 at yahoo.com Thu Jan 3 23:37:00 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Thu, 3 Jan 2008 15:37:00 -0800 (PST) Subject: What severity would this SELinux denial have for the latest kernel? In-Reply-To: <477D689B.9060002@insight.rr.com> Message-ID: <537065.20067.qm@web52606.mail.re2.yahoo.com> --- Jim Cornette wrote: > I updated the kernel after installing the latest > mkinitrd package and > some errors were reported when pup finished. I also > got the attsched > SELinux error. > The other SELinux error with xdm_var_lib_t was > already mentioned in an > earlier post. > > Jim > > > kernel - 2.6.24-0.133.rc6.git8.fc9.i686 > WARNING: Couldn't open directory > /tmp/initrd.dY3159/lib/modules/2.6.24-0.133.rc6.git8.fc9: > Permission denied > FATAL: Could not open > /tmp/initrd.dY3159/lib/modules/2.6.24-0.133.rc6.git8.fc9/modules.dep.temp > > for writing: Permission denied > > -- > If life is a stage, I want some better lighting. > > > Summary > > SELinux is preventing the depmod(/sbin/depmod) from > using potentially mislabeled > files (). > Detailed Description > > SELinux has denied depmod(/sbin/depmod) access to > potentially mislabeled file(s) > (). This means that SELinux will not allow > depmod(/sbin/depmod) 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 depmod(/sbin/depmod) to access this > files, you need to relabel them > using restorecon -v . You might want to > relabel the entire directory > using restorecon -R -v .Additional > Information > > Source Context > system_u:system_r:depmod_t > Target Context > system_u:object_r:tmp_t > Target Objects None [ dir ] > Source depmod(/sbin/depmod) > Port > Host HP-JCF7 > Source RPM Packages > Target RPM Packages > Policy RPM > selinux-policy-3.2.5-7.fc9 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name home_tmp_bad_labels > Host Name HP-JCF7 > Platform Linux HP-JCF7 > 2.6.23.8-63.fc8 #1 SMP Wed Nov 21 > 18:51:08 EST 2007 i686 > athlon > Alert Count 2 > First Seen Thu 03 Jan 2008 > 05:47:20 PM EST > Last Seen Thu 03 Jan 2008 > 05:47:20 PM EST > Local ID > bf1d6609-37f4-42b1-bd2c-75c64deca263 > Line Numbers > > Raw Audit Messages > > host=HP-JCF7 type=AVC msg=audit(1199400440.555:34): > avc: denied { search } for pid=5198 comm="depmod" > name="tmp" dev=sda6 ino=260097 > scontext=system_u:system_r:depmod_t:s0 > tcontext=system_u:object_r:tmp_t:s0 tclass=dir > > host=HP-JCF7 type=SYSCALL > msg=audit(1199400440.555:34): arch=40000003 > syscall=5 success=no exit=-13 a0=bf866ab0 a1=241 > a2=1b6 a3=9c68480 items=0 ppid=2957 pid=5198 > auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=(none) comm="depmod" > exe="/sbin/depmod" > subj=system_u:system_r:depmod_t:s0 key=(null) > > > > -- > fedora-test-list mailing list > fedora-test-list at redhat.com > To unsubscribe: > https://www.redhat.com/mailman/listinfo/fedora-test-list Jim, at least you have it installed, on my machine it failed :( /sbin/new-kernel-pkg: line 254: /sbin/depmod: Permission denied nash received SIGSEGV! Backtrace (11): /sbin/nash[0x805315a] [0x130440] /lib/libglib-2.0.so.0[0x1991a3] /usr/lib/libbdevid.so.6.0.24(bdevid_module_unload_all+0x31)[0x5cee37] /usr/lib/libbdevid.so.6.0.24(bdevid_destroy+0x2d)[0x5ce57c] /usr/lib/libnash.so.6.0.24[0x5ac198] /usr/lib/libnash.so.6.0.24(nash_vitals_destroy_probes+0x3f)[0x5ac810] /usr/lib/libnash.so.6.0.24(_nashFreeContext+0x1c)[0x59cfd6] /sbin/nash[0x80536f4] /lib/libc.so.6(__libc_start_main+0xe0)[0x33f4a0] /sbin/nash[0x804ae71] ^[[B error: %post(kernel-2.6.24-0.133.rc6.git8.fc9.i686) scriptlet failed, signal 2 Selinux upon rebooting caused other errors with firefox3beta, previously submitted to this list and selinux-list as well. I will also forward this to fedora-selinux-list as well so that they can recommend us what to do :) 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 selinux at gmail.com Thu Jan 3 23:55:10 2008 From: selinux at gmail.com (Tom London) Date: Thu, 3 Jan 2008 15:55:10 -0800 Subject: What severity would this SELinux denial have for the latest kernel? In-Reply-To: <537065.20067.qm@web52606.mail.re2.yahoo.com> References: <477D689B.9060002@insight.rr.com> <537065.20067.qm@web52606.mail.re2.yahoo.com> Message-ID: <4c4ba1530801031555u2b612628ud7c700b7b4e4cd8c@mail.gmail.com> On Jan 3, 2008 3:37 PM, Antonio Olivares wrote: > > > --- Jim Cornette wrote: > > > I updated the kernel after installing the latest > > mkinitrd package and > > some errors were reported when pup finished. I also > > got the attsched > > SELinux error. > > The other SELinux error with xdm_var_lib_t was > > already mentioned in an > > earlier post. > > > > Jim This has been reported and is being worked on (per posting on selinux list). There is a simple workaround that 'works for me': remove the improperly installed kernel package (via 'rpm -e' or 'yum remove'), change to permissive mode, and redo the install of the kernel package (via 'rpm -ivh' or 'yum update'). You can then change back to enforcing mode. This will not prevent the AVC, but the kernel installs properly and boots. I suspect we will see this fixed in a real short time. tom -- Tom London From fenn at stanford.edu Fri Jan 4 01:57:20 2008 From: fenn at stanford.edu (Tim Fenn) Date: Thu, 3 Jan 2008 17:57:20 -0800 Subject: sendmail/smrsh f8 avc error Message-ID: <20080103175720.067cb135@atbws1.stanford.edu> After updating from f7 to f8, it appears smrsh might be mislabelled (using selinux-policy-3.0.8-72.fc8) - or am I missing something? type=AVC msg=audit(1199408924.325:1608): avc: denied { getattr } for pid=10777 comm="sendmail" path="/usr/sbin/smrsh" dev=dm-0 ino=3785966 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file type=SYSCALL msg=audit(1199408924.325:1608): arch=c000003e syscall=4 success=no exit=-13 a0=7fff6e1c7d90 a1=7fff6e1c7c70 a2=7fff6e1c7c70 a3=7fff6e1c7d9f items=0 ppid=10776 pid=10777 auid=4294967295 uid=8 gid=12 euid=8 suid=8 fsuid=8 egid=12 sgid=12 fsgid=12 tty=(none) comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=system_u:system_r:sendmail_t:s0 key=(null) type=AVC msg=audit(1199408924.333:1609): avc: denied { execute } for pid=10777 comm="sendmail" name="smrsh" dev=dm-0 ino=3785966 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file type=SYSCALL msg=audit(1199408924.333:1609): arch=c000003e syscall=59 success=no exit=-13 a0=2aaaaae7a7a0 a1=7fff6e1c8f00 a2=2aaaaadb4b00 a3=0 items=0 ppid=10776 pid=10777 auid=4294967295 uid=8 gid=12 euid=8 suid=8 fsuid=8 egid=12 sgid=12 fsgid=12 tty=(none) comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=system_u:system_r:sendmail_t:s0 key=(null) -Tim -- CAPS LOCK IS THE CRUISE CONTROL OF AWESOMNESS From mike.clarkson at baesystems.com Fri Jan 4 22:26:46 2008 From: mike.clarkson at baesystems.com (Clarkson, Mike R (US SSA)) Date: Fri, 4 Jan 2008 14:26:46 -0800 Subject: two questions Message-ID: Is there someplace I can go to find a description of the libselinux API? Is there a way to change the context of an existing process, without having to execute a new process? Thanks From eparis at redhat.com Fri Jan 4 23:34:06 2008 From: eparis at redhat.com (Eric Paris) Date: Fri, 04 Jan 2008 18:34:06 -0500 Subject: two questions In-Reply-To: References: Message-ID: <1199489646.3716.106.camel@localhost.localdomain> On Fri, 2008-01-04 at 14:26 -0800, Clarkson, Mike R (US SSA) wrote: > Is there someplace I can go to find a description of the libselinux API? not sure, i just read the code :) the fedora libselinux-devel package provides man pages for most (maybe all?) of the interfaces. > > Is there a way to change the context of an existing process, without > having to execute a new process? yes, the permission is dyntransition in the process class. it is STRONGLY, let me say that again VERY STRONGLY, suggested that you don't make use of this facility. Basically you lose all seperation between those 2 domains. You don't have any assurance that the process before the transition didn't get hacked/corrupted/bugged and is now transitioning to a new domain but able to do the wrong things (or sometimes even worse not transition to the new domain at all) I'm not sure what the rationale was to put it in originally but please just find a way to do it on an execve boundary. -Eric From choeger at cs.tu-berlin.de Sat Jan 5 13:58:20 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Sat, 05 Jan 2008 14:58:20 +0100 Subject: two questions In-Reply-To: <1199489646.3716.106.camel@localhost.localdomain> References: <1199489646.3716.106.camel@localhost.localdomain> Message-ID: <1199541500.5014.1.camel@choeger4> Am Freitag, den 04.01.2008, 18:34 -0500 schrieb Eric Paris: > On Fri, 2008-01-04 at 14:26 -0800, Clarkson, Mike R (US SSA) wrote: > > Is there someplace I can go to find a description of the libselinux API? > > not sure, i just read the code :) the fedora libselinux-devel > package provides man pages for most (maybe all?) of the interfaces. > > > > > Is there a way to change the context of an existing process, without > > having to execute a new process? > > yes, the permission is dyntransition in the process class. it is > STRONGLY, let me say that again VERY STRONGLY, suggested that you don't > make use of this facility. Basically you lose all seperation between > those 2 domains. You don't have any assurance that the process before > the transition didn't get hacked/corrupted/bugged and is now > transitioning to a new domain but able to do the wrong things (or > sometimes even worse not transition to the new domain at all) Hi, I don't think that it is that bad. Basically I think if you can transition from dom_a to dom_b that still does not include transition back to dom_a. So you can e.g. secure a new thread which handles a client or something without using execve. > > I'm not sure what the rationale was to put it in originally but please > just find a way to do it on an execve boundary. > > -Eric > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From eparis at redhat.com Sat Jan 5 15:22:39 2008 From: eparis at redhat.com (Eric Paris) Date: Sat, 05 Jan 2008 10:22:39 -0500 Subject: two questions In-Reply-To: <1199541500.5014.1.camel@choeger4> References: <1199489646.3716.106.camel@localhost.localdomain> <1199541500.5014.1.camel@choeger4> Message-ID: <1199546559.3716.108.camel@localhost.localdomain> On Sat, 2008-01-05 at 14:58 +0100, Christoph H?ger wrote: > Am Freitag, den 04.01.2008, 18:34 -0500 schrieb Eric Paris: > > On Fri, 2008-01-04 at 14:26 -0800, Clarkson, Mike R (US SSA) wrote: > > > Is there someplace I can go to find a description of the libselinux API? > > > > not sure, i just read the code :) the fedora libselinux-devel > > package provides man pages for most (maybe all?) of the interfaces. > > > > > > > > Is there a way to change the context of an existing process, without > > > having to execute a new process? > > > > yes, the permission is dyntransition in the process class. it is > > STRONGLY, let me say that again VERY STRONGLY, suggested that you don't > > make use of this facility. Basically you lose all seperation between > > those 2 domains. You don't have any assurance that the process before > > the transition didn't get hacked/corrupted/bugged and is now > > transitioning to a new domain but able to do the wrong things (or > > sometimes even worse not transition to the new domain at all) > > Hi, I don't think that it is that bad. Basically I think if you can > transition from dom_a to dom_b that still does not include transition > back to dom_a. So you can e.g. secure a new thread which handles a > client or something without using execve. dyntrans only works on single threaded processes. -Eric > > > > > I'm not sure what the rationale was to put it in originally but please > > just find a way to do it on an execve boundary. > > > > -Eric > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From choeger at cs.tu-berlin.de Sat Jan 5 16:02:50 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Sat, 05 Jan 2008 17:02:50 +0100 Subject: two questions In-Reply-To: <1199546559.3716.108.camel@localhost.localdomain> References: <1199489646.3716.106.camel@localhost.localdomain> <1199541500.5014.1.camel@choeger4> <1199546559.3716.108.camel@localhost.localdomain> Message-ID: <1199548970.5014.9.camel@choeger4> Am Samstag, den 05.01.2008, 10:22 -0500 schrieb Eric Paris: > On Sat, 2008-01-05 at 14:58 +0100, Christoph H?ger wrote: > > Am Freitag, den 04.01.2008, 18:34 -0500 schrieb Eric Paris: > > > On Fri, 2008-01-04 at 14:26 -0800, Clarkson, Mike R (US SSA) wrote: > > > > Is there someplace I can go to find a description of the libselinux API? > > > > > > not sure, i just read the code :) the fedora libselinux-devel > > > package provides man pages for most (maybe all?) of the interfaces. > > > > > > > > > > > Is there a way to change the context of an existing process, without > > > > having to execute a new process? > > > > > > yes, the permission is dyntransition in the process class. it is > > > STRONGLY, let me say that again VERY STRONGLY, suggested that you don't > > > make use of this facility. Basically you lose all seperation between > > > those 2 domains. You don't have any assurance that the process before > > > the transition didn't get hacked/corrupted/bugged and is now > > > transitioning to a new domain but able to do the wrong things (or > > > sometimes even worse not transition to the new domain at all) > > > > Hi, I don't think that it is that bad. Basically I think if you can > > transition from dom_a to dom_b that still does not include transition > > back to dom_a. So you can e.g. secure a new thread which handles a > > client or something without using execve. > > dyntrans only works on single threaded processes. > > -Eric > > > > > > > > I'm not sure what the rationale was to put it in originally but please > > > just find a way to do it on an execve boundary. > > > > > > -Eric > > > > > > -- > > > fedora-selinux-list mailing list > > > fedora-selinux-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Hi, how does that work? After fork() a new thread/process should have the same rights as its parent, so if dyntrans is allowed before fork(), it should also work after that? From eparis at redhat.com Sat Jan 5 16:17:04 2008 From: eparis at redhat.com (Eric Paris) Date: Sat, 05 Jan 2008 11:17:04 -0500 Subject: two questions In-Reply-To: <1199548970.5014.9.camel@choeger4> References: <1199489646.3716.106.camel@localhost.localdomain> <1199541500.5014.1.camel@choeger4> <1199546559.3716.108.camel@localhost.localdomain> <1199548970.5014.9.camel@choeger4> Message-ID: <1199549824.3716.117.camel@localhost.localdomain> On Sat, 2008-01-05 at 17:02 +0100, Christoph H?ger wrote: > Am Samstag, den 05.01.2008, 10:22 -0500 schrieb Eric Paris: > > On Sat, 2008-01-05 at 14:58 +0100, Christoph H?ger wrote: > > > Am Freitag, den 04.01.2008, 18:34 -0500 schrieb Eric Paris: > > > > On Fri, 2008-01-04 at 14:26 -0800, Clarkson, Mike R (US SSA) wrote: > > > > > Is there someplace I can go to find a description of the libselinux API? > > > > > > > > not sure, i just read the code :) the fedora libselinux-devel > > > > package provides man pages for most (maybe all?) of the interfaces. > > > > > > > > > > > > > > Is there a way to change the context of an existing process, without > > > > > having to execute a new process? > > > > > > > > yes, the permission is dyntransition in the process class. it is > > > > STRONGLY, let me say that again VERY STRONGLY, suggested that you don't > > > > make use of this facility. Basically you lose all seperation between > > > > those 2 domains. You don't have any assurance that the process before > > > > the transition didn't get hacked/corrupted/bugged and is now > > > > transitioning to a new domain but able to do the wrong things (or > > > > sometimes even worse not transition to the new domain at all) > > > > > > Hi, I don't think that it is that bad. Basically I think if you can > > > transition from dom_a to dom_b that still does not include transition > > > back to dom_a. So you can e.g. secure a new thread which handles a > > > client or something without using execve. > > > > dyntrans only works on single threaded processes. > > > > -Eric > > > > > > > > > > > I'm not sure what the rationale was to put it in originally but please > > > > just find a way to do it on an execve boundary. > > > > > > > > -Eric > > > > > > > > -- > > > > fedora-selinux-list mailing list > > > > fedora-selinux-list at redhat.com > > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > Hi, > > how does that work? After fork() a new thread/process should have the > same rights as its parent, so if dyntrans is allowed before fork(), it > should also work after that? /* Only allow single threaded processes to change context */ if (atomic_read(&p->mm->mm_users) != 1) { struct task_struct *g, *t; struct mm_struct *mm = p->mm; read_lock(&tasklist_lock); do_each_thread(g, t) if (t->mm == mm && t != p) { read_unlock(&tasklist_lock); return -EPERM; } while_each_thread(g, t); read_unlock(&tasklist_lock); } You just explained the rationale why it should only work on single threaded processes :) Two threads share all of the same resources, if one of those is in dom_a and one of those is in dom_b you don't have any seperation between the domains. The thread in dom_b might (depending on the permissions of the code pages) be able to rewrite the code executing by the thread in dom_a. Now even without dom_b -> dom_a transition dom_b thread has full control in dom_a. Also remember that the thread in dom_b can write to data segments used by dom_a, so even if it can't rewrite its code pages it can probably pretty easily get it to call into a function it controls by rewriting its data pages (which obviously have no seperation) dyntransition is only allowed in single threaded processes. It can fork children after the transition, but if it forks before the transition it won't be allowed. -Eric From knute at frazmtn.com Sat Jan 5 18:14:33 2008 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 05 Jan 2008 10:14:33 -0800 Subject: Any idea what causes this message? Message-ID: <477F5889.17406.264C81@knute.frazmtn.com> Jan 5 03:19:30 www kernel: audit(1199531970.371:42): avc: denied { append } for pid=29639 comm="sshd" name="btmp" dev=dm-0 ino=2130022 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_log_t:s0 tclass=file I get these once in a while. Can anybody tell what causes them from this? F8 i386. Thanks, -- Knute Johnson Molon Labe... From eparis at redhat.com Sat Jan 5 20:03:26 2008 From: eparis at redhat.com (Eric Paris) Date: Sat, 05 Jan 2008 15:03:26 -0500 Subject: Any idea what causes this message? In-Reply-To: <477F5889.17406.264C81@knute.frazmtn.com> References: <477F5889.17406.264C81@knute.frazmtn.com> Message-ID: <1199563406.3716.121.camel@localhost.localdomain> Its a mislabeled file. /var/log/btmp should be labeled faillog_t restorecon -R -v /var/log to fix up everything in /var/log. btmp is used whenever there is a login failure (I think only failure...) not sure how it got mislabeled (what is supposed to create it, anyone know? do you remember at some time untaring a bunch of files in /var/log? or cp'ing in files? somehow it got created without the 'right' label) but it is occasional because people only occasionally screw up logging in and you get the denial because it is mislabeled. Fix the label and you should be good from now on. -Eric On Sat, 2008-01-05 at 10:14 -0800, Knute Johnson wrote: > Jan 5 03:19:30 www kernel: audit(1199531970.371:42): avc: denied { > append } for pid=29639 comm="sshd" name="btmp" dev=dm-0 ino=2130022 > scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 > tcontext=unconfined_u:object_r:var_log_t:s0 tclass=file > > I get these once in a while. Can anybody tell what causes them from > this? F8 i386. > > Thanks, > From knute at frazmtn.com Sun Jan 6 00:13:14 2008 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 05 Jan 2008 16:13:14 -0800 Subject: Any idea what causes this message? In-Reply-To: <1199563406.3716.121.camel@localhost.localdomain> References: <477F5889.17406.264C81@knute.frazmtn.com>, <1199563406.3716.121.camel@localhost.localdomain> Message-ID: <477FAC9A.30070.1CC78D@knute.frazmtn.com> >Its a mislabeled file. /var/log/btmp should be labeled faillog_t > >restorecon -R -v /var/log > >to fix up everything in /var/log. btmp is used whenever there is a >login failure (I think only failure...) > >not sure how it got mislabeled (what is supposed to create it, anyone >know? do you remember at some time untaring a bunch of files >in /var/log? or cp'ing in files? somehow it got created without the >'right' label) but it is occasional because people only occasionally >screw up logging in and you get the denial because it is mislabeled. >Fix the label and you should be good from now on. > >-Eric Thanks, it was mislabeled. I don't know how but it's fixed now. -- Knute Johnson Molon Labe... From gene.heskett at verizon.net Sun Jan 6 15:33:27 2008 From: gene.heskett at verizon.net (Gene Heskett) Date: Sun, 06 Jan 2008 10:33:27 -0500 Subject: su user -c problem Message-ID: <200801061033.27657.gene.heskett@verizon.net> Greetings; For years, I have been starting fetchmail as a background daemon by having the line: su user -c "fetchmail -d etc etc" in my rc.local script. Forced to re-install because something wiped the partition table on my boot drive, I installed F8 and I believe its was uptodate as of last night. But, its not running anymore via that procedure, and setroubleshoot's gui will display that it was denied at the time of the boot. It still works perfectly if I cut/paste that line into a root shell after I'm logged in. How can I address this? I've also bz'd it. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) I've found my niche. If you're wondering why I'm not there, there was this little hole in the bottom ... -- John Croll From selinux at gmail.com Sun Jan 6 18:50:00 2008 From: selinux at gmail.com (Tom London) Date: Sun, 6 Jan 2008 10:50:00 -0800 Subject: Funny AVC from USB CD plugin Message-ID: <4c4ba1530801061050y6f237ado949dc7f911412cd@mail.gmail.com> Running latest Rawhide, targeted/enforcing. Plugging in an 'old USB CD drive', I got the following audit message: [root at localhost ~]# sealert -l fb77e7e0-3515-4866-9a8f-e1db99f9b4b8 Summary: SELinux is preventing ln(/bin/ln) (udev_t) "create" to (etc_t). Detailed Description: SELinux denied access requested by ln(/bin/ln). It is not expected that this access is required by ln(/bin/ln) 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 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:udev_t:SystemLow-SystemHigh Target Context system_u:object_r:etc_t Target Objects None [ lnk_file ] Source ln(/bin/ln) Port Host localhost.localdomain Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.2.5-8.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.24-0.136.rc6.git12.fc9 #1 SMP Sat Jan 5 12:46:45 EST 2008 i686 i686 Alert Count 2 First Seen Sun Jan 6 10:30:15 2008 Last Seen Sun Jan 6 10:30:15 2008 Local ID fb77e7e0-3515-4866-9a8f-e1db99f9b4b8 Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1199644215.878:31): avc: denied { create } for pid=6933 comm="ln" name=".is-writeable" scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=lnk_file host=localhost.localdomain type=SYSCALL msg=audit(1199644215.878:31): arch=40000003 syscall=83 success=no exit=-13 a0=bff3ddc3 a1=bff3ddcd a2=804f77c a3=0 items=0 ppid=6931 pid=6933 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="ln" exe="/bin/ln" subj=system_u:system_r:udev_t:s0-s0:c0.c1023 key=(null) Here are the messages from /var/log/messages: Jan 6 10:30:05 localhost kernel: usb 2-2: new full speed USB device using uhci_hcd and address 4 Jan 6 10:30:06 localhost kernel: usb 2-2: configuration #1 chosen from 1 choice Jan 6 10:30:06 localhost kernel: scsi8 : SCSI emulation for USB Mass Storage devices Jan 6 10:30:06 localhost kernel: usb-storage: device found at 4 Jan 6 10:30:06 localhost kernel: usb-storage: waiting for device to settle before scanning Jan 6 10:30:11 localhost kernel: usb-storage: device scan complete Jan 6 10:30:11 localhost kernel: scsi 8:0:0:0: CD-ROM IBM USB CD-ROM 20A4 PQ: 0 ANSI: 0 CCS Jan 6 10:30:11 localhost kernel: sr1: scsi3-mmc drive: 10x/10x cd/rw xa/form2 cdda pop-up Jan 6 10:30:11 localhost kernel: sr 8:0:0:0: Attached scsi CD-ROM sr1 Jan 6 10:30:11 localhost kernel: sr 8:0:0:0: Attached scsi generic sg2 type 5 Jan 6 10:30:18 localhost setroubleshoot: #012 SELinux is preventing ln(/bin/ln) (udev_t) "create" to <Unknown> (etc_t).#012 For complete SELinux messages. run sealert -l fb77e7e0-3515-4866-9a8f-e1db99f9b4b8 Putting system in permissive mode, I get these: type=AVC msg=audit(1199645179.126:34): avc: denied { create } for pid=7782 comm="ln" name=".is-writeable" scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=lnk_file type=SYSCALL msg=audit(1199645179.126:34): arch=40000003 syscall=83 success=yes exit=0 a0=bfb56db6 a1=bfb56dc0 a2=804f77c a3=0 items=0 ppid=7780 pid=7782 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="ln" exe="/bin/ln" subj=system_u:system_r:udev_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1199645179.245:35): avc: denied { unlink } for pid=7783 comm="rm" name=".is-writeable" dev=dm-0 ino=11076747 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=lnk_file type=SYSCALL msg=audit(1199645179.245:35): arch=40000003 syscall=301 success=yes exit=0 a0=ffffff9c a1=bfa17dc0 a2=0 a3=bfa17dc0 items=0 ppid=7780 pid=7783 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="rm" exe="/bin/rm" subj=system_u:system_r:udev_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1199645179.255:36): avc: denied { append } for pid=7780 comm="write_cd_rules" name="70-persistent-cd.rules" dev=dm-0 ino=11076866 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=file type=SYSCALL msg=audit(1199645179.255:36): arch=40000003 syscall=5 success=yes exit=3 a0=8a98400 a1=8441 a2=1b6 a3=8441 items=0 ppid=7761 pid=7780 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="write_cd_rules" exe="/bin/bash" subj=system_u:system_r:udev_t:s0-s0:c0.c1023 key=(null) udev issue? tom -- Tom London From tmz at pobox.com Sun Jan 6 19:32:07 2008 From: tmz at pobox.com (Todd Zullinger) Date: Sun, 6 Jan 2008 14:32:07 -0500 Subject: su user -c problem In-Reply-To: <200801061033.27657.gene.heskett@verizon.net> References: <200801061033.27657.gene.heskett@verizon.net> Message-ID: <20080106193207.GE3136@inocybe.teonanacatl.org> Gene Heskett wrote: > For years, I have been starting fetchmail as a background daemon by > having the line: > su user -c "fetchmail -d etc etc" in my rc.local script. > > Forced to re-install because something wiped the partition table on > my boot drive, I installed F8 and I believe its was uptodate as of > last night. > > But, its not running anymore via that procedure, and > setroubleshoot's gui will display that it was denied at the time of > the boot. > > It still works perfectly if I cut/paste that line into a root shell > after I'm logged in. > > How can I address this? I've got similar things in /etc/rc.local that used to use su -c. I don't recall having them get denied outright, but the programs that were run definitely didn't pick up the proper SELinux contexts. So I now have a few entries like this: runcon user_u:system_r:unconfined_t -- runuser -l -c "screen -dm" tmz -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There's no trick to being a humorist when you have the whole government working for you. -- Will Rogers. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From gene.heskett at verizon.net Sun Jan 6 21:46:11 2008 From: gene.heskett at verizon.net (Gene Heskett) Date: Sun, 06 Jan 2008 16:46:11 -0500 Subject: su user -c problem In-Reply-To: <20080106193207.GE3136@inocybe.teonanacatl.org> References: <200801061033.27657.gene.heskett@verizon.net> <20080106193207.GE3136@inocybe.teonanacatl.org> Message-ID: <200801061646.11184.gene.heskett@verizon.net> On Sunday 06 January 2008, Todd Zullinger wrote: >Gene Heskett wrote: >> For years, I have been starting fetchmail as a background daemon by >> having the line: >> su user -c "fetchmail -d etc etc" in my rc.local script. >> >> Forced to re-install because something wiped the partition table on >> my boot drive, I installed F8 and I believe its was uptodate as of >> last night. >> >> But, its not running anymore via that procedure, and >> setroubleshoot's gui will display that it was denied at the time of >> the boot. >> >> It still works perfectly if I cut/paste that line into a root shell >> after I'm logged in. >> >> How can I address this? > >I've got similar things in /etc/rc.local that used to use su -c. I >don't recall having them get denied outright, but the programs that >were run definitely didn't pick up the proper SELinux contexts. So I >now have a few entries like this: > >runcon user_u:system_r:unconfined_t -- runuser -l -c "screen -dm" tmz I'm afraid I have pretty close to a NDI what that will do, Todd. And your use of the words 'used to' above also tells be your are doing this su user -c function differently now. Can you elaborate? The manpage for runcon is so concise as to be obtuse. Here is the line in question, in rc.local, that does not now work: su gene -c "fetchmail -d 90 --fetchmailrc /home/gene/.fetchmailrc" Can you translate that into a 'runcon' style line please? Thanks. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Failure is not an option -- it comes bundled with Windows. From tmz at pobox.com Sun Jan 6 22:06:31 2008 From: tmz at pobox.com (Todd Zullinger) Date: Sun, 6 Jan 2008 17:06:31 -0500 Subject: su user -c problem In-Reply-To: <200801061646.11184.gene.heskett@verizon.net> References: <200801061033.27657.gene.heskett@verizon.net> <20080106193207.GE3136@inocybe.teonanacatl.org> <200801061646.11184.gene.heskett@verizon.net> Message-ID: <20080106220631.GH3136@inocybe.teonanacatl.org> Gene Heskett wrote: >>I've got similar things in /etc/rc.local that used to use su -c. I >>don't recall having them get denied outright, but the programs that >>were run definitely didn't pick up the proper SELinux contexts. So I >>now have a few entries like this: >> >>runcon user_u:system_r:unconfined_t -- runuser -l -c "screen -dm" tmz > > I'm afraid I have pretty close to a NDI what that will do, Todd. > And your use of the words 'used to' above also tells be your are > doing this su user -c function differently now. Can you elaborate? > The manpage for runcon is so concise as to be obtuse. I noticed that the processes I started with su -c didn't have the proper SELinux contexts, so that's why I added the runcon call. It sets up the processes to use the same contexts as they would get if I had logged in as tmz and run them (AFAIK). Using runuser is very similar to using su. I don't know if you'd have any problems using su instead of runuser or not. I'm far from knowledgeable on the subject. > > Here is the line in question, in rc.local, that does not now work: > > su gene -c "fetchmail -d 90 --fetchmailrc /home/gene/.fetchmailrc" > > Can you translate that into a 'runcon' style line please? Sure. (No guarantees that this is the best or most correct way. :) runcon user_u:system_r:unconfined_t -- runuser -l -c "fetchmail -d 90" gene (I think I'd remove the --fetchmailrc option since ~/.fetchmailrc is the default and using the -l option to runuser will make the command run as gene, so ~/.fetchmailrc will be /home/gene/.fetchmailrc. But that shouldn't matter at all in regards to SELinux.) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The kind of man who wants the government to adopt and enforce his ideas is always the kind of man whose ideas are idiotic. -- H. L. Mencken -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From jmorris at namei.org Sun Jan 6 22:43:26 2008 From: jmorris at namei.org (James Morris) Date: Mon, 7 Jan 2008 09:43:26 +1100 (EST) Subject: two questions In-Reply-To: <1199489646.3716.106.camel@localhost.localdomain> References: <1199489646.3716.106.camel@localhost.localdomain> Message-ID: On Fri, 4 Jan 2008, Eric Paris wrote: > yes, the permission is dyntransition in the process class. it is > STRONGLY, let me say that again VERY STRONGLY, suggested that you don't > make use of this facility. Basically you lose all seperation between > those 2 domains. You don't have any assurance that the process before > the transition didn't get hacked/corrupted/bugged and is now > transitioning to a new domain but able to do the wrong things (or > sometimes even worse not transition to the new domain at all) > > I'm not sure what the rationale was to put it in originally but please > just find a way to do it on an execve boundary. Dynamic transitions were added for privileged MLS applications, which sometimes need to implement privilege bracketing (i.e. changing security level for some operation). It should be thought of as a legacy MLS feature and not otherwise used. - James -- James Morris From gene.heskett at verizon.net Mon Jan 7 08:19:33 2008 From: gene.heskett at verizon.net (Gene Heskett) Date: Mon, 07 Jan 2008 03:19:33 -0500 Subject: su user -c problem In-Reply-To: <20080106220631.GH3136@inocybe.teonanacatl.org> References: <200801061033.27657.gene.heskett@verizon.net> <200801061646.11184.gene.heskett@verizon.net> <20080106220631.GH3136@inocybe.teonanacatl.org> Message-ID: <200801070319.34072.gene.heskett@verizon.net> On Sunday 06 January 2008, Todd Zullinger wrote: >Gene Heskett wrote: >>>I've got similar things in /etc/rc.local that used to use su -c. I >>>don't recall having them get denied outright, but the programs that >>>were run definitely didn't pick up the proper SELinux contexts. So I >>>now have a few entries like this: >>> >>>runcon user_u:system_r:unconfined_t -- runuser -l -c "screen -dm" tmz >> >> I'm afraid I have pretty close to a NDI what that will do, Todd. >> And your use of the words 'used to' above also tells be your are >> doing this su user -c function differently now. Can you elaborate? >> The manpage for runcon is so concise as to be obtuse. > >I noticed that the processes I started with su -c didn't have the >proper SELinux contexts, so that's why I added the runcon call. It >sets up the processes to use the same contexts as they would get if I >had logged in as tmz and run them (AFAIK). Using runuser is very >similar to using su. I don't know if you'd have any problems using su >instead of runuser or not. I'm far from knowledgeable on the subject. > >> Here is the line in question, in rc.local, that does not now work: >> >> su gene -c "fetchmail -d 90 --fetchmailrc /home/gene/.fetchmailrc" >> >> Can you translate that into a 'runcon' style line please? > >Sure. (No guarantees that this is the best or most correct way. :) > >runcon user_u:system_r:unconfined_t -- runuser -l -c "fetchmail -d 90" gene > >(I think I'd remove the --fetchmailrc option since ~/.fetchmailrc is >the default and using the -l option to runuser will make the command >run as gene, so ~/.fetchmailrc will be /home/gene/.fetchmailrc. But >that shouldn't matter at all in regards to SELinux.) Now I have a more pressing problem. If I exec that file after booting and logging in I get a bunch of rejects from several things I tried to convert so they weren't running as root, like heyu, so I took those back out, but the fetchmail line says this: starting fetchmail user_u:system_r:unconfined_t is not a valid context And fetchmail is not running. But the bigger problem is that according to the trace I can see by shift pageup as soon as I log in from a fresh reboot, there is absolutely nothing showing to indicate that S99local ever ran, nothing in that file is echoed or performed. setroubleshooter is also silent on the subject. I can post this rc.local if you'd like. An ls -lZ on it: -rwxr-xr-x root root system_u:object_r:initrc_exec_t:s0 /etc/rc.d/rc.local And I just did an autorelabel. I've been following setroubleshooter's advice & doing the semanage things too so hopefully I won't need to do them again. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Please don't recommend me to your friends-- it's difficult enough to cope with you alone. From gene.heskett at verizon.net Mon Jan 7 08:50:33 2008 From: gene.heskett at verizon.net (Gene Heskett) Date: Mon, 07 Jan 2008 03:50:33 -0500 Subject: miss-match between needs and setroubleshooter's output recommendations Message-ID: <200801070350.33452.gene.heskett@verizon.net> Greetings; I have now been in the center ring of this circus about long enough. selinux is about to get made permissive or disabled. I have now issued these commands: [root at coyote ~]# semanage fcontext -a -t textrel_shlib_t /root/.mozilla/plugins/vorbisrend.so [root at coyote ~]# chcon -t textrel_shlib_t /root/.mozilla/plugins/vorbisrend.so [root at coyote ~]# semanage fcontext -a -t textrel_shlib_t /root/.mozilla/plugins/vorbisrend.so [root at coyote ~]# chcon -t textrel_shlib_t /root/.mozilla/plugins/vorbisrend.so Twice as can be seen, and restarted firefox each time, and each time selinux denies firefox a plugin it needs to pay this site: I now have the third denial showing in the setroubleshooter's screen. ----------------- How can I fix this? Thanks. -- Cheers, Gene "There are four boxes to be used in defense of liberty:<> soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Q: How many Zen masters does it take to screw in a light bulb? A: None. The Universe spins the bulb, and the Zen master stays out of the way. From eparis at redhat.com Mon Jan 7 15:29:12 2008 From: eparis at redhat.com (Eric Paris) Date: Mon, 07 Jan 2008 10:29:12 -0500 Subject: su user -c problem In-Reply-To: <200801070319.34072.gene.heskett@verizon.net> References: <200801061033.27657.gene.heskett@verizon.net> <200801061646.11184.gene.heskett@verizon.net> <20080106220631.GH3136@inocybe.teonanacatl.org> <200801070319.34072.gene.heskett@verizon.net> Message-ID: <1199719752.3716.130.camel@localhost.localdomain> On Mon, 2008-01-07 at 03:19 -0500, Gene Heskett wrote: > On Sunday 06 January 2008, Todd Zullinger wrote: > >Gene Heskett wrote: > >>>I've got similar things in /etc/rc.local that used to use su -c. I > >>>don't recall having them get denied outright, but the programs that > >>>were run definitely didn't pick up the proper SELinux contexts. So I > >>>now have a few entries like this: > >>> > >>>runcon user_u:system_r:unconfined_t -- runuser -l -c "screen -dm" tmz > >> > >> I'm afraid I have pretty close to a NDI what that will do, Todd. > >> And your use of the words 'used to' above also tells be your are > >> doing this su user -c function differently now. Can you elaborate? > >> The manpage for runcon is so concise as to be obtuse. > > > >I noticed that the processes I started with su -c didn't have the > >proper SELinux contexts, so that's why I added the runcon call. It > >sets up the processes to use the same contexts as they would get if I > >had logged in as tmz and run them (AFAIK). Using runuser is very > >similar to using su. I don't know if you'd have any problems using su > >instead of runuser or not. I'm far from knowledgeable on the subject. > > > >> Here is the line in question, in rc.local, that does not now work: > >> > >> su gene -c "fetchmail -d 90 --fetchmailrc /home/gene/.fetchmailrc" > >> > >> Can you translate that into a 'runcon' style line please? > > > >Sure. (No guarantees that this is the best or most correct way. :) > > > >runcon user_u:system_r:unconfined_t -- runuser -l -c "fetchmail -d 90" gene for F8 I think it should be "unconfined_u:system_r:unconfined_t" for rawhide i think it is "unconfined_u:unconfined_r:unconfined_t" I don't really understand the rest of what you are asking... typically we on list like to see the output of ausearch -m AVC -ts recent or some other form of the raw denial (its at the bottom of the setroubleshoot output) so we actually know what is failing. -Eric From sds at tycho.nsa.gov Mon Jan 7 15:41:32 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 07 Jan 2008 10:41:32 -0500 Subject: two questions In-Reply-To: <1199549824.3716.117.camel@localhost.localdomain> References: <1199489646.3716.106.camel@localhost.localdomain> <1199541500.5014.1.camel@choeger4> <1199546559.3716.108.camel@localhost.localdomain> <1199548970.5014.9.camel@choeger4> <1199549824.3716.117.camel@localhost.localdomain> Message-ID: <1199720492.2944.144.camel@moss-spartans.epoch.ncsc.mil> On Sat, 2008-01-05 at 11:17 -0500, Eric Paris wrote: > On Sat, 2008-01-05 at 17:02 +0100, Christoph H?ger wrote: > > Am Samstag, den 05.01.2008, 10:22 -0500 schrieb Eric Paris: > > > On Sat, 2008-01-05 at 14:58 +0100, Christoph H?ger wrote: > > > > Am Freitag, den 04.01.2008, 18:34 -0500 schrieb Eric Paris: > > > > > On Fri, 2008-01-04 at 14:26 -0800, Clarkson, Mike R (US SSA) wrote: > > > > > > Is there someplace I can go to find a description of the libselinux API? > > > > > > > > > > not sure, i just read the code :) the fedora libselinux-devel > > > > > package provides man pages for most (maybe all?) of the interfaces. > > > > > > > > > > > > > > > > > Is there a way to change the context of an existing process, without > > > > > > having to execute a new process? > > > > > > > > > > yes, the permission is dyntransition in the process class. it is > > > > > STRONGLY, let me say that again VERY STRONGLY, suggested that you don't > > > > > make use of this facility. Basically you lose all seperation between > > > > > those 2 domains. You don't have any assurance that the process before > > > > > the transition didn't get hacked/corrupted/bugged and is now > > > > > transitioning to a new domain but able to do the wrong things (or > > > > > sometimes even worse not transition to the new domain at all) > > > > > > > > Hi, I don't think that it is that bad. Basically I think if you can > > > > transition from dom_a to dom_b that still does not include transition > > > > back to dom_a. So you can e.g. secure a new thread which handles a > > > > client or something without using execve. > > > > > > dyntrans only works on single threaded processes. > > > > > > -Eric > > > > > > > > > > > > > > I'm not sure what the rationale was to put it in originally but please > > > > > just find a way to do it on an execve boundary. > > > > > > > > > > -Eric > > > > > > > > > > -- > > > > > fedora-selinux-list mailing list > > > > > fedora-selinux-list at redhat.com > > > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > > > > Hi, > > > > how does that work? After fork() a new thread/process should have the > > same rights as its parent, so if dyntrans is allowed before fork(), it > > should also work after that? > > /* Only allow single threaded processes to change context */ > if (atomic_read(&p->mm->mm_users) != 1) { > struct task_struct *g, *t; > struct mm_struct *mm = p->mm; > read_lock(&tasklist_lock); > do_each_thread(g, t) > if (t->mm == mm && t != p) { > read_unlock(&tasklist_lock); > return -EPERM; > } > while_each_thread(g, t); > read_unlock(&tasklist_lock); > } > > You just explained the rationale why it should only work on single > threaded processes :) Two threads share all of the same resources, > if one of those is in dom_a and one of those is in dom_b you don't have > any seperation between the domains. The thread in dom_b might > (depending on the permissions of the code pages) be able to rewrite the > code executing by the thread in dom_a. Now even without dom_b -> dom_a > transition dom_b thread has full control in dom_a. Also remember that > the thread in dom_b can write to data segments used by dom_a, so even if > it can't rewrite its code pages it can probably pretty easily get it to > call into a function it controls by rewriting its data pages (which > obviously have no seperation) > > dyntransition is only allowed in single threaded processes. It can fork > children after the transition, but if it forks before the transition it > won't be allowed. fork creates a child process, not another thread within the same process. The discussion above applies to clone() with CLONE_VM set, not to fork. See the setcon(3) man page for a discussion of dynamic context transitions. An alternative to disallowing switching the security context of a multi-threaded process altogether would be to provide a way to switch the security context of all threads within a process atomically. I think Ulrich wants something similar for uids and gids for POSIX compliance in Linux, but it would require a shared credential structure for all threads in a thread group, including the security label. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Mon Jan 7 15:45:38 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 07 Jan 2008 10:45:38 -0500 Subject: two questions In-Reply-To: References: <1199489646.3716.106.camel@localhost.localdomain> Message-ID: <1199720738.2944.149.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2008-01-07 at 09:43 +1100, James Morris wrote: > On Fri, 4 Jan 2008, Eric Paris wrote: > > > yes, the permission is dyntransition in the process class. it is > > STRONGLY, let me say that again VERY STRONGLY, suggested that you don't > > make use of this facility. Basically you lose all seperation between > > those 2 domains. You don't have any assurance that the process before > > the transition didn't get hacked/corrupted/bugged and is now > > transitioning to a new domain but able to do the wrong things (or > > sometimes even worse not transition to the new domain at all) > > > > I'm not sure what the rationale was to put it in originally but please > > just find a way to do it on an execve boundary. > > Dynamic transitions were added for privileged MLS applications, which > sometimes need to implement privilege bracketing (i.e. changing security > level for some operation). It should be thought of as a legacy MLS > feature and not otherwise used. It has also been suggested as a way of dealing with php scripts (switching contexts when interpreting them), and as a way of handling samba (switching to a context derived from the client so that filesystem accesses are confined based on the client, although to do that properly, you need derived domains or a fscontext ala fsuid). It is weaker than the exec-based transitions, but can have practical benefits. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Mon Jan 7 15:46:17 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 07 Jan 2008 10:46:17 -0500 Subject: two questions In-Reply-To: References: Message-ID: <1199720777.2944.151.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2008-01-04 at 14:26 -0800, Clarkson, Mike R (US SSA) wrote: > Is there someplace I can go to find a description of the libselinux API? > > Is there a way to change the context of an existing process, without > having to execute a new process? man setcon -- Stephen Smalley National Security Agency From dwalsh at redhat.com Mon Jan 7 16:10:37 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 07 Jan 2008 11:10:37 -0500 Subject: sendmail/smrsh f8 avc error In-Reply-To: <20080103175720.067cb135@atbws1.stanford.edu> References: <20080103175720.067cb135@atbws1.stanford.edu> Message-ID: <47824EFD.8010007@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tim Fenn wrote: > After updating from f7 to f8, it appears smrsh might be mislabelled > (using selinux-policy-3.0.8-72.fc8) - or am I missing something? > > type=AVC msg=audit(1199408924.325:1608): avc: denied { getattr } for > pid=10777 comm="sendmail" path="/usr/sbin/smrsh" dev=dm-0 ino=3785966 > scontext=system_u:system_r:sendmail_t:s0 > tcontext=system_u:object_r:bin_t:s0 tclass=file > > type=SYSCALL msg=audit(1199408924.325:1608): arch=c000003e syscall=4 > success=no exit=-13 a0=7fff6e1c7d90 a1=7fff6e1c7c70 a2=7fff6e1c7c70 > a3=7fff6e1c7d9f items=0 ppid=10776 pid=10777 auid=4294967295 uid=8 > gid=12 euid=8 suid=8 fsuid=8 egid=12 sgid=12 fsgid=12 tty=(none) > comm="sendmail" exe="/usr/sbin/sendmail.sendmail" > subj=system_u:system_r:sendmail_t:s0 key=(null) > > type=AVC msg=audit(1199408924.333:1609): avc: denied { execute } for > pid=10777 comm="sendmail" name="smrsh" dev=dm-0 ino=3785966 > scontext=system_u:system_r:sendmail_t:s0 > tcontext=system_u:object_r:bin_t:s0 tclass=file > > type=SYSCALL msg=audit(1199408924.333:1609): arch=c000003e syscall=59 > success=no exit=-13 a0=2aaaaae7a7a0 a1=7fff6e1c8f00 a2=2aaaaadb4b00 > a3=0 items=0 ppid=10776 pid=10777 auid=4294967295 uid=8 gid=12 euid=8 > suid=8 fsuid=8 egid=12 sgid=12 fsgid=12 tty=(none) comm="sendmail" > exe="/usr/sbin/sendmail.sendmail" subj=system_u:system_r:sendmail_t:s0 > key=(null) > > -Tim > Nope should be labeled shell_exec_t. I will update in next release chcon -t shell_exec_t /usr/sbin/smrsh Will fix it for now. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeCTvwACgkQrlYvE4MpobMC5QCgmEZgm6BrY717a9V56NGRFAgk LEAAnibrzoEk3juw6UfOkuTbTC+LaODP =5fH/ -----END PGP SIGNATURE----- From gene.heskett at verizon.net Mon Jan 7 16:23:20 2008 From: gene.heskett at verizon.net (Gene Heskett) Date: Mon, 07 Jan 2008 11:23:20 -0500 Subject: su user -c problem In-Reply-To: <1199719752.3716.130.camel@localhost.localdomain> References: <200801061033.27657.gene.heskett@verizon.net> <200801070319.34072.gene.heskett@verizon.net> <1199719752.3716.130.camel@localhost.localdomain> Message-ID: <200801071123.20559.gene.heskett@verizon.net> On Monday 07 January 2008, Eric Paris wrote: >On Mon, 2008-01-07 at 03:19 -0500, Gene Heskett wrote: >> On Sunday 06 January 2008, Todd Zullinger wrote: >> >Gene Heskett wrote: >> >>>I've got similar things in /etc/rc.local that used to use su -c. I >> >>>don't recall having them get denied outright, but the programs that >> >>>were run definitely didn't pick up the proper SELinux contexts. So I >> >>>now have a few entries like this: >> >>> >> >>>runcon user_u:system_r:unconfined_t -- runuser -l -c "screen -dm" tmz >> >> >> >> I'm afraid I have pretty close to a NDI what that will do, Todd. >> >> And your use of the words 'used to' above also tells be your are >> >> doing this su user -c function differently now. Can you elaborate? >> >> The manpage for runcon is so concise as to be obtuse. >> > >> >I noticed that the processes I started with su -c didn't have the >> >proper SELinux contexts, so that's why I added the runcon call. It >> >sets up the processes to use the same contexts as they would get if I >> >had logged in as tmz and run them (AFAIK). Using runuser is very >> >similar to using su. I don't know if you'd have any problems using su >> >instead of runuser or not. I'm far from knowledgeable on the subject. >> > >> >> Here is the line in question, in rc.local, that does not now work: >> >> >> >> su gene -c "fetchmail -d 90 --fetchmailrc /home/gene/.fetchmailrc" >> >> >> >> Can you translate that into a 'runcon' style line please? >> > >> >Sure. (No guarantees that this is the best or most correct way. :) >> > >> >runcon user_u:system_r:unconfined_t -- runuser -l -c "fetchmail -d 90" >> > gene > >for F8 I think it should be "unconfined_u:system_r:unconfined_t" for >rawhide i think it is "unconfined_u:unconfined_r:unconfined_t" and both of those return "invalid context" and fetchmail is not started. >I don't really understand the rest of what you are asking... typically >we on list like to see the output of ausearch -m AVC -ts recent or some >other form of the raw denial (its at the bottom of the setroubleshoot >output) so we actually know what is failing. That output of "ausearch -m AVC -ts recent" is empty, as is the setroubleshoot screen after running rc.local three times just now. The larger problem ATM is that rc.local is NOT being executed at the end of the bootup. And yet: root at coyote ~]# ls -l /etc/rc.d/rc3.d/S99local lrwxrwxrwx 1 root root 11 2008-01-04 22:39 /etc/rc.d/rc3.d/S99local -> ../rc.local and [root at coyote ~]# ls -lZ /etc/rc.d/rc3.d/S99local lrwxrwxrwx root root system_u:object_r:etc_t:s0 /etc/rc.d/rc3.d/S99local -> ../rc.local and [root at coyote ~]# ls -lZ /etc/rc.d/rc.local -rwxr-xr-x root root system_u:object_r:initrc_exec_t:s0 /etc/rc.d/rc.local I boot and login at runlevel 3, the everything but X, then run startx by hand. I'm a big dummy maybe, and an old fart, but *I* can run it by using the S99local link exactly the same as it real name, so why doesn't init run it? I should be seeing in my login console, all of this: ------------ [root at coyote ~]# /etc/rc.d/rc.local /root/bin:/usr/lib/qt-3.3/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib/ccache:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:/usr/local/bin /usr/local/mozilla /usr/lib/qt-3.3 restoring audio settings starting heyu heyu_engine is running - use 'heyu restart' to reconfigure CM11A clock set to Mon, 11:03:52 (Standard Time), Day 6 Emulating macro Dawn_Off at address 1013 heyu started LATITUDE=39:41 LONGITUDE=80:17 starting fetchmail user_u:system_r:unconfined_t is not a valid context starting drift-checker adding shop.coyote.den to xhost access list 5279 ttyUSB0 00:00:00 heyu 5281 ? 00:00:38 heyu 20736 ? 00:00:00 heyu 4097 ? 00:00:04 fetchmail restoreing midi playback to Audigy 2 card setup env for nitros9 development ssh /opt/os9 -------------- But I am not. Thanks Eric. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) "Don't hate me because I'm beautiful. Hate me because I'm beautiful, smart and rich." -- Calvin Keegan From dwalsh at redhat.com Mon Jan 7 16:52:13 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 07 Jan 2008 11:52:13 -0500 Subject: miss-match between needs and setroubleshooter's output recommendations In-Reply-To: <200801070350.33452.gene.heskett@verizon.net> References: <200801070350.33452.gene.heskett@verizon.net> Message-ID: <478258BD.2040905@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gene Heskett wrote: > Greetings; > > I have now been in the center ring of this circus about long enough. selinux > is about to get made permissive or disabled. > > I have now issued these commands: > > [root at coyote ~]# semanage fcontext -a -t > textrel_shlib_t /root/.mozilla/plugins/vorbisrend.so > [root at coyote ~]# chcon -t textrel_shlib_t /root/.mozilla/plugins/vorbisrend.so > [root at coyote ~]# semanage fcontext -a -t > textrel_shlib_t /root/.mozilla/plugins/vorbisrend.so > [root at coyote ~]# chcon -t textrel_shlib_t /root/.mozilla/plugins/vorbisrend.so > > Twice as can be seen, and restarted firefox each time, and each time selinux > denies firefox a plugin it needs to pay this site: > > > I now have the third denial showing in the setroubleshooter's screen. > ----------------- > > How can I fix this? > > Thanks. > Please attach the AVC messages from /var/log/audit/audit.log This looks like you could be running Firefox as root, which is a bad idea. ausearch -m avc Will grab all of the avc messages. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeCWL0ACgkQrlYvE4MpobMX5ACg46tN7VjBjPApAAfE1J9mipNp J8sAn2YrQDBqssOrPNz10gmM1rF+pJyf =dcGv -----END PGP SIGNATURE----- From eparis at redhat.com Mon Jan 7 16:53:53 2008 From: eparis at redhat.com (Eric Paris) Date: Mon, 07 Jan 2008 11:53:53 -0500 Subject: su user -c problem In-Reply-To: <200801071123.20559.gene.heskett@verizon.net> References: <200801061033.27657.gene.heskett@verizon.net> <200801070319.34072.gene.heskett@verizon.net> <1199719752.3716.130.camel@localhost.localdomain> <200801071123.20559.gene.heskett@verizon.net> Message-ID: <1199724833.3716.136.camel@localhost.localdomain> On Mon, 2008-01-07 at 11:23 -0500, Gene Heskett wrote: > On Monday 07 January 2008, Eric Paris wrote: > >On Mon, 2008-01-07 at 03:19 -0500, Gene Heskett wrote: > >> On Sunday 06 January 2008, Todd Zullinger wrote: > >> >Gene Heskett wrote: > >> >>>I've got similar things in /etc/rc.local that used to use su -c. I > >> >>>don't recall having them get denied outright, but the programs that > >> >>>were run definitely didn't pick up the proper SELinux contexts. So I > >> >>>now have a few entries like this: > >> >>> > >> >>>runcon user_u:system_r:unconfined_t -- runuser -l -c "screen -dm" tmz > >> >> > >> >> I'm afraid I have pretty close to a NDI what that will do, Todd. > >> >> And your use of the words 'used to' above also tells be your are > >> >> doing this su user -c function differently now. Can you elaborate? > >> >> The manpage for runcon is so concise as to be obtuse. > >> > > >> >I noticed that the processes I started with su -c didn't have the > >> >proper SELinux contexts, so that's why I added the runcon call. It > >> >sets up the processes to use the same contexts as they would get if I > >> >had logged in as tmz and run them (AFAIK). Using runuser is very > >> >similar to using su. I don't know if you'd have any problems using su > >> >instead of runuser or not. I'm far from knowledgeable on the subject. > >> > > >> >> Here is the line in question, in rc.local, that does not now work: > >> >> > >> >> su gene -c "fetchmail -d 90 --fetchmailrc /home/gene/.fetchmailrc" > >> >> > >> >> Can you translate that into a 'runcon' style line please? > >> > > >> >Sure. (No guarantees that this is the best or most correct way. :) > >> > > >> >runcon user_u:system_r:unconfined_t -- runuser -l -c "fetchmail -d 90" > >> > gene > > > >for F8 I think it should be "unconfined_u:system_r:unconfined_t" for > >rawhide i think it is "unconfined_u:unconfined_r:unconfined_t" > > and both of those return "invalid context" and fetchmail is not started. ahh, yeah, i should have paid more attention to the suggestion you were given on how to use runcon and read the man page again. runcon -t unconfined_t -- whatever you want to run. I think i'll have a little chat with dan about this stuff.... > > >I don't really understand the rest of what you are asking... typically > >we on list like to see the output of ausearch -m AVC -ts recent or some > >other form of the raw denial (its at the bottom of the setroubleshoot > >output) so we actually know what is failing. > > That output of "ausearch -m AVC -ts recent" is empty, as is the > setroubleshoot screen after running rc.local three times just now. > > The larger problem ATM is that rc.local is NOT being executed at the > end of the bootup. And yet: I'm at a total loss on this one, did it execute on boot up if you add enforcing=0 to the kernel boot line? -Eric From dwalsh at redhat.com Mon Jan 7 16:56:45 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 07 Jan 2008 11:56:45 -0500 Subject: Funny AVC from USB CD plugin In-Reply-To: <4c4ba1530801061050y6f237ado949dc7f911412cd@mail.gmail.com> References: <4c4ba1530801061050y6f237ado949dc7f911412cd@mail.gmail.com> Message-ID: <478259CD.2060102@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom London wrote: > Running latest Rawhide, targeted/enforcing. > > Plugging in an 'old USB CD drive', I got the following audit message: > > [root at localhost ~]# sealert -l fb77e7e0-3515-4866-9a8f-e1db99f9b4b8 > > Summary: > > SELinux is preventing ln(/bin/ln) (udev_t) "create" to (etc_t). > > Detailed Description: > > SELinux denied access requested by ln(/bin/ln). It is not expected that this > access is required by ln(/bin/ln) 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 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:udev_t:SystemLow-SystemHigh > Target Context system_u:object_r:etc_t > Target Objects None [ lnk_file ] > Source ln(/bin/ln) > Port > Host localhost.localdomain > Source RPM Packages > Target RPM Packages > Policy RPM selinux-policy-3.2.5-8.fc9 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name catchall_file > Host Name localhost.localdomain > Platform Linux localhost.localdomain > 2.6.24-0.136.rc6.git12.fc9 #1 SMP Sat Jan 5 > 12:46:45 EST 2008 i686 i686 > Alert Count 2 > First Seen Sun Jan 6 10:30:15 2008 > Last Seen Sun Jan 6 10:30:15 2008 > Local ID fb77e7e0-3515-4866-9a8f-e1db99f9b4b8 > Line Numbers > > Raw Audit Messages > > host=localhost.localdomain type=AVC msg=audit(1199644215.878:31): avc: > denied { create } for pid=6933 comm="ln" name=".is-writeable" > scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:etc_t:s0 tclass=lnk_file > > host=localhost.localdomain type=SYSCALL msg=audit(1199644215.878:31): > arch=40000003 syscall=83 success=no exit=-13 a0=bff3ddc3 a1=bff3ddcd > a2=804f77c a3=0 items=0 ppid=6931 pid=6933 auid=4294967295 uid=0 gid=0 > euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="ln" > exe="/bin/ln" subj=system_u:system_r:udev_t:s0-s0:c0.c1023 key=(null) > > > Here are the messages from /var/log/messages: > > Jan 6 10:30:05 localhost kernel: usb 2-2: new full speed USB device > using uhci_hcd and address 4 > Jan 6 10:30:06 localhost kernel: usb 2-2: configuration #1 chosen from 1 choice > Jan 6 10:30:06 localhost kernel: scsi8 : SCSI emulation for USB Mass > Storage devices > Jan 6 10:30:06 localhost kernel: usb-storage: device found at 4 > Jan 6 10:30:06 localhost kernel: usb-storage: waiting for device to > settle before scanning > Jan 6 10:30:11 localhost kernel: usb-storage: device scan complete > Jan 6 10:30:11 localhost kernel: scsi 8:0:0:0: CD-ROM IBM > USB CD-ROM 20A4 PQ: 0 ANSI: 0 CCS > Jan 6 10:30:11 localhost kernel: sr1: scsi3-mmc drive: 10x/10x cd/rw > xa/form2 cdda pop-up > Jan 6 10:30:11 localhost kernel: sr 8:0:0:0: Attached scsi CD-ROM sr1 > Jan 6 10:30:11 localhost kernel: sr 8:0:0:0: Attached scsi generic sg2 type 5 > Jan 6 10:30:18 localhost setroubleshoot: #012 SELinux is > preventing ln(/bin/ln) (udev_t) "create" to <Unknown> > (etc_t).#012 For complete SELinux messages. run sealert -l > fb77e7e0-3515-4866-9a8f-e1db99f9b4b8 > > > Putting system in permissive mode, I get these: > > type=AVC msg=audit(1199645179.126:34): avc: denied { create } for > pid=7782 comm="ln" name=".is-writeable" > scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:etc_t:s0 tclass=lnk_file > type=SYSCALL msg=audit(1199645179.126:34): arch=40000003 syscall=83 > success=yes exit=0 a0=bfb56db6 a1=bfb56dc0 a2=804f77c a3=0 items=0 > ppid=7780 pid=7782 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 > egid=0 sgid=0 fsgid=0 tty=(none) comm="ln" exe="/bin/ln" > subj=system_u:system_r:udev_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1199645179.245:35): avc: denied { unlink } for > pid=7783 comm="rm" name=".is-writeable" dev=dm-0 ino=11076747 > scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:etc_t:s0 tclass=lnk_file > type=SYSCALL msg=audit(1199645179.245:35): arch=40000003 syscall=301 > success=yes exit=0 a0=ffffff9c a1=bfa17dc0 a2=0 a3=bfa17dc0 items=0 > ppid=7780 pid=7783 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 > egid=0 sgid=0 fsgid=0 tty=(none) comm="rm" exe="/bin/rm" > subj=system_u:system_r:udev_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1199645179.255:36): avc: denied { append } for > pid=7780 comm="write_cd_rules" name="70-persistent-cd.rules" dev=dm-0 > ino=11076866 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:etc_t:s0 tclass=file > type=SYSCALL msg=audit(1199645179.255:36): arch=40000003 syscall=5 > success=yes exit=3 a0=8a98400 a1=8441 a2=1b6 a3=8441 items=0 ppid=7761 > pid=7780 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=(none) comm="write_cd_rules" exe="/bin/bash" > subj=system_u:system_r:udev_t:s0-s0:c0.c1023 key=(null) > > udev issue? > > tom Yes report it as a bug there. I have a fealing it should be something done in the post install script and not by udev. udev writing its own config files is probably a bad idea. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeCWc0ACgkQrlYvE4MpobMJQwCgicGwHVWLjo3mFaVNx7ExilO1 jDsAoNlzbXVlmqkGeea7KaI8HmEJwqlg =tBkg -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Jan 7 16:58:30 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 07 Jan 2008 11:58:30 -0500 Subject: Any idea what causes this message? In-Reply-To: <477FAC9A.30070.1CC78D@knute.frazmtn.com> References: <477F5889.17406.264C81@knute.frazmtn.com>, <1199563406.3716.121.camel@localhost.localdomain> <477FAC9A.30070.1CC78D@knute.frazmtn.com> Message-ID: <47825A36.6050005@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Knute Johnson wrote: >> Its a mislabeled file. /var/log/btmp should be labeled faillog_t >> >> restorecon -R -v /var/log >> >> to fix up everything in /var/log. btmp is used whenever there is a >> login failure (I think only failure...) >> >> not sure how it got mislabeled (what is supposed to create it, anyone >> know? do you remember at some time untaring a bunch of files >> in /var/log? or cp'ing in files? somehow it got created without the >> 'right' label) but it is occasional because people only occasionally >> screw up logging in and you get the denial because it is mislabeled. >> Fix the label and you should be good from now on. >> >> -Eric > > Thanks, it was mislabeled. I don't know how but it's fixed now. > THere is a reported bug on logrotate I believe that is clearing the btmp file but not labeling it correctly. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeCWjYACgkQrlYvE4MpobNxpACdHcUIw1m/CiGAklKX9BxoD4PR byYAn0/UZEXdbSlqBKUkSdumFwg01vqN =b8zk -----END PGP SIGNATURE----- From paul at city-fan.org Mon Jan 7 16:59:22 2008 From: paul at city-fan.org (Paul Howarth) Date: Mon, 07 Jan 2008 16:59:22 +0000 Subject: Any idea what causes this message? In-Reply-To: <477FAC9A.30070.1CC78D@knute.frazmtn.com> References: <477F5889.17406.264C81@knute.frazmtn.com>, <1199563406.3716.121.camel@localhost.localdomain> <477FAC9A.30070.1CC78D@knute.frazmtn.com> Message-ID: <47825A6A.5000507@city-fan.org> Knute Johnson wrote: >> Its a mislabeled file. /var/log/btmp should be labeled faillog_t >> >> restorecon -R -v /var/log >> >> to fix up everything in /var/log. btmp is used whenever there is a >> login failure (I think only failure...) >> >> not sure how it got mislabeled (what is supposed to create it, anyone >> know? do you remember at some time untaring a bunch of files >> in /var/log? or cp'ing in files? somehow it got created without the >> 'right' label) but it is occasional because people only occasionally >> screw up logging in and you get the denial because it is mislabeled. >> Fix the label and you should be good from now on. >> >> -Eric > > Thanks, it was mislabeled. I don't know how but it's fixed now. It'll be logrotate. https://bugzilla.redhat.com/show_bug.cgi?id=427274 Paul. From selinux at gmail.com Mon Jan 7 17:25:06 2008 From: selinux at gmail.com (Tom London) Date: Mon, 7 Jan 2008 09:25:06 -0800 Subject: Funny AVC from USB CD plugin In-Reply-To: <478259CD.2060102@redhat.com> References: <4c4ba1530801061050y6f237ado949dc7f911412cd@mail.gmail.com> <478259CD.2060102@redhat.com> Message-ID: <4c4ba1530801070925p17449954s74a87aaa2a2f000d@mail.gmail.com> On Jan 7, 2008 8:56 AM, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Tom London wrote: > > Running latest Rawhide, targeted/enforcing. > > > > Plugging in an 'old USB CD drive', I got the following audit message: > > > > [root at localhost ~]# sealert -l fb77e7e0-3515-4866-9a8f-e1db99f9b4b8 > > > > Summary: > > > > SELinux is preventing ln(/bin/ln) (udev_t) "create" to (etc_t). > > > > Detailed Description: > > > > SELinux denied access requested by ln(/bin/ln). It is not expected that this > > access is required by ln(/bin/ln) 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 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:udev_t:SystemLow-SystemHigh > > Target Context system_u:object_r:etc_t > > Target Objects None [ lnk_file ] > > Source ln(/bin/ln) > > Port > > Host localhost.localdomain > > Source RPM Packages > > Target RPM Packages > > Policy RPM selinux-policy-3.2.5-8.fc9 > > Selinux Enabled True > > Policy Type targeted > > MLS Enabled True > > Enforcing Mode Enforcing > > Plugin Name catchall_file > > Host Name localhost.localdomain > > Platform Linux localhost.localdomain > > 2.6.24-0.136.rc6.git12.fc9 #1 SMP Sat Jan 5 > > 12:46:45 EST 2008 i686 i686 > > Alert Count 2 > > First Seen Sun Jan 6 10:30:15 2008 > > Last Seen Sun Jan 6 10:30:15 2008 > > Local ID fb77e7e0-3515-4866-9a8f-e1db99f9b4b8 > > Line Numbers > > > > Raw Audit Messages > > > > host=localhost.localdomain type=AVC msg=audit(1199644215.878:31): avc: > > denied { create } for pid=6933 comm="ln" name=".is-writeable" > > scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 > > tcontext=system_u:object_r:etc_t:s0 tclass=lnk_file > > > > host=localhost.localdomain type=SYSCALL msg=audit(1199644215.878:31): > > arch=40000003 syscall=83 success=no exit=-13 a0=bff3ddc3 a1=bff3ddcd > > a2=804f77c a3=0 items=0 ppid=6931 pid=6933 auid=4294967295 uid=0 gid=0 > > euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="ln" > > exe="/bin/ln" subj=system_u:system_r:udev_t:s0-s0:c0.c1023 key=(null) > > > > > > Here are the messages from /var/log/messages: > > > > Jan 6 10:30:05 localhost kernel: usb 2-2: new full speed USB device > > using uhci_hcd and address 4 > > Jan 6 10:30:06 localhost kernel: usb 2-2: configuration #1 chosen from 1 choice > > Jan 6 10:30:06 localhost kernel: scsi8 : SCSI emulation for USB Mass > > Storage devices > > Jan 6 10:30:06 localhost kernel: usb-storage: device found at 4 > > Jan 6 10:30:06 localhost kernel: usb-storage: waiting for device to > > settle before scanning > > Jan 6 10:30:11 localhost kernel: usb-storage: device scan complete > > Jan 6 10:30:11 localhost kernel: scsi 8:0:0:0: CD-ROM IBM > > USB CD-ROM 20A4 PQ: 0 ANSI: 0 CCS > > Jan 6 10:30:11 localhost kernel: sr1: scsi3-mmc drive: 10x/10x cd/rw > > xa/form2 cdda pop-up > > Jan 6 10:30:11 localhost kernel: sr 8:0:0:0: Attached scsi CD-ROM sr1 > > Jan 6 10:30:11 localhost kernel: sr 8:0:0:0: Attached scsi generic sg2 type 5 > > Jan 6 10:30:18 localhost setroubleshoot: #012 SELinux is > > preventing ln(/bin/ln) (udev_t) "create" to <Unknown> > > (etc_t).#012 For complete SELinux messages. run sealert -l > > fb77e7e0-3515-4866-9a8f-e1db99f9b4b8 > > > > > > Putting system in permissive mode, I get these: > > > > type=AVC msg=audit(1199645179.126:34): avc: denied { create } for > > pid=7782 comm="ln" name=".is-writeable" > > scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 > > tcontext=system_u:object_r:etc_t:s0 tclass=lnk_file > > type=SYSCALL msg=audit(1199645179.126:34): arch=40000003 syscall=83 > > success=yes exit=0 a0=bfb56db6 a1=bfb56dc0 a2=804f77c a3=0 items=0 > > ppid=7780 pid=7782 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 > > egid=0 sgid=0 fsgid=0 tty=(none) comm="ln" exe="/bin/ln" > > subj=system_u:system_r:udev_t:s0-s0:c0.c1023 key=(null) > > type=AVC msg=audit(1199645179.245:35): avc: denied { unlink } for > > pid=7783 comm="rm" name=".is-writeable" dev=dm-0 ino=11076747 > > scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 > > tcontext=system_u:object_r:etc_t:s0 tclass=lnk_file > > type=SYSCALL msg=audit(1199645179.245:35): arch=40000003 syscall=301 > > success=yes exit=0 a0=ffffff9c a1=bfa17dc0 a2=0 a3=bfa17dc0 items=0 > > ppid=7780 pid=7783 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 > > egid=0 sgid=0 fsgid=0 tty=(none) comm="rm" exe="/bin/rm" > > subj=system_u:system_r:udev_t:s0-s0:c0.c1023 key=(null) > > type=AVC msg=audit(1199645179.255:36): avc: denied { append } for > > pid=7780 comm="write_cd_rules" name="70-persistent-cd.rules" dev=dm-0 > > ino=11076866 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 > > tcontext=system_u:object_r:etc_t:s0 tclass=file > > type=SYSCALL msg=audit(1199645179.255:36): arch=40000003 syscall=5 > > success=yes exit=3 a0=8a98400 a1=8441 a2=1b6 a3=8441 items=0 ppid=7761 > > pid=7780 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > > sgid=0 fsgid=0 tty=(none) comm="write_cd_rules" exe="/bin/bash" > > subj=system_u:system_r:udev_t:s0-s0:c0.c1023 key=(null) > > > > udev issue? > > > > tom > Yes report it as a bug there. I have a fealing it should be something > done in the post install script and not by udev. udev writing its own > config files is probably a bad idea. BZ: https://bugzilla.redhat.com/show_bug.cgi?id=427808 -- Tom London From dwalsh at redhat.com Mon Jan 7 17:51:08 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 07 Jan 2008 12:51:08 -0500 Subject: su user -c problem In-Reply-To: <1199724833.3716.136.camel@localhost.localdomain> References: <200801061033.27657.gene.heskett@verizon.net> <200801070319.34072.gene.heskett@verizon.net> <1199719752.3716.130.camel@localhost.localdomain> <200801071123.20559.gene.heskett@verizon.net> <1199724833.3716.136.camel@localhost.localdomain> Message-ID: <4782668C.2090404@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Paris wrote: > On Mon, 2008-01-07 at 11:23 -0500, Gene Heskett wrote: >> On Monday 07 January 2008, Eric Paris wrote: >>> On Mon, 2008-01-07 at 03:19 -0500, Gene Heskett wrote: >>>> On Sunday 06 January 2008, Todd Zullinger wrote: >>>>> Gene Heskett wrote: >>>>>>> I've got similar things in /etc/rc.local that used to use su -c. I >>>>>>> don't recall having them get denied outright, but the programs that >>>>>>> were run definitely didn't pick up the proper SELinux contexts. So I >>>>>>> now have a few entries like this: >>>>>>> >>>>>>> runcon user_u:system_r:unconfined_t -- runuser -l -c "screen -dm" tmz >>>>>> I'm afraid I have pretty close to a NDI what that will do, Todd. >>>>>> And your use of the words 'used to' above also tells be your are >>>>>> doing this su user -c function differently now. Can you elaborate? >>>>>> The manpage for runcon is so concise as to be obtuse. >>>>> I noticed that the processes I started with su -c didn't have the >>>>> proper SELinux contexts, so that's why I added the runcon call. It >>>>> sets up the processes to use the same contexts as they would get if I >>>>> had logged in as tmz and run them (AFAIK). Using runuser is very >>>>> similar to using su. I don't know if you'd have any problems using su >>>>> instead of runuser or not. I'm far from knowledgeable on the subject. >>>>> >>>>>> Here is the line in question, in rc.local, that does not now work: >>>>>> >>>>>> su gene -c "fetchmail -d 90 --fetchmailrc /home/gene/.fetchmailrc" >>>>>> >>>>>> Can you translate that into a 'runcon' style line please? >>>>> Sure. (No guarantees that this is the best or most correct way. :) >>>>> >>>>> runcon user_u:system_r:unconfined_t -- runuser -l -c "fetchmail -d 90" >>>>> gene >>> for F8 I think it should be "unconfined_u:system_r:unconfined_t" for >>> rawhide i think it is "unconfined_u:unconfined_r:unconfined_t" >> and both of those return "invalid context" and fetchmail is not started. > > ahh, yeah, i should have paid more attention to the suggestion you were > given on how to use runcon and read the man page again. > > runcon -t unconfined_t -- whatever you want to run. > > I think i'll have a little chat with dan about this stuff.... > > >>> I don't really understand the rest of what you are asking... typically >>> we on list like to see the output of ausearch -m AVC -ts recent or some >>> other form of the raw denial (its at the bottom of the setroubleshoot >>> output) so we actually know what is failing. >> That output of "ausearch -m AVC -ts recent" is empty, as is the >> setroubleshoot screen after running rc.local three times just now. >> >> The larger problem ATM is that rc.local is NOT being executed at the >> end of the bootup. And yet: > > I'm at a total loss on this one, did it execute on boot up if you add > enforcing=0 to the kernel boot line? > > -Eric > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list You are missing the s0 at the end runcon user_u:system_r:unconfined_t:s0 -- runuser -l -c "fetchmail -d 90" runcon -t unconfined_t -- runuser -l -c "fetchmail -d 90" Would also work. Why are you doing this though? Is this because fetchmail runs under a context that SELinux is preventing when run from init? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeCZowACgkQrlYvE4MpobPF5QCeJmNt5AAN6AwRbU5L6cQECyjz 2c4An1fsyV9VuksIL1fFPNJnQa7ZTlFQ =p9u2 -----END PGP SIGNATURE----- From gene.heskett at verizon.net Mon Jan 7 18:21:34 2008 From: gene.heskett at verizon.net (Gene Heskett) Date: Mon, 07 Jan 2008 13:21:34 -0500 Subject: Any idea what causes this message? In-Reply-To: <47825A6A.5000507@city-fan.org> References: <477F5889.17406.264C81@knute.frazmtn.com> <477FAC9A.30070.1CC78D@knute.frazmtn.com> <47825A6A.5000507@city-fan.org> Message-ID: <200801071321.34326.gene.heskett@verizon.net> On Monday 07 January 2008, Paul Howarth wrote: >Knute Johnson wrote: >>> Its a mislabeled file. /var/log/btmp should be labeled faillog_t >>> >>> restorecon -R -v /var/log >>> >>> to fix up everything in /var/log. btmp is used whenever there is a >>> login failure (I think only failure...) >>> >>> not sure how it got mislabeled (what is supposed to create it, anyone >>> know? do you remember at some time untaring a bunch of files >>> in /var/log? or cp'ing in files? somehow it got created without the >>> 'right' label) but it is occasional because people only occasionally >>> screw up logging in and you get the denial because it is mislabeled. >>> Fix the label and you should be good from now on. >>> >>> -Eric >> >> Thanks, it was mislabeled. I don't know how but it's fixed now. > >It'll be logrotate. > >https://bugzilla.redhat.com/show_bug.cgi?id=427274 > >Paul. Humm, new package soon I hope? Thanks -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) "Seed me, Seymour" -- a random number generator meets the big green mother from outer space From dblistsub-fedora at yahoo.it Mon Jan 7 20:53:16 2008 From: dblistsub-fedora at yahoo.it (Davide Bolcioni) Date: Mon, 7 Jan 2008 21:53:16 +0100 Subject: su user -c problem In-Reply-To: <200801071123.20559.gene.heskett@verizon.net> References: <200801061033.27657.gene.heskett@verizon.net> <1199719752.3716.130.camel@localhost.localdomain> <200801071123.20559.gene.heskett@verizon.net> Message-ID: <200801072153.16128.dblistsub-fedora@yahoo.it> On Monday 07 January 2008 05:23:20 pm Gene Heskett wrote: > I boot and login at runlevel 3, the everything but X, then run startx by > hand. I'm a big dummy maybe, and an old fart, but *I* can run it by using > the S99local link exactly the same as it real name, so why doesn't init run > it? I had something similar happen to me some time in the past, say about Fedora Core 3, and my init script was hanging (I could see it with pstree) asking for user input. I would pepper the script with echo $$ so far so good >> /tmp/cursed-initscript.log to see if it is started at all and then hangs or exits somewhere. Davide Bolcioni -- There is no place like /home. From gene.heskett at verizon.net Tue Jan 8 00:10:47 2008 From: gene.heskett at verizon.net (Gene Heskett) Date: Mon, 07 Jan 2008 19:10:47 -0500 Subject: su user -c problem In-Reply-To: <200801072153.16128.dblistsub-fedora@yahoo.it> References: <200801061033.27657.gene.heskett@verizon.net> <200801071123.20559.gene.heskett@verizon.net> <200801072153.16128.dblistsub-fedora@yahoo.it> Message-ID: <200801071910.47800.gene.heskett@verizon.net> On Monday 07 January 2008, Davide Bolcioni wrote: >On Monday 07 January 2008 05:23:20 pm Gene Heskett wrote: >> I boot and login at runlevel 3, the everything but X, then run startx by >> hand. I'm a big dummy maybe, and an old fart, but *I* can run it by using >> the S99local link exactly the same as it real name, so why doesn't init >> run it? > >I had something similar happen to me some time in the past, say about Fedora >Core 3, and my init script was hanging (I could see it with pstree) asking >for user input. I would pepper the script with > > echo $$ so far so good >> /tmp/cursed-initscript.log > >to see if it is started at all and then hangs or exits somewhere. Interesting idea Davide according to pstree, init is indeed still present, top of the list in fact: init???/usr/bin/sealer ??acpid ??artsd ??atd ??auditd???audispd???{audispd} ? ??{auditd} ??automount???4*[{automount}] ??avahi-daemon???avahi-daemon ??console-kit-dae???61*[{console-kit-dae}] ??crond ??cupsd ??2*[dbus-daemon???{dbus-daemon}] ??dbus-launch ??dcopserver ??drift-checker???sleep ??fetchmail ??gam_server ??gconfd-2 ??gpg-agent ??gpm ??hald???hald-runner???hald-addon-acpi ? ??hald-addon-hid- ? ??hald-addon-inpu ? ??hald-addon-stor ? ??hald-addon-usb- ??hcid ??2*[heyu] ??kaccess ??kded ??kdeinit???gkrellm???{gkrellm} ? ??kio_file ? ??klauncher ? ??konsole???su???bash???amrecover ? ? ??su???bash???pstree ? ? ??2*[su???bash] ? ??konsole???2*[su???bash] ? ??konsole???su???bash ? ? ??su???bash???htop ? ??konsole???4*[su???bash???tail] ? ??kwin ? ??nm-applet ? ??puplet ? ??python ??kdesktop ??kgpg ??kicker ??kio_uiserver ??kmail???4*[{kmail}] ??kmix ??knotify ??ksensors ??ksmserver ??kwalletmanager ??login???bash???startx???xinit???X ? ??ck-xinit-sessio???startkde???kwrapper ? ??ssh-agent ??login???bash ??4*[mingetty] ??notification-da ??ntpd ??pcscd ??restorecond ??rklogd ??rpc.idmapd ??rpc.statd ??rpcbind ??rsyslogd???{rsyslogd} ??2*[sendmail] ??setroubleshootd???2*[{setroubleshootd}] ??spamd???2*[spamd] ??sshd ??start_kdeinit ??udevd ??xinetd???amandad???amindexd ??yum-updatesd OTOH, I have NDI if that is normal. It is also sitting there in an htop screen showing "init(3)" which I assume is the runlevel. I'll pepper the last S## before that and see if its hung, and the top of rc.local, but that doesn't show anyplace, and if I run it by hand, it does everything and exits cleanly. Many thanks for the hint. >Davide Bolcioni -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Artistic ventures highlighted. Rob a museum. From gene.heskett at verizon.net Tue Jan 8 00:31:48 2008 From: gene.heskett at verizon.net (Gene Heskett) Date: Mon, 07 Jan 2008 19:31:48 -0500 Subject: su user -c problem In-Reply-To: <200801072153.16128.dblistsub-fedora@yahoo.it> References: <200801061033.27657.gene.heskett@verizon.net> <200801071123.20559.gene.heskett@verizon.net> <200801072153.16128.dblistsub-fedora@yahoo.it> Message-ID: <200801071931.48892.gene.heskett@verizon.net> On Monday 07 January 2008, Davide Bolcioni wrote: >On Monday 07 January 2008 05:23:20 pm Gene Heskett wrote: >> I boot and login at runlevel 3, the everything but X, then run startx by >> hand. I'm a big dummy maybe, and an old fart, but *I* can run it by using >> the S99local link exactly the same as it real name, so why doesn't init >> run it? > >I had something similar happen to me some time in the past, say about Fedora >Core 3, and my init script was hanging (I could see it with pstree) asking >for user input. I would pepper the script with > > echo $$ so far so good >> /tmp/cursed-initscript.log > And would you believe, it all worked on this reboot. I think I'll go shoot the neighbors worthless tomcat. This is frustrating, it failed absolutely on the last 3 reboots. I put that echo in S98wine, S99anacron, S99 firstboot and S99local, and while init is still visible in a pstree output, that file looks like this: 2563 so far so good, start of wine 2563 so far so good, end of wine startup 2571 so far so good, start of anacron 2571 so far so good, end of anacron 2581 so far so good, start of firstboot 2581 so far so good, firstboot should exit here 2588 so far so good, start of rc.local >to see if it is started at all and then hangs or exits somewhere. > >Davide Bolcioni -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) QOTD: "A child of 5 could understand this! Fetch me a child of 5." From craigwhite at azapple.com Tue Jan 8 01:17:25 2008 From: craigwhite at azapple.com (Craig White) Date: Mon, 07 Jan 2008 18:17:25 -0700 Subject: miss-match between needs and setroubleshooter's output recommendations In-Reply-To: <478258BD.2040905@redhat.com> References: <200801070350.33452.gene.heskett@verizon.net> <478258BD.2040905@redhat.com> Message-ID: <1199755045.26459.13.camel@lin-workstation.azapple.com> On Mon, 2008-01-07 at 11:52 -0500, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Gene Heskett wrote: > > Greetings; > > > > I have now been in the center ring of this circus about long enough. selinux > > is about to get made permissive or disabled. > > > > I have now issued these commands: > > > > [root at coyote ~]# semanage fcontext -a -t > > textrel_shlib_t /root/.mozilla/plugins/vorbisrend.so > > [root at coyote ~]# chcon -t textrel_shlib_t /root/.mozilla/plugins/vorbisrend.so > > [root at coyote ~]# semanage fcontext -a -t > > textrel_shlib_t /root/.mozilla/plugins/vorbisrend.so > > [root at coyote ~]# chcon -t textrel_shlib_t /root/.mozilla/plugins/vorbisrend.so > > > > Twice as can be seen, and restarted firefox each time, and each time selinux > > denies firefox a plugin it needs to pay this site: > > > > > > I now have the third denial showing in the setroubleshooter's screen. > > ----------------- > > > > How can I fix this? > > > > Thanks. > > > Please attach the AVC messages from /var/log/audit/audit.log > > This looks like you could be running Firefox as root, which is a bad idea. > > ausearch -m avc > > Will grab all of the avc messages. ---- let me assure you that he indeed runs firefox as root. We've been down that road (bad idea) on fedora-list Craig From gene.heskett at verizon.net Tue Jan 8 02:13:50 2008 From: gene.heskett at verizon.net (Gene Heskett) Date: Mon, 07 Jan 2008 21:13:50 -0500 Subject: su user -c problem In-Reply-To: <200801071931.48892.gene.heskett@verizon.net> References: <200801061033.27657.gene.heskett@verizon.net> <200801072153.16128.dblistsub-fedora@yahoo.it> <200801071931.48892.gene.heskett@verizon.net> Message-ID: <200801072113.50953.gene.heskett@verizon.net> On Monday 07 January 2008, Gene Heskett wrote: >On Monday 07 January 2008, Davide Bolcioni wrote: >>On Monday 07 January 2008 05:23:20 pm Gene Heskett wrote: >>> I boot and login at runlevel 3, the everything but X, then run startx by >>> hand. I'm a big dummy maybe, and an old fart, but *I* can run it by using >>> the S99local link exactly the same as it real name, so why doesn't init >>> run it? >> >>I had something similar happen to me some time in the past, say about >> Fedora Core 3, and my init script was hanging (I could see it with pstree) >> asking for user input. I would pepper the script with >> >> echo $$ so far so good >> /tmp/cursed-initscript.log > >And would you believe, it all worked on this reboot. I think I'll go shoot >the neighbors worthless tomcat. This is frustrating, it failed absolutely > on the last 3 reboots. > >I put that echo in S98wine, S99anacron, S99 firstboot and S99local, and > while init is still visible in a pstree output, that file looks like this: > >2563 so far so good, start of wine >2563 so far so good, end of wine startup >2571 so far so good, start of anacron >2571 so far so good, end of anacron >2581 so far so good, start of firstboot >2581 so far so good, firstboot should exit here >2588 so far so good, start of rc.local > >>to see if it is started at all and then hangs or exits somewhere. >> >>Davide Bolcioni And a PS to the PS if you will. That boot above had an selinux=0 on the grub kernel line that I had forgot adding earlier this day. I obviously have a bad case of CRS. So I took it out and rebooted again. Of course it had to relabel everything, but this time S99local ran just fine including getting fetchmail started. Repeatable? Damnifiknow. Thanks for the hints though, that might come in handy yet. Humm, I should take the double >> back to a single > for the first one, else that file will get pretty big in a few years. :) -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Fortune and love befriend the bold. -- Ovid From dwalsh at redhat.com Tue Jan 8 10:44:33 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 08 Jan 2008 05:44:33 -0500 Subject: miss-match between needs and setroubleshooter's output recommendations In-Reply-To: <200801071319.14579.gene.heskett@verizon.net> References: <200801070350.33452.gene.heskett@verizon.net> <478258BD.2040905@redhat.com> <200801071319.14579.gene.heskett@verizon.net> Message-ID: <47835411.2010704@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gene Heskett wrote: > On Monday 07 January 2008, Daniel J Walsh wrote: >> ausearch -m avc > > That returned a bunch of stuff starting on the 5th, and includes a whole bunch > of hits from procmail, log related I think, but the /var/log/procmail.log is > being generated ok ANAICT. I have a tail sitting on it now. > > So I trimmed that output to just today and its attached. Still 170kb though. > > And yes, FF is being run as root. I'm working on fixing me to do all this, > but its damnedably difficult to do when I am being denied su and sudo, > despite putting myself in the sudoers list with visudo, when logged in as me, > so I have to run as root in order to actually get anything done. Yes, I am > doing a lot of copying, and chown'ing while trying to get an environment > setup for me that duplicates what root can do. > > Also, none of you guys have headers that allow me to reply all, the addresses > are missing, so I have to do a simple reply which goes to you, and then add > the fedora-selinux-list at redhat.com address by hand. I'm assuming you want > this in the archive anyway. > > Also what OS version is this? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeDVBEACgkQrlYvE4MpobMnhACfQcebVPnBIRIXG8xbDXm7wvdP fsgAoIswstUar3WNI/z07ouTcqFcrXlH =b4zT -----END PGP SIGNATURE----- From Dan.HAWKER at uk4.astrium.eads.net Tue Jan 8 11:52:14 2008 From: Dan.HAWKER at uk4.astrium.eads.net (HAWKER, Dan 2 (external)) Date: Tue, 8 Jan 2008 11:52:14 -0000 Subject: UNCLASSIFIED - Developing Policies for SELinux on Embedded Systems Message-ID: <7F6B06837A5DBD49AC6E1650EFF5490601C64BE6@auk52177.ukr.astrium.corp> Hi All, Am very much a SELinux Policy Newbie, so please be gentle :) Have been tasked with generating a series of SELinux policies for some embedded Linux devices we are developing. Naturally, time is not in abundance :( The target system is a special stripped-down FC4 variant (i386, about 80MB footprint), we have developed in-house for our embedded platform and runs a custom 2.6.12ish kernel with some modifications for the target hardware. I planned to start with the base reference policy, strip out the bits we don't need (it only runs our own apps plus the minimum to boot) and then add policies for our apps. All presuming the relatively old kernel we are using can handle the ref policy and subsequent libselinux, etc updates of course. Obviously with time being of the essence, I'd like a quick and easy way of developing the appropriate policies. I have looked at the tools that are available at present (SLIDE, SETools, etc) however tbh am a bit confused about what would be the best way forward and whether it'll all work as expected before I spend days/weeks of development time down a dead end. Naturally the embedded nature of the hardware means I am unable to develop directly on the target and as such SLIDE seems a good tool and with the SLIDERemote, would seem a good fit, (install SLIDE on my RHEL5 DevBox and connect to my remote target, which has network access but limited onboard resources). However am just unsure as to whether it will work as expected or indeed if there is another better route or toolset I should take. Any ideas/insights gratefully received :) Thanks for any help Dan -- Dan Hawker Linux System Administrator Astrium http://www.astrium.eads.net -- This email (including any attachments) may contain confidential and/or privileged information or information otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately, do not copy this message or any attachments and do not use it for any purpose or disclose its content to any person, but delete this message and any attachments from your system. Astrium disclaims any and all liability if this email transmission was virus corrupted, altered or falsified. --------------------------------------------------------------------- Astrium Limited, Registered in England and Wales No. 2449259 REGISTERED OFFICE:- Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England From gene.heskett at verizon.net Tue Jan 8 15:04:02 2008 From: gene.heskett at verizon.net (Gene Heskett) Date: Tue, 08 Jan 2008 10:04:02 -0500 Subject: miss-match between needs and setroubleshooter's output recommendations In-Reply-To: <47835411.2010704@redhat.com> References: <200801070350.33452.gene.heskett@verizon.net> <200801071319.14579.gene.heskett@verizon.net> <47835411.2010704@redhat.com> Message-ID: <200801081004.02485.gene.heskett@verizon.net> On Tuesday 08 January 2008, Daniel J Walsh wrote: >Gene Heskett wrote: >> On Monday 07 January 2008, Daniel J Walsh wrote: >>> ausearch -m avc >> >> That returned a bunch of stuff starting on the 5th, and includes a whole >> bunch of hits from procmail, log related I think, but the >> /var/log/procmail.log is being generated ok ANAICT. I have a tail sitting >> on it now. >> >> So I trimmed that output to just today and its attached. Still 170kb >> though. >> >> And yes, FF is being run as root. I'm working on fixing me to do all >> this, but its damnedably difficult to do when I am being denied su and >> sudo, despite putting myself in the sudoers list with visudo, when logged >> in as me, so I have to run as root in order to actually get anything done. >> Yes, I am doing a lot of copying, and chown'ing while trying to get an >> environment setup for me that duplicates what root can do. >> >> Also, none of you guys have headers that allow me to reply all, the >> addresses are missing, so I have to do a simple reply which goes to you, >> and then add the fedora-selinux-list at redhat.com address by hand. I'm >> assuming you want this in the archive anyway. > >Also what OS version is this? Fedora 8, uptodate. And my face is red. it seems the default toobat for kmail now has the fwd button next to the reply button, so I edited the toobar to restore that buttons location to immediately right of the plain reply button. About one minute ago when I was checking to see what another strange to me button was. My apologies for the noise. Possibly a -ENOTENOUGHCOFFE error? PEBKAC in other words. :-) -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Anything cut to length will be too short. From fenn at stanford.edu Tue Jan 8 19:05:00 2008 From: fenn at stanford.edu (Tim Fenn) Date: Tue, 8 Jan 2008 11:05:00 -0800 Subject: sendmail/smrsh f8 avc error In-Reply-To: <47824EFD.8010007@redhat.com> References: <20080103175720.067cb135@atbws1.stanford.edu> <47824EFD.8010007@redhat.com> Message-ID: <20080108110500.206b8a72@atbws1.stanford.edu> On Mon, 07 Jan 2008 11:10:37 -0500 Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Tim Fenn wrote: > > After updating from f7 to f8, it appears smrsh might be mislabelled > > (using selinux-policy-3.0.8-72.fc8) - or am I missing something? > > > > type=AVC msg=audit(1199408924.325:1608): avc: denied { getattr } > > for pid=10777 comm="sendmail" path="/usr/sbin/smrsh" dev=dm-0 > > ino=3785966 scontext=system_u:system_r:sendmail_t:s0 > > tcontext=system_u:object_r:bin_t:s0 tclass=file > > > > type=SYSCALL msg=audit(1199408924.325:1608): arch=c000003e syscall=4 > > success=no exit=-13 a0=7fff6e1c7d90 a1=7fff6e1c7c70 a2=7fff6e1c7c70 > > a3=7fff6e1c7d9f items=0 ppid=10776 pid=10777 auid=4294967295 uid=8 > > gid=12 euid=8 suid=8 fsuid=8 egid=12 sgid=12 fsgid=12 tty=(none) > > comm="sendmail" exe="/usr/sbin/sendmail.sendmail" > > subj=system_u:system_r:sendmail_t:s0 key=(null) > > > > type=AVC msg=audit(1199408924.333:1609): avc: denied { execute } > > for pid=10777 comm="sendmail" name="smrsh" dev=dm-0 ino=3785966 > > scontext=system_u:system_r:sendmail_t:s0 > > tcontext=system_u:object_r:bin_t:s0 tclass=file > > > > type=SYSCALL msg=audit(1199408924.333:1609): arch=c000003e > > syscall=59 success=no exit=-13 a0=2aaaaae7a7a0 a1=7fff6e1c8f00 > > a2=2aaaaadb4b00 a3=0 items=0 ppid=10776 pid=10777 auid=4294967295 > > uid=8 gid=12 euid=8 suid=8 fsuid=8 egid=12 sgid=12 fsgid=12 > > tty=(none) comm="sendmail" exe="/usr/sbin/sendmail.sendmail" > > subj=system_u:system_r:sendmail_t:s0 key=(null) > > > > -Tim > > > Nope should be labeled shell_exec_t. I will update in next release > > chcon -t shell_exec_t /usr/sbin/smrsh > > Will fix it for now. Thanks again, Dan. Also take a look at mailman: avc: denied { getattr } for comm=smrsh dev=dm-0 egid=12 euid=8 exe=/usr/sbin/smrsh exit=-13 fsgid=12 fsuid=8 gid=12 items=0 path=/usr/lib/mailman/mail/mailman pid=2542 scontext=unconfined_u:system_r:sendmail_t:s0 sgid=12 subj=unconfined_u:system_r:sendmail_t:s0 suid=8 tclass=file tcontext=system_u:object_r:bin_t:s0 tty=(none) uid=8 Regards, Tim -- CAPS LOCK IS THE CRUISE CONTROL OF AWESOMNESS From mike.clarkson at baesystems.com Tue Jan 8 20:53:52 2008 From: mike.clarkson at baesystems.com (Clarkson, Mike R (US SSA)) Date: Tue, 8 Jan 2008 12:53:52 -0800 Subject: two new questions (sort of) Message-ID: I've been testing dynamic transitions with a simple test program that uses setcon to change from one mls level to another, as well as one domain to another. I wrote a policy for this test program and provided all the rules necessary to remove all of the avc denials from the audit log. When I run my program in permissive mode, it works as expected without adding any avc denial messages to the audit log. But when I switch to enforcing mode, the setcon call fails. Maybe there are some dontaudit statements that come with the policy causing this. I'm using RHEL5.1 with the mls policy.Any ideas as to what may be causing this? Since the subject of dynamic transitions seems to raise much angst and gnashing of teeth, I thought I'd ask if there is a better way to solve the problem that we have? I'm investigating dynamic transitions for the following purpose. We have services that we run that take a long time to start up, too long to start them up on demand. We want to have a pool of them up and running, waiting to be tasked by a server. But we'll be running an MLS system with many compartments and possible combinations of compartments so it is not feasible to have services up and running for all the compartment combinations. The idea is to have a pool of services initialize at some default level, and then assign them to the correct level/compartment when tasked. Upon completing a task, a service would shut down and a new service would be started to replace it, at the default level. Two domains would be used. A service initialization domain, and a service running domain. The service initialization domain would have the capability of dynamic transitions. The service running domain would not. Therefore, when the service is tasked, it also dynamically transitions to the correct level and to the service running domain. From that point on it no longer has the capability of further dynamic transitions. If there is a better way to solve this problem, I'd like to know. Thanks From sds at tycho.nsa.gov Tue Jan 8 21:30:04 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 08 Jan 2008 16:30:04 -0500 Subject: two new questions (sort of) In-Reply-To: References: Message-ID: <1199827804.9393.202.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2008-01-08 at 12:53 -0800, Clarkson, Mike R (US SSA) wrote: > I've been testing dynamic transitions with a simple test program that > uses setcon to change from one mls level to another, as well as one > domain to another. I wrote a policy for this test program and provided > all the rules necessary to remove all of the avc denials from the audit > log. When I run my program in permissive mode, it works as expected > without adding any avc denial messages to the audit log. But when I > switch to enforcing mode, the setcon call fails. Maybe there are some > dontaudit statements that come with the policy causing this. I'm using > RHEL5.1 with the mls policy.Any ideas as to what may be causing this? Try loading policy without any dontaudit rules and try again. With modern userland, you can just do: semodule -DB to remove all dontaudits from policy and load it. semodule -B later will revert the change. The old way before semodule -DB was to install enableaudit.pp (a base module with dontaudits stripped at build time) from /usr/share/selinux/$SELINUXTYPE. But that only affects the base module, not any other modules. So if this is for a policy module you've created, you should really look there to see what dontaudits are in the postprocessed file under the tmp directory. > Since the subject of dynamic transitions seems to raise much angst and > gnashing of teeth, I thought I'd ask if there is a better way to solve > the problem that we have? I'm investigating dynamic transitions for the > following purpose. We have services that we run that take a long time to > start up, too long to start them up on demand. We want to have a pool of > them up and running, waiting to be tasked by a server. But we'll be > running an MLS system with many compartments and possible combinations > of compartments so it is not feasible to have services up and running > for all the compartment combinations. The idea is to have a pool of > services initialize at some default level, and then assign them to the > correct level/compartment when tasked. Upon completing a task, a service > would shut down and a new service would be started to replace it, at the > default level. Two domains would be used. A service initialization > domain, and a service running domain. The service initialization domain > would have the capability of dynamic transitions. The service running > domain would not. Therefore, when the service is tasked, it also > dynamically transitions to the correct level and to the service running > domain. From that point on it no longer has the capability of further > dynamic transitions. If there is a better way to solve this problem, I'd > like to know. exec based transitions are preferable as we can control the inheritance of state across the transition and the initialization of the process in the new context, including binding entry into the context to a specific executable. But it does carry an overhead, of course. Refactoring your service program may be possible, or maybe not. These kinds of questions are likely better suited to selinux list rather than fedora selinux list, btw. Not really fedora specific. -- Stephen Smalley National Security Agency From dant at cdkkt.com Tue Jan 8 21:46:43 2008 From: dant at cdkkt.com (Daniel B. Thurman) Date: Tue, 8 Jan 2008 13:46:43 -0800 Subject: ALSA problems. Message-ID: <021126B987E43D44A860139823C079110E2C56@ns1.cdkkt.com> I was forced to install ALSA manually in my F8 system and unfortunately, I discovered that setting /.autorelabel did not correctly set ALSA permissions. I did note that a bug report was filed for this. Meanwhile, I would like a solution to solve my issue, if there is one? Kind regards, Dan No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.17.13/1213 - Release Date: 1/7/2008 9:14 AM From eparis at redhat.com Tue Jan 8 22:19:14 2008 From: eparis at redhat.com (Eric Paris) Date: Tue, 08 Jan 2008 17:19:14 -0500 Subject: ALSA problems. In-Reply-To: <021126B987E43D44A860139823C079110E2C56@ns1.cdkkt.com> References: <021126B987E43D44A860139823C079110E2C56@ns1.cdkkt.com> Message-ID: <1199830754.6089.36.camel@localhost.localdomain> -ENOINFO what problems are you having, why do you believe this is an selinux issue, please, tell us what is happening, what you are seeing and provide output of errors? If this is selinux you will find message in either /var/log/messages or /var/log/audit/audit.log which will be most interesting to the people on this list. -Eric On Tue, 2008-01-08 at 13:46 -0800, Daniel B. Thurman wrote: > I was forced to install ALSA manually in my F8 system and unfortunately, > I discovered that setting /.autorelabel did not correctly set ALSA permissions. > > I did note that a bug report was filed for this. > > Meanwhile, I would like a solution to solve my issue, if there is one? > > Kind regards, > Dan > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.17.13/1213 - Release Date: 1/7/2008 9:14 AM > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From dant at cdkkt.com Tue Jan 8 23:58:20 2008 From: dant at cdkkt.com (Daniel B. Thurman) Date: Tue, 8 Jan 2008 15:58:20 -0800 Subject: ALSA problems. Message-ID: <021126B987E43D44A860139823C079110E2C57@ns1.cdkkt.com> Eric Paris wrote: >what problems are you having, why do you believe this is an selinux >issue, please, tell us what is happening, what you are seeing and >provide output of errors? If this is selinux you will find message in >either /var/log/messages or /var/log/audit/audit.log which will be most >interesting to the people on this list. > >-Eric > >>Daniel B. Thurman wrote: >> I was forced to install ALSA manually in my F8 system and >unfortunately, >> I discovered that setting /.autorelabel did not correctly >set ALSA permissions. >> >> I did note that a bug report was filed for this. >> >> Meanwhile, I would like a solution to solve my issue, if >there is one? >> >> Kind regards, >> Dan >> This is something I just found when searching the /var/log/message file but this is not related to ALSA, but to rhgb: Jan 7 13:11:44 localhost kernel: audit(1199740241.970:9): avc: denied { read write } for pid=1775 comm="consoletype" path="/dev/pts/0" dev=devpts ino=2 scontext=system_u:system_r:consoletype_t:s0 tcontext=system_u:object_r:rhgb_devpts_t:s0 tclass=chr_file As for ALSA issues, there was a problem writing to /etc/asound.state and to ~/.asoundrc but this is not recorded where I can find it. It only happens during logoff/shutdown and I see it very briefly and it appears to be an 'alsactl store' command failure and *maybe* the log below is related to it but I cannot confirm it. Jan 8 12:28:30 gold kernel: audit(1199823854.622:4): avc: denied { getattr } for pid=1264 comm="salsa" path="/usr/share/alsa/alsa.conf" dev=sda5 ino=147458 scontext=system_u:system_r:alsa_t:s0-s0:c0.c1023 tcontext=system_u:object_r:usr_t:s0 tclass=file I DO know that alsactl is not able to set the volume control settings for which I am forced to reset every time at login after a boot. There was some months ago that Daniel Walsh wrote as a bug report in getting the /etc/asound.state moved to /var/lib directory and it was written on Sept 17, 2007. No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.17.13/1213 - Release Date: 1/7/2008 9:14 AM From mike.clarkson at baesystems.com Wed Jan 9 01:11:50 2008 From: mike.clarkson at baesystems.com (Clarkson, Mike R (US SSA)) Date: Tue, 8 Jan 2008 17:11:50 -0800 Subject: two new questions (sort of) References: <1199827804.9393.202.camel@moss-spartans.epoch.ncsc.mil> Message-ID: Thanks. I wasn't aware that all dontaudit rules could be disabled. It looks like RHEL5.1 doesn't have the -D option available for semodule, so I'm attempting to use the older method of loading enableaudit.pp. I keep getting duplicate declaration errors. It appears that to load enableaudit.pp, I first need to remove nearly all the non-base modules. Is there an easier method to do that other than either of the following? -using "semodule -i" and listing all the modules -changing each module to off in the modules.conf file Thanks > -----Original Message----- > From: Stephen Smalley [mailto:sds at tycho.nsa.gov] > Sent: Tuesday, January 08, 2008 1:30 PM > To: Clarkson, Mike R (US SSA) > Cc: fedora-selinux-list at redhat.com; Daniel J Walsh > Subject: Re: two new questions (sort of) > > > On Tue, 2008-01-08 at 12:53 -0800, Clarkson, Mike R (US SSA) wrote: > > I've been testing dynamic transitions with a simple test program that > > uses setcon to change from one mls level to another, as well as one > > domain to another. I wrote a policy for this test program and provided > > all the rules necessary to remove all of the avc denials from the audit > > log. When I run my program in permissive mode, it works as expected > > without adding any avc denial messages to the audit log. But when I > > switch to enforcing mode, the setcon call fails. Maybe there are some > > dontaudit statements that come with the policy causing this. I'm using > > RHEL5.1 with the mls policy.Any ideas as to what may be causing this? > > Try loading policy without any dontaudit rules and try again. > With modern userland, you can just do: > semodule -DB > to remove all dontaudits from policy and load it. semodule -B later > will revert the change. > > The old way before semodule -DB was to install enableaudit.pp (a base > module with dontaudits stripped at build time) > from /usr/share/selinux/$SELINUXTYPE. But that only affects the base > module, not any other modules. So if this is for a policy module you've > created, you should really look there to see what dontaudits are in the > postprocessed file under the tmp directory. > > > Since the subject of dynamic transitions seems to raise much angst and > > gnashing of teeth, I thought I'd ask if there is a better way to solve > > the problem that we have? I'm investigating dynamic transitions for the > > following purpose. We have services that we run that take a long time to > > start up, too long to start them up on demand. We want to have a pool of > > them up and running, waiting to be tasked by a server. But we'll be > > running an MLS system with many compartments and possible combinations > > of compartments so it is not feasible to have services up and running > > for all the compartment combinations. The idea is to have a pool of > > services initialize at some default level, and then assign them to the > > correct level/compartment when tasked. Upon completing a task, a service > > would shut down and a new service would be started to replace it, at the > > default level. Two domains would be used. A service initialization > > domain, and a service running domain. The service initialization domain > > would have the capability of dynamic transitions. The service running > > domain would not. Therefore, when the service is tasked, it also > > dynamically transitions to the correct level and to the service running > > domain. From that point on it no longer has the capability of further > > dynamic transitions. If there is a better way to solve this problem, I'd > > like to know. > > exec based transitions are preferable as we can control the inheritance > of state across the transition and the initialization of the process in > the new context, including binding entry into the context to a specific > executable. But it does carry an overhead, of course. Refactoring your > service program may be possible, or maybe not. > > These kinds of questions are likely better suited to selinux list rather > than fedora selinux list, btw. Not really fedora specific. > > -- > Stephen Smalley > National Security Agency From eparis at redhat.com Wed Jan 9 03:34:10 2008 From: eparis at redhat.com (Eric Paris) Date: Tue, 08 Jan 2008 22:34:10 -0500 Subject: two new questions (sort of) In-Reply-To: References: <1199827804.9393.202.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1199849650.6089.44.camel@localhost.localdomain> enableaudit.pp is a base module, are you using -i or -b to load it? If you can't just semodule -b enableaudit.pp file a bug explaining what you did and what went wrong (dan loves bugs, i heard him say it) -Eric On Tue, 2008-01-08 at 17:11 -0800, Clarkson, Mike R (US SSA) wrote: > Thanks. I wasn't aware that all dontaudit rules could be disabled. > > It looks like RHEL5.1 doesn't have the -D option available for semodule, > so I'm attempting to use the older method of loading enableaudit.pp. I > keep getting duplicate declaration errors. It appears that to load > enableaudit.pp, I first need to remove nearly all the non-base modules. > Is there an easier method to do that other than either of the following? > -using "semodule -i" and listing all the modules > -changing each module to off in the modules.conf file > > Thanks > > > -----Original Message----- > > From: Stephen Smalley [mailto:sds at tycho.nsa.gov] > > Sent: Tuesday, January 08, 2008 1:30 PM > > To: Clarkson, Mike R (US SSA) > > Cc: fedora-selinux-list at redhat.com; Daniel J Walsh > > Subject: Re: two new questions (sort of) > > > > > > On Tue, 2008-01-08 at 12:53 -0800, Clarkson, Mike R (US SSA) wrote: > > > I've been testing dynamic transitions with a simple test program > that > > > uses setcon to change from one mls level to another, as well as one > > > domain to another. I wrote a policy for this test program and > provided > > > all the rules necessary to remove all of the avc denials from the > audit > > > log. When I run my program in permissive mode, it works as expected > > > without adding any avc denial messages to the audit log. But when I > > > switch to enforcing mode, the setcon call fails. Maybe there are > some > > > dontaudit statements that come with the policy causing this. I'm > using > > > RHEL5.1 with the mls policy.Any ideas as to what may be causing > this? > > > > Try loading policy without any dontaudit rules and try again. > > With modern userland, you can just do: > > semodule -DB > > to remove all dontaudits from policy and load it. semodule -B later > > will revert the change. > > > > The old way before semodule -DB was to install enableaudit.pp (a base > > module with dontaudits stripped at build time) > > from /usr/share/selinux/$SELINUXTYPE. But that only affects the base > > module, not any other modules. So if this is for a policy module > you've > > created, you should really look there to see what dontaudits are in > the > > postprocessed file under the tmp directory. > > > > > Since the subject of dynamic transitions seems to raise much angst > and > > > gnashing of teeth, I thought I'd ask if there is a better way to > solve > > > the problem that we have? I'm investigating dynamic transitions for > the > > > following purpose. We have services that we run that take a long > time to > > > start up, too long to start them up on demand. We want to have a > pool of > > > them up and running, waiting to be tasked by a server. But we'll be > > > running an MLS system with many compartments and possible > combinations > > > of compartments so it is not feasible to have services up and > running > > > for all the compartment combinations. The idea is to have a pool of > > > services initialize at some default level, and then assign them to > the > > > correct level/compartment when tasked. Upon completing a task, a > service > > > would shut down and a new service would be started to replace it, at > the > > > default level. Two domains would be used. A service initialization > > > domain, and a service running domain. The service initialization > domain > > > would have the capability of dynamic transitions. The service > running > > > domain would not. Therefore, when the service is tasked, it also > > > dynamically transitions to the correct level and to the service > running > > > domain. From that point on it no longer has the capability of > further > > > dynamic transitions. If there is a better way to solve this problem, > I'd > > > like to know. > > > > exec based transitions are preferable as we can control the > inheritance > > of state across the transition and the initialization of the process > in > > the new context, including binding entry into the context to a > specific > > executable. But it does carry an overhead, of course. Refactoring > your > > service program may be possible, or maybe not. > > > > These kinds of questions are likely better suited to selinux list > rather > > than fedora selinux list, btw. Not really fedora specific. > > > > -- > > Stephen Smalley > > National Security Agency > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From mike.clarkson at baesystems.com Wed Jan 9 17:27:31 2008 From: mike.clarkson at baesystems.com (Clarkson, Mike R (US SSA)) Date: Wed, 9 Jan 2008 09:27:31 -0800 Subject: two new questions (sort of) References: <1199827804.9393.202.camel@moss-spartans.epoch.ncsc.mil> <1199849650.6089.44.camel@localhost.localdomain> Message-ID: I'll file a bug. Here is what I did: # semodule -b /usr/share/selinux/mls/enableaudit.pp libsepol.scope_copy_callback: acct: Duplicate declaration in module: type/attribute acct_t libsemanage.semanage_link_sandbox: Link packages failed semodule: Failed! # semodule -r acct # semodule -b /usr/share/selinux/mls/enableaudit.pp libsepol.scope_copy_callback: aide: Duplicate declaration in module: type/attribute aide_t libsemanage.semanage_link_sandbox: Link packages failed semodule: Failed! > -----Original Message----- > From: Eric Paris [mailto:eparis at redhat.com] > Sent: Tuesday, January 08, 2008 7:34 PM > To: Clarkson, Mike R (US SSA) > Cc: Stephen Smalley; Daniel J Walsh; fedora-selinux-list at redhat.com > Subject: RE: two new questions (sort of) > > enableaudit.pp is a base module, are you using -i or -b to load it? If > you can't just semodule -b enableaudit.pp file a bug explaining what you > did and what went wrong (dan loves bugs, i heard him say it) > > -Eric > > On Tue, 2008-01-08 at 17:11 -0800, Clarkson, Mike R (US SSA) wrote: > > Thanks. I wasn't aware that all dontaudit rules could be disabled. > > > > It looks like RHEL5.1 doesn't have the -D option available for semodule, > > so I'm attempting to use the older method of loading enableaudit.pp. I > > keep getting duplicate declaration errors. It appears that to load > > enableaudit.pp, I first need to remove nearly all the non-base modules. > > Is there an easier method to do that other than either of the following? > > -using "semodule -i" and listing all the modules > > -changing each module to off in the modules.conf file > > > > Thanks > > > > > -----Original Message----- > > > From: Stephen Smalley [mailto:sds at tycho.nsa.gov] > > > Sent: Tuesday, January 08, 2008 1:30 PM > > > To: Clarkson, Mike R (US SSA) > > > Cc: fedora-selinux-list at redhat.com; Daniel J Walsh > > > Subject: Re: two new questions (sort of) > > > > > > > > > On Tue, 2008-01-08 at 12:53 -0800, Clarkson, Mike R (US SSA) wrote: > > > > I've been testing dynamic transitions with a simple test program > > that > > > > uses setcon to change from one mls level to another, as well as one > > > > domain to another. I wrote a policy for this test program and > > provided > > > > all the rules necessary to remove all of the avc denials from the > > audit > > > > log. When I run my program in permissive mode, it works as expected > > > > without adding any avc denial messages to the audit log. But when I > > > > switch to enforcing mode, the setcon call fails. Maybe there are > > some > > > > dontaudit statements that come with the policy causing this. I'm > > using > > > > RHEL5.1 with the mls policy.Any ideas as to what may be causing > > this? > > > > > > Try loading policy without any dontaudit rules and try again. > > > With modern userland, you can just do: > > > semodule -DB > > > to remove all dontaudits from policy and load it. semodule -B later > > > will revert the change. > > > > > > The old way before semodule -DB was to install enableaudit.pp (a base > > > module with dontaudits stripped at build time) > > > from /usr/share/selinux/$SELINUXTYPE. But that only affects the base > > > module, not any other modules. So if this is for a policy module > > you've > > > created, you should really look there to see what dontaudits are in > > the > > > postprocessed file under the tmp directory. > > > > > > > Since the subject of dynamic transitions seems to raise much angst > > and > > > > gnashing of teeth, I thought I'd ask if there is a better way to > > solve > > > > the problem that we have? I'm investigating dynamic transitions for > > the > > > > following purpose. We have services that we run that take a long > > time to > > > > start up, too long to start them up on demand. We want to have a > > pool of > > > > them up and running, waiting to be tasked by a server. But we'll be > > > > running an MLS system with many compartments and possible > > combinations > > > > of compartments so it is not feasible to have services up and > > running > > > > for all the compartment combinations. The idea is to have a pool of > > > > services initialize at some default level, and then assign them to > > the > > > > correct level/compartment when tasked. Upon completing a task, a > > service > > > > would shut down and a new service would be started to replace it, at > > the > > > > default level. Two domains would be used. A service initialization > > > > domain, and a service running domain. The service initialization > > domain > > > > would have the capability of dynamic transitions. The service > > running > > > > domain would not. Therefore, when the service is tasked, it also > > > > dynamically transitions to the correct level and to the service > > running > > > > domain. From that point on it no longer has the capability of > > further > > > > dynamic transitions. If there is a better way to solve this problem, > > I'd > > > > like to know. > > > > > > exec based transitions are preferable as we can control the > > inheritance > > > of state across the transition and the initialization of the process > > in > > > the new context, including binding entry into the context to a > > specific > > > executable. But it does carry an overhead, of course. Refactoring > > your > > > service program may be possible, or maybe not. > > > > > > These kinds of questions are likely better suited to selinux list > > rather > > > than fedora selinux list, btw. Not really fedora specific. > > > > > > -- > > > Stephen Smalley > > > National Security Agency > > > > > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From sds at tycho.nsa.gov Wed Jan 9 18:15:28 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 09 Jan 2008 13:15:28 -0500 Subject: two new questions (sort of) In-Reply-To: References: <1199827804.9393.202.camel@moss-spartans.epoch.ncsc.mil> <1199849650.6089.44.camel@localhost.localdomain> Message-ID: <1199902528.9393.287.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-01-09 at 09:27 -0800, Clarkson, Mike R (US SSA) wrote: > I'll file a bug. > > Here is what I did: > > # semodule -b /usr/share/selinux/mls/enableaudit.pp > libsepol.scope_copy_callback: acct: Duplicate declaration in module: > type/attribute acct_t > libsemanage.semanage_link_sandbox: Link packages failed > semodule: Failed! > # semodule -r acct > # semodule -b /usr/share/selinux/mls/enableaudit.pp > libsepol.scope_copy_callback: aide: Duplicate declaration in module: > type/attribute aide_t > libsemanage.semanage_link_sandbox: Link packages failed > semodule: Failed! That suggests that enableaudit.pp wasn't built the same way (or against the same policy) as the policy you are using. Are you using a custom policy or the RH-provided selinux-policy-mls? Also, I suspect that stripping dontaudits from your base module isn't going to help you since you are talking about your own custom module for your own application, right? So I'd start by looking at the postprocessed module file for dontaudits and strip those by hand. Or just build a modern selinux userland into a private directory, set PATH and LD_LIBRARY_PATH to refer to it, and run the modern semodule -DB command from it. > > > > -----Original Message----- > > From: Eric Paris [mailto:eparis at redhat.com] > > Sent: Tuesday, January 08, 2008 7:34 PM > > To: Clarkson, Mike R (US SSA) > > Cc: Stephen Smalley; Daniel J Walsh; fedora-selinux-list at redhat.com > > Subject: RE: two new questions (sort of) > > > > enableaudit.pp is a base module, are you using -i or -b to load it? > If > > you can't just semodule -b enableaudit.pp file a bug explaining what > you > > did and what went wrong (dan loves bugs, i heard him say it) > > > > -Eric > > > > On Tue, 2008-01-08 at 17:11 -0800, Clarkson, Mike R (US SSA) wrote: > > > Thanks. I wasn't aware that all dontaudit rules could be disabled. > > > > > > It looks like RHEL5.1 doesn't have the -D option available for > semodule, > > > so I'm attempting to use the older method of loading enableaudit.pp. > I > > > keep getting duplicate declaration errors. It appears that to load > > > enableaudit.pp, I first need to remove nearly all the non-base > modules. > > > Is there an easier method to do that other than either of the > following? > > > -using "semodule -i" and listing all the modules > > > -changing each module to off in the modules.conf file > > > > > > Thanks > > > > > > > -----Original Message----- > > > > From: Stephen Smalley [mailto:sds at tycho.nsa.gov] > > > > Sent: Tuesday, January 08, 2008 1:30 PM > > > > To: Clarkson, Mike R (US SSA) > > > > Cc: fedora-selinux-list at redhat.com; Daniel J Walsh > > > > Subject: Re: two new questions (sort of) > > > > > > > > > > > > On Tue, 2008-01-08 at 12:53 -0800, Clarkson, Mike R (US SSA) > wrote: > > > > > I've been testing dynamic transitions with a simple test program > > > that > > > > > uses setcon to change from one mls level to another, as well as > one > > > > > domain to another. I wrote a policy for this test program and > > > provided > > > > > all the rules necessary to remove all of the avc denials from > the > > > audit > > > > > log. When I run my program in permissive mode, it works as > expected > > > > > without adding any avc denial messages to the audit log. But > when I > > > > > switch to enforcing mode, the setcon call fails. Maybe there are > > > some > > > > > dontaudit statements that come with the policy causing this. I'm > > > using > > > > > RHEL5.1 with the mls policy.Any ideas as to what may be causing > > > this? > > > > > > > > Try loading policy without any dontaudit rules and try again. > > > > With modern userland, you can just do: > > > > semodule -DB > > > > to remove all dontaudits from policy and load it. semodule -B > later > > > > will revert the change. > > > > > > > > The old way before semodule -DB was to install enableaudit.pp (a > base > > > > module with dontaudits stripped at build time) > > > > from /usr/share/selinux/$SELINUXTYPE. But that only affects the > base > > > > module, not any other modules. So if this is for a policy module > > > you've > > > > created, you should really look there to see what dontaudits are > in > > > the > > > > postprocessed file under the tmp directory. > > > > > > > > > Since the subject of dynamic transitions seems to raise much > angst > > > and > > > > > gnashing of teeth, I thought I'd ask if there is a better way to > > > solve > > > > > the problem that we have? I'm investigating dynamic transitions > for > > > the > > > > > following purpose. We have services that we run that take a long > > > time to > > > > > start up, too long to start them up on demand. We want to have a > > > pool of > > > > > them up and running, waiting to be tasked by a server. But we'll > be > > > > > running an MLS system with many compartments and possible > > > combinations > > > > > of compartments so it is not feasible to have services up and > > > running > > > > > for all the compartment combinations. The idea is to have a pool > of > > > > > services initialize at some default level, and then assign them > to > > > the > > > > > correct level/compartment when tasked. Upon completing a task, a > > > service > > > > > would shut down and a new service would be started to replace > it, at > > > the > > > > > default level. Two domains would be used. A service > initialization > > > > > domain, and a service running domain. The service initialization > > > domain > > > > > would have the capability of dynamic transitions. The service > > > running > > > > > domain would not. Therefore, when the service is tasked, it also > > > > > dynamically transitions to the correct level and to the service > > > running > > > > > domain. From that point on it no longer has the capability of > > > further > > > > > dynamic transitions. If there is a better way to solve this > problem, > > > I'd > > > > > like to know. > > > > > > > > exec based transitions are preferable as we can control the > > > inheritance > > > > of state across the transition and the initialization of the > process > > > in > > > > the new context, including binding entry into the context to a > > > specific > > > > executable. But it does carry an overhead, of course. > Refactoring > > > your > > > > service program may be possible, or maybe not. > > > > > > > > These kinds of questions are likely better suited to selinux list > > > rather > > > > than fedora selinux list, btw. Not really fedora specific. > > > > > > > > -- > > > > Stephen Smalley > > > > National Security Agency > > > > > > > > > > > > -- > > > 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 mike.clarkson at baesystems.com Wed Jan 9 19:09:58 2008 From: mike.clarkson at baesystems.com (Clarkson, Mike R (US SSA)) Date: Wed, 9 Jan 2008 11:09:58 -0800 Subject: two new questions (sort of) References: <1199827804.9393.202.camel@moss-spartans.epoch.ncsc.mil> <1199849650.6089.44.camel@localhost.localdomain> <1199902528.9393.287.camel@moss-spartans.epoch.ncsc.mil> Message-ID: > -----Original Message----- > From: Stephen Smalley [mailto:sds at tycho.nsa.gov] > Sent: Wednesday, January 09, 2008 10:15 AM > To: Clarkson, Mike R (US SSA) > Cc: Eric Paris; Daniel J Walsh; fedora-selinux-list at redhat.com > Subject: RE: two new questions (sort of) > > > On Wed, 2008-01-09 at 09:27 -0800, Clarkson, Mike R (US SSA) wrote: > > I'll file a bug. > > > > Here is what I did: > > > > # semodule -b /usr/share/selinux/mls/enableaudit.pp > > libsepol.scope_copy_callback: acct: Duplicate declaration in module: > > type/attribute acct_t > > libsemanage.semanage_link_sandbox: Link packages failed > > semodule: Failed! > > # semodule -r acct > > # semodule -b /usr/share/selinux/mls/enableaudit.pp > > libsepol.scope_copy_callback: aide: Duplicate declaration in module: > > type/attribute aide_t > > libsemanage.semanage_link_sandbox: Link packages failed > > semodule: Failed! > > That suggests that enableaudit.pp wasn't built the same way (or against > the same policy) as the policy you are using. Are you using a custom > policy or the RH-provided selinux-policy-mls? I thought I was using the RedHat provided mls policy. I downloaded the src from RedHat and built as a strict-mls policy. > > Also, I suspect that stripping dontaudits from your base module isn't > going to help you since you are talking about your own custom module for > your own application, right? So I'd start by looking at the > postprocessed module file for dontaudits and strip those by hand. Or > just build a modern selinux userland into a private directory, set PATH > and LD_LIBRARY_PATH to refer to it, and run the modern semodule -DB > command from it. > I think the only non-base module coming into play is my small setcontest module, and I didn't add any dontaudit statements it. I do call a number of interfaces that may add dontaudit statements but I think most/all of them are to base modules. By "postprocessed module file" do you mean the setcontest.pp file? This file doesn't appear to have any dontaudit statements in it, but aren't *.pp files binary? I wouldn't know how to strip out a dontaudit statement if I found one. I'm not sure what you mean by "build a modern selinux userland ...". > > > > > > > -----Original Message----- > > > From: Eric Paris [mailto:eparis at redhat.com] > > > Sent: Tuesday, January 08, 2008 7:34 PM > > > To: Clarkson, Mike R (US SSA) > > > Cc: Stephen Smalley; Daniel J Walsh; fedora-selinux-list at redhat.com > > > Subject: RE: two new questions (sort of) > > > > > > enableaudit.pp is a base module, are you using -i or -b to load it? > > If > > > you can't just semodule -b enableaudit.pp file a bug explaining what > > you > > > did and what went wrong (dan loves bugs, i heard him say it) > > > > > > -Eric > > > > > > On Tue, 2008-01-08 at 17:11 -0800, Clarkson, Mike R (US SSA) wrote: > > > > Thanks. I wasn't aware that all dontaudit rules could be disabled. > > > > > > > > It looks like RHEL5.1 doesn't have the -D option available for > > semodule, > > > > so I'm attempting to use the older method of loading enableaudit.pp. > > I > > > > keep getting duplicate declaration errors. It appears that to load > > > > enableaudit.pp, I first need to remove nearly all the non-base > > modules. > > > > Is there an easier method to do that other than either of the > > following? > > > > -using "semodule -i" and listing all the modules > > > > -changing each module to off in the modules.conf file > > > > > > > > Thanks > > > > > > > > > -----Original Message----- > > > > > From: Stephen Smalley [mailto:sds at tycho.nsa.gov] > > > > > Sent: Tuesday, January 08, 2008 1:30 PM > > > > > To: Clarkson, Mike R (US SSA) > > > > > Cc: fedora-selinux-list at redhat.com; Daniel J Walsh > > > > > Subject: Re: two new questions (sort of) > > > > > > > > > > > > > > > On Tue, 2008-01-08 at 12:53 -0800, Clarkson, Mike R (US SSA) > > wrote: > > > > > > I've been testing dynamic transitions with a simple test program > > > > that > > > > > > uses setcon to change from one mls level to another, as well as > > one > > > > > > domain to another. I wrote a policy for this test program and > > > > provided > > > > > > all the rules necessary to remove all of the avc denials from > > the > > > > audit > > > > > > log. When I run my program in permissive mode, it works as > > expected > > > > > > without adding any avc denial messages to the audit log. But > > when I > > > > > > switch to enforcing mode, the setcon call fails. Maybe there are > > > > some > > > > > > dontaudit statements that come with the policy causing this. I'm > > > > using > > > > > > RHEL5.1 with the mls policy.Any ideas as to what may be causing > > > > this? > > > > > > > > > > Try loading policy without any dontaudit rules and try again. > > > > > With modern userland, you can just do: > > > > > semodule -DB > > > > > to remove all dontaudits from policy and load it. semodule -B > > later > > > > > will revert the change. > > > > > > > > > > The old way before semodule -DB was to install enableaudit.pp (a > > base > > > > > module with dontaudits stripped at build time) > > > > > from /usr/share/selinux/$SELINUXTYPE. But that only affects the > > base > > > > > module, not any other modules. So if this is for a policy module > > > > you've > > > > > created, you should really look there to see what dontaudits are > > in > > > > the > > > > > postprocessed file under the tmp directory. > > > > > > > > > > > Since the subject of dynamic transitions seems to raise much > > angst > > > > and > > > > > > gnashing of teeth, I thought I'd ask if there is a better way to > > > > solve > > > > > > the problem that we have? I'm investigating dynamic transitions > > for > > > > the > > > > > > following purpose. We have services that we run that take a long > > > > time to > > > > > > start up, too long to start them up on demand. We want to have a > > > > pool of > > > > > > them up and running, waiting to be tasked by a server. But we'll > > be > > > > > > running an MLS system with many compartments and possible > > > > combinations > > > > > > of compartments so it is not feasible to have services up and > > > > running > > > > > > for all the compartment combinations. The idea is to have a pool > > of > > > > > > services initialize at some default level, and then assign them > > to > > > > the > > > > > > correct level/compartment when tasked. Upon completing a task, a > > > > service > > > > > > would shut down and a new service would be started to replace > > it, at > > > > the > > > > > > default level. Two domains would be used. A service > > initialization > > > > > > domain, and a service running domain. The service initialization > > > > domain > > > > > > would have the capability of dynamic transitions. The service > > > > running > > > > > > domain would not. Therefore, when the service is tasked, it also > > > > > > dynamically transitions to the correct level and to the service > > > > running > > > > > > domain. From that point on it no longer has the capability of > > > > further > > > > > > dynamic transitions. If there is a better way to solve this > > problem, > > > > I'd > > > > > > like to know. > > > > > > > > > > exec based transitions are preferable as we can control the > > > > inheritance > > > > > of state across the transition and the initialization of the > > process > > > > in > > > > > the new context, including binding entry into the context to a > > > > specific > > > > > executable. But it does carry an overhead, of course. > > Refactoring > > > > your > > > > > service program may be possible, or maybe not. > > > > > > > > > > These kinds of questions are likely better suited to selinux list > > > > rather > > > > > than fedora selinux list, btw. Not really fedora specific. > > > > > > > > > > -- > > > > > Stephen Smalley > > > > > National Security Agency > > > > > > > > > > > > > > > > -- > > > > 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 sds at tycho.nsa.gov Wed Jan 9 19:34:24 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 09 Jan 2008 14:34:24 -0500 Subject: two new questions (sort of) In-Reply-To: References: <1199827804.9393.202.camel@moss-spartans.epoch.ncsc.mil> <1199849650.6089.44.camel@localhost.localdomain> <1199902528.9393.287.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1199907264.9393.338.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-01-09 at 11:09 -0800, Clarkson, Mike R (US SSA) wrote: > > > -----Original Message----- > > From: Stephen Smalley [mailto:sds at tycho.nsa.gov] > > Sent: Wednesday, January 09, 2008 10:15 AM > > To: Clarkson, Mike R (US SSA) > > Cc: Eric Paris; Daniel J Walsh; fedora-selinux-list at redhat.com > > Subject: RE: two new questions (sort of) > > > > > > On Wed, 2008-01-09 at 09:27 -0800, Clarkson, Mike R (US SSA) wrote: > > > I'll file a bug. > > > > > > Here is what I did: > > > > > > # semodule -b /usr/share/selinux/mls/enableaudit.pp > > > libsepol.scope_copy_callback: acct: Duplicate declaration in module: > > > type/attribute acct_t > > > libsemanage.semanage_link_sandbox: Link packages failed > > > semodule: Failed! > > > # semodule -r acct > > > # semodule -b /usr/share/selinux/mls/enableaudit.pp > > > libsepol.scope_copy_callback: aide: Duplicate declaration in module: > > > type/attribute aide_t > > > libsemanage.semanage_link_sandbox: Link packages failed > > > semodule: Failed! > > > > That suggests that enableaudit.pp wasn't built the same way (or > against > > the same policy) as the policy you are using. Are you using a custom > > policy or the RH-provided selinux-policy-mls? > > I thought I was using the RedHat provided mls policy. I downloaded the > src from RedHat and built as a strict-mls policy. There should have already been a selinux-policy-mls binary rpm available that you could have used. If you rebuilt from source, you may have used a different modules.conf or build.conf settings, unless you just rebuild their src rpm as is via rpmbuild. > > > > Also, I suspect that stripping dontaudits from your base module isn't > > going to help you since you are talking about your own custom module > for > > your own application, right? So I'd start by looking at the > > postprocessed module file for dontaudits and strip those by hand. Or > > just build a modern selinux userland into a private directory, set > PATH > > and LD_LIBRARY_PATH to refer to it, and run the modern semodule -DB > > command from it. > > > > I think the only non-base module coming into play is my small setcontest > module, and I didn't add any dontaudit statements it. I do call a number > of interfaces that may add dontaudit statements but I think most/all of > them are to base modules. Interfaces are just m4 macros at present, so they get expanded into your module, not in the base. So any dontaudits they included would show up in your module after processing by m4. > By "postprocessed module file" do you mean the setcontest.pp file? This > file doesn't appear to have any dontaudit statements in it, but aren't > *.pp files binary? I wouldn't know how to strip out a dontaudit > statement if I found one. When you do a 'make -f /usr/share/selinux/devel/Makefile', it creates a tmp/ directory, processes your .te file, creating a postprocessed tmp/.tmp file. That's the real module content. Then that gets fed into checkmodule and that gets fed into semodule_package. So, for example, you might do the following to strip dontaudits from your module: cd tmp/ grep -v dontaudit setcontext.tmp > foo mv foo setcontext.tmp checkmodule -m -M -o setcontext.mod setcontext.tmp semodule_package -o setcontext.pp -m setcontext.mod -f setcontext.fc semodule -i setcontext.pp > I'm not sure what you mean by "build a modern selinux userland ...". Grab the sources of the current selinux userland (ones that support semodule -DB) and compile them? -- Stephen Smalley National Security Agency From dant at cdkkt.com Wed Jan 9 23:09:29 2008 From: dant at cdkkt.com (Dan Thurman) Date: Wed, 9 Jan 2008 15:09:29 -0800 Subject: ALSA problems. In-Reply-To: <021126B987E43D44A860139823C079110E2C57@ns1.cdkkt.com> References: <021126B987E43D44A860139823C079110E2C57@ns1.cdkkt.com> Message-ID: <200801091509.29422.dant@cdkkt.com> On Tuesday 08 January 2008 03:58:20 pm Daniel B. Thurman wrote: > Eric Paris wrote: > >what problems are you having, why do you believe this is an selinux > >issue, please, tell us what is happening, what you are seeing and > >provide output of errors?? If this is selinux you will find message in > >either /var/log/messages or /var/log/audit/audit.log which will be most > >interesting to the people on this list. > > > >-Eric > > > >>Daniel B. Thurman wrote: > >> I was forced to install ALSA manually in my F8 system and > > > >unfortunately, > > > >> I discovered that setting /.autorelabel did not correctly > > > >set ALSA permissions. > > > >> I did note that a bug report was filed for this. > >> > >> Meanwhile, I would like a solution to solve my issue, if > > > >there is one? > > > >> Kind regards, > >> Dan > > This is something I just found when searching the /var/log/message file > but this is not related to ALSA, but to rhgb: > Jan? 7 13:11:44 localhost kernel: audit(1199740241.970:9): avc:? denied? { > read write } for? pid=1775 comm="consoletype" path="/dev/pts/0" dev=devpts > ino=2 scontext=system_u:system_r:consoletype_t:s0 > tcontext=system_u:object_r:rhgb_devpts_t:s0 tclass=chr_file As for ALSA > issues, there was a problem writing to /etc/asound.state and to ~/.asoundrc > but this is not recorded where I can find it.? It only happens during > logoff/shutdown and I see it very briefly and it appears to be an 'alsactl > store' command failure and *maybe* the log below is related to it but I > cannot confirm it. > Jan? 8 12:28:30 gold kernel: audit(1199823854.622:4): avc:? denied? { > getattr } for? pid=1264 comm="salsa" path="/usr/share/alsa/alsa.conf" > dev=sda5 ino=147458 scontext=system_u:system_r:alsa_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:usr_t:s0 tclass=file I DO know that alsactl is > not able to set the volume control settings for which I am forced to reset > every time at login after a boot.? There was some months ago that Daniel > Walsh wrote as a bug report in getting the /etc/asound.state moved to > /var/lib directory and it was written on Sept 17, 2007. > Is there any resolution to this issue? Seems that no one is responding as to what I can to do try to analyze or to fix this issue? From maximilian_bianco at yahoo.com Thu Jan 10 03:20:30 2008 From: maximilian_bianco at yahoo.com (Mr.Scrooge) Date: Wed, 9 Jan 2008 19:20:30 -0800 (PST) Subject: ALSA problems. In-Reply-To: <200801091509.29422.dant@cdkkt.com> Message-ID: <323550.42431.qm@web62312.mail.re1.yahoo.com> --- Dan Thurman wrote: > On Tuesday 08 January 2008 03:58:20 pm Daniel B. Thurman wrote: > > Eric Paris wrote: > > >what problems are you having, why do you believe this is an selinux > > >issue, please, tell us what is happening, what you are seeing and > > >provide output of errors? If this is selinux you will find message in > > >either /var/log/messages or /var/log/audit/audit.log which will be most > > >interesting to the people on this list. > > > > > >-Eric > > > > > >>Daniel B. Thurman wrote: > > >> I was forced to install ALSA manually in my F8 system and > > > > > >unfortunately, > > > > > >> I discovered that setting /.autorelabel did not correctly > > > > > >set ALSA permissions. > > > > > >> I did note that a bug report was filed for this. > > >> > > >> Meanwhile, I would like a solution to solve my issue, if > > > > > >there is one? > > > > > >> Kind regards, > > >> Dan > > > > This is something I just found when searching the /var/log/message file > > but this is not related to ALSA, but to rhgb: > > Jan 7 13:11:44 localhost kernel: audit(1199740241.970:9): avc: denied { > > read write } for pid=1775 comm="consoletype" path="/dev/pts/0" dev=devpts > > ino=2 scontext=system_u:system_r:consoletype_t:s0 > > tcontext=system_u:object_r:rhgb_devpts_t:s0 tclass=chr_file As for ALSA > > issues, there was a problem writing to /etc/asound.state and to ~/.asoundrc > > but this is not recorded where I can find it. It only happens during > > logoff/shutdown and I see it very briefly and it appears to be an 'alsactl > > store' command failure and *maybe* the log below is related to it but I > > cannot confirm it. > > Jan 8 12:28:30 gold kernel: audit(1199823854.622:4): avc: denied { > > getattr } for pid=1264 comm="salsa" path="/usr/share/alsa/alsa.conf" > > dev=sda5 ino=147458 scontext=system_u:system_r:alsa_t:s0-s0:c0.c1023 > > tcontext=system_u:object_r:usr_t:s0 tclass=file I DO know that alsactl is > > not able to set the volume control settings for which I am forced to reset > > every time at login after a boot. There was some months ago that Daniel > > Walsh wrote as a bug report in getting the /etc/asound.state moved to > > /var/lib directory and it was written on Sept 17, 2007. > > > > Is there any resolution to this issue? Seems that no one is responding > as to what I can to do try to analyze or to fix this issue? > I am resisting the temptation to quote YODA! ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From dant at cdkkt.com Thu Jan 10 14:42:57 2008 From: dant at cdkkt.com (Dan Thurman) Date: Thu, 10 Jan 2008 06:42:57 -0800 Subject: [F8] ALSA problems. [SOLVED] In-Reply-To: <200801091509.29422.dant@cdkkt.com> References: <021126B987E43D44A860139823C079110E2C57@ns1.cdkkt.com> <200801091509.29422.dant@cdkkt.com> Message-ID: <200801100642.57441.dant@cdkkt.com> Problem solved. Solution was to remove all alsa packages using 'rpm -e --justdb --nodeps ', manually delete /etc/alsa and /usr/share/alsa. and then re-install the latest yum updates. Sorry for wasting your time. From selinux at gmail.com Thu Jan 10 15:41:09 2008 From: selinux at gmail.com (Tom London) Date: Thu, 10 Jan 2008 07:41:09 -0800 Subject: AVC generated from virtual terminal switch ('Ctl-Alt-F1/Ctl-Alt-F7') Message-ID: <4c4ba1530801100741l28a17026k661774c08dbf2366@mail.gmail.com> Running Rawhide, targeted enforcing. Booting into gdm/gnome, entering 'Ctl-Alt-F1' and logging in as the same user generates the following audit messages: type=USER_AUTH msg=audit(1199979217.226:28): user pid=2602 uid=0 auid=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct=tbl exe="/bin/login" (hostname=?, addr=?, terminal=tty1 res=failed)' type=USER_LOGIN msg=audit(1199979217.266:29): user pid=2602 uid=0 auid=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='uid=500: exe="/bin/login" (hostname=?, addr=?, terminal=tty1 res=failed)' type=USER_AUTH msg=audit(1199979226.383:30): user pid=2602 uid=0 auid=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct=tbl exe="/bin/login" (hostname=?, addr=?, terminal=tty1 res=failed)' type=USER_LOGIN msg=audit(1199979226.384:31): user pid=2602 uid=0 auid=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='uid=500: exe="/bin/login" (hostname=?, addr=?, terminal=tty1 res=failed)' type=USER_AUTH msg=audit(1199979234.098:32): user pid=2602 uid=0 auid=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct=tbl exe="/bin/login" (hostname=?, addr=?, terminal=tty1 res=success)' type=USER_ACCT msg=audit(1199979234.106:33): user pid=2602 uid=0 auid=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:accounting acct=tbl exe="/bin/login" (hostname=?, addr=?, terminal=tty1 res=success)' type=LOGIN msg=audit(1199979234.108:34): login pid=2602 uid=0 old auid=4294967295 new auid=500 type=USER_ROLE_CHANGE msg=audit(1199979234.130:35): user pid=2602 uid=0 auid=500 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0 selected-context=unconfined_u:unconfined_r:unconfined_t:s0: exe="/bin/login" (hostname=?, addr=?, terminal=tty1 res=success)' type=AVC msg=audit(1199979234.132:36): avc: denied { link } for pid=2602 comm="login" scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tclass=key type=SYSCALL msg=audit(1199979234.132:36): arch=40000003 syscall=288 success=no exit=-13 a0=8 a1=fffffffc a2=fffffffd a3=1f4 items=0 ppid=1 pid=2602 auid=500 uid=500 gid=500 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty1 comm="login" exe="/bin/login" subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 key=(null) type=USER_START msg=audit(1199979234.142:37): user pid=2602 uid=0 auid=500 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct=tbl exe="/bin/login" (hostname=?, addr=?, terminal=tty1 res=success)' type=CRED_ACQ msg=audit(1199979234.142:38): user pid=2602 uid=0 auid=500 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct=tbl exe="/bin/login" (hostname=?, addr=?, terminal=tty1 res=success)' type=USER_LOGIN msg=audit(1199979234.145:39): user pid=2602 uid=0 auid=500 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='uid=500: exe="/bin/login" (hostname=?, addr=?, terminal=tty1 res=success)' Putting system into permissive mode and retrying appears to generate no new AVCs. Does #============= local_login_t ============== allow local_login_t xdm_t:key link; make sense? tom -- Tom London From maximilian_bianco at yahoo.com Thu Jan 10 16:29:21 2008 From: maximilian_bianco at yahoo.com (Mr.Scrooge) Date: Thu, 10 Jan 2008 08:29:21 -0800 (PST) Subject: [F8] ALSA problems. [SOLVED] In-Reply-To: <200801100642.57441.dant@cdkkt.com> Message-ID: <446756.60214.qm@web62306.mail.re1.yahoo.com> --- Dan Thurman wrote: > > Problem solved. Solution was to remove all alsa packages > using 'rpm -e --justdb --nodeps ', manually > delete /etc/alsa and /usr/share/alsa. and then re-install the latest > yum updates. > > Sorry for wasting your time. I don't think there is anything to apologize for, after all that's what makes the list useful. It is a sounding board of sorts. After all no one is required to reply. Glad you got it working. -Max ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From selinux at gmail.com Thu Jan 10 18:52:05 2008 From: selinux at gmail.com (Tom London) Date: Thu, 10 Jan 2008 10:52:05 -0800 Subject: AVC generated from virtual terminal switch ('Ctl-Alt-F1/Ctl-Alt-F7') In-Reply-To: <4c4ba1530801100741l28a17026k661774c08dbf2366@mail.gmail.com> References: <4c4ba1530801100741l28a17026k661774c08dbf2366@mail.gmail.com> Message-ID: <4c4ba1530801101052s24eec606kd1763d1ce278fe14@mail.gmail.com> Sorry, missed this one: type=AVC msg=audit(1199980182.688:53): avc: denied { search } for pid=3671 comm="login" scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tclass=key type=SYSCALL msg=audit(1199980182.688:53): arch=40000003 syscall=288 success=yes exit=0 a0=3 a1=f315af4 a2=0 a3=1f4 items=0 ppid=1 pid=3671 auid=500 uid=0 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="login" exe="/bin/login" subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 key=(null) From dant at cdkkt.com Fri Jan 11 01:06:51 2008 From: dant at cdkkt.com (Dan Thurman) Date: Thu, 10 Jan 2008 17:06:51 -0800 Subject: Problem with samba mounts via fstab and credentials option In-Reply-To: <446756.60214.qm@web62306.mail.re1.yahoo.com> References: <446756.60214.qm@web62306.mail.re1.yahoo.com> Message-ID: <200801101706.51540.dant@cdkkt.com> When one adds a samba share via /etc/fstab and using as an entry: credentials=/etc/share/auth.smb in the options field This file contains sensitive username/password data, has a samba_etc_t type but on reboot, SELinux does not allow the mount.cifs program to read fstab entries containing the credentials mount options and produces an error 13 message during the loading of the services. The result is that the mount has failed and must be remounted manually as a root user after the system comes up. The logs show: type=AVC msg=audit(1200012700.796:14): avc: denied { read } for pid=2528 comm="mount.cifs" name="auth.smb" dev=sda5 ino=788340 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:samba_etc_t:s0 tclass=file Should I simply attempt to chcon -t mount_t /etc/samba.auth.smb or should this be handled differently? Thanks- Dan From dant at cdkkt.com Fri Jan 11 01:48:03 2008 From: dant at cdkkt.com (Dan Thurman) Date: Thu, 10 Jan 2008 17:48:03 -0800 Subject: Problem with samba mounts via fstab and credentials option In-Reply-To: <200801101706.51540.dant@cdkkt.com> References: <446756.60214.qm@web62306.mail.re1.yahoo.com> <200801101706.51540.dant@cdkkt.com> Message-ID: <200801101748.03053.dant@cdkkt.com> On Thursday 10 January 2008 05:06:51 pm Daniel B. Thurman wrote: > When one adds a samba share via /etc/fstab and using as an entry: > credentials=/etc/share/auth.smb in the options field > This file contains sensitive username/password data, has a samba_etc_t type > but on reboot, SELinux does not allow the mount.cifs program to read fstab > entries containing the credentials mount options and produces an error 13 > message during the loading of the services. The result is that the mount > has failed and must be remounted manually as a root user after the system > comes up. > The logs show: > type=AVC msg=audit(1200012700.796:14): avc:? denied? { read } for > pid=2528 comm="mount.cifs" name="auth.smb" dev=sda5 ino=788340 > scontext=system_u:system_r:mount_t:s0 > tcontext=system_u:object_r:samba_etc_t:s0 tclass=file > Should I simply attempt to chcon -t mount_t /etc/samba.auth.smb or should > this be handled differently? > Thanks- > Dan Oops. It should have said: /etc/samba/auth.smb From paul at city-fan.org Fri Jan 11 10:07:10 2008 From: paul at city-fan.org (Paul Howarth) Date: Fri, 11 Jan 2008 10:07:10 +0000 Subject: Problem with samba mounts via fstab and credentials option In-Reply-To: <200801101748.03053.dant@cdkkt.com> References: <446756.60214.qm@web62306.mail.re1.yahoo.com> <200801101706.51540.dant@cdkkt.com> <200801101748.03053.dant@cdkkt.com> Message-ID: <47873FCE.1070303@city-fan.org> Dan Thurman wrote: > On Thursday 10 January 2008 05:06:51 pm Daniel B. Thurman wrote: >> When one adds a samba share via /etc/fstab and using as an entry: >> credentials=/etc/share/auth.smb in the options field >> This file contains sensitive username/password data, has a samba_etc_t type >> but on reboot, SELinux does not allow the mount.cifs program to read fstab >> entries containing the credentials mount options and produces an error 13 >> message during the loading of the services. The result is that the mount >> has failed and must be remounted manually as a root user after the system >> comes up. >> The logs show: >> type=AVC msg=audit(1200012700.796:14): avc: denied { read } for >> pid=2528 comm="mount.cifs" name="auth.smb" dev=sda5 ino=788340 >> scontext=system_u:system_r:mount_t:s0 >> tcontext=system_u:object_r:samba_etc_t:s0 tclass=file >> Should I simply attempt to chcon -t mount_t /etc/samba.auth.smb or should >> this be handled differently? >> Thanks- >> Dan > > Oops. It should have said: /etc/samba/auth.smb Try setting the allow_mount_anyfile boolean. # setsebool -P allow_mount_anyfile 1 Paul. From cra at WPI.EDU Fri Jan 11 21:06:20 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 11 Jan 2008 16:06:20 -0500 Subject: audit log for "setenforce" changes? Message-ID: <20080111210620.GB29887@angus.ind.WPI.EDU> Is there any way to tell from the audit log or elsewhere when someone/something changed SELinux from enforcing to permissive or vice versa? From sds at tycho.nsa.gov Fri Jan 11 21:16:21 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 11 Jan 2008 16:16:21 -0500 Subject: audit log for "setenforce" changes? In-Reply-To: <20080111210620.GB29887@angus.ind.WPI.EDU> References: <20080111210620.GB29887@angus.ind.WPI.EDU> Message-ID: <1200086181.29816.100.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2008-01-11 at 16:06 -0500, Chuck Anderson wrote: > Is there any way to tell from the audit log or elsewhere when > someone/something changed SELinux from enforcing to permissive or vice > versa? Look for MAC_STATUS records in the audit log, e.g. /sbin/ausearch -m MAC_STATUS These include changes to enforcing mode, with the enforcing= and old_enforcing= values. -- Stephen Smalley National Security Agency From cra at WPI.EDU Fri Jan 11 22:10:33 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 11 Jan 2008 17:10:33 -0500 Subject: audit log for "setenforce" changes? In-Reply-To: <1200086181.29816.100.camel@moss-spartans.epoch.ncsc.mil> References: <20080111210620.GB29887@angus.ind.WPI.EDU> <1200086181.29816.100.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20080111221033.GC29887@angus.ind.WPI.EDU> On Fri, Jan 11, 2008 at 04:16:21PM -0500, Stephen Smalley wrote: > > On Fri, 2008-01-11 at 16:06 -0500, Chuck Anderson wrote: > > Is there any way to tell from the audit log or elsewhere when > > someone/something changed SELinux from enforcing to permissive or vice > > versa? > > Look for MAC_STATUS records in the audit log, e.g. > /sbin/ausearch -m MAC_STATUS > > These include changes to enforcing mode, with the enforcing= and > old_enforcing= values. This doesn't work apparently: #cat /etc/fedora-release Fedora release 8 (Werewolf) #ausearch -m MAC_STATUS #sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: permissive Mode from config file: enforcing Policy version: 21 Policy from config file: targeted #setenforce 1 #sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 21 Policy from config file: targeted [root at gkar 17:09:19 /var/log/audit]#ausearch -m MAC_STATUS #setenforce 0 #sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: permissive Mode from config file: enforcing Policy version: 21 Policy from config file: targeted #ausearch -m MAC_STATUS From eparis at redhat.com Sat Jan 12 13:37:04 2008 From: eparis at redhat.com (Eric Paris) Date: Sat, 12 Jan 2008 08:37:04 -0500 Subject: audit log for "setenforce" changes? In-Reply-To: <20080111221033.GC29887@angus.ind.WPI.EDU> References: <20080111210620.GB29887@angus.ind.WPI.EDU> <1200086181.29816.100.camel@moss-spartans.epoch.ncsc.mil> <20080111221033.GC29887@angus.ind.WPI.EDU> Message-ID: <1200145024.3282.2.camel@localhost.localdomain> On Fri, 2008-01-11 at 17:10 -0500, Chuck Anderson wrote: > On Fri, Jan 11, 2008 at 04:16:21PM -0500, Stephen Smalley wrote: > > > > On Fri, 2008-01-11 at 16:06 -0500, Chuck Anderson wrote: > > > Is there any way to tell from the audit log or elsewhere when > > > someone/something changed SELinux from enforcing to permissive or vice > > > versa? > > > > Look for MAC_STATUS records in the audit log, e.g. > > /sbin/ausearch -m MAC_STATUS > > > > These include changes to enforcing mode, with the enforcing= and > > old_enforcing= values. > > This doesn't work apparently: > > #cat /etc/fedora-release > Fedora release 8 (Werewolf) > > #ausearch -m MAC_STATUS > > #sestatus > SELinux status: enabled > SELinuxfs mount: /selinux > Current mode: permissive > Mode from config file: enforcing > Policy version: 21 > Policy from config file: targeted > #setenforce 1 > #sestatus > SELinux status: enabled > SELinuxfs mount: /selinux > Current mode: enforcing > Mode from config file: enforcing > Policy version: 21 > Policy from config file: targeted > [root at gkar 17:09:19 /var/log/audit]#ausearch -m MAC_STATUS > > #setenforce 0 > #sestatus > SELinux status: enabled > SELinuxfs mount: /selinux > Current mode: permissive > Mode from config file: enforcing > Policy version: 21 > Policy from config file: targeted > #ausearch -m MAC_STATUS > Do you have auditd running? If not look in dmesg or /var/log/messages instead of ausearch because it seems to be working fine for me.... [root at localhost ~]# cat /etc/fedora-release Fedora release 8 (Werewolf) [root at localhost ~]# setenforce 1 [root at localhost ~]# ausearch -m MAC_STATUS ---- time->Sat Jan 12 08:33:04 2008 type=SYSCALL msg=audit(1200144784.891:24): arch=40000003 syscall=4 success=yes exit=1 a0=3 a1=bf83f1e4 a2=1 a3=bf83f1e4 items=0 ppid=3155 pid=3394 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 comm="setenforce" exe="/usr/sbin/setenforce" subj=unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023 key=(null) type=MAC_STATUS msg=audit(1200144784.891:24): enforcing=0 old_enforcing=1 auid=500 ---- time->Sat Jan 12 08:33:39 2008 type=SYSCALL msg=audit(1200144819.882:26): arch=40000003 syscall=4 success=yes exit=1 a0=3 a1=bfb534f4 a2=1 a3=bfb534f4 items=0 ppid=3155 pid=3399 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 comm="setenforce" exe="/usr/sbin/setenforce" subj=unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023 key=(null) type=MAC_STATUS msg=audit(1200144819.882:26): enforcing=1 old_enforcing=0 auid=500 [root at localhost ~]# From choeger at cs.tu-berlin.de Mon Jan 14 10:32:04 2008 From: choeger at cs.tu-berlin.de (=?ISO-8859-15?Q?Christoph_H=F6ger?=) Date: Mon, 14 Jan 2008 11:32:04 +0100 Subject: Is 'search' on home_root_t always bad? Message-ID: <478B3A24.8060309@cs.tu-berlin.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, currently I encounter a denial for openvpn which tries to "search" home_root_t. Is that generally a bad idea (and openvpn should be fixed) or should it be allowed? regards christoph -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHizokhMBO4cVSGS8RAks+AKCcEkPPdz76HvYj/4IQoDcX1ZRaGQCgnhVP BaGsILyaQZcZ+pF9TbYTdc8= =blai -----END PGP SIGNATURE----- From paul at city-fan.org Mon Jan 14 15:41:16 2008 From: paul at city-fan.org (Paul Howarth) Date: Mon, 14 Jan 2008 15:41:16 +0000 Subject: Sendmail milters in Fedora 8 In-Reply-To: <477BC440.9000809@city-fan.org> References: <477BC440.9000809@city-fan.org> Message-ID: <478B829C.1090606@city-fan.org> Paul Howarth wrote: > Since upgrading my mail server from Fedora 7 to Fedora 8, I've come > across some problems with the sockets used for communication between > sendmail and two of the "milter" plugins I'm using with it, namely > milter-regex and spamass-milter. It's very likely that other milters > will have similar issues. > > The sockets used are created when the milter starts, as follows: > > milter-regex: > /var/spool/milter-regex/sock (var_spool_t, inherited from parent directory) > > spamass-milter: > /var/run/spamass-milter/spamass-milter.sock (spamd_var_run_t, in policy) > > These are pretty well the upstream locations, though I'm open to moving > the milter-regex socket from /var/spool to /var/run or elsewhere for > consistency. > > Since moving to Fedora 8, I've had to add the following to local policy > to get these milters working: > > allow sendmail_t spamd_var_run_t:dir { search getattr }; > allow sendmail_t spamd_var_run_t:sock_file { getattr write }; > allow sendmail_t var_spool_t:sock_file { getattr write }; > allow sendmail_t initrc_t:unix_stream_socket { read write connectto }; > > The last of these is the strangest, and relates to Bug #425958 > (https://bugzilla.redhat.com/show_bug.cgi?id=425958). Whilst the socket > file itself has the context listed above, the unix domain socket that > sendmail connects to is still initrc_t, as can be seen from the output > of "netstat -lpZ": > > ... > unix 2 [ ACC ] STREAM LISTENING 14142 > 5853/spamass-milter system_u:system_r:initrc_t:s0 > /var/run/spamass-milter/spamass-milter.sock > unix 2 [ ACC ] STREAM LISTENING 13794 > 5779/milter-regex system_u:system_r:initrc_t:s0 > /var/spool/milter-regex/sock > ... > > So, my questions are: > > 1. Why are the sockets still initrc_t? > 2. Is this a kernel issue or a userspace issue that should be fixed in > the milters? > 3. Should there be a standard place for milter sockets to live, and if > so, where? > 4. How come this worked OK in Fedora 7 and previous releases? Looking at the source code for these applications, I see that both of them use the smfi_setconn() function in the sendmail milter library to set up the sockets. It's therefore likely that this problem is common to all milter applications that use unix domain sockets. I'm now of the opinion that moving the directory locations for these sockets is a bad idea - it would need corresponding changes in people's sendmail configuration files, which would lead to problems for people doing package updates, or installing from upstream sources. Setting different context types for the directories (e.g. make /var/spool/milter-regex spamd_var_run_t) would seem a better option, along with policy tweaks to allow sendmail to do the permissions checks and write to the sockets). I'm still confused about the initrc_t sockets though. Paul. From dwalsh at redhat.com Mon Jan 14 15:43:41 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 14 Jan 2008 10:43:41 -0500 Subject: AVC generated from virtual terminal switch ('Ctl-Alt-F1/Ctl-Alt-F7') In-Reply-To: <4c4ba1530801100741l28a17026k661774c08dbf2366@mail.gmail.com> References: <4c4ba1530801100741l28a17026k661774c08dbf2366@mail.gmail.com> Message-ID: <478B832D.3040409@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom London wrote: > Running Rawhide, targeted enforcing. > > Booting into gdm/gnome, entering 'Ctl-Alt-F1' and logging in as the > same user generates the following audit messages: > > type=USER_AUTH msg=audit(1199979217.226:28): user pid=2602 uid=0 > auid=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 > msg='op=PAM:authentication acct=tbl exe="/bin/login" (hostname=?, > addr=?, terminal=tty1 res=failed)' > type=USER_LOGIN msg=audit(1199979217.266:29): user pid=2602 uid=0 > auid=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 > msg='uid=500: exe="/bin/login" (hostname=?, addr=?, terminal=tty1 > res=failed)' > type=USER_AUTH msg=audit(1199979226.383:30): user pid=2602 uid=0 > auid=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 > msg='op=PAM:authentication acct=tbl exe="/bin/login" (hostname=?, > addr=?, terminal=tty1 res=failed)' > type=USER_LOGIN msg=audit(1199979226.384:31): user pid=2602 uid=0 > auid=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 > msg='uid=500: exe="/bin/login" (hostname=?, addr=?, terminal=tty1 > res=failed)' > type=USER_AUTH msg=audit(1199979234.098:32): user pid=2602 uid=0 > auid=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 > msg='op=PAM:authentication acct=tbl exe="/bin/login" (hostname=?, > addr=?, terminal=tty1 res=success)' > type=USER_ACCT msg=audit(1199979234.106:33): user pid=2602 uid=0 > auid=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 > msg='op=PAM:accounting acct=tbl exe="/bin/login" (hostname=?, addr=?, > terminal=tty1 res=success)' > type=LOGIN msg=audit(1199979234.108:34): login pid=2602 uid=0 old > auid=4294967295 new auid=500 > type=USER_ROLE_CHANGE msg=audit(1199979234.130:35): user pid=2602 > uid=0 auid=500 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 > msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0 > selected-context=unconfined_u:unconfined_r:unconfined_t:s0: > exe="/bin/login" (hostname=?, addr=?, terminal=tty1 res=success)' > type=AVC msg=audit(1199979234.132:36): avc: denied { link } for > pid=2602 comm="login" > scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 > tcontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tclass=key > type=SYSCALL msg=audit(1199979234.132:36): arch=40000003 syscall=288 > success=no exit=-13 a0=8 a1=fffffffc a2=fffffffd a3=1f4 items=0 ppid=1 > pid=2602 auid=500 uid=500 gid=500 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 tty=tty1 comm="login" exe="/bin/login" > subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 key=(null) > type=USER_START msg=audit(1199979234.142:37): user pid=2602 uid=0 > auid=500 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 > msg='op=PAM:session_open acct=tbl exe="/bin/login" (hostname=?, > addr=?, terminal=tty1 res=success)' > type=CRED_ACQ msg=audit(1199979234.142:38): user pid=2602 uid=0 > auid=500 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 > msg='op=PAM:setcred acct=tbl exe="/bin/login" (hostname=?, addr=?, > terminal=tty1 res=success)' > type=USER_LOGIN msg=audit(1199979234.145:39): user pid=2602 uid=0 > auid=500 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 > msg='uid=500: exe="/bin/login" (hostname=?, addr=?, terminal=tty1 > res=success)' > > Putting system into permissive mode and retrying appears to generate > no new AVCs. > > Does > > #============= local_login_t ============== > allow local_login_t xdm_t:key link; > > make sense? > > tom This is caused by a bad gdm pam file. You pam file should look something like. #%PAM-1.0 auth [success=done ignore=ignore default=bad] pam_selinux_permit.so auth required pam_env.so auth substack system-auth auth optional pam_gnome_keyring.so account required pam_nologin.so account include system-auth password include system-auth session required pam_selinux.so close session required pam_loginuid.so session optional pam_console.so session required pam_selinux.so open session optional pam_keyinit.so force revoke session required pam_namespace.so session optional pam_gnome_keyring.so auto_start session include system-auth pam_keyinit.so has to happen after pam_selinux. This will create a keyring labeled unconfined_t or xguest_t which other domains would have access to. A keyring labeled after a login program makes no sense. I just updated gdm in rawhide to have this pam file. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeLgy0ACgkQrlYvE4MpobM2mACeKqtd04BdHEaD8276ZBJAfBYg nkYAn3pYgd42m198kVQdvhzUs7WUpuh1 =ECHH -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Jan 14 15:52:06 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 14 Jan 2008 10:52:06 -0500 Subject: Is 'search' on home_root_t always bad? In-Reply-To: <478B3A24.8060309@cs.tu-berlin.de> References: <478B3A24.8060309@cs.tu-berlin.de> Message-ID: <478B8526.2080601@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christoph H?ger wrote: > Hi, > > currently I encounter a denial for openvpn which tries to "search" > home_root_t. Is that generally a bad idea (and openvpn should be fixed) > or should it be allowed? > > regards > > christoph - -- fedora-selinux-list mailing list fedora-selinux-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list home_root_t is the label of /home and potentially other parent directory of user homedirectories. So if I had my homedirs in /users/dwalsh /users would be labeled home_root_t and /users/dwalsh would be labeled user_home_dir_t. So searching of the home_root_t usually means that a domain is trying to look at something in the home directory. If a domain has no reason to look in the home directory, this could indicate a problem. If I was a cracker and I broken into your machine, I would want to attack home directories to grab secrets like stored password and credit card data. Now that being said, it is fairly easy to generate this type of avc. When you start up a daemon, it often checs out it's current working directory, So if you su to root and then "service openvpn restart" you could generate this avc. Also openvpn might have a legitimate reason to read the users homedir, and we don't allow it in policy, which could be a bug. Dan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeLhSYACgkQrlYvE4MpobPJyACdGB8r+kAkpdtncpn/Hvaltw8Q N7EAoIoQPbbzcMvhFEJ6ShSrOTaCypF0 =LMrI -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Jan 14 17:00:01 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 14 Jan 2008 12:00:01 -0500 Subject: Sendmail milters in Fedora 8 In-Reply-To: <478B829C.1090606@city-fan.org> References: <477BC440.9000809@city-fan.org> <478B829C.1090606@city-fan.org> Message-ID: <478B9511.20006@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Howarth wrote: > Paul Howarth wrote: >> Since upgrading my mail server from Fedora 7 to Fedora 8, I've come >> across some problems with the sockets used for communication between >> sendmail and two of the "milter" plugins I'm using with it, namely >> milter-regex and spamass-milter. It's very likely that other milters >> will have similar issues. >> >> The sockets used are created when the milter starts, as follows: >> >> milter-regex: >> /var/spool/milter-regex/sock (var_spool_t, inherited from parent >> directory) >> >> spamass-milter: >> /var/run/spamass-milter/spamass-milter.sock (spamd_var_run_t, in policy) >> >> These are pretty well the upstream locations, though I'm open to >> moving the milter-regex socket from /var/spool to /var/run or >> elsewhere for consistency. >> >> Since moving to Fedora 8, I've had to add the following to local >> policy to get these milters working: >> >> allow sendmail_t spamd_var_run_t:dir { search getattr }; >> allow sendmail_t spamd_var_run_t:sock_file { getattr write }; >> allow sendmail_t var_spool_t:sock_file { getattr write }; >> allow sendmail_t initrc_t:unix_stream_socket { read write connectto }; >> >> The last of these is the strangest, and relates to Bug #425958 >> (https://bugzilla.redhat.com/show_bug.cgi?id=425958). Whilst the >> socket file itself has the context listed above, the unix domain >> socket that sendmail connects to is still initrc_t, as can be seen >> from the output of "netstat -lpZ": >> >> ... >> unix 2 [ ACC ] STREAM LISTENING 14142 >> 5853/spamass-milter system_u:system_r:initrc_t:s0 >> /var/run/spamass-milter/spamass-milter.sock >> unix 2 [ ACC ] STREAM LISTENING 13794 >> 5779/milter-regex system_u:system_r:initrc_t:s0 >> /var/spool/milter-regex/sock >> ... >> >> So, my questions are: >> >> 1. Why are the sockets still initrc_t? >> 2. Is this a kernel issue or a userspace issue that should be fixed in >> the milters? >> 3. Should there be a standard place for milter sockets to live, and if >> so, where? >> 4. How come this worked OK in Fedora 7 and previous releases? > > Looking at the source code for these applications, I see that both of > them use the smfi_setconn() function in the sendmail milter library to > set up the sockets. It's therefore likely that this problem is common to > all milter applications that use unix domain sockets. > > I'm now of the opinion that moving the directory locations for these > sockets is a bad idea - it would need corresponding changes in people's > sendmail configuration files, which would lead to problems for people > doing package updates, or installing from upstream sources. Setting > different context types for the directories (e.g. make > /var/spool/milter-regex spamd_var_run_t) would seem a better option, > along with policy tweaks to allow sendmail to do the permissions checks > and write to the sockets). > > I'm still confused about the initrc_t sockets though. > > Paul. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Ok I will add this to the next update. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeLlRAACgkQrlYvE4MpobO1HwCfQsrNCtXCrE9dgvUmZ8bNhqPQ QTAAoI9sc5n1v1qfQNPJlRDuc5DgSKO0 =qCWL -----END PGP SIGNATURE----- From paul at city-fan.org Mon Jan 14 17:11:02 2008 From: paul at city-fan.org (Paul Howarth) Date: Mon, 14 Jan 2008 17:11:02 +0000 Subject: Sendmail milters in Fedora 8 In-Reply-To: <478B9511.20006@redhat.com> References: <477BC440.9000809@city-fan.org> <478B829C.1090606@city-fan.org> <478B9511.20006@redhat.com> Message-ID: <478B97A6.9050002@city-fan.org> Hi Dan, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Paul Howarth wrote: >> Paul Howarth wrote: >>> Since upgrading my mail server from Fedora 7 to Fedora 8, I've come >>> across some problems with the sockets used for communication between >>> sendmail and two of the "milter" plugins I'm using with it, namely >>> milter-regex and spamass-milter. It's very likely that other milters >>> will have similar issues. >>> >>> The sockets used are created when the milter starts, as follows: >>> >>> milter-regex: >>> /var/spool/milter-regex/sock (var_spool_t, inherited from parent >>> directory) >>> >>> spamass-milter: >>> /var/run/spamass-milter/spamass-milter.sock (spamd_var_run_t, in policy) >>> >>> These are pretty well the upstream locations, though I'm open to >>> moving the milter-regex socket from /var/spool to /var/run or >>> elsewhere for consistency. >>> >>> Since moving to Fedora 8, I've had to add the following to local >>> policy to get these milters working: >>> >>> allow sendmail_t spamd_var_run_t:dir { search getattr }; >>> allow sendmail_t spamd_var_run_t:sock_file { getattr write }; >>> allow sendmail_t var_spool_t:sock_file { getattr write }; >>> allow sendmail_t initrc_t:unix_stream_socket { read write connectto }; >>> >>> The last of these is the strangest, and relates to Bug #425958 >>> (https://bugzilla.redhat.com/show_bug.cgi?id=425958). Whilst the >>> socket file itself has the context listed above, the unix domain >>> socket that sendmail connects to is still initrc_t, as can be seen >>> from the output of "netstat -lpZ": >>> >>> ... >>> unix 2 [ ACC ] STREAM LISTENING 14142 >>> 5853/spamass-milter system_u:system_r:initrc_t:s0 >>> /var/run/spamass-milter/spamass-milter.sock >>> unix 2 [ ACC ] STREAM LISTENING 13794 >>> 5779/milter-regex system_u:system_r:initrc_t:s0 >>> /var/spool/milter-regex/sock >>> ... >>> >>> So, my questions are: >>> >>> 1. Why are the sockets still initrc_t? >>> 2. Is this a kernel issue or a userspace issue that should be fixed in >>> the milters? >>> 3. Should there be a standard place for milter sockets to live, and if >>> so, where? >>> 4. How come this worked OK in Fedora 7 and previous releases? >> Looking at the source code for these applications, I see that both of >> them use the smfi_setconn() function in the sendmail milter library to >> set up the sockets. It's therefore likely that this problem is common to >> all milter applications that use unix domain sockets. >> >> I'm now of the opinion that moving the directory locations for these >> sockets is a bad idea - it would need corresponding changes in people's >> sendmail configuration files, which would lead to problems for people >> doing package updates, or installing from upstream sources. Setting >> different context types for the directories (e.g. make >> /var/spool/milter-regex spamd_var_run_t) would seem a better option, >> along with policy tweaks to allow sendmail to do the permissions checks >> and write to the sockets). >> >> I'm still confused about the initrc_t sockets though. >> >> Paul. >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Ok I will add this to the next update. What exactly is "this"? The 4 "allow" rules mentioned above, the context type change for /var/spool/milter-regex mentioned later, both? Cheers, Paul. From dwalsh at redhat.com Mon Jan 14 17:24:19 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 14 Jan 2008 12:24:19 -0500 Subject: Sendmail milters in Fedora 8 In-Reply-To: <478B97A6.9050002@city-fan.org> References: <477BC440.9000809@city-fan.org> <478B829C.1090606@city-fan.org> <478B9511.20006@redhat.com> <478B97A6.9050002@city-fan.org> Message-ID: <478B9AC3.9040500@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Howarth wrote: > Hi Dan, > > Daniel J Walsh wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Paul Howarth wrote: >>> Paul Howarth wrote: >>>> Since upgrading my mail server from Fedora 7 to Fedora 8, I've come >>>> across some problems with the sockets used for communication between >>>> sendmail and two of the "milter" plugins I'm using with it, namely >>>> milter-regex and spamass-milter. It's very likely that other milters >>>> will have similar issues. >>>> >>>> The sockets used are created when the milter starts, as follows: >>>> >>>> milter-regex: >>>> /var/spool/milter-regex/sock (var_spool_t, inherited from parent >>>> directory) >>>> >>>> spamass-milter: >>>> /var/run/spamass-milter/spamass-milter.sock (spamd_var_run_t, in >>>> policy) >>>> >>>> These are pretty well the upstream locations, though I'm open to >>>> moving the milter-regex socket from /var/spool to /var/run or >>>> elsewhere for consistency. >>>> >>>> Since moving to Fedora 8, I've had to add the following to local >>>> policy to get these milters working: >>>> >>>> allow sendmail_t spamd_var_run_t:dir { search getattr }; >>>> allow sendmail_t spamd_var_run_t:sock_file { getattr write }; >>>> allow sendmail_t var_spool_t:sock_file { getattr write }; >>>> allow sendmail_t initrc_t:unix_stream_socket { read write connectto }; >>>> >>>> The last of these is the strangest, and relates to Bug #425958 >>>> (https://bugzilla.redhat.com/show_bug.cgi?id=425958). Whilst the >>>> socket file itself has the context listed above, the unix domain >>>> socket that sendmail connects to is still initrc_t, as can be seen >>>> from the output of "netstat -lpZ": >>>> >>>> ... >>>> unix 2 [ ACC ] STREAM LISTENING 14142 >>>> 5853/spamass-milter system_u:system_r:initrc_t:s0 >>>> /var/run/spamass-milter/spamass-milter.sock >>>> unix 2 [ ACC ] STREAM LISTENING 13794 >>>> 5779/milter-regex system_u:system_r:initrc_t:s0 >>>> /var/spool/milter-regex/sock >>>> ... >>>> >>>> So, my questions are: >>>> >>>> 1. Why are the sockets still initrc_t? >>>> 2. Is this a kernel issue or a userspace issue that should be fixed in >>>> the milters? >>>> 3. Should there be a standard place for milter sockets to live, and if >>>> so, where? >>>> 4. How come this worked OK in Fedora 7 and previous releases? >>> Looking at the source code for these applications, I see that both of >>> them use the smfi_setconn() function in the sendmail milter library to >>> set up the sockets. It's therefore likely that this problem is common to >>> all milter applications that use unix domain sockets. >>> >>> I'm now of the opinion that moving the directory locations for these >>> sockets is a bad idea - it would need corresponding changes in people's >>> sendmail configuration files, which would lead to problems for people >>> doing package updates, or installing from upstream sources. Setting >>> different context types for the directories (e.g. make >>> /var/spool/milter-regex spamd_var_run_t) would seem a better option, >>> along with policy tweaks to allow sendmail to do the permissions checks >>> and write to the sockets). >>> >>> I'm still confused about the initrc_t sockets though. >>> >>> Paul. >>> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> Ok I will add this to the next update. > > What exactly is "this"? The 4 "allow" rules mentioned above, the context > type change for /var/spool/milter-regex mentioned later, both? > > Cheers, Paul. > Context change for /var/spool/milter-regex to spamd_var_run_t. sendmail can already use sockets in this directory. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeLmsMACgkQrlYvE4MpobNpdQCguag0iZ0TXGz1INdHVRz4tTSg yt4AoMTm7FchzGNMFJwGLBa74vmnqadk =n0Jd -----END PGP SIGNATURE----- From paul at city-fan.org Mon Jan 14 17:29:54 2008 From: paul at city-fan.org (Paul Howarth) Date: Mon, 14 Jan 2008 17:29:54 +0000 Subject: Sendmail milters in Fedora 8 In-Reply-To: <478B9AC3.9040500@redhat.com> References: <477BC440.9000809@city-fan.org> <478B829C.1090606@city-fan.org> <478B9511.20006@redhat.com> <478B97A6.9050002@city-fan.org> <478B9AC3.9040500@redhat.com> Message-ID: <478B9C12.9000909@city-fan.org> Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Paul Howarth wrote: >> Hi Dan, >> >> Daniel J Walsh wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Paul Howarth wrote: >>>> Paul Howarth wrote: >>>>> Since upgrading my mail server from Fedora 7 to Fedora 8, I've come >>>>> across some problems with the sockets used for communication between >>>>> sendmail and two of the "milter" plugins I'm using with it, namely >>>>> milter-regex and spamass-milter. It's very likely that other milters >>>>> will have similar issues. >>>>> >>>>> The sockets used are created when the milter starts, as follows: >>>>> >>>>> milter-regex: >>>>> /var/spool/milter-regex/sock (var_spool_t, inherited from parent >>>>> directory) >>>>> >>>>> spamass-milter: >>>>> /var/run/spamass-milter/spamass-milter.sock (spamd_var_run_t, in >>>>> policy) >>>>> >>>>> These are pretty well the upstream locations, though I'm open to >>>>> moving the milter-regex socket from /var/spool to /var/run or >>>>> elsewhere for consistency. >>>>> >>>>> Since moving to Fedora 8, I've had to add the following to local >>>>> policy to get these milters working: >>>>> >>>>> allow sendmail_t spamd_var_run_t:dir { search getattr }; >>>>> allow sendmail_t spamd_var_run_t:sock_file { getattr write }; >>>>> allow sendmail_t var_spool_t:sock_file { getattr write }; >>>>> allow sendmail_t initrc_t:unix_stream_socket { read write connectto }; >>>>> >>>>> The last of these is the strangest, and relates to Bug #425958 >>>>> (https://bugzilla.redhat.com/show_bug.cgi?id=425958). Whilst the >>>>> socket file itself has the context listed above, the unix domain >>>>> socket that sendmail connects to is still initrc_t, as can be seen >>>>> from the output of "netstat -lpZ": >>>>> >>>>> ... >>>>> unix 2 [ ACC ] STREAM LISTENING 14142 >>>>> 5853/spamass-milter system_u:system_r:initrc_t:s0 >>>>> /var/run/spamass-milter/spamass-milter.sock >>>>> unix 2 [ ACC ] STREAM LISTENING 13794 >>>>> 5779/milter-regex system_u:system_r:initrc_t:s0 >>>>> /var/spool/milter-regex/sock >>>>> ... >>>>> >>>>> So, my questions are: >>>>> >>>>> 1. Why are the sockets still initrc_t? >>>>> 2. Is this a kernel issue or a userspace issue that should be fixed in >>>>> the milters? >>>>> 3. Should there be a standard place for milter sockets to live, and if >>>>> so, where? >>>>> 4. How come this worked OK in Fedora 7 and previous releases? >>>> Looking at the source code for these applications, I see that both of >>>> them use the smfi_setconn() function in the sendmail milter library to >>>> set up the sockets. It's therefore likely that this problem is common to >>>> all milter applications that use unix domain sockets. >>>> >>>> I'm now of the opinion that moving the directory locations for these >>>> sockets is a bad idea - it would need corresponding changes in people's >>>> sendmail configuration files, which would lead to problems for people >>>> doing package updates, or installing from upstream sources. Setting >>>> different context types for the directories (e.g. make >>>> /var/spool/milter-regex spamd_var_run_t) would seem a better option, >>>> along with policy tweaks to allow sendmail to do the permissions checks >>>> and write to the sockets). >>>> >>>> I'm still confused about the initrc_t sockets though. >>>> >>>> Paul. >>>> >>>> -- >>>> fedora-selinux-list mailing list >>>> fedora-selinux-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>> Ok I will add this to the next update. >> What exactly is "this"? The 4 "allow" rules mentioned above, the context >> type change for /var/spool/milter-regex mentioned later, both? >> >> Cheers, Paul. >> > Context change for /var/spool/milter-regex to spamd_var_run_t. sendmail > can already use sockets in this directory. So that includes the: allow sendmail_t initrc_t:unix_stream_socket { read write connectto } ? Cheers, Paul. From cra at WPI.EDU Mon Jan 14 17:35:32 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 14 Jan 2008 12:35:32 -0500 Subject: audit log for "setenforce" changes? In-Reply-To: <1200145024.3282.2.camel@localhost.localdomain> References: <20080111210620.GB29887@angus.ind.WPI.EDU> <1200086181.29816.100.camel@moss-spartans.epoch.ncsc.mil> <20080111221033.GC29887@angus.ind.WPI.EDU> <1200145024.3282.2.camel@localhost.localdomain> Message-ID: <20080114173532.GA32031@angus.ind.WPI.EDU> On Sat, Jan 12, 2008 at 08:37:04AM -0500, Eric Paris wrote: > Do you have auditd running? If not look in dmesg or /var/log/messages > instead of ausearch because it seems to be working fine for me.... Yes, I do have auditd running. #service auditd status auditd (pid 2523) is running... #service rsyslog status rsyslogd (pid 19658) is running... rklogd (pid 19664) is running... #ausearch -m MAC_STATUS #setenforce 0 #ausearch -m MAC_STATUS #setenforce 1 #ausearch -m MAC_STATUS #setenforce 0 #ausearch -m MAC_STATUS #grep setenforce /var/log/messages #grep setenforce /var/log/syslog #grep setenforce /var/log/secure #dmesg|grep setenforce From eparis at redhat.com Mon Jan 14 17:46:52 2008 From: eparis at redhat.com (Eric Paris) Date: Mon, 14 Jan 2008 12:46:52 -0500 Subject: audit log for "setenforce" changes? In-Reply-To: <20080114173532.GA32031@angus.ind.WPI.EDU> References: <20080111210620.GB29887@angus.ind.WPI.EDU> <1200086181.29816.100.camel@moss-spartans.epoch.ncsc.mil> <20080111221033.GC29887@angus.ind.WPI.EDU> <1200145024.3282.2.camel@localhost.localdomain> <20080114173532.GA32031@angus.ind.WPI.EDU> Message-ID: <1200332812.2761.5.camel@localhost.localdomain> hmmm, are you getting any audit messages? Maybe a long time back your ran out of disk space and auditd stopped logging? If you service auditd restart and it can't log for some reason it should tell you in /var/log/messages... maybe auditd is turned off? what do you get from auditctl -s ?? is it enabled? maybe you ran auditctl -e 0 at some time? assuming audit isn't running the message in dmesg looks like: type=1404 audit(1200447974.622:247): enforcing=0 old_enforcing=1 auid=4294967295 ses=4294967295 and the corresponding /var/log/messages: Jan 15 20:46:14 dhcp231-146 kernel: type=1404 audit(1200447974.622:247): enforcing=0 old_enforcing=1 auid=4294967295 ses=4294967295 start telling me about all of your versions, are they all stock or did you build some of these parts yourself. Because I can't find a way to reproduce the problem to fix it.... -Eric On Mon, 2008-01-14 at 12:35 -0500, Chuck Anderson wrote: > On Sat, Jan 12, 2008 at 08:37:04AM -0500, Eric Paris wrote: > > Do you have auditd running? If not look in dmesg or /var/log/messages > > instead of ausearch because it seems to be working fine for me.... > > Yes, I do have auditd running. > > #service auditd status > auditd (pid 2523) is running... > #service rsyslog status > rsyslogd (pid 19658) is running... > rklogd (pid 19664) is running... > #ausearch -m MAC_STATUS > > #setenforce 0 > #ausearch -m MAC_STATUS > > #setenforce 1 > #ausearch -m MAC_STATUS > > #setenforce 0 > #ausearch -m MAC_STATUS > > #grep setenforce /var/log/messages > #grep setenforce /var/log/syslog > #grep setenforce /var/log/secure > #dmesg|grep setenforce > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From sds at tycho.nsa.gov Mon Jan 14 17:48:33 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 14 Jan 2008 12:48:33 -0500 Subject: audit log for "setenforce" changes? In-Reply-To: <20080114173532.GA32031@angus.ind.WPI.EDU> References: <20080111210620.GB29887@angus.ind.WPI.EDU> <1200086181.29816.100.camel@moss-spartans.epoch.ncsc.mil> <20080111221033.GC29887@angus.ind.WPI.EDU> <1200145024.3282.2.camel@localhost.localdomain> <20080114173532.GA32031@angus.ind.WPI.EDU> Message-ID: <1200332913.22505.31.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2008-01-14 at 12:35 -0500, Chuck Anderson wrote: > On Sat, Jan 12, 2008 at 08:37:04AM -0500, Eric Paris wrote: > > Do you have auditd running? If not look in dmesg or /var/log/messages > > instead of ausearch because it seems to be working fine for me.... > > Yes, I do have auditd running. > > #service auditd status > auditd (pid 2523) is running... > #service rsyslog status > rsyslogd (pid 19658) is running... > rklogd (pid 19664) is running... > #ausearch -m MAC_STATUS > > #setenforce 0 > #ausearch -m MAC_STATUS > > #setenforce 1 > #ausearch -m MAC_STATUS > > #setenforce 0 > #ausearch -m MAC_STATUS > > #grep setenforce /var/log/messages > #grep setenforce /var/log/syslog > #grep setenforce /var/log/secure > #dmesg|grep setenforce kernel version? audit version? -- Stephen Smalley National Security Agency From cra at WPI.EDU Mon Jan 14 18:31:55 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 14 Jan 2008 13:31:55 -0500 Subject: audit log for "setenforce" changes? In-Reply-To: <1200332812.2761.5.camel@localhost.localdomain> References: <20080111210620.GB29887@angus.ind.WPI.EDU> <1200086181.29816.100.camel@moss-spartans.epoch.ncsc.mil> <20080111221033.GC29887@angus.ind.WPI.EDU> <1200145024.3282.2.camel@localhost.localdomain> <20080114173532.GA32031@angus.ind.WPI.EDU> <1200332812.2761.5.camel@localhost.localdomain> Message-ID: <20080114183155.GA32604@angus.ind.WPI.EDU> On Mon, Jan 14, 2008 at 12:46:52PM -0500, Eric Paris wrote: > hmmm, are you getting any audit messages? It appears that the last message I got was on Dec 12: #ausearch -m AVC -i | tail -1 type=AVC msg=audit(12/12/2007 06:05:58.434:68533739) : avc: denied { getattr } for pid=31687 comm=named path=/var/log/named/queries dev=dm-3 ino=10944781 scontext=system_u:system_r:named_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file > Maybe a long time back your > ran out of disk space and auditd stopped logging? I don't think I ran out of space: #df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/VolGroup00-root 39G 301M 37G 1% / /dev/sda2 494M 32M 438M 7% /boot tmpfs 1.5G 0 1.5G 0% /dev/shm /dev/mapper/VolGroup00-home 97G 9.3G 83G 11% /home /dev/mapper/VolGroup00-usr 97G 1.3G 91G 2% /usr /dev/mapper/VolGroup00-var 97G 15G 78G 16% /var > If you service auditd > restart and it can't log for some reason it should tell you > in /var/log/messages... > > maybe auditd is turned off? what do you get from auditctl -s ?? is it > enabled? maybe you ran auditctl -e 0 at some time? #auditctl -s AUDIT_STATUS: enabled=1 flag=1 pid=2523 rate_limit=0 backlog_limit=256 lost=0 backlog=0 > assuming audit isn't running the message in dmesg looks like: > type=1404 audit(1200447974.622:247): enforcing=0 old_enforcing=1 > auid=4294967295 ses=4294967295 > > and the corresponding /var/log/messages: > Jan 15 20:46:14 dhcp231-146 kernel: type=1404 audit(1200447974.622:247): > enforcing=0 old_enforcing=1 auid=4294967295 ses=4294967295 #grep enforcing /var/log/messages #dmesg | grep enforcing Ok, I restarted auditd: #service auditd restart Stopping auditd: [ OK ] Starting auditd: [ OK ] #ausearch -m AVC -i | tail -1 type=AVC msg=audit(01/14/2008 13:25:32.903:137848459) : avc: denied { getattr } for pid=31227 comm=radiusd path=/var/log/radius/radius.log dev=dm-3 ino=10944744 scontext=unconfined_u:system_r:radiusd_t:s0 tcontext=system_u:object_r:user_home_t:s0 tclass=file > start telling me about all of your versions, are they all stock or did > you build some of these parts yourself. Because I can't find a way to > reproduce the problem to fix it.... Stock Fedora 8 with updates: #uname -r ; rpm -q kernel audit selinux-policy selinux-policy-targeted setools policycoreutils 2.6.23.8-63.fc8 kernel-2.6.23.8-63.fc8 kernel-2.6.23.9-85.fc8 audit-1.6.2-4.fc8 selinux-policy-3.0.8-73.fc8 selinux-policy-targeted-3.0.8-73.fc8 setools-3.3.1-7.fc8 policycoreutils-2.0.33-2.fc8 policycoreutils-2.0.33-3.fc8 Here is what updated on Dec 12 when the audit logging stopped: Dec 12 05:59:52 Updated: yum - 3.2.8-2.fc8.noarch Dec 12 06:05:20 Updated: cyrus-sasl-lib - 2.1.22-8.fc8.i386 Dec 12 06:05:20 Updated: libsepol - 2.0.15-1.fc8.i386 Dec 12 06:05:20 Updated: libsemanage - 2.0.12-2.fc8.i386 Dec 12 06:05:21 Updated: policycoreutils - 2.0.32-2.fc8.i386 Dec 12 06:05:23 Updated: samba-common - 3.0.28-0.fc8.i386 Dec 12 06:05:23 Updated: cyrus-sasl-md5 - 2.1.22-8.fc8.i386 Dec 12 06:05:23 Updated: cyrus-sasl-plain - 2.1.22-8.fc8.i386 Dec 12 06:05:24 Updated: samba-client - 3.0.28-0.fc8.i386 Dec 12 06:05:24 Updated: cyrus-sasl - 2.1.22-8.fc8.i386 Dec 12 06:05:25 Updated: selinux-policy - 3.0.8-64.fc8.noarch Dec 12 06:06:05 Updated: selinux-policy-targeted - 3.0.8-64.fc8.noarch I wonder if this is when it somehow got flipped back to enforcing=1 since I had been running with a manual "setenforce 0" since November. From eparis at redhat.com Mon Jan 14 18:42:48 2008 From: eparis at redhat.com (Eric Paris) Date: Mon, 14 Jan 2008 13:42:48 -0500 Subject: audit log for "setenforce" changes? In-Reply-To: <20080114183155.GA32604@angus.ind.WPI.EDU> References: <20080111210620.GB29887@angus.ind.WPI.EDU> <1200086181.29816.100.camel@moss-spartans.epoch.ncsc.mil> <20080111221033.GC29887@angus.ind.WPI.EDU> <1200145024.3282.2.camel@localhost.localdomain> <20080114173532.GA32031@angus.ind.WPI.EDU> <1200332812.2761.5.camel@localhost.localdomain> <20080114183155.GA32604@angus.ind.WPI.EDU> Message-ID: <1200336168.2761.7.camel@localhost.localdomain> On Mon, 2008-01-14 at 13:31 -0500, Chuck Anderson wrote: > On Mon, Jan 14, 2008 at 12:46:52PM -0500, Eric Paris wrote: > > hmmm, are you getting any audit messages? > > It appears that the last message I got was on Dec 12: > > #ausearch -m AVC -i | tail -1 > type=AVC msg=audit(12/12/2007 06:05:58.434:68533739) : avc: denied { > getattr } for pid=31687 comm=named path=/var/log/named/queries > dev=dm-3 ino=10944781 scontext=system_u:system_r:named_t:s0 > tcontext=system_u:object_r:var_log_t:s0 tclass=file > > > > Maybe a long time back your > > ran out of disk space and auditd stopped logging? > > I don't think I ran out of space: > > #df -h > Filesystem Size Used Avail Use% Mounted on > /dev/mapper/VolGroup00-root > 39G 301M 37G 1% / > /dev/sda2 494M 32M 438M 7% /boot > tmpfs 1.5G 0 1.5G 0% /dev/shm > /dev/mapper/VolGroup00-home > 97G 9.3G 83G 11% /home > /dev/mapper/VolGroup00-usr > 97G 1.3G 91G 2% /usr > /dev/mapper/VolGroup00-var > 97G 15G 78G 16% /var > > > If you service auditd > > restart and it can't log for some reason it should tell you > > in /var/log/messages... > > > > maybe auditd is turned off? what do you get from auditctl -s ?? is it > > enabled? maybe you ran auditctl -e 0 at some time? > > #auditctl -s > AUDIT_STATUS: enabled=1 flag=1 pid=2523 rate_limit=0 backlog_limit=256 > lost=0 backlog=0 > > > assuming audit isn't running the message in dmesg looks like: > > type=1404 audit(1200447974.622:247): enforcing=0 old_enforcing=1 > > auid=4294967295 ses=4294967295 > > > > and the corresponding /var/log/messages: > > Jan 15 20:46:14 dhcp231-146 kernel: type=1404 audit(1200447974.622:247): > > enforcing=0 old_enforcing=1 auid=4294967295 ses=4294967295 > > #grep enforcing /var/log/messages > #dmesg | grep enforcing > > Ok, I restarted auditd: > > #service auditd restart > Stopping auditd: [ OK ] > Starting auditd: [ OK ] > #ausearch -m AVC -i | tail -1 > type=AVC msg=audit(01/14/2008 13:25:32.903:137848459) : avc: denied > { getattr } for pid=31227 comm=radiusd > path=/var/log/radius/radius.log dev=dm-3 ino=10944744 > scontext=unconfined_u:system_r:radiusd_t:s0 > tcontext=system_u:object_r:user_home_t:s0 tclass=file > > > start telling me about all of your versions, are they all stock or did > > you build some of these parts yourself. Because I can't find a way to > > reproduce the problem to fix it.... > > Stock Fedora 8 with updates: > > #uname -r ; rpm -q kernel audit selinux-policy selinux-policy-targeted setools policycoreutils > 2.6.23.8-63.fc8 > kernel-2.6.23.8-63.fc8 > kernel-2.6.23.9-85.fc8 > audit-1.6.2-4.fc8 > selinux-policy-3.0.8-73.fc8 > selinux-policy-targeted-3.0.8-73.fc8 > setools-3.3.1-7.fc8 > policycoreutils-2.0.33-2.fc8 > policycoreutils-2.0.33-3.fc8 > > Here is what updated on Dec 12 when the audit logging stopped: > > Dec 12 05:59:52 Updated: yum - 3.2.8-2.fc8.noarch > Dec 12 06:05:20 Updated: cyrus-sasl-lib - 2.1.22-8.fc8.i386 > Dec 12 06:05:20 Updated: libsepol - 2.0.15-1.fc8.i386 > Dec 12 06:05:20 Updated: libsemanage - 2.0.12-2.fc8.i386 > Dec 12 06:05:21 Updated: policycoreutils - 2.0.32-2.fc8.i386 > Dec 12 06:05:23 Updated: samba-common - 3.0.28-0.fc8.i386 > Dec 12 06:05:23 Updated: cyrus-sasl-md5 - 2.1.22-8.fc8.i386 > Dec 12 06:05:23 Updated: cyrus-sasl-plain - 2.1.22-8.fc8.i386 > Dec 12 06:05:24 Updated: samba-client - 3.0.28-0.fc8.i386 > Dec 12 06:05:24 Updated: cyrus-sasl - 2.1.22-8.fc8.i386 > Dec 12 06:05:25 Updated: selinux-policy - 3.0.8-64.fc8.noarch > Dec 12 06:06:05 Updated: selinux-policy-targeted - 3.0.8-64.fc8.noarch > > I wonder if this is when it somehow got flipped back to enforcing=1 > since I had been running with a manual "setenforce 0" since November Maybe on policy reload it read /etc/selinux/config and pulled that setting? Anyway, you have some serious labeling issue there in /var... try restorecon -R /var -Eric From sds at tycho.nsa.gov Mon Jan 14 18:46:17 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 14 Jan 2008 13:46:17 -0500 Subject: audit log for "setenforce" changes? In-Reply-To: <1200336168.2761.7.camel@localhost.localdomain> References: <20080111210620.GB29887@angus.ind.WPI.EDU> <1200086181.29816.100.camel@moss-spartans.epoch.ncsc.mil> <20080111221033.GC29887@angus.ind.WPI.EDU> <1200145024.3282.2.camel@localhost.localdomain> <20080114173532.GA32031@angus.ind.WPI.EDU> <1200332812.2761.5.camel@localhost.localdomain> <20080114183155.GA32604@angus.ind.WPI.EDU> <1200336168.2761.7.camel@localhost.localdomain> Message-ID: <1200336377.22505.53.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2008-01-14 at 13:42 -0500, Eric Paris wrote: > On Mon, 2008-01-14 at 13:31 -0500, Chuck Anderson wrote: > > On Mon, Jan 14, 2008 at 12:46:52PM -0500, Eric Paris wrote: > > > hmmm, are you getting any audit messages? > > > > It appears that the last message I got was on Dec 12: > > > > #ausearch -m AVC -i | tail -1 > > type=AVC msg=audit(12/12/2007 06:05:58.434:68533739) : avc: denied { > > getattr } for pid=31687 comm=named path=/var/log/named/queries > > dev=dm-3 ino=10944781 scontext=system_u:system_r:named_t:s0 > > tcontext=system_u:object_r:var_log_t:s0 tclass=file > > > > > > > Maybe a long time back your > > > ran out of disk space and auditd stopped logging? > > > > I don't think I ran out of space: > > > > #df -h > > Filesystem Size Used Avail Use% Mounted on > > /dev/mapper/VolGroup00-root > > 39G 301M 37G 1% / > > /dev/sda2 494M 32M 438M 7% /boot > > tmpfs 1.5G 0 1.5G 0% /dev/shm > > /dev/mapper/VolGroup00-home > > 97G 9.3G 83G 11% /home > > /dev/mapper/VolGroup00-usr > > 97G 1.3G 91G 2% /usr > > /dev/mapper/VolGroup00-var > > 97G 15G 78G 16% /var > > > > > If you service auditd > > > restart and it can't log for some reason it should tell you > > > in /var/log/messages... > > > > > > maybe auditd is turned off? what do you get from auditctl -s ?? is it > > > enabled? maybe you ran auditctl -e 0 at some time? > > > > #auditctl -s > > AUDIT_STATUS: enabled=1 flag=1 pid=2523 rate_limit=0 backlog_limit=256 > > lost=0 backlog=0 > > > > > assuming audit isn't running the message in dmesg looks like: > > > type=1404 audit(1200447974.622:247): enforcing=0 old_enforcing=1 > > > auid=4294967295 ses=4294967295 > > > > > > and the corresponding /var/log/messages: > > > Jan 15 20:46:14 dhcp231-146 kernel: type=1404 audit(1200447974.622:247): > > > enforcing=0 old_enforcing=1 auid=4294967295 ses=4294967295 > > > > #grep enforcing /var/log/messages > > #dmesg | grep enforcing > > > > Ok, I restarted auditd: > > > > #service auditd restart > > Stopping auditd: [ OK ] > > Starting auditd: [ OK ] > > #ausearch -m AVC -i | tail -1 > > type=AVC msg=audit(01/14/2008 13:25:32.903:137848459) : avc: denied > > { getattr } for pid=31227 comm=radiusd > > path=/var/log/radius/radius.log dev=dm-3 ino=10944744 > > scontext=unconfined_u:system_r:radiusd_t:s0 > > tcontext=system_u:object_r:user_home_t:s0 tclass=file > > > > > start telling me about all of your versions, are they all stock or did > > > you build some of these parts yourself. Because I can't find a way to > > > reproduce the problem to fix it.... > > > > Stock Fedora 8 with updates: > > > > #uname -r ; rpm -q kernel audit selinux-policy selinux-policy-targeted setools policycoreutils > > 2.6.23.8-63.fc8 > > kernel-2.6.23.8-63.fc8 > > kernel-2.6.23.9-85.fc8 > > audit-1.6.2-4.fc8 > > selinux-policy-3.0.8-73.fc8 > > selinux-policy-targeted-3.0.8-73.fc8 > > setools-3.3.1-7.fc8 > > policycoreutils-2.0.33-2.fc8 > > policycoreutils-2.0.33-3.fc8 > > > > Here is what updated on Dec 12 when the audit logging stopped: > > > > Dec 12 05:59:52 Updated: yum - 3.2.8-2.fc8.noarch > > Dec 12 06:05:20 Updated: cyrus-sasl-lib - 2.1.22-8.fc8.i386 > > Dec 12 06:05:20 Updated: libsepol - 2.0.15-1.fc8.i386 > > Dec 12 06:05:20 Updated: libsemanage - 2.0.12-2.fc8.i386 > > Dec 12 06:05:21 Updated: policycoreutils - 2.0.32-2.fc8.i386 > > Dec 12 06:05:23 Updated: samba-common - 3.0.28-0.fc8.i386 > > Dec 12 06:05:23 Updated: cyrus-sasl-md5 - 2.1.22-8.fc8.i386 > > Dec 12 06:05:23 Updated: cyrus-sasl-plain - 2.1.22-8.fc8.i386 > > Dec 12 06:05:24 Updated: samba-client - 3.0.28-0.fc8.i386 > > Dec 12 06:05:24 Updated: cyrus-sasl - 2.1.22-8.fc8.i386 > > Dec 12 06:05:25 Updated: selinux-policy - 3.0.8-64.fc8.noarch > > Dec 12 06:06:05 Updated: selinux-policy-targeted - 3.0.8-64.fc8.noarch > > > > I wonder if this is when it somehow got flipped back to enforcing=1 > > since I had been running with a manual "setenforce 0" since November > > Maybe on policy reload it read /etc/selinux/config and pulled that > setting? load_policy doesn't touch the enforcing status. > Anyway, you have some serious labeling issue there in /var... > > try restorecon -R /var -- Stephen Smalley National Security Agency From cra at WPI.EDU Mon Jan 14 19:23:32 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 14 Jan 2008 14:23:32 -0500 Subject: audit log for "setenforce" changes? In-Reply-To: <1200336377.22505.53.camel@moss-spartans.epoch.ncsc.mil> References: <20080111210620.GB29887@angus.ind.WPI.EDU> <1200086181.29816.100.camel@moss-spartans.epoch.ncsc.mil> <20080111221033.GC29887@angus.ind.WPI.EDU> <1200145024.3282.2.camel@localhost.localdomain> <20080114173532.GA32031@angus.ind.WPI.EDU> <1200332812.2761.5.camel@localhost.localdomain> <20080114183155.GA32604@angus.ind.WPI.EDU> <1200336168.2761.7.camel@localhost.localdomain> <1200336377.22505.53.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20080114192332.GA882@angus.ind.WPI.EDU> On Mon, Jan 14, 2008 at 01:46:17PM -0500, Stephen Smalley wrote: > load_policy doesn't touch the enforcing status. > > > Anyway, you have some serious labeling issue there in /var... > > > > try restorecon -R /var The labelleing issues I would (perhaps incorrectly) expect from running SELinux in permissive mode. I decided to relabel and reboot into enforcing mode. What a disaster. The system couldn't boot enough to run the "fixfiles restore" from /etc/rc.sysinit, not even in single user mode. I had to eventually boot into single user mode with the selinux=0 kernel parameter and run "fixfiles restore" manully. Then I discovered that somehow a bunch of bogus "unconfined" entries had appeared in /etc/selinux/targeted/contexts/files/file_contexts.homedirs: # # # User-specific file contexts, generated via libsemanage # use semanage command to manage system users to change the file_context # # # # Home Context for user unconfined_u # /etc/[^/]*/.+ unconfined_u:object_r:unconfined_home_t:s0 /etc/[^/]*/.gnome2(/.*)? unconfined_u:object_r:unconfined_gnome_home_t:s0 /etc/[^/]*/.*/plugins/nprhapengine\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 /etc/[^/]*/.*/plugins/libflashplayer\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 /etc/[^/]*/((www)|(web)|(public_html))(/.+)? unconfined_u:object_r:httpd_unconfined_content_t:s0 /etc/[^/]*/\.java(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 /etc/[^/]*/\.galeon(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 /etc/[^/]*/\.mozilla(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 /etc/[^/]*/\.phoenix(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 /etc/[^/]*/\.mozilla(/.*)?/plugins/libflashplayer\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 /etc/[^/]*/\.netscape(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 /etc/[^/]*/\.gstreamer-.*/[^/]*\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 /etc/[^/]*/\.config/gtk-.* unconfined_u:object_r:unconfined_gnome_home_t:s0 /etc/[^/]* -d unconfined_u:object_r:unconfined_home_dir_t:s0 /etc/[^/]* -l unconfined_u:object_r:unconfined_home_dir_t:s0 /etc/lost\+found/.* <> /etc -d system_u:object_r:home_root_t:s0 /etc/\.journal <> /etc/lost\+found -d system_u:object_r:lost_found_t:s0 # # Home Context for user unconfined_u # /home/[^/]*/.+ unconfined_u:object_r:unconfined_home_t:s0 /home/[^/]*/.gnome2(/.*)? unconfined_u:object_r:unconfined_gnome_home_t:s0 /home/[^/]*/.*/plugins/nprhapengine\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 /home/[^/]*/.*/plugins/libflashplayer\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 /home/[^/]*/((www)|(web)|(public_html))(/.+)? unconfined_u:object_r:httpd_unconfined_content_t:s0 /home/[^/]*/\.java(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 /home/[^/]*/\.galeon(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 /home/[^/]*/\.mozilla(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 /home/[^/]*/\.phoenix(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 /home/[^/]*/\.mozilla(/.*)?/plugins/libflashplayer\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 /home/[^/]*/\.netscape(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 /home/[^/]*/\.gstreamer-.*/[^/]*\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 /home/[^/]*/\.config/gtk-.* unconfined_u:object_r:unconfined_gnome_home_t:s0 /home/[^/]* -d unconfined_u:object_r:unconfined_home_dir_t:s0 /home/[^/]* -l unconfined_u:object_r:unconfined_home_dir_t:s0 /home/lost\+found/.* <> /home -d system_u:object_r:home_root_t:s0 /home/\.journal <> /home/lost\+found -d system_u:object_r:lost_found_t:s0 # # Home Context for user unconfined_u # /opt/[^/]*/.+ unconfined_u:object_r:unconfined_home_t:s0 /opt/[^/]*/.gnome2(/.*)? unconfined_u:object_r:unconfined_gnome_home_t:s0 /opt/[^/]*/.*/plugins/nprhapengine\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 /opt/[^/]*/.*/plugins/libflashplayer\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 /opt/[^/]*/((www)|(web)|(public_html))(/.+)? unconfined_u:object_r:httpd_unconfined_content_t:s0 /opt/[^/]*/\.java(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 /opt/[^/]*/\.galeon(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 /opt/[^/]*/\.mozilla(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 /opt/[^/]*/\.phoenix(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 /opt/[^/]*/\.mozilla(/.*)?/plugins/libflashplayer\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 /opt/[^/]*/\.netscape(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 /opt/[^/]*/\.gstreamer-.*/[^/]*\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 /opt/[^/]*/\.config/gtk-.* unconfined_u:object_r:unconfined_gnome_home_t:s0 /opt/[^/]* -d unconfined_u:object_r:unconfined_home_dir_t:s0 /opt/[^/]* -l unconfined_u:object_r:unconfined_home_dir_t:s0 /opt/lost\+found/.* <> /opt -d system_u:object_r:home_root_t:s0 /opt/\.journal <> /opt/lost\+found -d system_u:object_r:lost_found_t:s0 # # Home Context for user unconfined_u # /usr/libexec/[^/]*/.+ unconfined_u:object_r:unconfined_home_t:s0 /usr/libexec/[^/]*/.gnome2(/.*)? unconfined_u:object_r:unconfined_gnome_home_t:s0 /usr/libexec/[^/]*/.*/plugins/nprhapengine\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 /usr/libexec/[^/]*/.*/plugins/libflashplayer\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 /usr/libexec/[^/]*/((www)|(web)|(public_html))(/.+)? unconfined_u:object_r:httpd_unconfined_content_t:s0 /usr/libexec/[^/]*/\.java(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 /usr/libexec/[^/]*/\.galeon(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 /usr/libexec/[^/]*/\.mozilla(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 /usr/libexec/[^/]*/\.phoenix(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 /usr/libexec/[^/]*/\.mozilla(/.*)?/plugins/libflashplayer\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 /usr/libexec/[^/]*/\.netscape(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 /usr/libexec/[^/]*/\.gstreamer-.*/[^/]*\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 /usr/libexec/[^/]*/\.config/gtk-.* unconfined_u:object_r:unconfined_gnome_home_t:s0 /usr/libexec/[^/]* -d unconfined_u:object_r:unconfined_home_dir_t:s0 /usr/libexec/[^/]* -l unconfined_u:object_r:unconfined_home_dir_t:s0 /usr/libexec/lost\+found/.* <> /usr/libexec -d system_u:object_r:home_root_t:s0 /usr/libexec/\.journal <> /usr/libexec/lost\+found -d system_u:object_r:lost_found_t:s0 # # Home Context for user unconfined_u # /var/log/[^/]*/.+ unconfined_u:object_r:unconfined_home_t:s0 /var/log/[^/]*/.gnome2(/.*)? unconfined_u:object_r:unconfined_gnome_home_t:s0 /var/log/[^/]*/.*/plugins/nprhapengine\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 /var/log/[^/]*/.*/plugins/libflashplayer\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 /var/log/[^/]*/((www)|(web)|(public_html))(/.+)? unconfined_u:object_r:httpd_unconfined_content_t:s0 /var/log/[^/]*/\.java(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 /var/log/[^/]*/\.galeon(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 /var/log/[^/]*/\.mozilla(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 /var/log/[^/]*/\.phoenix(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 /var/log/[^/]*/\.mozilla(/.*)?/plugins/libflashplayer\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 /var/log/[^/]*/\.netscape(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 /var/log/[^/]*/\.gstreamer-.*/[^/]*\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 /var/log/[^/]*/\.config/gtk-.* unconfined_u:object_r:unconfined_gnome_home_t:s0 /var/log/[^/]* -d unconfined_u:object_r:unconfined_home_dir_t:s0 /var/log/[^/]* -l unconfined_u:object_r:unconfined_home_dir_t:s0 /var/log/lost\+found/.* <> /var/log -d system_u:object_r:home_root_t:s0 /var/log/\.journal <> /var/log/lost\+found -d system_u:object_r:lost_found_t:s0 /tmp/gconfd-.* -d unconfined_u:object_r:unconfined_tmp_t:s0 # # Home Context for user root # /root/.+ root:object_r:sysadm_home_t:s0 /root/.gnome2(/.*)? root:object_r:sysadm_gnome_home_t:s0 /root/.*/plugins/nprhapengine\.so.* -- root:object_r:textrel_shlib_t:s0 /root/.*/plugins/libflashplayer\.so.* -- root:object_r:textrel_shlib_t:s0 /root/((www)|(web)|(public_html))(/.+)? root:object_r:httpd_sysadm_content_t:s0 /root/\.ssh(/.*)? root:object_r:sysadm_home_ssh_t:s0 /root/\.uml(/.*)? root:object_r:sysadm_uml_rw_t:s0 /root/\.java(/.*)? root:object_r:sysadm_mozilla_home_t:s0 /root/\.xauth.* -- root:object_r:sysadm_xauth_home_t:s0 /root/\.fonts(/.*)? root:object_r:sysadm_fonts_t:s0 /root/\.pyzor(/.*)? root:object_r:sysadm_pyzor_home_t:s0 /root/\.razor(/.*)? root:object_r:sysadm_razor_home_t:s0 /root/vmware(/.*)? root:object_r:sysadm_vmware_file_t:s0 /root/\.galeon(/.*)? root:object_r:sysadm_mozilla_home_t:s0 /root/\.vmware(/.*)? root:object_r:sysadm_vmware_file_t:s0 /root/\.vmware[^/]*/.*\.cfg -- root:object_r:sysadm_vmware_conf_t:s0 /root/\.mozilla(/.*)? root:object_r:sysadm_mozilla_home_t:s0 /root/\.phoenix(/.*)? root:object_r:sysadm_mozilla_home_t:s0 /root/\.mplayer(/.*)? root:object_r:sysadm_mplayer_home_t:s0 /root/\.mozilla(/.*)?/plugins/libflashplayer\.so.* -- root:object_r:textrel_shlib_t:s0 /root/\.ethereal(/.*)? root:object_r:sysadm_ethereal_home_t:s0 /root/\.netscape(/.*)? root:object_r:sysadm_mozilla_home_t:s0 /root/\.Xauthority.* -- root:object_r:sysadm_xauth_home_t:s0 /root/\.fonts/auto(/.*)? root:object_r:sysadm_fonts_cache_t:s0 /root/\.gstreamer-.*/[^/]*\.so.* -- root:object_r:textrel_shlib_t:s0 /root/\.config/gtk-.* root:object_r:sysadm_gnome_home_t:s0 /root/\.fonts\.cache-.* -- root:object_r:sysadm_fonts_cache_t:s0 /root/\.ICEauthority.* -- root:object_r:sysadm_iceauth_home_t:s0 /root/\.spamassassin(/.*)? root:object_r:sysadm_spamassassin_home_t:s0 /root -d root:object_r:sysadm_home_dir_t:s0 /root -l root:object_r:sysadm_home_dir_t:s0 /root/\.ircmotd -- root:object_r:sysadm_irc_home_t:s0 /root/\.screenrc -- root:object_r:sysadm_screen_ro_home_t:s0 /root/\.fonts\.conf -- root:object_r:sysadm_fonts_config_t:s0 /tmp/gconfd-root -d root:object_r:sysadm_tmp_t:s0 I deleted all the sections head up with "Home Context for user unconfined_u" then re-ran "fixfiles restore". The conclusion I draw is that running SELinux in permissive mode for an extended period of time isn't well supported at all, and shouldn't be recommended ever. Perhaps more testing should go into running a system in permissive mode while yum updates apply selinux packages, etc. to find these types of issues. From dwalsh at redhat.com Mon Jan 14 19:31:05 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 14 Jan 2008 14:31:05 -0500 Subject: Sendmail milters in Fedora 8 In-Reply-To: <478B9C12.9000909@city-fan.org> References: <477BC440.9000809@city-fan.org> <478B829C.1090606@city-fan.org> <478B9511.20006@redhat.com> <478B97A6.9050002@city-fan.org> <478B9AC3.9040500@redhat.com> <478B9C12.9000909@city-fan.org> Message-ID: <478BB879.2050604@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Howarth wrote: > Daniel J Walsh wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Paul Howarth wrote: >>> Hi Dan, >>> >>> Daniel J Walsh wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Paul Howarth wrote: >>>>> Paul Howarth wrote: >>>>>> Since upgrading my mail server from Fedora 7 to Fedora 8, I've come >>>>>> across some problems with the sockets used for communication between >>>>>> sendmail and two of the "milter" plugins I'm using with it, namely >>>>>> milter-regex and spamass-milter. It's very likely that other milters >>>>>> will have similar issues. >>>>>> >>>>>> The sockets used are created when the milter starts, as follows: >>>>>> >>>>>> milter-regex: >>>>>> /var/spool/milter-regex/sock (var_spool_t, inherited from parent >>>>>> directory) >>>>>> >>>>>> spamass-milter: >>>>>> /var/run/spamass-milter/spamass-milter.sock (spamd_var_run_t, in >>>>>> policy) >>>>>> >>>>>> These are pretty well the upstream locations, though I'm open to >>>>>> moving the milter-regex socket from /var/spool to /var/run or >>>>>> elsewhere for consistency. >>>>>> >>>>>> Since moving to Fedora 8, I've had to add the following to local >>>>>> policy to get these milters working: >>>>>> >>>>>> allow sendmail_t spamd_var_run_t:dir { search getattr }; >>>>>> allow sendmail_t spamd_var_run_t:sock_file { getattr write }; >>>>>> allow sendmail_t var_spool_t:sock_file { getattr write }; >>>>>> allow sendmail_t initrc_t:unix_stream_socket { read write >>>>>> connectto }; >>>>>> >>>>>> The last of these is the strangest, and relates to Bug #425958 >>>>>> (https://bugzilla.redhat.com/show_bug.cgi?id=425958). Whilst the >>>>>> socket file itself has the context listed above, the unix domain >>>>>> socket that sendmail connects to is still initrc_t, as can be seen >>>>>> from the output of "netstat -lpZ": >>>>>> >>>>>> ... >>>>>> unix 2 [ ACC ] STREAM LISTENING 14142 >>>>>> 5853/spamass-milter system_u:system_r:initrc_t:s0 >>>>>> /var/run/spamass-milter/spamass-milter.sock >>>>>> unix 2 [ ACC ] STREAM LISTENING 13794 >>>>>> 5779/milter-regex system_u:system_r:initrc_t:s0 >>>>>> /var/spool/milter-regex/sock >>>>>> ... >>>>>> >>>>>> So, my questions are: >>>>>> >>>>>> 1. Why are the sockets still initrc_t? >>>>>> 2. Is this a kernel issue or a userspace issue that should be >>>>>> fixed in >>>>>> the milters? >>>>>> 3. Should there be a standard place for milter sockets to live, >>>>>> and if >>>>>> so, where? >>>>>> 4. How come this worked OK in Fedora 7 and previous releases? >>>>> Looking at the source code for these applications, I see that both of >>>>> them use the smfi_setconn() function in the sendmail milter library to >>>>> set up the sockets. It's therefore likely that this problem is >>>>> common to >>>>> all milter applications that use unix domain sockets. >>>>> >>>>> I'm now of the opinion that moving the directory locations for these >>>>> sockets is a bad idea - it would need corresponding changes in >>>>> people's >>>>> sendmail configuration files, which would lead to problems for people >>>>> doing package updates, or installing from upstream sources. Setting >>>>> different context types for the directories (e.g. make >>>>> /var/spool/milter-regex spamd_var_run_t) would seem a better option, >>>>> along with policy tweaks to allow sendmail to do the permissions >>>>> checks >>>>> and write to the sockets). >>>>> >>>>> I'm still confused about the initrc_t sockets though. >>>>> >>>>> Paul. >>>>> >>>>> -- >>>>> fedora-selinux-list mailing list >>>>> fedora-selinux-list at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>>> Ok I will add this to the next update. >>> What exactly is "this"? The 4 "allow" rules mentioned above, the context >>> type change for /var/spool/milter-regex mentioned later, both? >>> >>> Cheers, Paul. >>> >> Context change for /var/spool/milter-regex to spamd_var_run_t. sendmail >> can already use sockets in this directory. > > So that includes the: > > allow sendmail_t initrc_t:unix_stream_socket { read write connectto } > > ? > > Cheers, Paul. > Nope. I don't know what is running as initrc_t and I would bet this is a leaked file descriptor. Or at least a redirectiron of stdin/stdout. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeLuHkACgkQrlYvE4MpobO9mACfT1ADnAw71pvxJyaDoQM2o0WZ LdIAoOYQe4Y05QfPzMaUjCFZ8z6Rz/C8 =OYMh -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Jan 14 19:36:45 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 14 Jan 2008 14:36:45 -0500 Subject: audit log for "setenforce" changes? In-Reply-To: <20080114192332.GA882@angus.ind.WPI.EDU> References: <20080111210620.GB29887@angus.ind.WPI.EDU> <1200086181.29816.100.camel@moss-spartans.epoch.ncsc.mil> <20080111221033.GC29887@angus.ind.WPI.EDU> <1200145024.3282.2.camel@localhost.localdomain> <20080114173532.GA32031@angus.ind.WPI.EDU> <1200332812.2761.5.camel@localhost.localdomain> <20080114183155.GA32604@angus.ind.WPI.EDU> <1200336168.2761.7.camel@localhost.localdomain> <1200336377.22505.53.camel@moss-spartans.epoch.ncsc.mil> <20080114192332.GA882@angus.ind.WPI.EDU> Message-ID: <478BB9CD.9070006@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chuck Anderson wrote: > On Mon, Jan 14, 2008 at 01:46:17PM -0500, Stephen Smalley wrote: >> load_policy doesn't touch the enforcing status. >> >>> Anyway, you have some serious labeling issue there in /var... >>> >>> try restorecon -R /var > > The labelleing issues I would (perhaps incorrectly) expect from > running SELinux in permissive mode. I decided to relabel and reboot > into enforcing mode. What a disaster. The system couldn't boot > enough to run the "fixfiles restore" from /etc/rc.sysinit, not even in > single user mode. I had to eventually boot into single user mode with > the selinux=0 kernel parameter and run "fixfiles restore" manully. > Then I discovered that somehow a bunch of bogus "unconfined" entries > had appeared in > /etc/selinux/targeted/contexts/files/file_contexts.homedirs: > > # > # > # User-specific file contexts, generated via libsemanage > # use semanage command to manage system users to change the file_context > # > # > > > # > # Home Context for user unconfined_u > # > > /etc/[^/]*/.+ unconfined_u:object_r:unconfined_home_t:s0 > /etc/[^/]*/.gnome2(/.*)? unconfined_u:object_r:unconfined_gnome_home_t:s0 > /etc/[^/]*/.*/plugins/nprhapengine\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 > /etc/[^/]*/.*/plugins/libflashplayer\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 > /etc/[^/]*/((www)|(web)|(public_html))(/.+)? unconfined_u:object_r:httpd_unconfined_content_t:s0 > /etc/[^/]*/\.java(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 > /etc/[^/]*/\.galeon(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 > /etc/[^/]*/\.mozilla(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 > /etc/[^/]*/\.phoenix(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 > /etc/[^/]*/\.mozilla(/.*)?/plugins/libflashplayer\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 > /etc/[^/]*/\.netscape(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 > /etc/[^/]*/\.gstreamer-.*/[^/]*\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 > /etc/[^/]*/\.config/gtk-.* unconfined_u:object_r:unconfined_gnome_home_t:s0 > /etc/[^/]* -d unconfined_u:object_r:unconfined_home_dir_t:s0 > /etc/[^/]* -l unconfined_u:object_r:unconfined_home_dir_t:s0 > /etc/lost\+found/.* <> > /etc -d system_u:object_r:home_root_t:s0 > /etc/\.journal <> > /etc/lost\+found -d system_u:object_r:lost_found_t:s0 > > > # > # Home Context for user unconfined_u > # > > /home/[^/]*/.+ unconfined_u:object_r:unconfined_home_t:s0 > /home/[^/]*/.gnome2(/.*)? unconfined_u:object_r:unconfined_gnome_home_t:s0 > /home/[^/]*/.*/plugins/nprhapengine\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 > /home/[^/]*/.*/plugins/libflashplayer\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 > /home/[^/]*/((www)|(web)|(public_html))(/.+)? unconfined_u:object_r:httpd_unconfined_content_t:s0 > /home/[^/]*/\.java(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 > /home/[^/]*/\.galeon(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 > /home/[^/]*/\.mozilla(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 > /home/[^/]*/\.phoenix(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 > /home/[^/]*/\.mozilla(/.*)?/plugins/libflashplayer\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 > /home/[^/]*/\.netscape(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 > /home/[^/]*/\.gstreamer-.*/[^/]*\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 > /home/[^/]*/\.config/gtk-.* unconfined_u:object_r:unconfined_gnome_home_t:s0 > /home/[^/]* -d unconfined_u:object_r:unconfined_home_dir_t:s0 > /home/[^/]* -l unconfined_u:object_r:unconfined_home_dir_t:s0 > /home/lost\+found/.* <> > /home -d system_u:object_r:home_root_t:s0 > /home/\.journal <> > /home/lost\+found -d system_u:object_r:lost_found_t:s0 > > > # > # Home Context for user unconfined_u > # > > /opt/[^/]*/.+ unconfined_u:object_r:unconfined_home_t:s0 > /opt/[^/]*/.gnome2(/.*)? unconfined_u:object_r:unconfined_gnome_home_t:s0 > /opt/[^/]*/.*/plugins/nprhapengine\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 > /opt/[^/]*/.*/plugins/libflashplayer\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 > /opt/[^/]*/((www)|(web)|(public_html))(/.+)? unconfined_u:object_r:httpd_unconfined_content_t:s0 > /opt/[^/]*/\.java(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 > /opt/[^/]*/\.galeon(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 > /opt/[^/]*/\.mozilla(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 > /opt/[^/]*/\.phoenix(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 > /opt/[^/]*/\.mozilla(/.*)?/plugins/libflashplayer\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 > /opt/[^/]*/\.netscape(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 > /opt/[^/]*/\.gstreamer-.*/[^/]*\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 > /opt/[^/]*/\.config/gtk-.* unconfined_u:object_r:unconfined_gnome_home_t:s0 > /opt/[^/]* -d unconfined_u:object_r:unconfined_home_dir_t:s0 > /opt/[^/]* -l unconfined_u:object_r:unconfined_home_dir_t:s0 > /opt/lost\+found/.* <> > /opt -d system_u:object_r:home_root_t:s0 > /opt/\.journal <> > /opt/lost\+found -d system_u:object_r:lost_found_t:s0 > > > # > # Home Context for user unconfined_u > # > > /usr/libexec/[^/]*/.+ unconfined_u:object_r:unconfined_home_t:s0 > /usr/libexec/[^/]*/.gnome2(/.*)? unconfined_u:object_r:unconfined_gnome_home_t:s0 > /usr/libexec/[^/]*/.*/plugins/nprhapengine\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 > /usr/libexec/[^/]*/.*/plugins/libflashplayer\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 > /usr/libexec/[^/]*/((www)|(web)|(public_html))(/.+)? unconfined_u:object_r:httpd_unconfined_content_t:s0 > /usr/libexec/[^/]*/\.java(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 > /usr/libexec/[^/]*/\.galeon(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 > /usr/libexec/[^/]*/\.mozilla(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 > /usr/libexec/[^/]*/\.phoenix(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 > /usr/libexec/[^/]*/\.mozilla(/.*)?/plugins/libflashplayer\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 > /usr/libexec/[^/]*/\.netscape(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 > /usr/libexec/[^/]*/\.gstreamer-.*/[^/]*\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 > /usr/libexec/[^/]*/\.config/gtk-.* unconfined_u:object_r:unconfined_gnome_home_t:s0 > /usr/libexec/[^/]* -d unconfined_u:object_r:unconfined_home_dir_t:s0 > /usr/libexec/[^/]* -l unconfined_u:object_r:unconfined_home_dir_t:s0 > /usr/libexec/lost\+found/.* <> > /usr/libexec -d system_u:object_r:home_root_t:s0 > /usr/libexec/\.journal <> > /usr/libexec/lost\+found -d system_u:object_r:lost_found_t:s0 > > > # > # Home Context for user unconfined_u > # > > /var/log/[^/]*/.+ unconfined_u:object_r:unconfined_home_t:s0 > /var/log/[^/]*/.gnome2(/.*)? unconfined_u:object_r:unconfined_gnome_home_t:s0 > /var/log/[^/]*/.*/plugins/nprhapengine\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 > /var/log/[^/]*/.*/plugins/libflashplayer\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 > /var/log/[^/]*/((www)|(web)|(public_html))(/.+)? unconfined_u:object_r:httpd_unconfined_content_t:s0 > /var/log/[^/]*/\.java(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 > /var/log/[^/]*/\.galeon(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 > /var/log/[^/]*/\.mozilla(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 > /var/log/[^/]*/\.phoenix(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 > /var/log/[^/]*/\.mozilla(/.*)?/plugins/libflashplayer\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 > /var/log/[^/]*/\.netscape(/.*)? unconfined_u:object_r:unconfined_mozilla_home_t:s0 > /var/log/[^/]*/\.gstreamer-.*/[^/]*\.so.* -- unconfined_u:object_r:textrel_shlib_t:s0 > /var/log/[^/]*/\.config/gtk-.* unconfined_u:object_r:unconfined_gnome_home_t:s0 > /var/log/[^/]* -d unconfined_u:object_r:unconfined_home_dir_t:s0 > /var/log/[^/]* -l unconfined_u:object_r:unconfined_home_dir_t:s0 > /var/log/lost\+found/.* <> > /var/log -d system_u:object_r:home_root_t:s0 > /var/log/\.journal <> > /var/log/lost\+found -d system_u:object_r:lost_found_t:s0 > /tmp/gconfd-.* -d unconfined_u:object_r:unconfined_tmp_t:s0 > > > # > # Home Context for user root > # > > /root/.+ root:object_r:sysadm_home_t:s0 > /root/.gnome2(/.*)? root:object_r:sysadm_gnome_home_t:s0 > /root/.*/plugins/nprhapengine\.so.* -- root:object_r:textrel_shlib_t:s0 > /root/.*/plugins/libflashplayer\.so.* -- root:object_r:textrel_shlib_t:s0 > /root/((www)|(web)|(public_html))(/.+)? root:object_r:httpd_sysadm_content_t:s0 > /root/\.ssh(/.*)? root:object_r:sysadm_home_ssh_t:s0 > /root/\.uml(/.*)? root:object_r:sysadm_uml_rw_t:s0 > /root/\.java(/.*)? root:object_r:sysadm_mozilla_home_t:s0 > /root/\.xauth.* -- root:object_r:sysadm_xauth_home_t:s0 > /root/\.fonts(/.*)? root:object_r:sysadm_fonts_t:s0 > /root/\.pyzor(/.*)? root:object_r:sysadm_pyzor_home_t:s0 > /root/\.razor(/.*)? root:object_r:sysadm_razor_home_t:s0 > /root/vmware(/.*)? root:object_r:sysadm_vmware_file_t:s0 > /root/\.galeon(/.*)? root:object_r:sysadm_mozilla_home_t:s0 > /root/\.vmware(/.*)? root:object_r:sysadm_vmware_file_t:s0 > /root/\.vmware[^/]*/.*\.cfg -- root:object_r:sysadm_vmware_conf_t:s0 > /root/\.mozilla(/.*)? root:object_r:sysadm_mozilla_home_t:s0 > /root/\.phoenix(/.*)? root:object_r:sysadm_mozilla_home_t:s0 > /root/\.mplayer(/.*)? root:object_r:sysadm_mplayer_home_t:s0 > /root/\.mozilla(/.*)?/plugins/libflashplayer\.so.* -- root:object_r:textrel_shlib_t:s0 > /root/\.ethereal(/.*)? root:object_r:sysadm_ethereal_home_t:s0 > /root/\.netscape(/.*)? root:object_r:sysadm_mozilla_home_t:s0 > /root/\.Xauthority.* -- root:object_r:sysadm_xauth_home_t:s0 > /root/\.fonts/auto(/.*)? root:object_r:sysadm_fonts_cache_t:s0 > /root/\.gstreamer-.*/[^/]*\.so.* -- root:object_r:textrel_shlib_t:s0 > /root/\.config/gtk-.* root:object_r:sysadm_gnome_home_t:s0 > /root/\.fonts\.cache-.* -- root:object_r:sysadm_fonts_cache_t:s0 > /root/\.ICEauthority.* -- root:object_r:sysadm_iceauth_home_t:s0 > /root/\.spamassassin(/.*)? root:object_r:sysadm_spamassassin_home_t:s0 > /root -d root:object_r:sysadm_home_dir_t:s0 > /root -l root:object_r:sysadm_home_dir_t:s0 > /root/\.ircmotd -- root:object_r:sysadm_irc_home_t:s0 > /root/\.screenrc -- root:object_r:sysadm_screen_ro_home_t:s0 > /root/\.fonts\.conf -- root:object_r:sysadm_fonts_config_t:s0 > /tmp/gconfd-root -d root:object_r:sysadm_tmp_t:s0 > > > I deleted all the sections head up with "Home Context for user > unconfined_u" then re-ran "fixfiles restore". > > The conclusion I draw is that running SELinux in permissive mode for > an extended period of time isn't well supported at all, and shouldn't > be recommended ever. Perhaps more testing should go into running a > system in permissive mode while yum updates apply selinux packages, > etc. to find these types of issues. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Do you have user accounts setup in /var/log? /lib/libexec? If you have system accounts with homedirs and real shells, you can confuse SELinux. Any system account should have a UID < 500 or a shell of /bin/false or /sbin/nologin. You also look like you have root account setup to login as system_u. You probably want to execute semanage login -m -s unconfined_u root -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeLucwACgkQrlYvE4MpobMbWQCgjv+H0sqo1AwqbozQuXxQ6gfw WpwAnj7rx4yavBgSPaAIEphpyUiZr/Ud =QQOb -----END PGP SIGNATURE----- From cra at WPI.EDU Mon Jan 14 20:10:43 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 14 Jan 2008 15:10:43 -0500 Subject: audit log for "setenforce" changes? In-Reply-To: <478BB9CD.9070006@redhat.com> References: <1200086181.29816.100.camel@moss-spartans.epoch.ncsc.mil> <20080111221033.GC29887@angus.ind.WPI.EDU> <1200145024.3282.2.camel@localhost.localdomain> <20080114173532.GA32031@angus.ind.WPI.EDU> <1200332812.2761.5.camel@localhost.localdomain> <20080114183155.GA32604@angus.ind.WPI.EDU> <1200336168.2761.7.camel@localhost.localdomain> <1200336377.22505.53.camel@moss-spartans.epoch.ncsc.mil> <20080114192332.GA882@angus.ind.WPI.EDU> <478BB9CD.9070006@redhat.com> Message-ID: <20080114201043.GB882@angus.ind.WPI.EDU> On Mon, Jan 14, 2008 at 02:36:45PM -0500, Daniel J Walsh wrote: > Do you have user accounts setup in /var/log? /lib/libexec? > If you have system accounts with homedirs and real shells, you can > confuse SELinux. Any system account should have a UID < 500 or a shell > of /bin/false or /sbin/nologin. I fixed all accounts to meet these expectations. There were these which I changed to use shells of /sbin/nologin: oracle:x:1003:1003:Oracle User:/opt/oracle:/bin/sh netsaint:x:1005:1005:netsaint:/usr/libexec/netsaint:/bin/sh autores:x:2000:2000:Autores:/opt/autores: dhcpd:x:2001:2001:DHCP Daemon:/etc/dhcpd:/bin/bash autostat:x:2003:2003:Autostatus:/etc/autostatus:/bin/false nagios:x:2004:2004:nagios:/var/log/nagios:/bin/sh > You also look like you have root account setup to login as system_u. > You probably want to execute > > semanage login -m -s unconfined_u root Done. Thanks for all the help. It sounds like I should go through all my systems to be sure they meet current SELinux standards. From sietjp at free.fr Tue Jan 15 13:34:01 2008 From: sietjp at free.fr (Sietjp) Date: Tue, 15 Jan 2008 14:34:01 +0100 Subject: SELinux newbie Message-ID: <1200404041.478cb64918c00@imp.free.fr> Hi all, Sorry for this newbie post. I'm running fedora 8 and lamp. All is wroking fine except of emails. Apache is not able to send emails via sendmail. I tried setenforce 0, and then all is working fine. But as I'm not a lazy guy, I would like to keep SELInux active and understand what is giong wrong. Please help :) I don't ask for the solution but maybe a starting point or a link, thx :) JP From eparis at redhat.com Tue Jan 15 13:49:21 2008 From: eparis at redhat.com (Eric Paris) Date: Tue, 15 Jan 2008 08:49:21 -0500 Subject: SELinux newbie In-Reply-To: <1200404041.478cb64918c00@imp.free.fr> References: <1200404041.478cb64918c00@imp.free.fr> Message-ID: <1200404961.11802.1.camel@localhost.localdomain> setsebool -P httpd_can_sendmail 1 if you have more httpd questions see man (8) httpd_selinux (oh yeah, dwalsh, httpd_can_sendmail isn't in that man page wanna add it?) -Eric On Tue, 2008-01-15 at 14:34 +0100, Sietjp wrote: > > Hi all, > Sorry for this newbie post. > I'm running fedora 8 and lamp. > All is wroking fine except of emails. Apache is not able to send emails via > sendmail. > > I tried setenforce 0, and then all is working fine. > > But as I'm not a lazy guy, I would like to keep SELInux active and understand > what is giong wrong. > > Please help :) > I don't ask for the solution but maybe a starting point or a link, thx :) > > JP > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From subscribed-lists at sterndata.com Tue Jan 15 13:53:48 2008 From: subscribed-lists at sterndata.com (Steven Stern) Date: Tue, 15 Jan 2008 07:53:48 -0600 Subject: SELinux newbie In-Reply-To: <1200404041.478cb64918c00@imp.free.fr> References: <1200404041.478cb64918c00@imp.free.fr> Message-ID: <478CBAEC.5020005@sterndata.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/15/2008 07:34 AM, Sietjp wrote: | | Hi all, | Sorry for this newbie post. | I'm running fedora 8 and lamp. | All is wroking fine except of emails. Apache is not able to send emails via | sendmail. | | I tried setenforce 0, and then all is working fine. | | But as I'm not a lazy guy, I would like to keep SELInux active and understand | what is giong wrong. | | Please help :) | I don't ask for the solution but maybe a starting point or a link, thx :) | | JP | setsebool -P httpd_can_network_connect=1 If you run with the gui active for a while, the SELinux Troubleshooter will pop up with this answer. It can also be run from APPLICATIONS -> SYSTEM TOOLS. - -- ~ Steve -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHjLrseERILVgMyvARAhjFAJ4kz4GjOYdYuL0AuLA7jyaTz96Y8ACfa57i 5NYxMBxwtVfcIGeIT1gAVUA= =FRWA -----END PGP SIGNATURE----- From sietjp at free.fr Tue Jan 15 14:16:42 2008 From: sietjp at free.fr (Sietjp) Date: Tue, 15 Jan 2008 15:16:42 +0100 Subject: SELinux newbie In-Reply-To: <1200404961.11802.1.camel@localhost.localdomain> References: <1200404041.478cb64918c00@imp.free.fr> <1200404961.11802.1.camel@localhost.localdomain> Message-ID: <1200406602.478cc04abf27b@imp.free.fr> Thx Eric, I tried and it still cause permission denied. Actually this morning I've done : chcon -t httpd_sys_content_t /usr/sbin/sendmail.sendmail Could it be the reason why it still doesn't work ? Thanks JP > setsebool -P httpd_can_sendmail 1 > > if you have more httpd questions see > man (8) httpd_selinux > > (oh yeah, dwalsh, httpd_can_sendmail isn't in that man page wanna add > it?) > > -Eric > > > On Tue, 2008-01-15 at 14:34 +0100, Sietjp wrote: > > > > Hi all, > > Sorry for this newbie post. > > I'm running fedora 8 and lamp. > > All is wroking fine except of emails. Apache is not able to send emails via > > sendmail. > > > > I tried setenforce 0, and then all is working fine. > > > > But as I'm not a lazy guy, I would like to keep SELInux active and > understand > > what is giong wrong. > > > > Please help :) > > I don't ask for the solution but maybe a starting point or a link, thx :) > > > > JP > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From dwalsh at redhat.com Tue Jan 15 14:28:26 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 15 Jan 2008 09:28:26 -0500 Subject: SELinux newbie In-Reply-To: <1200406602.478cc04abf27b@imp.free.fr> References: <1200404041.478cb64918c00@imp.free.fr> <1200404961.11802.1.camel@localhost.localdomain> <1200406602.478cc04abf27b@imp.free.fr> Message-ID: <478CC30A.3080509@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sietjp wrote: > Thx Eric, > > I tried and it still cause permission denied. > > Actually this morning I've done : > > chcon -t httpd_sys_content_t /usr/sbin/sendmail.sendmail > > Could it be the reason why it still doesn't work ? > > Thanks > JP > >> setsebool -P httpd_can_sendmail 1 >> >> if you have more httpd questions see >> man (8) httpd_selinux >> >> (oh yeah, dwalsh, httpd_can_sendmail isn't in that man page wanna add >> it?) >> >> -Eric >> >> >> On Tue, 2008-01-15 at 14:34 +0100, Sietjp wrote: >>> Hi all, >>> Sorry for this newbie post. >>> I'm running fedora 8 and lamp. >>> All is wroking fine except of emails. Apache is not able to send emails via >>> sendmail. >>> >>> I tried setenforce 0, and then all is working fine. >>> >>> But as I'm not a lazy guy, I would like to keep SELInux active and >> understand >>> what is giong wrong. >>> >>> Please help :) >>> I don't ask for the solution but maybe a starting point or a link, thx :) >>> >>> JP >>> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> > > Yes. restorecon /usr/sbin/sendmail.sendmail setsebool -P httpd_can_sendmail 1 Should fix it. Also install setroubleshoot -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeMwwoACgkQrlYvE4MpobNpdACfcbu40tzHU0h4FL745KzlcQou rdIAniMQbxz3l0GFoeoe4lKvcffwgcS3 =7jQU -----END PGP SIGNATURE----- From dwalsh at redhat.com Tue Jan 15 14:29:23 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 15 Jan 2008 09:29:23 -0500 Subject: SELinux newbie In-Reply-To: <478CBAEC.5020005@sterndata.com> References: <1200404041.478cb64918c00@imp.free.fr> <478CBAEC.5020005@sterndata.com> Message-ID: <478CC343.3030709@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steven Stern wrote: > On 01/15/2008 07:34 AM, Sietjp wrote: > | > | Hi all, > | Sorry for this newbie post. > | I'm running fedora 8 and lamp. > | All is wroking fine except of emails. Apache is not able to send > emails via > | sendmail. > | > | I tried setenforce 0, and then all is working fine. > | > | But as I'm not a lazy guy, I would like to keep SELInux active and > understand > | what is giong wrong. > | > | Please help :) > | I don't ask for the solution but maybe a starting point or a link, thx :) > | > | JP > | > setsebool -P httpd_can_network_connect=1 > > If you run with the gui active for a while, the SELinux Troubleshooter > will pop up with this answer. It can also be run from APPLICATIONS -> > SYSTEM TOOLS. > httpd_can_sendmail, only opens the mail ports for connections, can_network_connect opens any port. - -- 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 iEYEARECAAYFAkeMw0MACgkQrlYvE4MpobMvywCcCK+cREffBCBDM5HBDzXQH22F Vf0An36aV0/RoSP9oF6MYjaeydCNiHIN =rVlJ -----END PGP SIGNATURE----- From paul at city-fan.org Tue Jan 15 14:48:04 2008 From: paul at city-fan.org (Paul Howarth) Date: Tue, 15 Jan 2008 14:48:04 +0000 Subject: Sendmail milters in Fedora 8 In-Reply-To: <478BB879.2050604@redhat.com> References: <477BC440.9000809@city-fan.org> <478B829C.1090606@city-fan.org> <478B9511.20006@redhat.com> <478B97A6.9050002@city-fan.org> <478B9AC3.9040500@redhat.com> <478B9C12.9000909@city-fan.org> <478BB879.2050604@redhat.com> Message-ID: <478CC7A4.6030008@city-fan.org> Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Paul Howarth wrote: >> Daniel J Walsh wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Paul Howarth wrote: >>>> Hi Dan, >>>> >>>> Daniel J Walsh wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> Paul Howarth wrote: >>>>>> Paul Howarth wrote: >>>>>>> Since upgrading my mail server from Fedora 7 to Fedora 8, I've come >>>>>>> across some problems with the sockets used for communication between >>>>>>> sendmail and two of the "milter" plugins I'm using with it, namely >>>>>>> milter-regex and spamass-milter. It's very likely that other milters >>>>>>> will have similar issues. >>>>>>> >>>>>>> The sockets used are created when the milter starts, as follows: >>>>>>> >>>>>>> milter-regex: >>>>>>> /var/spool/milter-regex/sock (var_spool_t, inherited from parent >>>>>>> directory) >>>>>>> >>>>>>> spamass-milter: >>>>>>> /var/run/spamass-milter/spamass-milter.sock (spamd_var_run_t, in >>>>>>> policy) >>>>>>> >>>>>>> These are pretty well the upstream locations, though I'm open to >>>>>>> moving the milter-regex socket from /var/spool to /var/run or >>>>>>> elsewhere for consistency. >>>>>>> >>>>>>> Since moving to Fedora 8, I've had to add the following to local >>>>>>> policy to get these milters working: >>>>>>> >>>>>>> allow sendmail_t spamd_var_run_t:dir { search getattr }; >>>>>>> allow sendmail_t spamd_var_run_t:sock_file { getattr write }; >>>>>>> allow sendmail_t var_spool_t:sock_file { getattr write }; >>>>>>> allow sendmail_t initrc_t:unix_stream_socket { read write >>>>>>> connectto }; >>>>>>> >>>>>>> The last of these is the strangest, and relates to Bug #425958 >>>>>>> (https://bugzilla.redhat.com/show_bug.cgi?id=425958). Whilst the >>>>>>> socket file itself has the context listed above, the unix domain >>>>>>> socket that sendmail connects to is still initrc_t, as can be seen >>>>>>> from the output of "netstat -lpZ": >>>>>>> >>>>>>> ... >>>>>>> unix 2 [ ACC ] STREAM LISTENING 14142 >>>>>>> 5853/spamass-milter system_u:system_r:initrc_t:s0 >>>>>>> /var/run/spamass-milter/spamass-milter.sock >>>>>>> unix 2 [ ACC ] STREAM LISTENING 13794 >>>>>>> 5779/milter-regex system_u:system_r:initrc_t:s0 >>>>>>> /var/spool/milter-regex/sock >>>>>>> ... >>>>>>> >>>>>>> So, my questions are: >>>>>>> >>>>>>> 1. Why are the sockets still initrc_t? >>>>>>> 2. Is this a kernel issue or a userspace issue that should be >>>>>>> fixed in >>>>>>> the milters? >>>>>>> 3. Should there be a standard place for milter sockets to live, >>>>>>> and if >>>>>>> so, where? >>>>>>> 4. How come this worked OK in Fedora 7 and previous releases? >>>>>> Looking at the source code for these applications, I see that both of >>>>>> them use the smfi_setconn() function in the sendmail milter library to >>>>>> set up the sockets. It's therefore likely that this problem is >>>>>> common to >>>>>> all milter applications that use unix domain sockets. >>>>>> >>>>>> I'm now of the opinion that moving the directory locations for these >>>>>> sockets is a bad idea - it would need corresponding changes in >>>>>> people's >>>>>> sendmail configuration files, which would lead to problems for people >>>>>> doing package updates, or installing from upstream sources. Setting >>>>>> different context types for the directories (e.g. make >>>>>> /var/spool/milter-regex spamd_var_run_t) would seem a better option, >>>>>> along with policy tweaks to allow sendmail to do the permissions >>>>>> checks >>>>>> and write to the sockets). >>>>>> >>>>>> I'm still confused about the initrc_t sockets though. >>>>>> >>>>>> Paul. >>>>>> >>>>>> -- >>>>>> fedora-selinux-list mailing list >>>>>> fedora-selinux-list at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>>>> Ok I will add this to the next update. >>>> What exactly is "this"? The 4 "allow" rules mentioned above, the context >>>> type change for /var/spool/milter-regex mentioned later, both? >>>> >>>> Cheers, Paul. >>>> >>> Context change for /var/spool/milter-regex to spamd_var_run_t. sendmail >>> can already use sockets in this directory. >> So that includes the: >> >> allow sendmail_t initrc_t:unix_stream_socket { read write connectto } >> >> ? >> >> Cheers, Paul. >> > Nope. I don't know what is running as initrc_t and I would bet this is > a leaked file descriptor. Or at least a redirectiron of stdin/stdout. I don't think it's a leaked file descriptor - that would be dontaudit-able, right? By not allowing communications with the initrc_t:unix_stream_socket, the milter fails to work: ==> /var/log/audit/audit.log <== type=AVC msg=audit(1200408212.783:142453): avc: denied { connectto } for pid=7805 comm="sendmail" path="/var/spool/milter-regex/sock" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket type=SYSCALL msg=audit(1200408212.783:142453): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfd9f600 a2=b7f79bd4 a3=0 items=0 ppid=7764 pid=7805 auid=0 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:sendmail_t:s0 key=(null) ==> /var/log/maillog <== Jan 15 14:43:32 goalkeeper sendmail[7805]: NOQUEUE: connect from ard120.neoplus.adsl.tpnet.pl [83.26.189.120] Jan 15 14:43:32 goalkeeper sendmail[7805]: AUTH: available mech=CRAM-MD5 DIGEST-MD5, allowed mech=CRAM-MD5 DIGEST-MD5 LOGIN PLAIN Jan 15 14:43:32 goalkeeper sendmail[7805]: m0FEhW21007805: Milter (milter-regex): error connecting to filter: Permission denied Jan 15 14:43:32 goalkeeper sendmail[7805]: m0FEhW21007805: Milter (milter-regex): to error state Jan 15 14:43:32 goalkeeper sendmail[7805]: m0FEhW21007805: Milter: initialization failed, temp failing commands Jan 15 14:43:32 goalkeeper sendmail[7805]: m0FEhW21007805: SMTP MAIL command () from ard120.neoplus.adsl.tpnet.pl [83.26.189.120] tempfailed (due to previous checks) The initrc_t type shows up in netstat but not in ls: # netstat -aZp | grep initrc tcp 0 0 goalkeeper.intra.:bacula-fd *:* LISTEN 5864/bacula-fd system_u:system_r:initrc_t:s0 udp 0 0 rbldns.intra.cit:domain *:* 5885/rbldnsd system_u:system_r:initrc_t:s0 unix 2 [ ACC ] STREAM LISTENING 14142 5853/spamass-milter system_u:system_r:initrc_t:s0 /var/run/spamass-milter/spamass-milter.sock unix 2 [ ACC ] STREAM LISTENING 13794 5779/milter-regex system_u:system_r:initrc_t:s0 /var/spool/milter-regex/sock unix 2 [ ] DGRAM 2150436 5779/milter-regex system_u:system_r:initrc_t:s0 unix 2 [ ] DGRAM 14141 5853/spamass-milter system_u:system_r:initrc_t:s0 # ls -lZ /var/run/spamass-milter/spamass-milter.sock /var/spool/milter-regex/sock srwxr-xr-x sa-milt sa-milt system_u:object_r:spamd_var_run_t:s0 /var/run/spamass-milter/spamass-milter.sock srw------- mregex mregex system_u:object_r:spamd_var_run_t:s0 /var/spool/milter-regex/sock Paul. From sds at tycho.nsa.gov Tue Jan 15 14:22:02 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 15 Jan 2008 09:22:02 -0500 Subject: SELinux newbie In-Reply-To: <1200406602.478cc04abf27b@imp.free.fr> References: <1200404041.478cb64918c00@imp.free.fr> <1200404961.11802.1.camel@localhost.localdomain> <1200406602.478cc04abf27b@imp.free.fr> Message-ID: <1200406922.9669.32.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2008-01-15 at 15:16 +0100, Sietjp wrote: > Thx Eric, > > I tried and it still cause permission denied. > > Actually this morning I've done : > > chcon -t httpd_sys_content_t /usr/sbin/sendmail.sendmail > > Could it be the reason why it still doesn't work ? Yes, run 'restorecon -v /usr/sbin/sendmail.sendmail'. > > Thanks > JP > > > setsebool -P httpd_can_sendmail 1 > > > > if you have more httpd questions see > > man (8) httpd_selinux > > > > (oh yeah, dwalsh, httpd_can_sendmail isn't in that man page wanna add > > it?) > > > > -Eric > > > > > > On Tue, 2008-01-15 at 14:34 +0100, Sietjp wrote: > > > > > > Hi all, > > > Sorry for this newbie post. > > > I'm running fedora 8 and lamp. > > > All is wroking fine except of emails. Apache is not able to send emails via > > > sendmail. > > > > > > I tried setenforce 0, and then all is working fine. > > > > > > But as I'm not a lazy guy, I would like to keep SELInux active and > > understand > > > what is giong wrong. > > > > > > Please help :) > > > I don't ask for the solution but maybe a starting point or a link, thx :) > > > > > > JP > > > > > > -- > > > fedora-selinux-list mailing list > > > fedora-selinux-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Tue Jan 15 13:48:15 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 15 Jan 2008 08:48:15 -0500 Subject: SELinux newbie In-Reply-To: <1200404041.478cb64918c00@imp.free.fr> References: <1200404041.478cb64918c00@imp.free.fr> Message-ID: <1200404895.9669.5.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2008-01-15 at 14:34 +0100, Sietjp wrote: > > Hi all, > Sorry for this newbie post. > I'm running fedora 8 and lamp. > All is wroking fine except of emails. Apache is not able to send emails via > sendmail. > > I tried setenforce 0, and then all is working fine. > > But as I'm not a lazy guy, I would like to keep SELInux active and understand > what is giong wrong. > > Please help :) > I don't ask for the solution but maybe a starting point or a link, thx :) If you install setroubleshoot (yum install setroubleshoot), it can detect and report SELinux denials to you in a more friendly manner, either via desktop alert or via email if it is a server. Or you can look at the audit logs (/sbin/ausearch -i -m AVC) or system logs (grep avc /var/log/messages) to see what denials are being generated, and report those to this list. audit2allow can help you work around denials, but you should post the denials to get guidance on the proper fix. setroubleshoot can sometimes help as well with pointing you in the right direction. Stephen Smalley National Security Agency From mike.clarkson at baesystems.com Tue Jan 15 15:46:29 2008 From: mike.clarkson at baesystems.com (Clarkson, Mike R (US SSA)) Date: Tue, 15 Jan 2008 07:46:29 -0800 Subject: SELinux newbie References: <1200404041.478cb64918c00@imp.free.fr><478CBAEC.5020005@sterndata.com> <478CC343.3030709@redhat.com> Message-ID: Is httpd_can_sendmail new? I don't see it in booleans.conf in RHEL5.1 > -----Original Message----- > From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux-list- > bounces at redhat.com] On Behalf Of Daniel J Walsh > Sent: Tuesday, January 15, 2008 6:29 AM > To: Steven Stern > Cc: fedora-selinux-list at redhat.com > Subject: Re: SELinux newbie > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Steven Stern wrote: > > On 01/15/2008 07:34 AM, Sietjp wrote: > > | > > | Hi all, > > | Sorry for this newbie post. > > | I'm running fedora 8 and lamp. > > | All is wroking fine except of emails. Apache is not able to send > > emails via > > | sendmail. > > | > > | I tried setenforce 0, and then all is working fine. > > | > > | But as I'm not a lazy guy, I would like to keep SELInux active and > > understand > > | what is giong wrong. > > | > > | Please help :) > > | I don't ask for the solution but maybe a starting point or a link, thx > :) > > | > > | JP > > | > > setsebool -P httpd_can_network_connect=1 > > > > If you run with the gui active for a while, the SELinux Troubleshooter > > will pop up with this answer. It can also be run from APPLICATIONS -> > > SYSTEM TOOLS. > > > > httpd_can_sendmail, only opens the mail ports for connections, > can_network_connect opens any port. > - -- > 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 > > iEYEARECAAYFAkeMw0MACgkQrlYvE4MpobMvywCcCK+cREffBCBDM5HBDzXQH22F > Vf0An36aV0/RoSP9oF6MYjaeydCNiHIN > =rVlJ > -----END PGP SIGNATURE----- > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From dwalsh at redhat.com Tue Jan 15 19:10:44 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 15 Jan 2008 14:10:44 -0500 Subject: SELinux newbie In-Reply-To: References: <1200404041.478cb64918c00@imp.free.fr><478CBAEC.5020005@sterndata.com> <478CC343.3030709@redhat.com> Message-ID: <478D0534.4010800@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Clarkson, Mike R (US SSA) wrote: > Is httpd_can_sendmail new? I don't see it in booleans.conf in RHEL5.1 > Newer the RHEL5. :^( >> -----Original Message----- >> From: fedora-selinux-list-bounces at redhat.com > [mailto:fedora-selinux-list- >> bounces at redhat.com] On Behalf Of Daniel J Walsh >> Sent: Tuesday, January 15, 2008 6:29 AM >> To: Steven Stern >> Cc: fedora-selinux-list at redhat.com >> Subject: Re: SELinux newbie >> > Steven Stern wrote: >>>> On 01/15/2008 07:34 AM, Sietjp wrote: >>>> | >>>> | Hi all, >>>> | Sorry for this newbie post. >>>> | I'm running fedora 8 and lamp. >>>> | All is wroking fine except of emails. Apache is not able to send >>>> emails via >>>> | sendmail. >>>> | >>>> | I tried setenforce 0, and then all is working fine. >>>> | >>>> | But as I'm not a lazy guy, I would like to keep SELInux active and >>>> understand >>>> | what is giong wrong. >>>> | >>>> | Please help :) >>>> | I don't ask for the solution but maybe a starting point or a link, >> thx > :) >>>> | >>>> | JP >>>> | >>>> setsebool -P httpd_can_network_connect=1 >>>> >>>> If you run with the gui active for a while, the SELinux >> Troubleshooter >>>> will pop up with this answer. It can also be run from APPLICATIONS >> -> >>>> SYSTEM TOOLS. >>>> > httpd_can_sendmail, only opens the mail ports for connections, > can_network_connect opens any port. >> - -- 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 iEYEARECAAYFAkeNBTQACgkQrlYvE4MpobN8LACfTrzIliDQeodd5xiRpu9YFEDl cyMAn2e3S5bKWZuQe88ZKctkPfctnROM =axAX -----END PGP SIGNATURE----- From dwalsh at redhat.com Tue Jan 15 19:53:18 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 15 Jan 2008 14:53:18 -0500 Subject: Sendmail milters in Fedora 8 In-Reply-To: <478CC7A4.6030008@city-fan.org> References: <477BC440.9000809@city-fan.org> <478B829C.1090606@city-fan.org> <478B9511.20006@redhat.com> <478B97A6.9050002@city-fan.org> <478B9AC3.9040500@redhat.com> <478B9C12.9000909@city-fan.org> <478BB879.2050604@redhat.com> <478CC7A4.6030008@city-fan.org> Message-ID: <478D0F2E.3050401@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Howarth wrote: > Daniel J Walsh wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Paul Howarth wrote: >>> Daniel J Walsh wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Paul Howarth wrote: >>>>> Hi Dan, >>>>> >>>>> Daniel J Walsh wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA1 >>>>>> >>>>>> Paul Howarth wrote: >>>>>>> Paul Howarth wrote: >>>>>>>> Since upgrading my mail server from Fedora 7 to Fedora 8, I've come >>>>>>>> across some problems with the sockets used for communication >>>>>>>> between >>>>>>>> sendmail and two of the "milter" plugins I'm using with it, namely >>>>>>>> milter-regex and spamass-milter. It's very likely that other >>>>>>>> milters >>>>>>>> will have similar issues. >>>>>>>> >>>>>>>> The sockets used are created when the milter starts, as follows: >>>>>>>> >>>>>>>> milter-regex: >>>>>>>> /var/spool/milter-regex/sock (var_spool_t, inherited from parent >>>>>>>> directory) >>>>>>>> >>>>>>>> spamass-milter: >>>>>>>> /var/run/spamass-milter/spamass-milter.sock (spamd_var_run_t, in >>>>>>>> policy) >>>>>>>> >>>>>>>> These are pretty well the upstream locations, though I'm open to >>>>>>>> moving the milter-regex socket from /var/spool to /var/run or >>>>>>>> elsewhere for consistency. >>>>>>>> >>>>>>>> Since moving to Fedora 8, I've had to add the following to local >>>>>>>> policy to get these milters working: >>>>>>>> >>>>>>>> allow sendmail_t spamd_var_run_t:dir { search getattr }; >>>>>>>> allow sendmail_t spamd_var_run_t:sock_file { getattr write }; >>>>>>>> allow sendmail_t var_spool_t:sock_file { getattr write }; >>>>>>>> allow sendmail_t initrc_t:unix_stream_socket { read write >>>>>>>> connectto }; >>>>>>>> >>>>>>>> The last of these is the strangest, and relates to Bug #425958 >>>>>>>> (https://bugzilla.redhat.com/show_bug.cgi?id=425958). Whilst the >>>>>>>> socket file itself has the context listed above, the unix domain >>>>>>>> socket that sendmail connects to is still initrc_t, as can be seen >>>>>>>> from the output of "netstat -lpZ": >>>>>>>> >>>>>>>> ... >>>>>>>> unix 2 [ ACC ] STREAM LISTENING 14142 >>>>>>>> 5853/spamass-milter system_u:system_r:initrc_t:s0 >>>>>>>> /var/run/spamass-milter/spamass-milter.sock >>>>>>>> unix 2 [ ACC ] STREAM LISTENING 13794 >>>>>>>> 5779/milter-regex system_u:system_r:initrc_t:s0 >>>>>>>> /var/spool/milter-regex/sock >>>>>>>> ... >>>>>>>> >>>>>>>> So, my questions are: >>>>>>>> >>>>>>>> 1. Why are the sockets still initrc_t? >>>>>>>> 2. Is this a kernel issue or a userspace issue that should be >>>>>>>> fixed in >>>>>>>> the milters? >>>>>>>> 3. Should there be a standard place for milter sockets to live, >>>>>>>> and if >>>>>>>> so, where? >>>>>>>> 4. How come this worked OK in Fedora 7 and previous releases? >>>>>>> Looking at the source code for these applications, I see that >>>>>>> both of >>>>>>> them use the smfi_setconn() function in the sendmail milter >>>>>>> library to >>>>>>> set up the sockets. It's therefore likely that this problem is >>>>>>> common to >>>>>>> all milter applications that use unix domain sockets. >>>>>>> >>>>>>> I'm now of the opinion that moving the directory locations for these >>>>>>> sockets is a bad idea - it would need corresponding changes in >>>>>>> people's >>>>>>> sendmail configuration files, which would lead to problems for >>>>>>> people >>>>>>> doing package updates, or installing from upstream sources. Setting >>>>>>> different context types for the directories (e.g. make >>>>>>> /var/spool/milter-regex spamd_var_run_t) would seem a better option, >>>>>>> along with policy tweaks to allow sendmail to do the permissions >>>>>>> checks >>>>>>> and write to the sockets). >>>>>>> >>>>>>> I'm still confused about the initrc_t sockets though. >>>>>>> >>>>>>> Paul. >>>>>>> >>>>>>> -- >>>>>>> fedora-selinux-list mailing list >>>>>>> fedora-selinux-list at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>>>>> Ok I will add this to the next update. >>>>> What exactly is "this"? The 4 "allow" rules mentioned above, the >>>>> context >>>>> type change for /var/spool/milter-regex mentioned later, both? >>>>> >>>>> Cheers, Paul. >>>>> >>>> Context change for /var/spool/milter-regex to spamd_var_run_t. >>>> sendmail >>>> can already use sockets in this directory. >>> So that includes the: >>> >>> allow sendmail_t initrc_t:unix_stream_socket { read write connectto } >>> >>> ? >>> >>> Cheers, Paul. >>> >> Nope. I don't know what is running as initrc_t and I would bet this is >> a leaked file descriptor. Or at least a redirectiron of stdin/stdout. > > I don't think it's a leaked file descriptor - that would be > dontaudit-able, right? By not allowing communications with the > initrc_t:unix_stream_socket, the milter fails to work: > > ==> /var/log/audit/audit.log <== > type=AVC msg=audit(1200408212.783:142453): avc: denied { connectto } > for pid=7805 comm="sendmail" path="/var/spool/milter-regex/sock" > scontext=system_u:system_r:sendmail_t:s0 > tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket > type=SYSCALL msg=audit(1200408212.783:142453): arch=40000003 syscall=102 > success=no exit=-13 a0=3 a1=bfd9f600 a2=b7f79bd4 a3=0 items=0 ppid=7764 > pid=7805 auid=0 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:sendmail_t:s0 key=(null) > > ==> /var/log/maillog <== > Jan 15 14:43:32 goalkeeper sendmail[7805]: NOQUEUE: connect from > ard120.neoplus.adsl.tpnet.pl [83.26.189.120] > Jan 15 14:43:32 goalkeeper sendmail[7805]: AUTH: available mech=CRAM-MD5 > DIGEST-MD5, allowed mech=CRAM-MD5 DIGEST-MD5 LOGIN PLAIN > Jan 15 14:43:32 goalkeeper sendmail[7805]: m0FEhW21007805: Milter > (milter-regex): error connecting to filter: Permission denied > Jan 15 14:43:32 goalkeeper sendmail[7805]: m0FEhW21007805: Milter > (milter-regex): to error state > Jan 15 14:43:32 goalkeeper sendmail[7805]: m0FEhW21007805: Milter: > initialization failed, temp failing commands > Jan 15 14:43:32 goalkeeper sendmail[7805]: m0FEhW21007805: SMTP MAIL > command () from > ard120.neoplus.adsl.tpnet.pl [83.26.189.120] tempfailed (due to previous > checks) > > > The initrc_t type shows up in netstat but not in ls: > # netstat -aZp | grep initrc > tcp 0 0 goalkeeper.intra.:bacula-fd *:* LISTEN > 5864/bacula-fd system_u:system_r:initrc_t:s0 > udp 0 0 rbldns.intra.cit:domain *:* > 5885/rbldnsd system_u:system_r:initrc_t:s0 > unix 2 [ ACC ] STREAM LISTENING 14142 > 5853/spamass-milter system_u:system_r:initrc_t:s0 > /var/run/spamass-milter/spamass-milter.sock > unix 2 [ ACC ] STREAM LISTENING 13794 > 5779/milter-regex system_u:system_r:initrc_t:s0 > /var/spool/milter-regex/sock > unix 2 [ ] DGRAM 2150436 > 5779/milter-regex system_u:system_r:initrc_t:s0 > unix 2 [ ] DGRAM 14141 > 5853/spamass-milter system_u:system_r:initrc_t:s0 > # ls -lZ /var/run/spamass-milter/spamass-milter.sock > /var/spool/milter-regex/sock > srwxr-xr-x sa-milt sa-milt system_u:object_r:spamd_var_run_t:s0 > /var/run/spamass-milter/spamass-milter.sock > srw------- mregex mregex system_u:object_r:spamd_var_run_t:s0 > /var/spool/milter-regex/sock > > > Paul. > > Ok then I guess we need to label chcon -t spamd_exec_t /usr/sbin/spamass-milter And then build policy off of that. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeNDy0ACgkQrlYvE4MpobOJIACfYIuXiAVS506Wzv42LeBrwxdD hxkAoOXxP5M55WXgf/qVNZE0lqt+/uZZ =prIg -----END PGP SIGNATURE----- From paul at city-fan.org Wed Jan 16 00:16:17 2008 From: paul at city-fan.org (Paul Howarth) Date: Wed, 16 Jan 2008 00:16:17 +0000 Subject: Sendmail milters in Fedora 8 In-Reply-To: <478D0F2E.3050401@redhat.com> References: <477BC440.9000809@city-fan.org> <478B829C.1090606@city-fan.org> <478B9511.20006@redhat.com> <478B97A6.9050002@city-fan.org> <478B9AC3.9040500@redhat.com> <478B9C12.9000909@city-fan.org> <478BB879.2050604@redhat.com> <478CC7A4.6030008@city-fan.org> <478D0F2E.3050401@redhat.com> Message-ID: <20080116001617.6af19309@metropolis.intra.city-fan.org> On Tue, 15 Jan 2008 14:53:18 -0500 Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Paul Howarth wrote: > > Daniel J Walsh wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> Paul Howarth wrote: > >>> Daniel J Walsh wrote: > >>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>> Hash: SHA1 > >>>> > >>>> Paul Howarth wrote: > >>>>> Hi Dan, > >>>>> > >>>>> Daniel J Walsh wrote: > >>>>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>>>> Hash: SHA1 > >>>>>> > >>>>>> Paul Howarth wrote: > >>>>>>> Paul Howarth wrote: > >>>>>>>> Since upgrading my mail server from Fedora 7 to Fedora 8, > >>>>>>>> I've come across some problems with the sockets used for > >>>>>>>> communication between > >>>>>>>> sendmail and two of the "milter" plugins I'm using with it, > >>>>>>>> namely milter-regex and spamass-milter. It's very likely > >>>>>>>> that other milters > >>>>>>>> will have similar issues. > >>>>>>>> > >>>>>>>> The sockets used are created when the milter starts, as > >>>>>>>> follows: > >>>>>>>> > >>>>>>>> milter-regex: > >>>>>>>> /var/spool/milter-regex/sock (var_spool_t, inherited from > >>>>>>>> parent directory) > >>>>>>>> > >>>>>>>> spamass-milter: > >>>>>>>> /var/run/spamass-milter/spamass-milter.sock > >>>>>>>> (spamd_var_run_t, in policy) > >>>>>>>> > >>>>>>>> These are pretty well the upstream locations, though I'm > >>>>>>>> open to moving the milter-regex socket from /var/spool > >>>>>>>> to /var/run or elsewhere for consistency. > >>>>>>>> > >>>>>>>> Since moving to Fedora 8, I've had to add the following to > >>>>>>>> local policy to get these milters working: > >>>>>>>> > >>>>>>>> allow sendmail_t spamd_var_run_t:dir { search getattr }; > >>>>>>>> allow sendmail_t spamd_var_run_t:sock_file { getattr write }; > >>>>>>>> allow sendmail_t var_spool_t:sock_file { getattr write }; > >>>>>>>> allow sendmail_t initrc_t:unix_stream_socket { read write > >>>>>>>> connectto }; > >>>>>>>> > >>>>>>>> The last of these is the strangest, and relates to Bug > >>>>>>>> #425958 > >>>>>>>> (https://bugzilla.redhat.com/show_bug.cgi?id=425958). Whilst > >>>>>>>> the socket file itself has the context listed above, the > >>>>>>>> unix domain socket that sendmail connects to is still > >>>>>>>> initrc_t, as can be seen from the output of "netstat -lpZ": > >>>>>>>> > >>>>>>>> ... > >>>>>>>> unix 2 [ ACC ] STREAM LISTENING 14142 > >>>>>>>> 5853/spamass-milter system_u:system_r:initrc_t:s0 > >>>>>>>> /var/run/spamass-milter/spamass-milter.sock > >>>>>>>> unix 2 [ ACC ] STREAM LISTENING 13794 > >>>>>>>> 5779/milter-regex system_u:system_r:initrc_t:s0 > >>>>>>>> /var/spool/milter-regex/sock > >>>>>>>> ... > >>>>>>>> > >>>>>>>> So, my questions are: > >>>>>>>> > >>>>>>>> 1. Why are the sockets still initrc_t? > >>>>>>>> 2. Is this a kernel issue or a userspace issue that should be > >>>>>>>> fixed in > >>>>>>>> the milters? > >>>>>>>> 3. Should there be a standard place for milter sockets to > >>>>>>>> live, and if > >>>>>>>> so, where? > >>>>>>>> 4. How come this worked OK in Fedora 7 and previous releases? > >>>>>>> Looking at the source code for these applications, I see that > >>>>>>> both of > >>>>>>> them use the smfi_setconn() function in the sendmail milter > >>>>>>> library to > >>>>>>> set up the sockets. It's therefore likely that this problem is > >>>>>>> common to > >>>>>>> all milter applications that use unix domain sockets. > >>>>>>> > >>>>>>> I'm now of the opinion that moving the directory locations > >>>>>>> for these sockets is a bad idea - it would need corresponding > >>>>>>> changes in people's > >>>>>>> sendmail configuration files, which would lead to problems for > >>>>>>> people > >>>>>>> doing package updates, or installing from upstream sources. > >>>>>>> Setting different context types for the directories (e.g. make > >>>>>>> /var/spool/milter-regex spamd_var_run_t) would seem a better > >>>>>>> option, along with policy tweaks to allow sendmail to do the > >>>>>>> permissions checks > >>>>>>> and write to the sockets). > >>>>>>> > >>>>>>> I'm still confused about the initrc_t sockets though. > >>>>>>> > >>>>>>> Paul. > >>>>>>> > >>>>>>> -- > >>>>>>> fedora-selinux-list mailing list > >>>>>>> fedora-selinux-list at redhat.com > >>>>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > >>>>>> Ok I will add this to the next update. > >>>>> What exactly is "this"? The 4 "allow" rules mentioned above, the > >>>>> context > >>>>> type change for /var/spool/milter-regex mentioned later, both? > >>>>> > >>>>> Cheers, Paul. > >>>>> > >>>> Context change for /var/spool/milter-regex to spamd_var_run_t. > >>>> sendmail > >>>> can already use sockets in this directory. > >>> So that includes the: > >>> > >>> allow sendmail_t initrc_t:unix_stream_socket { read write > >>> connectto } > >>> > >>> ? > >>> > >>> Cheers, Paul. > >>> > >> Nope. I don't know what is running as initrc_t and I would bet > >> this is a leaked file descriptor. Or at least a redirectiron of > >> stdin/stdout. > > > > I don't think it's a leaked file descriptor - that would be > > dontaudit-able, right? By not allowing communications with the > > initrc_t:unix_stream_socket, the milter fails to work: > > > > ==> /var/log/audit/audit.log <== > > type=AVC msg=audit(1200408212.783:142453): avc: denied > > { connectto } for pid=7805 comm="sendmail" > > path="/var/spool/milter-regex/sock" > > scontext=system_u:system_r:sendmail_t:s0 > > tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket > > type=SYSCALL msg=audit(1200408212.783:142453): arch=40000003 > > syscall=102 success=no exit=-13 a0=3 a1=bfd9f600 a2=b7f79bd4 a3=0 > > items=0 ppid=7764 pid=7805 auid=0 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:sendmail_t:s0 key=(null) > > > > ==> /var/log/maillog <== > > Jan 15 14:43:32 goalkeeper sendmail[7805]: NOQUEUE: connect from > > ard120.neoplus.adsl.tpnet.pl [83.26.189.120] > > Jan 15 14:43:32 goalkeeper sendmail[7805]: AUTH: available > > mech=CRAM-MD5 DIGEST-MD5, allowed mech=CRAM-MD5 DIGEST-MD5 LOGIN > > PLAIN Jan 15 14:43:32 goalkeeper sendmail[7805]: m0FEhW21007805: > > Milter (milter-regex): error connecting to filter: Permission denied > > Jan 15 14:43:32 goalkeeper sendmail[7805]: m0FEhW21007805: Milter > > (milter-regex): to error state > > Jan 15 14:43:32 goalkeeper sendmail[7805]: m0FEhW21007805: Milter: > > initialization failed, temp failing commands > > Jan 15 14:43:32 goalkeeper sendmail[7805]: m0FEhW21007805: SMTP MAIL > > command () from > > ard120.neoplus.adsl.tpnet.pl [83.26.189.120] tempfailed (due to > > previous checks) > > > > > > The initrc_t type shows up in netstat but not in ls: > > # netstat -aZp | grep initrc > > tcp 0 0 goalkeeper.intra.:bacula-fd *:* LISTEN > > 5864/bacula-fd system_u:system_r:initrc_t:s0 > > udp 0 0 rbldns.intra.cit:domain *:* > > 5885/rbldnsd system_u:system_r:initrc_t:s0 > > unix 2 [ ACC ] STREAM LISTENING 14142 > > 5853/spamass-milter system_u:system_r:initrc_t:s0 > > /var/run/spamass-milter/spamass-milter.sock > > unix 2 [ ACC ] STREAM LISTENING 13794 > > 5779/milter-regex system_u:system_r:initrc_t:s0 > > /var/spool/milter-regex/sock > > unix 2 [ ] DGRAM 2150436 > > 5779/milter-regex system_u:system_r:initrc_t:s0 > > unix 2 [ ] DGRAM 14141 > > 5853/spamass-milter system_u:system_r:initrc_t:s0 > > # ls -lZ /var/run/spamass-milter/spamass-milter.sock > > /var/spool/milter-regex/sock > > srwxr-xr-x sa-milt sa-milt system_u:object_r:spamd_var_run_t:s0 > > /var/run/spamass-milter/spamass-milter.sock > > srw------- mregex mregex system_u:object_r:spamd_var_run_t:s0 > > /var/spool/milter-regex/sock > > > > > > Paul. > > > > > Ok then I guess we need to label > > chcon -t spamd_exec_t /usr/sbin/spamass-milter > > And then build policy off of that. Whilst that might result in a solution for spamass-milter, it's not going to help milter-regex or potentially any other milter (they're all likely to use the same libmilter [sendmail] API for setting up the sockets). There seems to be something odd about sockets in general; the netstat output quoted above shows a couple of network-listening sockets with type initrc_t too, from a further two non-milter programs, namely bacula and rbldnsd. I also see the same issue with nasd and rpc.quotad. though I can also see a bunch of listening sockets with system_u:system_r:unconfined_t on my desktop. Why might some of these apps transition to unconfined_t and others not? And why does "ls" show a different type than "netstat"? Paul. From dwalsh at redhat.com Wed Jan 16 11:23:04 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 16 Jan 2008 06:23:04 -0500 Subject: Sendmail milters in Fedora 8 In-Reply-To: <20080116001617.6af19309@metropolis.intra.city-fan.org> References: <477BC440.9000809@city-fan.org> <478B829C.1090606@city-fan.org> <478B9511.20006@redhat.com> <478B97A6.9050002@city-fan.org> <478B9AC3.9040500@redhat.com> <478B9C12.9000909@city-fan.org> <478BB879.2050604@redhat.com> <478CC7A4.6030008@city-fan.org> <478D0F2E.3050401@redhat.com> <20080116001617.6af19309@metropolis.intra.city-fan.org> Message-ID: <478DE918.1080907@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Howarth wrote: > On Tue, 15 Jan 2008 14:53:18 -0500 > Daniel J Walsh wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Paul Howarth wrote: >>> Daniel J Walsh wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Paul Howarth wrote: >>>>> Daniel J Walsh wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA1 >>>>>> >>>>>> Paul Howarth wrote: >>>>>>> Hi Dan, >>>>>>> >>>>>>> Daniel J Walsh wrote: >>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>>> Hash: SHA1 >>>>>>>> >>>>>>>> Paul Howarth wrote: >>>>>>>>> Paul Howarth wrote: >>>>>>>>>> Since upgrading my mail server from Fedora 7 to Fedora 8, >>>>>>>>>> I've come across some problems with the sockets used for >>>>>>>>>> communication between >>>>>>>>>> sendmail and two of the "milter" plugins I'm using with it, >>>>>>>>>> namely milter-regex and spamass-milter. It's very likely >>>>>>>>>> that other milters >>>>>>>>>> will have similar issues. >>>>>>>>>> >>>>>>>>>> The sockets used are created when the milter starts, as >>>>>>>>>> follows: >>>>>>>>>> >>>>>>>>>> milter-regex: >>>>>>>>>> /var/spool/milter-regex/sock (var_spool_t, inherited from >>>>>>>>>> parent directory) >>>>>>>>>> >>>>>>>>>> spamass-milter: >>>>>>>>>> /var/run/spamass-milter/spamass-milter.sock >>>>>>>>>> (spamd_var_run_t, in policy) >>>>>>>>>> >>>>>>>>>> These are pretty well the upstream locations, though I'm >>>>>>>>>> open to moving the milter-regex socket from /var/spool >>>>>>>>>> to /var/run or elsewhere for consistency. >>>>>>>>>> >>>>>>>>>> Since moving to Fedora 8, I've had to add the following to >>>>>>>>>> local policy to get these milters working: >>>>>>>>>> >>>>>>>>>> allow sendmail_t spamd_var_run_t:dir { search getattr }; >>>>>>>>>> allow sendmail_t spamd_var_run_t:sock_file { getattr write }; >>>>>>>>>> allow sendmail_t var_spool_t:sock_file { getattr write }; >>>>>>>>>> allow sendmail_t initrc_t:unix_stream_socket { read write >>>>>>>>>> connectto }; >>>>>>>>>> >>>>>>>>>> The last of these is the strangest, and relates to Bug >>>>>>>>>> #425958 >>>>>>>>>> (https://bugzilla.redhat.com/show_bug.cgi?id=425958). Whilst >>>>>>>>>> the socket file itself has the context listed above, the >>>>>>>>>> unix domain socket that sendmail connects to is still >>>>>>>>>> initrc_t, as can be seen from the output of "netstat -lpZ": >>>>>>>>>> >>>>>>>>>> ... >>>>>>>>>> unix 2 [ ACC ] STREAM LISTENING 14142 >>>>>>>>>> 5853/spamass-milter system_u:system_r:initrc_t:s0 >>>>>>>>>> /var/run/spamass-milter/spamass-milter.sock >>>>>>>>>> unix 2 [ ACC ] STREAM LISTENING 13794 >>>>>>>>>> 5779/milter-regex system_u:system_r:initrc_t:s0 >>>>>>>>>> /var/spool/milter-regex/sock >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> So, my questions are: >>>>>>>>>> >>>>>>>>>> 1. Why are the sockets still initrc_t? >>>>>>>>>> 2. Is this a kernel issue or a userspace issue that should be >>>>>>>>>> fixed in >>>>>>>>>> the milters? >>>>>>>>>> 3. Should there be a standard place for milter sockets to >>>>>>>>>> live, and if >>>>>>>>>> so, where? >>>>>>>>>> 4. How come this worked OK in Fedora 7 and previous releases? >>>>>>>>> Looking at the source code for these applications, I see that >>>>>>>>> both of >>>>>>>>> them use the smfi_setconn() function in the sendmail milter >>>>>>>>> library to >>>>>>>>> set up the sockets. It's therefore likely that this problem is >>>>>>>>> common to >>>>>>>>> all milter applications that use unix domain sockets. >>>>>>>>> >>>>>>>>> I'm now of the opinion that moving the directory locations >>>>>>>>> for these sockets is a bad idea - it would need corresponding >>>>>>>>> changes in people's >>>>>>>>> sendmail configuration files, which would lead to problems for >>>>>>>>> people >>>>>>>>> doing package updates, or installing from upstream sources. >>>>>>>>> Setting different context types for the directories (e.g. make >>>>>>>>> /var/spool/milter-regex spamd_var_run_t) would seem a better >>>>>>>>> option, along with policy tweaks to allow sendmail to do the >>>>>>>>> permissions checks >>>>>>>>> and write to the sockets). >>>>>>>>> >>>>>>>>> I'm still confused about the initrc_t sockets though. >>>>>>>>> >>>>>>>>> Paul. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> fedora-selinux-list mailing list >>>>>>>>> fedora-selinux-list at redhat.com >>>>>>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>>>>>>> Ok I will add this to the next update. >>>>>>> What exactly is "this"? The 4 "allow" rules mentioned above, the >>>>>>> context >>>>>>> type change for /var/spool/milter-regex mentioned later, both? >>>>>>> >>>>>>> Cheers, Paul. >>>>>>> >>>>>> Context change for /var/spool/milter-regex to spamd_var_run_t. >>>>>> sendmail >>>>>> can already use sockets in this directory. >>>>> So that includes the: >>>>> >>>>> allow sendmail_t initrc_t:unix_stream_socket { read write >>>>> connectto } >>>>> >>>>> ? >>>>> >>>>> Cheers, Paul. >>>>> >>>> Nope. I don't know what is running as initrc_t and I would bet >>>> this is a leaked file descriptor. Or at least a redirectiron of >>>> stdin/stdout. >>> I don't think it's a leaked file descriptor - that would be >>> dontaudit-able, right? By not allowing communications with the >>> initrc_t:unix_stream_socket, the milter fails to work: >>> >>> ==> /var/log/audit/audit.log <== >>> type=AVC msg=audit(1200408212.783:142453): avc: denied >>> { connectto } for pid=7805 comm="sendmail" >>> path="/var/spool/milter-regex/sock" >>> scontext=system_u:system_r:sendmail_t:s0 >>> tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket >>> type=SYSCALL msg=audit(1200408212.783:142453): arch=40000003 >>> syscall=102 success=no exit=-13 a0=3 a1=bfd9f600 a2=b7f79bd4 a3=0 >>> items=0 ppid=7764 pid=7805 auid=0 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:sendmail_t:s0 key=(null) >>> >>> ==> /var/log/maillog <== >>> Jan 15 14:43:32 goalkeeper sendmail[7805]: NOQUEUE: connect from >>> ard120.neoplus.adsl.tpnet.pl [83.26.189.120] >>> Jan 15 14:43:32 goalkeeper sendmail[7805]: AUTH: available >>> mech=CRAM-MD5 DIGEST-MD5, allowed mech=CRAM-MD5 DIGEST-MD5 LOGIN >>> PLAIN Jan 15 14:43:32 goalkeeper sendmail[7805]: m0FEhW21007805: >>> Milter (milter-regex): error connecting to filter: Permission denied >>> Jan 15 14:43:32 goalkeeper sendmail[7805]: m0FEhW21007805: Milter >>> (milter-regex): to error state >>> Jan 15 14:43:32 goalkeeper sendmail[7805]: m0FEhW21007805: Milter: >>> initialization failed, temp failing commands >>> Jan 15 14:43:32 goalkeeper sendmail[7805]: m0FEhW21007805: SMTP MAIL >>> command () from >>> ard120.neoplus.adsl.tpnet.pl [83.26.189.120] tempfailed (due to >>> previous checks) >>> >>> >>> The initrc_t type shows up in netstat but not in ls: >>> # netstat -aZp | grep initrc >>> tcp 0 0 goalkeeper.intra.:bacula-fd *:* LISTEN >>> 5864/bacula-fd system_u:system_r:initrc_t:s0 >>> udp 0 0 rbldns.intra.cit:domain *:* >>> 5885/rbldnsd system_u:system_r:initrc_t:s0 >>> unix 2 [ ACC ] STREAM LISTENING 14142 >>> 5853/spamass-milter system_u:system_r:initrc_t:s0 >>> /var/run/spamass-milter/spamass-milter.sock >>> unix 2 [ ACC ] STREAM LISTENING 13794 >>> 5779/milter-regex system_u:system_r:initrc_t:s0 >>> /var/spool/milter-regex/sock >>> unix 2 [ ] DGRAM 2150436 >>> 5779/milter-regex system_u:system_r:initrc_t:s0 >>> unix 2 [ ] DGRAM 14141 >>> 5853/spamass-milter system_u:system_r:initrc_t:s0 >>> # ls -lZ /var/run/spamass-milter/spamass-milter.sock >>> /var/spool/milter-regex/sock >>> srwxr-xr-x sa-milt sa-milt system_u:object_r:spamd_var_run_t:s0 >>> /var/run/spamass-milter/spamass-milter.sock >>> srw------- mregex mregex system_u:object_r:spamd_var_run_t:s0 >>> /var/spool/milter-regex/sock >>> >>> >>> Paul. >>> >>> >> Ok then I guess we need to label >> >> chcon -t spamd_exec_t /usr/sbin/spamass-milter >> >> And then build policy off of that. > > Whilst that might result in a solution for spamass-milter, it's not > going to help milter-regex or potentially any other milter (they're all > likely to use the same libmilter [sendmail] API for setting up the > sockets). > > There seems to be something odd about sockets in general; the netstat > output quoted above shows a couple of network-listening sockets with > type initrc_t too, from a further two non-milter programs, namely > bacula and rbldnsd. I also see the same issue with nasd and rpc.quotad. > though I can also see a bunch of listening sockets with > system_u:system_r:unconfined_t on my desktop. > > Why might some of these apps transition to unconfined_t and others not? > > And why does "ls" show a different type than "netstat"? > > Paul. ls is showing file context and netstat is showing processes. Processes running as unconfined_t were started by unconfined_t without going through an initrc_exec_t type. So either you started these processes directly or the label of their start up script is wrong ls -lZ /etc/init.d/* restorecon -R -v /etc/init.d Should fix. So we need to allow sendmail to read sockets setup by initrc_t? Adding init_stream_connect_script(mailserver_delivery) init_rw_script_stream_sockets(mailserver_delivery) Will allow all programs that deliver mail to read/write/connectto initrc_t unix_stream_sockets. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeN6RgACgkQrlYvE4MpobPmKQCdGdL26St7vIulDPItjbYlo19U NJoAoJUKSnILXvPG15XjHH+53icvmsMd =LpHn -----END PGP SIGNATURE----- From paul at city-fan.org Wed Jan 16 11:46:56 2008 From: paul at city-fan.org (Paul Howarth) Date: Wed, 16 Jan 2008 11:46:56 +0000 Subject: Sendmail milters in Fedora 8 In-Reply-To: <478DE918.1080907@redhat.com> References: <477BC440.9000809@city-fan.org> <478B829C.1090606@city-fan.org> <478B9511.20006@redhat.com> <478B97A6.9050002@city-fan.org> <478B9AC3.9040500@redhat.com> <478B9C12.9000909@city-fan.org> <478BB879.2050604@redhat.com> <478CC7A4.6030008@city-fan.org> <478D0F2E.3050401@redhat.com> <20080116001617.6af19309@metropolis.intra.city-fan.org> <478DE918.1080907@redhat.com> Message-ID: <478DEEB0.3090008@city-fan.org> Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Paul Howarth wrote: >> On Tue, 15 Jan 2008 14:53:18 -0500 >> Daniel J Walsh wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Paul Howarth wrote: >>>> Daniel J Walsh wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> Paul Howarth wrote: >>>>>> Daniel J Walsh wrote: >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>> Hash: SHA1 >>>>>>> >>>>>>> Paul Howarth wrote: >>>>>>>> Hi Dan, >>>>>>>> >>>>>>>> Daniel J Walsh wrote: >>>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>>>> Hash: SHA1 >>>>>>>>> >>>>>>>>> Paul Howarth wrote: >>>>>>>>>> Paul Howarth wrote: >>>>>>>>>>> Since upgrading my mail server from Fedora 7 to Fedora 8, >>>>>>>>>>> I've come across some problems with the sockets used for >>>>>>>>>>> communication between >>>>>>>>>>> sendmail and two of the "milter" plugins I'm using with it, >>>>>>>>>>> namely milter-regex and spamass-milter. It's very likely >>>>>>>>>>> that other milters >>>>>>>>>>> will have similar issues. >>>>>>>>>>> >>>>>>>>>>> The sockets used are created when the milter starts, as >>>>>>>>>>> follows: >>>>>>>>>>> >>>>>>>>>>> milter-regex: >>>>>>>>>>> /var/spool/milter-regex/sock (var_spool_t, inherited from >>>>>>>>>>> parent directory) >>>>>>>>>>> >>>>>>>>>>> spamass-milter: >>>>>>>>>>> /var/run/spamass-milter/spamass-milter.sock >>>>>>>>>>> (spamd_var_run_t, in policy) >>>>>>>>>>> >>>>>>>>>>> These are pretty well the upstream locations, though I'm >>>>>>>>>>> open to moving the milter-regex socket from /var/spool >>>>>>>>>>> to /var/run or elsewhere for consistency. >>>>>>>>>>> >>>>>>>>>>> Since moving to Fedora 8, I've had to add the following to >>>>>>>>>>> local policy to get these milters working: >>>>>>>>>>> >>>>>>>>>>> allow sendmail_t spamd_var_run_t:dir { search getattr }; >>>>>>>>>>> allow sendmail_t spamd_var_run_t:sock_file { getattr write }; >>>>>>>>>>> allow sendmail_t var_spool_t:sock_file { getattr write }; >>>>>>>>>>> allow sendmail_t initrc_t:unix_stream_socket { read write >>>>>>>>>>> connectto }; >>>>>>>>>>> >>>>>>>>>>> The last of these is the strangest, and relates to Bug >>>>>>>>>>> #425958 >>>>>>>>>>> (https://bugzilla.redhat.com/show_bug.cgi?id=425958). Whilst >>>>>>>>>>> the socket file itself has the context listed above, the >>>>>>>>>>> unix domain socket that sendmail connects to is still >>>>>>>>>>> initrc_t, as can be seen from the output of "netstat -lpZ": >>>>>>>>>>> >>>>>>>>>>> ... >>>>>>>>>>> unix 2 [ ACC ] STREAM LISTENING 14142 >>>>>>>>>>> 5853/spamass-milter system_u:system_r:initrc_t:s0 >>>>>>>>>>> /var/run/spamass-milter/spamass-milter.sock >>>>>>>>>>> unix 2 [ ACC ] STREAM LISTENING 13794 >>>>>>>>>>> 5779/milter-regex system_u:system_r:initrc_t:s0 >>>>>>>>>>> /var/spool/milter-regex/sock >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> So, my questions are: >>>>>>>>>>> >>>>>>>>>>> 1. Why are the sockets still initrc_t? >>>>>>>>>>> 2. Is this a kernel issue or a userspace issue that should be >>>>>>>>>>> fixed in >>>>>>>>>>> the milters? >>>>>>>>>>> 3. Should there be a standard place for milter sockets to >>>>>>>>>>> live, and if >>>>>>>>>>> so, where? >>>>>>>>>>> 4. How come this worked OK in Fedora 7 and previous releases? >>>>>>>>>> Looking at the source code for these applications, I see that >>>>>>>>>> both of >>>>>>>>>> them use the smfi_setconn() function in the sendmail milter >>>>>>>>>> library to >>>>>>>>>> set up the sockets. It's therefore likely that this problem is >>>>>>>>>> common to >>>>>>>>>> all milter applications that use unix domain sockets. >>>>>>>>>> >>>>>>>>>> I'm now of the opinion that moving the directory locations >>>>>>>>>> for these sockets is a bad idea - it would need corresponding >>>>>>>>>> changes in people's >>>>>>>>>> sendmail configuration files, which would lead to problems for >>>>>>>>>> people >>>>>>>>>> doing package updates, or installing from upstream sources. >>>>>>>>>> Setting different context types for the directories (e.g. make >>>>>>>>>> /var/spool/milter-regex spamd_var_run_t) would seem a better >>>>>>>>>> option, along with policy tweaks to allow sendmail to do the >>>>>>>>>> permissions checks >>>>>>>>>> and write to the sockets). >>>>>>>>>> >>>>>>>>>> I'm still confused about the initrc_t sockets though. >>>>>>>>>> >>>>>>>>>> Paul. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> fedora-selinux-list mailing list >>>>>>>>>> fedora-selinux-list at redhat.com >>>>>>>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>>>>>>>> Ok I will add this to the next update. >>>>>>>> What exactly is "this"? The 4 "allow" rules mentioned above, the >>>>>>>> context >>>>>>>> type change for /var/spool/milter-regex mentioned later, both? >>>>>>>> >>>>>>>> Cheers, Paul. >>>>>>>> >>>>>>> Context change for /var/spool/milter-regex to spamd_var_run_t. >>>>>>> sendmail >>>>>>> can already use sockets in this directory. >>>>>> So that includes the: >>>>>> >>>>>> allow sendmail_t initrc_t:unix_stream_socket { read write >>>>>> connectto } >>>>>> >>>>>> ? >>>>>> >>>>>> Cheers, Paul. >>>>>> >>>>> Nope. I don't know what is running as initrc_t and I would bet >>>>> this is a leaked file descriptor. Or at least a redirectiron of >>>>> stdin/stdout. >>>> I don't think it's a leaked file descriptor - that would be >>>> dontaudit-able, right? By not allowing communications with the >>>> initrc_t:unix_stream_socket, the milter fails to work: >>>> >>>> ==> /var/log/audit/audit.log <== >>>> type=AVC msg=audit(1200408212.783:142453): avc: denied >>>> { connectto } for pid=7805 comm="sendmail" >>>> path="/var/spool/milter-regex/sock" >>>> scontext=system_u:system_r:sendmail_t:s0 >>>> tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket >>>> type=SYSCALL msg=audit(1200408212.783:142453): arch=40000003 >>>> syscall=102 success=no exit=-13 a0=3 a1=bfd9f600 a2=b7f79bd4 a3=0 >>>> items=0 ppid=7764 pid=7805 auid=0 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:sendmail_t:s0 key=(null) >>>> >>>> ==> /var/log/maillog <== >>>> Jan 15 14:43:32 goalkeeper sendmail[7805]: NOQUEUE: connect from >>>> ard120.neoplus.adsl.tpnet.pl [83.26.189.120] >>>> Jan 15 14:43:32 goalkeeper sendmail[7805]: AUTH: available >>>> mech=CRAM-MD5 DIGEST-MD5, allowed mech=CRAM-MD5 DIGEST-MD5 LOGIN >>>> PLAIN Jan 15 14:43:32 goalkeeper sendmail[7805]: m0FEhW21007805: >>>> Milter (milter-regex): error connecting to filter: Permission denied >>>> Jan 15 14:43:32 goalkeeper sendmail[7805]: m0FEhW21007805: Milter >>>> (milter-regex): to error state >>>> Jan 15 14:43:32 goalkeeper sendmail[7805]: m0FEhW21007805: Milter: >>>> initialization failed, temp failing commands >>>> Jan 15 14:43:32 goalkeeper sendmail[7805]: m0FEhW21007805: SMTP MAIL >>>> command () from >>>> ard120.neoplus.adsl.tpnet.pl [83.26.189.120] tempfailed (due to >>>> previous checks) >>>> >>>> >>>> The initrc_t type shows up in netstat but not in ls: >>>> # netstat -aZp | grep initrc >>>> tcp 0 0 goalkeeper.intra.:bacula-fd *:* LISTEN >>>> 5864/bacula-fd system_u:system_r:initrc_t:s0 >>>> udp 0 0 rbldns.intra.cit:domain *:* >>>> 5885/rbldnsd system_u:system_r:initrc_t:s0 >>>> unix 2 [ ACC ] STREAM LISTENING 14142 >>>> 5853/spamass-milter system_u:system_r:initrc_t:s0 >>>> /var/run/spamass-milter/spamass-milter.sock >>>> unix 2 [ ACC ] STREAM LISTENING 13794 >>>> 5779/milter-regex system_u:system_r:initrc_t:s0 >>>> /var/spool/milter-regex/sock >>>> unix 2 [ ] DGRAM 2150436 >>>> 5779/milter-regex system_u:system_r:initrc_t:s0 >>>> unix 2 [ ] DGRAM 14141 >>>> 5853/spamass-milter system_u:system_r:initrc_t:s0 >>>> # ls -lZ /var/run/spamass-milter/spamass-milter.sock >>>> /var/spool/milter-regex/sock >>>> srwxr-xr-x sa-milt sa-milt system_u:object_r:spamd_var_run_t:s0 >>>> /var/run/spamass-milter/spamass-milter.sock >>>> srw------- mregex mregex system_u:object_r:spamd_var_run_t:s0 >>>> /var/spool/milter-regex/sock >>>> >>>> >>>> Paul. >>>> >>>> >>> Ok then I guess we need to label >>> >>> chcon -t spamd_exec_t /usr/sbin/spamass-milter >>> >>> And then build policy off of that. >> Whilst that might result in a solution for spamass-milter, it's not >> going to help milter-regex or potentially any other milter (they're all >> likely to use the same libmilter [sendmail] API for setting up the >> sockets). >> >> There seems to be something odd about sockets in general; the netstat >> output quoted above shows a couple of network-listening sockets with >> type initrc_t too, from a further two non-milter programs, namely >> bacula and rbldnsd. I also see the same issue with nasd and rpc.quotad. >> though I can also see a bunch of listening sockets with >> system_u:system_r:unconfined_t on my desktop. >> >> Why might some of these apps transition to unconfined_t and others not? >> >> And why does "ls" show a different type than "netstat"? >> >> Paul. > ls is showing file context and netstat is showing processes. > > Processes running as unconfined_t were started by unconfined_t without > going through an initrc_exec_t type. So either you started these > processes directly or the label of their start up script is wrong > > ls -lZ /etc/init.d/* > > restorecon -R -v /etc/init.d > > Should fix. I suspect that the stuff running in unconfined_t gets started as part of a Gnome session rather than via an initscript. > So we need to allow sendmail to read sockets setup by initrc_t? Is it true to say (I think it is) that any process started via an initscript that doesn't transition to another domain (e.g. stuff that nobody has written policy for yet) will be in initrc_t? If so, the following is currently needed. > Adding > init_stream_connect_script(mailserver_delivery) > init_rw_script_stream_sockets(mailserver_delivery) > > > Will allow all programs that deliver mail to read/write/connectto > initrc_t unix_stream_sockets. This looks right for now, though I'm tempted to hack together policy for my two milters at least. What I was thinking of was creating a milter_template along the lines of the apache_content_template that could be used as a starting point for milter applications (all of which will communicate with sendmail [and postfix too for that metter] in the same way), and then add on anything necessary for each individual milter (some of which would require nothing else, some would require database connectivity etc.). Paul. From gene.heskett at verizon.net Wed Jan 16 13:33:06 2008 From: gene.heskett at verizon.net (Gene Heskett) Date: Wed, 16 Jan 2008 08:33:06 -0500 Subject: procmail vs amanda selinux hits Message-ID: <200801160833.06309.gene.heskett@verizon.net> Greetings; At about the time the backup program amanda is due to send me an email, I'm getting popups from selinux. Amanda is at times trying to send the user gene an email, some of which I do get, but: >From setroubleshoot: SUMMARY SELinux is preventing /usr/bin/procmail (procmail_t) "search" to (var_log_t). Detailed Description SELinux denied access requested by /usr/bin/procmail. It is not expected that this access is required by /usr/bin/procmail 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 FAQ Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report against this package. ===================================== Note the space before the comma above, is a name missing? Also I have not done the restorecon -v as I've used the advice from setroubleshooter to clear a goodly number of squawks. ===================================== Additional Information Source Context: system_u:system_r:procmail_t:s0 Target Context: system_u:object_r:var_log_t:s0 Target Objects: None [ dir ] Affected RPM Packages: procmail-3.22-20.fc8 [application] Policy RPM: selinux-policy-3.0.8-74.fc8Selinux Enabled: True Policy Type: targeted MLS Enabled: True Enforcing Mode: Enforcing Plugin Name: plugins.catchall_file Host Name: coyote.coyote.den Platform: Linux coyote.coyote.den 2.6.24-rc7 #1 SMP Mon Jan 14 10:00:40 EST 2008 i686 athlon Alert Count: 26 First Seen: Wed 09 Jan 2008 05:09:14 AM EST Last Seen: Wed 16 Jan 2008 05:09:15 AM EST Local ID: bfec6c3c-7d3b-47f7-9174-a2251b12534a Line Numbers: Raw Audit Messages :avc: denied { search } for comm=procmail dev=dm-0 egid=500 euid=500 exe=/usr/bin/procmail exit=-13 fsgid=500 fsuid=500 gid=500 items=0 name=log pid=15219 scontext=system_u:system_r:procmail_t:s0 sgid=0 subj=system_u:system_r:procmail_t:s0 suid=500 tclass=dir tcontext=system_u:object_r:var_log_t:s0 tty=(none) uid=500 Comments people? -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) It is better for civilization to be going down the drain than to be coming up it. -- Henry Allen From dwalsh at redhat.com Wed Jan 16 13:55:44 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 16 Jan 2008 08:55:44 -0500 Subject: Sendmail milters in Fedora 8 In-Reply-To: <478DEEB0.3090008@city-fan.org> References: <477BC440.9000809@city-fan.org> <478B829C.1090606@city-fan.org> <478B9511.20006@redhat.com> <478B97A6.9050002@city-fan.org> <478B9AC3.9040500@redhat.com> <478B9C12.9000909@city-fan.org> <478BB879.2050604@redhat.com> <478CC7A4.6030008@city-fan.org> <478D0F2E.3050401@redhat.com> <20080116001617.6af19309@metropolis.intra.city-fan.org> <478DE918.1080907@redhat.com> <478DEEB0.3090008@city-fan.org> Message-ID: <478E0CE0.7040004@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Howarth wrote: > Daniel J Walsh wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Paul Howarth wrote: >>> On Tue, 15 Jan 2008 14:53:18 -0500 >>> Daniel J Walsh wrote: >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Paul Howarth wrote: >>>>> Daniel J Walsh wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA1 >>>>>> >>>>>> Paul Howarth wrote: >>>>>>> Daniel J Walsh wrote: >>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>>> Hash: SHA1 >>>>>>>> >>>>>>>> Paul Howarth wrote: >>>>>>>>> Hi Dan, >>>>>>>>> >>>>>>>>> Daniel J Walsh wrote: >>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>>>>> Hash: SHA1 >>>>>>>>>> >>>>>>>>>> Paul Howarth wrote: >>>>>>>>>>> Paul Howarth wrote: >>>>>>>>>>>> Since upgrading my mail server from Fedora 7 to Fedora 8, >>>>>>>>>>>> I've come across some problems with the sockets used for >>>>>>>>>>>> communication between >>>>>>>>>>>> sendmail and two of the "milter" plugins I'm using with it, >>>>>>>>>>>> namely milter-regex and spamass-milter. It's very likely >>>>>>>>>>>> that other milters >>>>>>>>>>>> will have similar issues. >>>>>>>>>>>> >>>>>>>>>>>> The sockets used are created when the milter starts, as >>>>>>>>>>>> follows: >>>>>>>>>>>> >>>>>>>>>>>> milter-regex: >>>>>>>>>>>> /var/spool/milter-regex/sock (var_spool_t, inherited from >>>>>>>>>>>> parent directory) >>>>>>>>>>>> >>>>>>>>>>>> spamass-milter: >>>>>>>>>>>> /var/run/spamass-milter/spamass-milter.sock >>>>>>>>>>>> (spamd_var_run_t, in policy) >>>>>>>>>>>> >>>>>>>>>>>> These are pretty well the upstream locations, though I'm >>>>>>>>>>>> open to moving the milter-regex socket from /var/spool >>>>>>>>>>>> to /var/run or elsewhere for consistency. >>>>>>>>>>>> >>>>>>>>>>>> Since moving to Fedora 8, I've had to add the following to >>>>>>>>>>>> local policy to get these milters working: >>>>>>>>>>>> >>>>>>>>>>>> allow sendmail_t spamd_var_run_t:dir { search getattr }; >>>>>>>>>>>> allow sendmail_t spamd_var_run_t:sock_file { getattr write }; >>>>>>>>>>>> allow sendmail_t var_spool_t:sock_file { getattr write }; >>>>>>>>>>>> allow sendmail_t initrc_t:unix_stream_socket { read write >>>>>>>>>>>> connectto }; >>>>>>>>>>>> >>>>>>>>>>>> The last of these is the strangest, and relates to Bug >>>>>>>>>>>> #425958 >>>>>>>>>>>> (https://bugzilla.redhat.com/show_bug.cgi?id=425958). Whilst >>>>>>>>>>>> the socket file itself has the context listed above, the >>>>>>>>>>>> unix domain socket that sendmail connects to is still >>>>>>>>>>>> initrc_t, as can be seen from the output of "netstat -lpZ": >>>>>>>>>>>> >>>>>>>>>>>> ... >>>>>>>>>>>> unix 2 [ ACC ] STREAM LISTENING 14142 >>>>>>>>>>>> 5853/spamass-milter system_u:system_r:initrc_t:s0 >>>>>>>>>>>> /var/run/spamass-milter/spamass-milter.sock >>>>>>>>>>>> unix 2 [ ACC ] STREAM LISTENING 13794 >>>>>>>>>>>> 5779/milter-regex system_u:system_r:initrc_t:s0 >>>>>>>>>>>> /var/spool/milter-regex/sock >>>>>>>>>>>> ... >>>>>>>>>>>> >>>>>>>>>>>> So, my questions are: >>>>>>>>>>>> >>>>>>>>>>>> 1. Why are the sockets still initrc_t? >>>>>>>>>>>> 2. Is this a kernel issue or a userspace issue that should be >>>>>>>>>>>> fixed in >>>>>>>>>>>> the milters? >>>>>>>>>>>> 3. Should there be a standard place for milter sockets to >>>>>>>>>>>> live, and if >>>>>>>>>>>> so, where? >>>>>>>>>>>> 4. How come this worked OK in Fedora 7 and previous releases? >>>>>>>>>>> Looking at the source code for these applications, I see that >>>>>>>>>>> both of >>>>>>>>>>> them use the smfi_setconn() function in the sendmail milter >>>>>>>>>>> library to >>>>>>>>>>> set up the sockets. It's therefore likely that this problem is >>>>>>>>>>> common to >>>>>>>>>>> all milter applications that use unix domain sockets. >>>>>>>>>>> >>>>>>>>>>> I'm now of the opinion that moving the directory locations >>>>>>>>>>> for these sockets is a bad idea - it would need corresponding >>>>>>>>>>> changes in people's >>>>>>>>>>> sendmail configuration files, which would lead to problems for >>>>>>>>>>> people >>>>>>>>>>> doing package updates, or installing from upstream sources. >>>>>>>>>>> Setting different context types for the directories (e.g. make >>>>>>>>>>> /var/spool/milter-regex spamd_var_run_t) would seem a better >>>>>>>>>>> option, along with policy tweaks to allow sendmail to do the >>>>>>>>>>> permissions checks >>>>>>>>>>> and write to the sockets). >>>>>>>>>>> >>>>>>>>>>> I'm still confused about the initrc_t sockets though. >>>>>>>>>>> >>>>>>>>>>> Paul. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> fedora-selinux-list mailing list >>>>>>>>>>> fedora-selinux-list at redhat.com >>>>>>>>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>>>>>>>>> Ok I will add this to the next update. >>>>>>>>> What exactly is "this"? The 4 "allow" rules mentioned above, the >>>>>>>>> context >>>>>>>>> type change for /var/spool/milter-regex mentioned later, both? >>>>>>>>> >>>>>>>>> Cheers, Paul. >>>>>>>>> >>>>>>>> Context change for /var/spool/milter-regex to spamd_var_run_t. >>>>>>>> sendmail >>>>>>>> can already use sockets in this directory. >>>>>>> So that includes the: >>>>>>> >>>>>>> allow sendmail_t initrc_t:unix_stream_socket { read write >>>>>>> connectto } >>>>>>> >>>>>>> ? >>>>>>> >>>>>>> Cheers, Paul. >>>>>>> >>>>>> Nope. I don't know what is running as initrc_t and I would bet >>>>>> this is a leaked file descriptor. Or at least a redirectiron of >>>>>> stdin/stdout. >>>>> I don't think it's a leaked file descriptor - that would be >>>>> dontaudit-able, right? By not allowing communications with the >>>>> initrc_t:unix_stream_socket, the milter fails to work: >>>>> >>>>> ==> /var/log/audit/audit.log <== >>>>> type=AVC msg=audit(1200408212.783:142453): avc: denied >>>>> { connectto } for pid=7805 comm="sendmail" >>>>> path="/var/spool/milter-regex/sock" >>>>> scontext=system_u:system_r:sendmail_t:s0 >>>>> tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket >>>>> type=SYSCALL msg=audit(1200408212.783:142453): arch=40000003 >>>>> syscall=102 success=no exit=-13 a0=3 a1=bfd9f600 a2=b7f79bd4 a3=0 >>>>> items=0 ppid=7764 pid=7805 auid=0 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:sendmail_t:s0 key=(null) >>>>> >>>>> ==> /var/log/maillog <== >>>>> Jan 15 14:43:32 goalkeeper sendmail[7805]: NOQUEUE: connect from >>>>> ard120.neoplus.adsl.tpnet.pl [83.26.189.120] >>>>> Jan 15 14:43:32 goalkeeper sendmail[7805]: AUTH: available >>>>> mech=CRAM-MD5 DIGEST-MD5, allowed mech=CRAM-MD5 DIGEST-MD5 LOGIN >>>>> PLAIN Jan 15 14:43:32 goalkeeper sendmail[7805]: m0FEhW21007805: >>>>> Milter (milter-regex): error connecting to filter: Permission denied >>>>> Jan 15 14:43:32 goalkeeper sendmail[7805]: m0FEhW21007805: Milter >>>>> (milter-regex): to error state >>>>> Jan 15 14:43:32 goalkeeper sendmail[7805]: m0FEhW21007805: Milter: >>>>> initialization failed, temp failing commands >>>>> Jan 15 14:43:32 goalkeeper sendmail[7805]: m0FEhW21007805: SMTP MAIL >>>>> command () from >>>>> ard120.neoplus.adsl.tpnet.pl [83.26.189.120] tempfailed (due to >>>>> previous checks) >>>>> >>>>> >>>>> The initrc_t type shows up in netstat but not in ls: >>>>> # netstat -aZp | grep initrc >>>>> tcp 0 0 goalkeeper.intra.:bacula-fd *:* LISTEN >>>>> 5864/bacula-fd system_u:system_r:initrc_t:s0 >>>>> udp 0 0 rbldns.intra.cit:domain *:* >>>>> 5885/rbldnsd system_u:system_r:initrc_t:s0 >>>>> unix 2 [ ACC ] STREAM LISTENING 14142 >>>>> 5853/spamass-milter system_u:system_r:initrc_t:s0 >>>>> /var/run/spamass-milter/spamass-milter.sock >>>>> unix 2 [ ACC ] STREAM LISTENING 13794 >>>>> 5779/milter-regex system_u:system_r:initrc_t:s0 >>>>> /var/spool/milter-regex/sock >>>>> unix 2 [ ] DGRAM 2150436 >>>>> 5779/milter-regex system_u:system_r:initrc_t:s0 >>>>> unix 2 [ ] DGRAM 14141 >>>>> 5853/spamass-milter system_u:system_r:initrc_t:s0 >>>>> # ls -lZ /var/run/spamass-milter/spamass-milter.sock >>>>> /var/spool/milter-regex/sock >>>>> srwxr-xr-x sa-milt sa-milt system_u:object_r:spamd_var_run_t:s0 >>>>> /var/run/spamass-milter/spamass-milter.sock >>>>> srw------- mregex mregex system_u:object_r:spamd_var_run_t:s0 >>>>> /var/spool/milter-regex/sock >>>>> >>>>> >>>>> Paul. >>>>> >>>>> >>>> Ok then I guess we need to label >>>> >>>> chcon -t spamd_exec_t /usr/sbin/spamass-milter >>>> >>>> And then build policy off of that. >>> Whilst that might result in a solution for spamass-milter, it's not >>> going to help milter-regex or potentially any other milter (they're all >>> likely to use the same libmilter [sendmail] API for setting up the >>> sockets). >>> >>> There seems to be something odd about sockets in general; the netstat >>> output quoted above shows a couple of network-listening sockets with >>> type initrc_t too, from a further two non-milter programs, namely >>> bacula and rbldnsd. I also see the same issue with nasd and rpc.quotad. >>> though I can also see a bunch of listening sockets with >>> system_u:system_r:unconfined_t on my desktop. >>> >>> Why might some of these apps transition to unconfined_t and others not? >>> >>> And why does "ls" show a different type than "netstat"? >>> >>> Paul. >> ls is showing file context and netstat is showing processes. >> >> Processes running as unconfined_t were started by unconfined_t without >> going through an initrc_exec_t type. So either you started these >> processes directly or the label of their start up script is wrong >> >> ls -lZ /etc/init.d/* >> >> restorecon -R -v /etc/init.d >> >> Should fix. > > I suspect that the stuff running in unconfined_t gets started as part of > a Gnome session rather than via an initscript. > >> So we need to allow sendmail to read sockets setup by initrc_t? > > Is it true to say (I think it is) that any process started via an > initscript that doesn't transition to another domain (e.g. stuff that > nobody has written policy for yet) will be in initrc_t? > > If so, the following is currently needed. > >> Adding >> init_stream_connect_script(mailserver_delivery) >> init_rw_script_stream_sockets(mailserver_delivery) >> >> >> Will allow all programs that deliver mail to read/write/connectto >> initrc_t unix_stream_sockets. > > This looks right for now, though I'm tempted to hack together policy for > my two milters at least. What I was thinking of was creating a > milter_template along the lines of the apache_content_template that > could be used as a starting point for milter applications (all of which > will communicate with sendmail [and postfix too for that metter] in the > same way), and then add on anything necessary for each individual milter > (some of which would require nothing else, some would require database > connectivity etc.). > > Paul. > Sounds good. All daemons that do not have policy and start from init run as initrc_t which is unconfined. The problem is that if they exec a domain that is confined, the transition will happen, and the execed domain may need to communicate back to the initrc_t domain. So allowing maildelivery to communicate with initrc_t seems to make sense. inetd runs unknown domains as inetd_child_t which is also unconfined. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeODOAACgkQrlYvE4MpobNCKQCfffvmB23LbcLxfGFtx2eVwvxC wZIAoNxo4Tz9qkbQum5t7fPD2a2l3UPY =elyr -----END PGP SIGNATURE----- From dwalsh at redhat.com Wed Jan 16 13:58:39 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 16 Jan 2008 08:58:39 -0500 Subject: procmail vs amanda selinux hits In-Reply-To: <200801160833.06309.gene.heskett@verizon.net> References: <200801160833.06309.gene.heskett@verizon.net> Message-ID: <478E0D8F.80006@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gene Heskett wrote: > Greetings; > > At about the time the backup program amanda is due to send me an email, I'm > getting popups from selinux. > > Amanda is at times trying to send the user gene an email, some of which I do > get, but: > >>From setroubleshoot: > SUMMARY > SELinux is preventing /usr/bin/procmail (procmail_t) "search" to (var_log_t). > > Detailed Description > SELinux denied access requested by /usr/bin/procmail. It is not expected that > this access is required by /usr/bin/procmail 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 FAQ Or you can > disable SELinux protection altogether. Disabling SELinux protection is not > recommended. Please file a bug report against this package. > ===================================== > Note the space before the comma above, is a name missing? > Also I have not done the restorecon -v as I've used the advice from > setroubleshooter to clear a goodly number of squawks. > ===================================== > Additional Information > Source Context: system_u:system_r:procmail_t:s0 > Target Context: system_u:object_r:var_log_t:s0 > Target Objects: None [ dir ] > Affected RPM Packages: procmail-3.22-20.fc8 [application] > Policy RPM: selinux-policy-3.0.8-74.fc8Selinux > Enabled: True > Policy Type: targeted > MLS Enabled: True > Enforcing Mode: Enforcing > Plugin Name: plugins.catchall_file > Host Name: coyote.coyote.den > Platform: Linux coyote.coyote.den 2.6.24-rc7 #1 SMP Mon Jan 14 10:00:40 EST > 2008 i686 athlon > Alert Count: 26 > First Seen: Wed 09 Jan 2008 05:09:14 AM EST > Last Seen: Wed 16 Jan 2008 05:09:15 AM EST > Local ID: bfec6c3c-7d3b-47f7-9174-a2251b12534a > Line Numbers: > Raw Audit Messages :avc: denied { search } for comm=procmail dev=dm-0 egid=500 > euid=500 exe=/usr/bin/procmail exit=-13 fsgid=500 fsuid=500 gid=500 items=0 > name=log pid=15219 scontext=system_u:system_r:procmail_t:s0 sgid=0 > subj=system_u:system_r:procmail_t:s0 suid=500 tclass=dir > tcontext=system_u:object_r:var_log_t:s0 tty=(none) uid=500 > > Comments people? > Should be allowed. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeODY8ACgkQrlYvE4MpobPHKACcDKr66XLSfDV30clJPv1z1tJK 6E0AoOA5tGI518Ftz1r3/nfQrqDWh0HR =RCOf -----END PGP SIGNATURE----- From fedora02 at grifent.com Wed Jan 16 14:55:35 2008 From: fedora02 at grifent.com (John Griffiths) Date: Wed, 16 Jan 2008 09:55:35 -0500 Subject: postfix sendmail and GeoIP In-Reply-To: <20080116135551.77E8B736AC@hormel.redhat.com> References: <20080116135551.77E8B736AC@hormel.redhat.com> Message-ID: <478E1AE7.50402@grifent.com> I use postfix and installed GeoIP so that country of origin can be determined from the IP. postfix.sendmail is constrained so that it cannot read the GeoIP database file, /usr/share/GeoIP/GeoIP.dat . The AVC is: avc: denied { read } for comm=sendmail dev=dm-0 egid=48 euid=48 exe=/usr/sbin/sendmail.postfix exit=0 fsgid=48 fsuid=48 gid=48 items=0 path=/usr/share/GeoIP/GeoIP.dat pid=27728 scontext=system_u:system_r:system_mail_t:s0 sgid=48 subj=system_u:system_r:system_mail_t:s0 suid=48 tclass=file tcontext=system_u:object_r:usr_t:s0 tty=(none) uid=48 I ran audit2allow -M which produced the following policy: module postfixSendmail 1.0; require { type system_mail_t; type usr_t; class file read; } #============= system_mail_t ============== allow system_mail_t usr_t:file read; I don't think allowing postfix.sendmail to read all files of type usr_t is the right thing to do, yet, I do need to allow postfix.sendmail to read the GeoIP data file. Any suggestions? Regards, John From stefan at seekline.net Wed Jan 16 15:08:41 2008 From: stefan at seekline.net (Stefan Schulze Frielinghaus) Date: Wed, 16 Jan 2008 15:08:41 +0000 Subject: postfix sendmail and GeoIP In-Reply-To: <478E1AE7.50402@grifent.com> References: <20080116135551.77E8B736AC@hormel.redhat.com> <478E1AE7.50402@grifent.com> Message-ID: <1200496121.9596.3.camel@vogon> On Wed, 2008-01-16 at 09:55 -0500, John Griffiths wrote: > I use postfix and installed GeoIP so that country of origin can be > determined from the IP. postfix.sendmail is constrained so that it > cannot read the GeoIP database file, /usr/share/GeoIP/GeoIP.dat . > > The AVC is: > > avc: denied { read } for comm=sendmail dev=dm-0 egid=48 euid=48 > exe=/usr/sbin/sendmail.postfix exit=0 fsgid=48 fsuid=48 gid=48 > items=0 path=/usr/share/GeoIP/GeoIP.dat pid=27728 > scontext=system_u:system_r:system_mail_t:s0 sgid=48 > subj=system_u:system_r:system_mail_t:s0 suid=48 tclass=file > tcontext=system_u:object_r:usr_t:s0 tty=(none) uid=48 > > > I ran audit2allow -M which produced the following policy: > > module postfixSendmail 1.0; > > require { > type system_mail_t; > type usr_t; > class file read; > } > > #============= system_mail_t ============== > allow system_mail_t usr_t:file read; > > I don't think allowing postfix.sendmail to read all files of type usr_t > is the right thing to do, yet, I do need to allow postfix.sendmail to > read the GeoIP data file. > > Any suggestions? I think it's not a big problem allowing _read_ of usr_t files. If you really want to separate these files from others you could create a new type. But like I already mentioned usr_t files do not hold any confidential information (or at least they shouldn't). IMHO I would allow read access. -Stefan From wolfy at nobugconsulting.ro Wed Jan 16 15:31:39 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Wed, 16 Jan 2008 17:31:39 +0200 Subject: postfix sendmail and GeoIP In-Reply-To: <1200496121.9596.3.camel@vogon> References: <20080116135551.77E8B736AC@hormel.redhat.com> <478E1AE7.50402@grifent.com> <1200496121.9596.3.camel@vogon> Message-ID: <478E235B.4060802@nobugconsulting.ro> Stefan Schulze Frielinghaus wrote: > >> I ran audit2allow -M which produced the following policy: >> >> module postfixSendmail 1.0; >> >> require { >> type system_mail_t; >> type usr_t; >> class file read; >> } >> >> #============= system_mail_t ============== >> allow system_mail_t usr_t:file read; >> >> I don't think allowing postfix.sendmail to read all files of type usr_t >> is the right thing to do, yet, I do need to allow postfix.sendmail to >> read the GeoIP data file. >> >> Any suggestions? >> > > I think it's not a big problem allowing _read_ of usr_t files. If you > really want to separate these files from others you could create a new > type. But like I already mentioned usr_t files do not hold any > confidential information (or at least they shouldn't). IMHO I would > allow read access. > > -Stefan > > -- > + you could also add into equation the good old pre-selinux attributes and allow postfix.sendmail to read only from the desired dir. either setfacl or chmod o-rwx plus chgrp (or variants of this combination) would help here. From paul at city-fan.org Wed Jan 16 15:51:37 2008 From: paul at city-fan.org (Paul Howarth) Date: Wed, 16 Jan 2008 15:51:37 +0000 Subject: procmail vs amanda selinux hits In-Reply-To: <478E0D8F.80006@redhat.com> References: <200801160833.06309.gene.heskett@verizon.net> <478E0D8F.80006@redhat.com> Message-ID: <478E2809.3000808@city-fan.org> Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Gene Heskett wrote: >> Greetings; >> >> At about the time the backup program amanda is due to send me an email, I'm >> getting popups from selinux. >> >> Amanda is at times trying to send the user gene an email, some of which I do >> get, but: >> >> >From setroubleshoot: >> SUMMARY >> SELinux is preventing /usr/bin/procmail (procmail_t) "search" to (var_log_t). On a related matter, I sometimes like to use a system-wide procmail script (/etc/procmailrc) and have system-wide procmail logs to go with that, which can be done by putting in /etc/procmailrc something like: LOGFILE=/var/log/procmail.log or LOGFILE=/var/log/procmail/$LOGNAME Current policy doesn't cater for this, so I added: :::::::::::::: myprocmail.te :::::::::::::: policy_module(myprocmail, 0.5.6) require { type procmail_t; type sendmail_t; }; # log files type procmail_log_t; logging_log_file(procmail_log_t) # Write log to /var/log/procmail.log or /var/log/procmail/.* allow procmail_t procmail_log_t:dir setattr; create_files_pattern(procmail_t,procmail_log_t,procmail_log_t) append_files_pattern(procmail_t,procmail_log_t,procmail_log_t) read_lnk_files_pattern(procmail_t,procmail_log_t,procmail_log_t) logging_log_filetrans(procmail_t,procmail_log_t, { file dir }) # ============================================== # Procmail needs to call sendmail for forwarding # ============================================== # Read alternatives link (still not in policy?) corecmd_read_bin_symlinks(procmail_t) # Procmail occasionally signals sendmail, e.g. when it times out during forwarding sendmail_signal(procmail_t) :::::::::::::: myprocmail.fc :::::::::::::: /var/log/procmail\.log -- gen_context(system_u:object_r:procmail_log_t,s0) /var/log/procmail(/.*)? gen_context(system_u:object_r:procmail_log_t,s0) The last bits of policy are things I've had locally for a couple of Fedora releases now; not sure if they're in current policy but I think they should be. Cheers, Paul. From olivares14031 at yahoo.com Wed Jan 16 16:41:08 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Wed, 16 Jan 2008 08:41:08 -0800 (PST) Subject: SELinux is preventing access to files with the label, file_t. Message-ID: <99292.77345.qm@web52607.mail.re2.yahoo.com> Is anybody else seeing this? I have seen it before. I have not added other disks/drives. I do not know what file_t is? I ask why should I do this: "touch /.autorelabel; reboot" ? It takes a big while. I have already allowed a stack from new firefox3.0 beta. [root at localhost ~]# chcon -t unconfined_execmem_exec_t /usr/lib/firefox-3.0b3pre/firefox because it complains as well. 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 /tmp/virtual-olivares.p28akz [ dir ] Source tmpwatch(/usr/sbin/tmpwatch) Port Host localhost Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.2.5-12.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name file Host Name localhost Platform Linux localhost 2.6.24-0.150.rc7.git4.fc9 #1 SMP Sat Jan 12 11:44:09 EST 2008 i686 athlon Alert Count 1 First Seen Wed 16 Jan 2008 08:48:19 AM CST Last Seen Wed 16 Jan 2008 08:48:19 AM CST Local ID ac67f7f5-25da-43ef-8f11-682504e2a274 Line Numbers Raw Audit Messages host=localhost type=AVC msg=audit(1200494899.124:38): avc: denied { getattr } for pid=3073 comm="tmpwatch" path="/tmp/virtual-olivares.p28akz" dev=dm-0 ino=31391794 scontext=system_u:system_r:tmpreaper_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=dir host=localhost type=SYSCALL msg=audit(1200494899.124:38): arch=40000003 syscall=196 success=no exit=-13 a0=99f65bb a1=bfc24780 a2=5feff4 a3=99f6008 items=0 ppid=3071 pid=3073 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="tmpwatch" exe="/usr/sbin/tmpwatch" subj=system_u:system_r:tmpreaper_t:s0 key=(null) ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From paul at city-fan.org Wed Jan 16 16:46:07 2008 From: paul at city-fan.org (Paul Howarth) Date: Wed, 16 Jan 2008 16:46:07 +0000 Subject: Fedora 8 odds and sods Message-ID: <478E34CF.5000503@city-fan.org> Today I've done a bit of a clean-up of the local policy modules I've had in use over the last couple of Fedora releases, removing bits that are no longer needed and consolidating the remaining ones into a single "localmisc" module. The results of this is: policy_module(localmisc, 0.1.34) require { attribute mailserver_delivery; type depmod_t; type httpd_t; type load_policy_t; type procmail_t; type procmail_tmp_t; type pptp_t; type restorecon_t; type sendmail_t; type setfiles_t; type soundd_port_t; type squid_t; type useradd_t; type var_t; }; # ======================================== # Things that probably need to go upstream # ======================================== # Milter sockets, why did this work before? #allow sendmail_t initrc_t:unix_stream_socket { read write connectto }; init_stream_connect_script(mailserver_delivery) init_rw_script_stream_sockets(mailserver_delivery) # Allow misc command output to be sent to a pipe, needed for rpm scriptlets # Probably not needed since Fedora 8 #unconfined_rw_pipes(depmod_t) #unconfined_rw_pipes(load_policy_t) #unconfined_rw_pipes(setfiles_t) #unconfined_rw_pipes(useradd_t) # Allow pptp to manage its own processes allow pptp_t self:process signal; # Allow sendmail to read procmail tempfiles for forwarding # (would need a new interface in procmail.if to do this properly) allow sendmail_t procmail_tmp_t:file { read write getattr ioctl }; # Not sure what this is, needed when network is congested allow sendmail_t self:process signull; # ============== # Local oddities # ============== # Allow restorecon to restore file contexts via the /var/www -> /srv/www symlink allow restorecon_t var_t:lnk_file read; # Allow httpd to read /var/www -> /srv/www symlink allow httpd_t var_t:lnk_file { getattr read }; # Allow squid to connect to websites on port 8000 (defined in policy as soundd_port_t) allow squid_t soundd_port_t:tcp_socket name_connect; Not a lot left there, so I thought I'd post them here in their entirety for discussion and hopefully inclusion (at least in part) in a future policy update. Paul. From wart at kobold.org Wed Jan 16 17:05:55 2008 From: wart at kobold.org (Michael Thomas) Date: Wed, 16 Jan 2008 12:05:55 -0500 Subject: more avc denials Message-ID: <478E3973.3040107@kobold.org> While testing some changes to the cyphesis selinux module in Rawhide, I started getting the following denials: type=AVC msg=audit(1200547499.303:66): avc: denied { write } for pid=2722 comm="cyphesis" name="context" dev=selinuxfs ino=5 scontext=unconfined_u:system_r:cyphesis_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=file type=AVC msg=audit(1200547499.303:67): avc: denied { check_context } for pid=2722 comm="cyphesis" scontext=unconfined_u:system_r:cyphesis_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=security What would cause these? --Wart From dpquigl at tycho.nsa.gov Wed Jan 16 17:08:19 2008 From: dpquigl at tycho.nsa.gov (Dave Quigley) Date: Wed, 16 Jan 2008 12:08:19 -0500 Subject: postfix sendmail and GeoIP In-Reply-To: <478E1AE7.50402@grifent.com> References: <20080116135551.77E8B736AC@hormel.redhat.com> <478E1AE7.50402@grifent.com> Message-ID: <1200503299.2851.26.camel@moss-terrapins.epoch.ncsc.mil> On Wed, 2008-01-16 at 09:55 -0500, John Griffiths wrote: > I use postfix and installed GeoIP so that country of origin can be > determined from the IP. postfix.sendmail is constrained so that it > cannot read the GeoIP database file, /usr/share/GeoIP/GeoIP.dat . > > The AVC is: > > avc: denied { read } for comm=sendmail dev=dm-0 egid=48 euid=48 > exe=/usr/sbin/sendmail.postfix exit=0 fsgid=48 fsuid=48 gid=48 > items=0 path=/usr/share/GeoIP/GeoIP.dat pid=27728 > scontext=system_u:system_r:system_mail_t:s0 sgid=48 > subj=system_u:system_r:system_mail_t:s0 suid=48 tclass=file > tcontext=system_u:object_r:usr_t:s0 tty=(none) uid=48 > > > I ran audit2allow -M which produced the following policy: > > module postfixSendmail 1.0; > > require { > type system_mail_t; > type usr_t; > class file read; > } > > #============= system_mail_t ============== > allow system_mail_t usr_t:file read; > > I don't think allowing postfix.sendmail to read all files of type usr_t > is the right thing to do, yet, I do need to allow postfix.sendmail to > read the GeoIP data file. > > Any suggestions? > > Regards, > John > > -- If you want the resource to have its own type you could modify the policy you have to look like something below. Note this hasn't been tested in any way so your mileage may vary. The the fc file will make sure that the file gets relabeled properly. I haven't worked with modular policy much so I may have missed something. postfixSendmail.te module postfixSendmail 1.0; require { type system_mail_t; class file read; } type geoip_usr_t; #============= system_mail_t ============== allow system_mail_t geoip_usr_t:file read; postfixSendmail.fc /usr/share/GeoIP/GeoIP.dat -- sustem_u:object_r:geoip_usr_t:s0 > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From sds at tycho.nsa.gov Wed Jan 16 18:08:58 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 16 Jan 2008 13:08:58 -0500 Subject: more avc denials In-Reply-To: <478E3973.3040107@kobold.org> References: <478E3973.3040107@kobold.org> Message-ID: <1200506938.9669.150.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-01-16 at 12:05 -0500, Michael Thomas wrote: > While testing some changes to the cyphesis selinux module in Rawhide, I > started getting the following denials: > > type=AVC msg=audit(1200547499.303:66): avc: denied { write } for > pid=2722 comm="cyphesis" name="context" dev=selinuxfs ino=5 > scontext=unconfined_u:system_r:cyphesis_t:s0 > tcontext=system_u:object_r:security_t:s0 tclass=file > type=AVC msg=audit(1200547499.303:67): avc: denied { check_context } > for pid=2722 comm="cyphesis" > scontext=unconfined_u:system_r:cyphesis_t:s0 > tcontext=system_u:object_r:security_t:s0 tclass=security > > What would cause these? That suggests that cyphesis is invoking a libselinux function that is validating a security context (by writing to /selinux/context). Would be allowed by selinux_validate_context(cyphesis_t), if using refpolicy interfaces and building via make -f /usr/share/selinux/devel/Makefile. -- Stephen Smalley National Security Agency From choeger at cs.tu-berlin.de Wed Jan 16 19:53:55 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Wed, 16 Jan 2008 20:53:55 +0100 Subject: Feature request: Tomcat5-Policy In-Reply-To: <1199115888.3197.1.camel@choeger4> References: <1199115888.3197.1.camel@choeger4> Message-ID: <1200513236.5919.2.camel@choeger4> has no one a comment? I'd never thought, that tomcat was _that_ secure. Am Montag, den 31.12.2007, 16:44 +0100 schrieb Christoph H?ger: > Hi, > > here is a sample policy for Tomcat5. Could we integrate this (or a > reviewed and much better version) into fedora? > > regards > > christoph > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From gene.heskett at verizon.net Thu Jan 17 02:12:49 2008 From: gene.heskett at verizon.net (Gene Heskett) Date: Wed, 16 Jan 2008 21:12:49 -0500 Subject: procmail vs amanda selinux hits In-Reply-To: <478E2809.3000808@city-fan.org> References: <200801160833.06309.gene.heskett@verizon.net> <478E0D8F.80006@redhat.com> <478E2809.3000808@city-fan.org> Message-ID: <200801162112.50238.gene.heskett@verizon.net> On Wednesday 16 January 2008, Paul Howarth wrote: >Daniel J Walsh wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Gene Heskett wrote: >>> Greetings; >>> >>> At about the time the backup program amanda is due to send me an email, >>> I'm getting popups from selinux. >>> >>> Amanda is at times trying to send the user gene an email, some of which I >>> do >>> >>> get, but: >>> >From setroubleshoot: >>> >>> SUMMARY >>> SELinux is preventing /usr/bin/procmail (procmail_t) "search" to >>> (var_log_t). > >On a related matter, I sometimes like to use a system-wide procmail >script (/etc/procmailrc) and have system-wide procmail logs to go with >that, which can be done by putting in /etc/procmailrc something like: > >LOGFILE=/var/log/procmail.log >or >LOGFILE=/var/log/procmail/$LOGNAME > >Current policy doesn't cater for this, so I added: > > >myprocmail.te > >policy_module(myprocmail, 0.5.6) > >require { > type procmail_t; > type sendmail_t; >}; > ># log files >type procmail_log_t; >logging_log_file(procmail_log_t) > ># Write log to /var/log/procmail.log or /var/log/procmail/.* >allow procmail_t procmail_log_t:dir setattr; >create_files_pattern(procmail_t,procmail_log_t,procmail_log_t) >append_files_pattern(procmail_t,procmail_log_t,procmail_log_t) >read_lnk_files_pattern(procmail_t,procmail_log_t,procmail_log_t) >logging_log_filetrans(procmail_t,procmail_log_t, { file dir }) > ># ============================================== ># Procmail needs to call sendmail for forwarding ># ============================================== > ># Read alternatives link (still not in policy?) >corecmd_read_bin_symlinks(procmail_t) > ># Procmail occasionally signals sendmail, e.g. when it times out during >forwarding >sendmail_signal(procmail_t) > > >myprocmail.fc > >/var/log/procmail\.log -- >gen_context(system_u:object_r:procmail_log_t,s0) >/var/log/procmail(/.*)? >gen_context(system_u:object_r:procmail_log_t,s0) > > > > > >The last bits of policy are things I've had locally for a couple of >Fedora releases now; not sure if they're in current policy but I think >they should be. > >Cheers, Paul. > Thanks guys, it sounds like the next release will fix this. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If A equals success, then the formula is _A = _X + _Y + _Z. _X is work. _Y is play. _Z is keep your mouth shut. -- Albert Einstein From dwalsh at redhat.com Thu Jan 17 17:42:39 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 17 Jan 2008 12:42:39 -0500 Subject: SELinux is preventing access to files with the label, file_t. In-Reply-To: <200801162057.35862.opensource@till.name> References: <99292.77345.qm@web52607.mail.re2.yahoo.com> <200801162057.35862.opensource@till.name> Message-ID: <478F938F.5020600@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Till Maas wrote: > On Wed January 16 2008, Antonio Olivares wrote: > >> I have seen it before. I have not added other >> disks/drives. I do not know what file_t is? > > file_t is the type/context of files that are not really labeled. > >> I ask why should I do this: >> >> "touch /.autorelabel; reboot" >> ? > > These should apply the correct context on all files, maybe in you case running > restorecon (man restorecon) is enough, too. This does not require a reboot. > But I do not know more about this issue. > > Regards, > Till > Yes file_t means you have a file with no label on it. If you are adding a new disk drive with existing files, you can end up with this, or if you turn on SELinux on a machine that did not have it before, this can happen. (Although when Fedora boots it is supposed to realize SELinux is turned no and the machine needs to be labeled.) touch /.autorelabel; reboot will relabel the entire machine. But if you are just adding a new disk you could just execute restorecon -R -v PATHTOMOUNTPOINT And that will fix it. You can also mount the disk using context=system_u:object_r:TYPE_t:s0 and not add labels at all. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkePk48ACgkQrlYvE4MpobPfLQCffGROjw2lUETDIlET1vj//PkY VQsAn23zFdSm0TYnR4CmEmKG8WEwVVIY =vMDe -----END PGP SIGNATURE----- From Valdis.Kletnieks at vt.edu Fri Jan 18 07:51:01 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 18 Jan 2008 02:51:01 -0500 Subject: 2.6.24-rc8-mm1 and SELinux MLS - not playing nice.... Message-ID: <15439.1200642661@turing-police.cc.vt.edu> Posting to both lists because I'm not sure who's at fault here.... System is a Dell Latitude D820, x86_64 kernel, userspace is basically Fedora Rawhide as of earlier today, in particular selinux-policy-mls-3.2.5-12.fc9 Trying to boot a 2.6.24-rc8-mm1 kernel gets me these msgs: security: 5 users, 8 roles, 2043 types, 102 bools, 16 sens, 1024 cats security: 67 classes, 164754 rules security: class peer not defined in policy security: permission recvfrom in class node not defined in policy security: permission sendto in class node not defined in policy security: permission ingress in class netif not defined in policy security: permission egress in class netif not defined in policy security: permission forward_in in class packet not found in policy, bad policy security: the definition of a class is incorrect 2.6.24-rc6-mm1 said this instead: security: class peer not defined in policy security: permission recvfrom in class node not defined in policy security: permission sendto in class node not defined in policy security: permission ingress in class netif not defined in policy security: permission egress in class netif not defined in policy SELinux: policy loaded with handle_unknown=deny and then proceeded to work OK. (I suspect this may be the same thing Andrew Morton hit, but I can't be sure). Anybody got hints on how to move forward? Or is a fixed policy already in the Rawhide pipe? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From jmorris at namei.org Fri Jan 18 09:17:00 2008 From: jmorris at namei.org (James Morris) Date: Fri, 18 Jan 2008 20:17:00 +1100 (EST) Subject: 2.6.24-rc8-mm1 and SELinux MLS - not playing nice.... In-Reply-To: <15439.1200642661@turing-police.cc.vt.edu> References: <15439.1200642661@turing-police.cc.vt.edu> Message-ID: On Fri, 18 Jan 2008, Valdis.Kletnieks at vt.edu wrote: > Posting to both lists because I'm not sure who's at fault here.... > > System is a Dell Latitude D820, x86_64 kernel, userspace is basically > Fedora Rawhide as of earlier today, in particular selinux-policy-mls-3.2.5-12.fc9 > > Trying to boot a 2.6.24-rc8-mm1 kernel gets me these msgs: > > security: 5 users, 8 roles, 2043 types, 102 bools, 16 sens, 1024 cats > security: 67 classes, 164754 rules > security: class peer not defined in policy > security: permission recvfrom in class node not defined in policy > security: permission sendto in class node not defined in policy > security: permission ingress in class netif not defined in policy > security: permission egress in class netif not defined in policy > security: permission forward_in in class packet not found in policy, bad policy > security: the definition of a class is incorrect This looks the same as what akpm hit. Paul Moore has updated his labeled networking patches (see Subject: [RFC PATCH v12 00/18] Labeled networking changes for 2.6.25), and you could try dropping those into the broken out -mm in place of the existing git patch, or just wait for a new -mm. > > 2.6.24-rc6-mm1 said this instead: > > security: class peer not defined in policy > security: permission recvfrom in class node not defined in policy > security: permission sendto in class node not defined in policy > security: permission ingress in class netif not defined in policy > security: permission egress in class netif not defined in policy > SELinux: policy loaded with handle_unknown=deny > > and then proceeded to work OK. > > (I suspect this may be the same thing Andrew Morton hit, but I can't be sure). > > Anybody got hints on how to move forward? Or is a fixed policy already in the > Rawhide pipe? > > -- James Morris From tony.molloy at ul.ie Fri Jan 18 12:49:58 2008 From: tony.molloy at ul.ie (Tony Molloy) Date: Fri, 18 Jan 2008 12:49:58 +0000 Subject: Relabeling User home directories Message-ID: <200801181249.58975.tony.molloy@ul.ie> Hi, First of all this is a SElinux question on a CentOS File server rather than Fedora but I don't think that should make any difference. The clients are Fedora. For historical reasons we mount our user home directories under /users instead of /home. During a recent installation of CentOS-5 the user home directories appear to have been relabeled. Many now seem to have the type default_t drwx------ 8237 csim root:object_r:default_t x0667617 If I unmount the users directories and mount them under /home can I use restorecon -v /home to restore the correct file contexts as I understand that SElinux understands /home is for user directories. Also if I can do that will the command understand public_html directories have to be labelled so that apache can access them. Thanks Tony From dwalsh at redhat.com Fri Jan 18 13:36:14 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 18 Jan 2008 08:36:14 -0500 Subject: Relabeling User home directories In-Reply-To: <200801181249.58975.tony.molloy@ul.ie> References: <200801181249.58975.tony.molloy@ul.ie> Message-ID: <4790AB4E.6060508@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tony Molloy wrote: > Hi, > > First of all this is a SElinux question on a CentOS File server rather than > Fedora but I don't think that should make any difference. The clients are > Fedora. > > For historical reasons we mount our user home directories under /users instead > of /home. During a recent installation of CentOS-5 the user home directories > appear to have been relabeled. Many now seem to have the type default_t > > drwx------ 8237 csim root:object_r:default_t x0667617 > > If I unmount the users directories and mount them under /home can I use > restorecon -v /home to restore the correct file contexts as I understand that > SElinux understands /home is for user directories. Also if I can do that will > the command understand public_html directories have to be labelled so that > apache can access them. Yes. restorecon -R -v /home Should label home dirs correctly and public_html. SELinux is supposed to figure out that homedirs are mounted under /users and label that correctly. Could you give an example of a homedir entry in /etc/passwd? genhomedircon is supposed to setup file labeling for alternate home dir locations. > > Thanks > > Tony > > -- > 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 iEYEARECAAYFAkeQq00ACgkQrlYvE4MpobMDRQCg1JpiBSq9kVjtOFA7/SAOfHUH XYsAnRUx71D6OZvGMCxPon74TUgbXacR =qLbT -----END PGP SIGNATURE----- From selinux at gmail.com Sat Jan 19 18:56:59 2008 From: selinux at gmail.com (Tom London) Date: Sat, 19 Jan 2008 10:56:59 -0800 Subject: wpa_supplicant, NetworkManager_t & inotifyfs_t AVC Message-ID: <4c4ba1530801191056h58e77e3ei8004462aa37bdcdf@mail.gmail.com> Running latest rawhide, targeted/enforcing (selinux-policy-3.2.5-12.fc9). Notice the following AVC in audit.log type=AVC msg=audit(1200767626.005:18): avc: denied { read } for pid=2725 comm="wpa_supplicant" path="inotify" dev=inotifyfs ino=1 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:inotifyfs_t:s0 tclass=dir type=SYSCALL msg=audit(1200767626.005:18): arch=40000003 syscall=11 success=yes exit=0 a0=8619fd8 a1=8619c78 a2=8619008 a3=de799c items=0 ppid=2724 pid=2725 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="wpa_supplicant" exe="/usr/sbin/wpa_supplicant" subj=system_u:system_r:NetworkManager_t:s0 key=(null) type=ANOM_ABEND msg=audit(1200767646.778:19): auid=4294967295 uid=42 gid=42 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 pid=2742 comm="dbus-launch" sig=6 #============= NetworkManager_t ============== allow NetworkManager_t inotifyfs_t:dir read; Appears to be generated before gdm login; sort of looks like when NetworkManager is started by init. Not exactly sure where to BZ..... wpa_supplicant? NetworkManager? inotify? tom -- Tom London From gene.heskett at verizon.net Sat Jan 19 22:14:02 2008 From: gene.heskett at verizon.net (Gene Heskett) Date: Sat, 19 Jan 2008 17:14:02 -0500 Subject: procmail revisited, and now squid Message-ID: <200801191714.02900.gene.heskett@verizon.net> Greetings; The last policy update didn't fix my procmail problems yet, in fact it made them worse cuz now I'm getting failure messages in its logfile that I wasn't before. procmail, setroubleshoot output: Source Context:??system_u:system_r:procmail_t:s0 Target Context:??unconfined_u:object_r:var_log_t:s0 Target Objects:??None [ file ] Affected RPM Packages:??procmail-3.22-20.fc8 [application] Policy RPM:??selinux-policy-3.0.8-74.fc8 Selinux Enabled:??True Policy Type:??targeted MLS Enabled:??True Enforcing Mode:??Enforcing Plugin Name:??plugins.mislabeled_file Host Name:??coyote.coyote.den Platform:??Linux coyote.coyote.den 2.6.24-rc8 #2 SMP Wed Jan 16 22:47:57 EST 2008 i686 athlon Alert Count:??3 First Seen:??Sat 19 Jan 2008 01:50:20 AM EST Last Seen:??Sat 19 Jan 2008 05:09:16 AM EST Local ID:??3114f17d-0dc1-4453-ad4c-3b3548003cc4 Line Numbers:??Raw Audit Messages : avc: denied { append } for comm=procmail dev=dm-0 egid=500 euid=500 exe=/usr/bin/procmail exit=-13 fsgid=500 fsuid=500 gid=500 items=0 name=procmail.log pid=10138 scontext=system_u:system_r:procmail_t:s0 sgid=0 subj=system_u:system_r:procmail_t:s0 suid=500 tclass=file tcontext=unconfined_u:object_r:var_log_t:s0 tty=(none) uid=500 I note that the Last Seen time is before I did an autorelabel this morning. And now, trying to setup squid, I'm failing that: Source Context:??system_u:system_r:squid_t:s0 Target Context:??system_u:object_r:var_spool_t:s0 Target Objects:??None [ dir ] Affected RPM Packages:??squid-2.6.STABLE17-1.fc8 [application] Policy RPM:??selinux-policy-3.0.8-74.fc8 Selinux Enabled:??True Policy Type:??targeted MLS Enabled:??True Enforcing Mode:??Enforcing Plugin Name:??plugins.mislabeled_file Host Name:??coyote.coyote.den Platform:??Linux coyote.coyote.den 2.6.24-rc8 #2 SMP Wed Jan 16 22:47:57 EST 2008 i686 athlon Alert Count:??3 First Seen:??Sat 19 Jan 2008 02:29:31 PM EST Last Seen:??Sat 19 Jan 2008 04:43:50 PM EST Local ID:??1eb62793-1368-45b9-b0c0-c117f10dafd4 Line Numbers:??Raw Audit Messages : avc: denied { write } for comm=squid dev=dm-0 egid=23 euid=23 exe=/usr/sbin/squid exit=-13 fsgid=23 fsuid=23 gid=23 items=0 name=squid pid=17099 scontext=system_u:system_r:squid_t:s0 sgid=23 subj=system_u:system_r:squid_t:s0 suid=0 tclass=dir tcontext=system_u:object_r:var_spool_t:s0 tty=pts9 uid=23 For squid, I hand made its parent /var/spool/squid dir, and chowned it to squid:squid but the exact same failure occurs as it is trying to setup its cache dirs within that dir, so I gave it up. Its logs gets a new stanza of this: squid: ERROR: No running copy 2008/01/19 14:29:31| Creating Swap Directories FATAL: Failed to make swap directory /var/spool/squid/00: (13) Permission denied Squid Cache (Version 2.6.STABLE17): Terminated abnormally. CPU Usage: 0.001 seconds = 0.001 user + 0.000 sys Maximum Resident Size: 0 KB Page faults with physical i/o: 0 for everytime I attempt a 'service squid start' Can we make these work please? setroubleshooter's suggestions about running restorecon are rather worthless without the rest of the command line as an example cuz I have NDI what the file should be relabeled as. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) In my experience, if you have to keep the lavatory door shut by extending your left leg, it's modern architecture. -- Nancy Banks Smith From Valdis.Kletnieks at vt.edu Sun Jan 20 05:01:41 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 20 Jan 2008 00:01:41 -0500 Subject: 2.6.24-rc8-mm1 and SELinux MLS - not playing nice.... In-Reply-To: Your message of "Fri, 18 Jan 2008 20:17:00 +1100." References: <15439.1200642661@turing-police.cc.vt.edu> Message-ID: <3757.1200805301@turing-police.cc.vt.edu> On Fri, 18 Jan 2008 20:17:00 +1100, James Morris said: > This looks the same as what akpm hit. Paul Moore has updated his labeled > networking patches (see Subject: [RFC PATCH v12 00/18] Labeled networking > changes for 2.6.25), and you could try dropping those into the broken out > -mm in place of the existing git patch, or just wait for a new -mm. Confirming - I took V12 0-18, cat'ed it into one file, plopped that on top of the broken-out/git-lblnet.patch and quilted up a test -rc8-mm1 and that booted without complaints - dmesg says: SELinux:8192 avtab hash slots allocated. Num of rules:164754 SELinux:8192 avtab hash slots allocated. Num of rules:164754 security: 5 users, 8 roles, 2043 types, 102 bools, 16 sens, 1024 cats security: 67 classes, 164754 rules security: class peer not defined in policy security: permission recvfrom in class node not defined in policy security: permission sendto in class node not defined in policy security: permission ingress in class netif not defined in policy security: permission egress in class netif not defined in policy security: permission forward_in in class packet not defined in policy security: permission forward_out in class packet not defined in policy SELinux: Completing initialization. SELinux: Setting up existing superblocks. SELinux: initialized (dev dm-0, type ext3), uses xattr SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts SELinux: initialized (dev configfs, type configfs), uses genfs_contexts SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs SELinux: initialized (dev devpts, type devpts), uses transition SIDs SELinux: initialized (dev inotifyfs, type inotifyfs), uses genfs_contexts SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts SELinux: initialized (dev anon_inodefs, type anon_inodefs), uses genfs_contexts SELinux: initialized (dev pipefs, type pipefs), uses task SIDs SELinux: initialized (dev sockfs, type sockfs), uses task SIDs SELinux: initialized (dev proc, type proc), uses genfs_contexts SELinux: initialized (dev bdev, type bdev), uses genfs_contexts SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts SELinux: policy loaded with handle_unknown=deny type=1403 audit(1200804071.837:2): policy loaded auid=4294967295 ses=4294967295 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From jmorris at namei.org Sun Jan 20 22:10:40 2008 From: jmorris at namei.org (James Morris) Date: Mon, 21 Jan 2008 09:10:40 +1100 (EST) Subject: 2.6.24-rc8-mm1 and SELinux MLS - not playing nice.... In-Reply-To: <3757.1200805301@turing-police.cc.vt.edu> References: <15439.1200642661@turing-police.cc.vt.edu> <3757.1200805301@turing-police.cc.vt.edu> Message-ID: On Sun, 20 Jan 2008, Valdis.Kletnieks at vt.edu wrote: > On Fri, 18 Jan 2008 20:17:00 +1100, James Morris said: > > > This looks the same as what akpm hit. Paul Moore has updated his labeled > > networking patches (see Subject: [RFC PATCH v12 00/18] Labeled networking > > changes for 2.6.25), and you could try dropping those into the broken out > > -mm in place of the existing git patch, or just wait for a new -mm. > > Confirming - I took V12 0-18, cat'ed it into one file, plopped that on top > of the broken-out/git-lblnet.patch and quilted up a test -rc8-mm1 and that > booted without complaints - dmesg says: Thanks for testing this! > > SELinux:8192 avtab hash slots allocated. Num of rules:164754 > SELinux:8192 avtab hash slots allocated. Num of rules:164754 > security: 5 users, 8 roles, 2043 types, 102 bools, 16 sens, 1024 cats > security: 67 classes, 164754 rules > security: class peer not defined in policy > security: permission recvfrom in class node not defined in policy > security: permission sendto in class node not defined in policy > security: permission ingress in class netif not defined in policy > security: permission egress in class netif not defined in policy > security: permission forward_in in class packet not defined in policy > security: permission forward_out in class packet not defined in policy > SELinux: Completing initialization. > SELinux: Setting up existing superblocks. > SELinux: initialized (dev dm-0, type ext3), uses xattr > SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs > SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts > SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts > SELinux: initialized (dev configfs, type configfs), uses genfs_contexts > SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts > SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs > SELinux: initialized (dev devpts, type devpts), uses transition SIDs > SELinux: initialized (dev inotifyfs, type inotifyfs), uses genfs_contexts > SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs > SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts > SELinux: initialized (dev anon_inodefs, type anon_inodefs), uses genfs_contexts > SELinux: initialized (dev pipefs, type pipefs), uses task SIDs > SELinux: initialized (dev sockfs, type sockfs), uses task SIDs > SELinux: initialized (dev proc, type proc), uses genfs_contexts > SELinux: initialized (dev bdev, type bdev), uses genfs_contexts > SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts > SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts > SELinux: policy loaded with handle_unknown=deny > type=1403 audit(1200804071.837:2): policy loaded auid=4294967295 ses=4294967295 > > > -- James Morris From paul at city-fan.org Mon Jan 21 12:24:52 2008 From: paul at city-fan.org (Paul Howarth) Date: Mon, 21 Jan 2008 12:24:52 +0000 Subject: procmail revisited, and now squid In-Reply-To: <200801191714.02900.gene.heskett@verizon.net> References: <200801191714.02900.gene.heskett@verizon.net> Message-ID: <47948F14.8020807@city-fan.org> Gene Heskett wrote: > Greetings; > > The last policy update didn't fix my procmail problems yet, in fact it made > them worse cuz now I'm getting failure messages in its logfile that I wasn't > before. > procmail, setroubleshoot output: > Source Context: system_u:system_r:procmail_t:s0 > Target Context: unconfined_u:object_r:var_log_t:s0 > Target Objects: None [ file ] > Affected RPM Packages: procmail-3.22-20.fc8 [application] > Policy RPM: selinux-policy-3.0.8-74.fc8 > Selinux Enabled: True > Policy Type: targeted > MLS Enabled: True > Enforcing Mode: Enforcing > Plugin Name: plugins.mislabeled_file > Host Name: coyote.coyote.den > Platform: Linux coyote.coyote.den 2.6.24-rc8 #2 SMP Wed Jan 16 22:47:57 EST > 2008 i686 athlon > Alert Count: 3 > First Seen: Sat 19 Jan 2008 01:50:20 AM EST > Last Seen: Sat 19 Jan 2008 05:09:16 AM EST > Local ID: 3114f17d-0dc1-4453-ad4c-3b3548003cc4 > Line Numbers: Raw > Audit Messages : > avc: denied { append } for comm=procmail dev=dm-0 egid=500 euid=500 > exe=/usr/bin/procmail exit=-13 fsgid=500 fsuid=500 gid=500 items=0 > name=procmail.log pid=10138 scontext=system_u:system_r:procmail_t:s0 sgid=0 > subj=system_u:system_r:procmail_t:s0 suid=500 tclass=file > tcontext=unconfined_u:object_r:var_log_t:s0 tty=(none) uid=500 > > I note that the Last Seen time is before I did an autorelabel this morning. Try running "restorecon -v procmail.log" (which is presumably in /var/log) > And now, trying to setup squid, I'm failing that: > > Source Context: system_u:system_r:squid_t:s0 > Target Context: system_u:object_r:var_spool_t:s0 > Target Objects: None [ dir ] > Affected RPM Packages: squid-2.6.STABLE17-1.fc8 [application] > Policy RPM: selinux-policy-3.0.8-74.fc8 > Selinux Enabled: True > Policy Type: targeted > MLS Enabled: True > Enforcing Mode: Enforcing > Plugin Name: plugins.mislabeled_file > Host Name: coyote.coyote.den > Platform: Linux coyote.coyote.den 2.6.24-rc8 #2 SMP Wed Jan 16 22:47:57 EST > 2008 i686 athlon > Alert Count: 3 > First Seen: Sat 19 Jan 2008 02:29:31 PM EST > Last Seen: Sat 19 Jan 2008 04:43:50 PM EST > Local ID: 1eb62793-1368-45b9-b0c0-c117f10dafd4 > Line Numbers: Raw > Audit Messages : > avc: denied { write } for comm=squid dev=dm-0 egid=23 euid=23 > exe=/usr/sbin/squid exit=-13 fsgid=23 fsuid=23 gid=23 items=0 name=squid > pid=17099 scontext=system_u:system_r:squid_t:s0 sgid=23 > subj=system_u:system_r:squid_t:s0 suid=0 tclass=dir > tcontext=system_u:object_r:var_spool_t:s0 tty=pts9 uid=23 > > For squid, I hand made its parent /var/spool/squid dir, and chowned it to > squid:squid but the exact same failure occurs as it is trying to setup its > cache dirs within that dir, so I gave it up. Its logs gets a new stanza of > this: > > squid: ERROR: No running copy > 2008/01/19 14:29:31| Creating Swap Directories > FATAL: Failed to make swap directory /var/spool/squid/00: (13) Permission > denied > Squid Cache (Version 2.6.STABLE17): Terminated abnormally. > CPU Usage: 0.001 seconds = 0.001 user + 0.000 sys > Maximum Resident Size: 0 KB > Page faults with physical i/o: 0 > > for everytime I attempt a 'service squid start' > > Can we make these work please? setroubleshooter's suggestions about running > restorecon are rather worthless without the rest of the command line as an > example cuz I have NDI what the file should be relabeled as. restorecon -rv /var/spool/squid It should be squid_cache_t Paul. From shintaro.fujiwara at gmail.com Mon Jan 21 21:06:46 2008 From: shintaro.fujiwara at gmail.com (Shintaro Fujiwara) Date: Tue, 22 Jan 2008 06:06:46 +0900 Subject: segatex-4.40 released Message-ID: Hi, I released segatex-4.40. segatex is SELinux tool written with qt. GUI program and colorful. segatex-4.40 can do, audit2allow semodule semanage login, fcontext, and list objects. Analize refpolicy (20071214 included). Edit files related to policies like .te, .fc, .if files. Thank you.p.s. http://sourceforge.net/projects/segatex/ Any comments appreciated to this address. -- http://intrajp.no-ip.com/ Home Page -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwalsh at redhat.com Mon Jan 21 21:38:02 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 21 Jan 2008 16:38:02 -0500 Subject: wpa_supplicant, NetworkManager_t & inotifyfs_t AVC In-Reply-To: <4c4ba1530801191056h58e77e3ei8004462aa37bdcdf@mail.gmail.com> References: <4c4ba1530801191056h58e77e3ei8004462aa37bdcdf@mail.gmail.com> Message-ID: <479510BA.3040100@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom London wrote: > Running latest rawhide, targeted/enforcing (selinux-policy-3.2.5-12.fc9). > > Notice the following AVC in audit.log > > type=AVC msg=audit(1200767626.005:18): avc: denied { read } for > pid=2725 comm="wpa_supplicant" path="inotify" dev=inotifyfs ino=1 > scontext=system_u:system_r:NetworkManager_t:s0 > tcontext=system_u:object_r:inotifyfs_t:s0 tclass=dir > type=SYSCALL msg=audit(1200767626.005:18): arch=40000003 syscall=11 > success=yes exit=0 a0=8619fd8 a1=8619c78 a2=8619008 a3=de799c items=0 > ppid=2724 pid=2725 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 > egid=0 sgid=0 fsgid=0 tty=(none) comm="wpa_supplicant" > exe="/usr/sbin/wpa_supplicant" > subj=system_u:system_r:NetworkManager_t:s0 key=(null) > type=ANOM_ABEND msg=audit(1200767646.778:19): auid=4294967295 uid=42 > gid=42 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 pid=2742 > comm="dbus-launch" sig=6 > > #============= NetworkManager_t ============== > allow NetworkManager_t inotifyfs_t:dir read; > > Appears to be generated before gdm login; sort of looks like when > NetworkManager is started by init. > > Not exactly sure where to BZ..... wpa_supplicant? NetworkManager? inotify? > > tom Yes it should be fixed tonight's rawhide. Lots of new stuff seems to be using inotify gdm is getting a facelift/rewrite to be able to do things like setup networking before login. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeVELkACgkQrlYvE4MpobOU8wCdGSreL33XaGcP5iHNXwqXueXl p1wAnRRnxYTf9jNYe+h/lQ2JlAOh0YtX =gCZb -----END PGP SIGNATURE----- From olivares14031 at yahoo.com Tue Jan 22 12:49:57 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Tue, 22 Jan 2008 04:49:57 -0800 (PST) Subject: SELinux is preventing dbus-daemon(/bin/dbus-daemon) (system_dbusd_t) "read" to (inotifyfs_t). Message-ID: <582220.31987.qm@web52608.mail.re2.yahoo.com> Dear all, as of yesterday's updates, I get a bunch of dbus-deamon denials, the cpu went to 99-100% during the update and running top showed dbus-daemon to be up there causing trouble. When I rebooted the machine, Selinux caught the act which is summarized below. Thanks, Antonio Summary: SELinux is preventing dbus-daemon(/bin/dbus-daemon) (system_dbusd_t) "read" to (inotifyfs_t). Detailed Description: SELinux denied access requested by dbus-daemon(/bin/dbus-daemon). It is not expected that this access is required by dbus-daemon(/bin/dbus-daemon) 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 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:system_dbusd_t Target Context system_u:object_r:inotifyfs_t Target Objects None [ dir ] Source dbus-daemon(/bin/dbus-daemon) Port Host localhost Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.2.5-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.24-0.155.rc7.git6.fc9 #1 SMP Tue Jan 15 17:52:31 EST 2008 i686 athlon Alert Count 1026 First Seen Mon 21 Jan 2008 07:18:32 AM CST Last Seen Mon 21 Jan 2008 07:19:08 AM CST Local ID 4b1ce20c-c683-40fb-a014-85dbe8d69052 Line Numbers Raw Audit Messages host=localhost type=AVC msg=audit(1200921548.546:1057): avc: denied { read } for pid=1898 comm="dbus-daemon" path="inotify" dev=inotifyfs ino=1 scontext=system_u:system_r:system_dbusd_t:s0 tcontext=system_u:object_r:inotifyfs_t:s0 tclass=dir host=localhost type=SYSCALL msg=audit(1200921548.546:1057): arch=40000003 syscall=3 success=no exit=-13 a0=5 a1=bfae1fe0 a2=10 a3=b8608508 items=0 ppid=1 pid=1898 auid=4294967295 uid=81 gid=81 euid=81 suid=81 fsuid=81 egid=81 sgid=81 fsgid=81 tty=(none) comm="dbus-daemon" exe="/bin/dbus-daemon" subj=system_u:system_r:system_dbusd_t:s0 key=(null) ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From gene.heskett at verizon.net Tue Jan 22 15:37:23 2008 From: gene.heskett at verizon.net (Gene Heskett) Date: Tue, 22 Jan 2008 10:37:23 -0500 Subject: Nother selinux denial to be dealt with. Message-ID: <200801221037.24051.gene.heskett@verizon.net> Greetings; Verizon makes life a bitch by violating common carrier rules when the block port 80 to keep their customers from running a web server. But port 85 appears to be an unassigned port, and I have successfully used it to test when selinux, privoxy and squid were not running. Now they are, and an attempted connect to http://gene.homelinux.net:85 now gets a 503 cuz selinux denies it. As saved from setroubleshooter: ================= Summary: SELinux is preventing the privoxy(/usr/sbin/privoxy) (privoxy_t) from connecting to port 85. Detailed Description: SELinux has denied the privoxy(/usr/sbin/privoxy) from connecting to a network port 85 which does not have an SELinux type associated with it. If privoxy(/usr/sbin/privoxy) is supposed to be allowed to connect on this port, you can use the semanage command to add this port to a port type that privoxy_t can connect to. semanage port -L will list all port types. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against the selinux-policy package. If privoxy(/usr/sbin/privoxy) is not supposed to bind to this port, this could signal a intrusion attempt. Allowing Access: If you want to allow privoxy(/usr/sbin/privoxy) to connect to this port semanage port -a -t PORT_TYPE -p PROTOCOL 85 Where PORT_TYPE is a type that privoxy_t can connect. Additional Information: Source Context system_u:system_r:privoxy_t:s0 Target Context system_u:object_r:reserved_port_t:s0 Target Objects None [ tcp_socket ] Source privoxy(/usr/sbin/privoxy) Port 85 Host coyote.coyote.den Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.0.8-76.fc8 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name connect_ports Host Name coyote.coyote.den Platform Linux coyote.coyote.den 2.6.24-rc8 #2 SMP Wed Jan 16 22:47:57 EST 2008 i686 athlon Alert Count 4 First Seen Tue 22 Jan 2008 10:10:07 AM EST Last Seen Tue 22 Jan 2008 10:11:16 AM EST Local ID 748d1fcf-28fe-4b1b-87c3-40a0b272393d Line Numbers Raw Audit Messages host=coyote.coyote.den type=AVC msg=audit(1201014676.609:434): avc: denied { name_connect } for pid=14357 comm="privoxy" dest=85 scontext=system_u:system_r:privoxy_t:s0 tcontext=system_u:object_r:reserved_port_t:s0 tclass=tcp_socket host=coyote.coyote.den type=SYSCALL msg=audit(1201014676.609:434): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=b67366e0 a2=b6736798 a3=0 items=0 ppid=1 pid=14357 auid=4294967295 uid=73 gid=73 euid=73 suid=73 fsuid=73 egid=73 sgid=73 fsgid=73 tty=(none) comm="privoxy" exe="/usr/sbin/privoxy" subj=system_u:system_r:privoxy_t:s0 key=(null) ================== What can I do to allow this? The above isn't precise enough for me to go stumbling around. 2nd, do these mailing lists echo each other? If so, sorry about hitting both. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Real Users hate Real Programmers. From tony.molloy at ul.ie Wed Jan 23 11:40:36 2008 From: tony.molloy at ul.ie (Tony Molloy) Date: Wed, 23 Jan 2008 11:40:36 +0000 Subject: AVC denial with bugzilla from epel Message-ID: <200801231140.36508.tony.molloy@ul.ie> Hi, I'm installing bugzilla from epel-5 onto a Centos-5 Server. I'm getting the following AVC denied message: Summary SELinux prevented httpd reading and writing access to http files. Detailed Description SELinux prevented httpd reading and writing access to http files. Ordinarily httpd is allowed full access to all files labeled with http file context. This machine has a tightened security policy with the httpd_unified turned off, This requires explicit labeling of all files. If a file is a cgi script it needs to be labeled with httpd_TYPE_script_exec_t in order to be executed. If it is read only content, it needs to be labeled httpd_TYPE_content_t, it is writable content. it needs to be labeled httpd_TYPE_script_rw_t or httpd_TYPE_script_ra_t. You can use the chcon command to change these context. Please refer to the man page "man httpd_selinux" or http://fedora.redhat.com/docs/selinux-apache-fc3 "TYPE" refers toi one of "sys", "user" or "staff" or potentially other script types. Allowing Access Changing the "httpd_unified" boolean to true will allow this access: "setsebool -P httpd_unified=1" The following command will allow this access: setsebool -P httpd_unified=1 Additional Information Source Context root:system_r:httpd_bugzilla_script_t Target Context root:object_r:httpd_tmp_t Target Objects /tmp/.NSPR-AFM-6806-97520c8.0 (deleted) [ file ] Affected RPM Packages Policy RPM selinux-policy-2.4.6-106.el5_1.3 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.httpd_unified Host Name richmond.csis.ul.ie Platform Linux richmond.csis.ul.ie 2.6.18-53.1.4.el5 #1 SMP Fri Nov 30 00:45:16 EST 2007 i686 i686 Alert Count 21 Line Numbers Raw Audit Messages avc: denied { read, write } for comm="index.cgi" dev=sda6 egid=48 euid=48 exe="/usr/bin/perl" exit=0 fsgid=48 fsuid=48 gid=48 items=0 path=2F746D702F2E4E5 350522D41464D2D363830362D393735323063382E30202864656C6574656429 pid=12090 scontext=root:system_r:httpd_bugzilla_script_t:s0 sgid=48 subj=root:system_r:httpd_bugzilla_script_t:s0 suid=48 tclass=file tcontext=root:object_r:httpd_tmp_t:s0 tty=(none) uid=48 This seems to a denial to r/w a file in /tmp I can generate a local policy to allow this access with audit2allow but what is the correct way to handle this. Regards, Tony From sundaram at fedoraproject.org Wed Jan 23 12:17:54 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 23 Jan 2008 17:47:54 +0530 Subject: AVC denial with bugzilla from epel In-Reply-To: <200801231140.36508.tony.molloy@ul.ie> References: <200801231140.36508.tony.molloy@ul.ie> Message-ID: <47973072.20600@fedoraproject.org> Tony Molloy wrote: > Hi, > > I'm installing bugzilla from epel-5 onto a Centos-5 Server. I'm getting the > following AVC denied message: > > Summary > SELinux prevented httpd reading and writing access to http files. > > Detailed Description > SELinux prevented httpd reading and writing access to http files. > Ordinarily > httpd is allowed full access to all files labeled with http file context. > This machine has a tightened security policy with the httpd_unified turned > off, This requires explicit labeling of all files. If a file is a cgi > script it needs to be labeled with httpd_TYPE_script_exec_t in order to be > executed. If it is read only content, it needs to be labeled > httpd_TYPE_content_t, it is writable content. it needs to be labeled > httpd_TYPE_script_rw_t or httpd_TYPE_script_ra_t. You can use the chcon > command to change these context. Please refer to the man page "man > httpd_selinux" or http://fedora.redhat.com/docs/selinux-apache-fc3 "TYPE" > refers toi one of "sys", "user" or "staff" or potentially other script > types. > > Allowing Access > Changing the "httpd_unified" boolean to true will allow this access: > "setsebool -P httpd_unified=1" > > The following command will allow this access: > setsebool -P httpd_unified=1 > > Additional Information > > Source Context root:system_r:httpd_bugzilla_script_t > Target Context root:object_r:httpd_tmp_t > Target Objects /tmp/.NSPR-AFM-6806-97520c8.0 (deleted) [ file ] > Affected RPM Packages > Policy RPM selinux-policy-2.4.6-106.el5_1.3 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name plugins.httpd_unified > Host Name richmond.csis.ul.ie > Platform Linux richmond.csis.ul.ie 2.6.18-53.1.4.el5 #1 > SMP > Fri Nov 30 00:45:16 EST 2007 i686 i686 > Alert Count 21 > Line Numbers > > > Raw Audit Messages > > avc: denied { read, write } for comm="index.cgi" dev=sda6 egid=48 euid=48 > exe="/usr/bin/perl" exit=0 fsgid=48 fsuid=48 gid=48 items=0 > path=2F746D702F2E4E5 > 350522D41464D2D363830362D393735323063382E30202864656C6574656429 pid=12090 > scontext=root:system_r:httpd_bugzilla_script_t:s0 sgid=48 > subj=root:system_r:httpd_bugzilla_script_t:s0 suid=48 tclass=file > tcontext=root:object_r:httpd_tmp_t:s0 tty=(none) uid=48 > > This seems to a denial to r/w a file in /tmp > > I can generate a local policy to allow this access with audit2allow but what > is the correct way to handle this. The answer was within the report itself # setsebool -P httpd_unified=1 Rahul From paul at city-fan.org Wed Jan 23 14:12:50 2008 From: paul at city-fan.org (Paul Howarth) Date: Wed, 23 Jan 2008 14:12:50 +0000 Subject: AVC denial with bugzilla from epel In-Reply-To: <47973072.20600@fedoraproject.org> References: <200801231140.36508.tony.molloy@ul.ie> <47973072.20600@fedoraproject.org> Message-ID: <47974B62.3070302@city-fan.org> Rahul Sundaram wrote: > Tony Molloy wrote: >> Hi, >> >> I'm installing bugzilla from epel-5 onto a Centos-5 Server. I'm >> getting the following AVC denied message: >> >> Summary >> SELinux prevented httpd reading and writing access to http files. >> >> Detailed Description >> SELinux prevented httpd reading and writing access to http files. >> Ordinarily >> httpd is allowed full access to all files labeled with http file >> context. >> This machine has a tightened security policy with the >> httpd_unified turned >> off, This requires explicit labeling of all files. If a file is >> a cgi >> script it needs to be labeled with httpd_TYPE_script_exec_t in >> order to be >> executed. If it is read only content, it needs to be labeled >> httpd_TYPE_content_t, it is writable content. it needs to be labeled >> httpd_TYPE_script_rw_t or httpd_TYPE_script_ra_t. You can use the >> chcon >> command to change these context. Please refer to the man page "man >> httpd_selinux" or http://fedora.redhat.com/docs/selinux-apache-fc3 >> "TYPE" >> refers toi one of "sys", "user" or "staff" or potentially other >> script >> types. >> >> Allowing Access >> Changing the "httpd_unified" boolean to true will allow this access: >> "setsebool -P httpd_unified=1" >> >> The following command will allow this access: >> setsebool -P httpd_unified=1 >> >> Additional Information >> Source Context root:system_r:httpd_bugzilla_script_t >> Target Context root:object_r:httpd_tmp_t >> Target Objects /tmp/.NSPR-AFM-6806-97520c8.0 (deleted) >> [ file ] >> Affected RPM Packages Policy RPM >> selinux-policy-2.4.6-106.el5_1.3 >> Selinux Enabled True >> Policy Type targeted >> MLS Enabled True >> Enforcing Mode Enforcing >> Plugin Name plugins.httpd_unified >> Host Name richmond.csis.ul.ie >> Platform Linux richmond.csis.ul.ie >> 2.6.18-53.1.4.el5 #1 SMP >> Fri Nov 30 00:45:16 EST 2007 i686 i686 >> Alert Count 21 >> Line Numbers >> >> Raw Audit Messages >> avc: denied { read, write } for comm="index.cgi" dev=sda6 egid=48 euid=48 >> exe="/usr/bin/perl" exit=0 fsgid=48 fsuid=48 gid=48 items=0 >> path=2F746D702F2E4E5 >> 350522D41464D2D363830362D393735323063382E30202864656C6574656429 pid=12090 >> scontext=root:system_r:httpd_bugzilla_script_t:s0 sgid=48 >> subj=root:system_r:httpd_bugzilla_script_t:s0 suid=48 tclass=file >> tcontext=root:object_r:httpd_tmp_t:s0 tty=(none) uid=48 >> >> This seems to a denial to r/w a file in /tmp >> >> I can generate a local policy to allow this access with audit2allow >> but what is the correct way to handle this. > > The answer was within the report itself > > # setsebool -P httpd_unified=1 What's probably needed is for the bugzilla policy to have: allow httpd_bugzilla_script_t httpd_tmp_t:dir manage_dir_perms; allow httpd_bugzilla_script_t httpd_tmp_t:file manage_file_perms; files_tmp_filetrans(httpd_bugzilla_script_t,httpd_bugzilla_script_rw_t,{ dir file lnk_file sock_file fifo_file }) This is in line with existing policy for httpd_sys_script_t I believe (and what I'm using in the fastcgi policy in mod_fcgid-selinux). It should be possible to use bugzilla without having httpd_unified set. Paul. From notting at redhat.com Wed Jan 23 22:29:55 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 23 Jan 2008 17:29:55 -0500 Subject: [RFC] change policy loading to initramfs Message-ID: <20080123222955.GA10709@nostromo.devel.redhat.com> We're looking to move to a different init system in Fedora - the current work is going to be around upstart, most likely. upstart does not have native code for loading the SELinux policy. We could modify every possible init to load the policy... but that would be painful. So we might as well move to having the policy loaded from the initramfs. The attached patches are the first quick cut at doing that. The main patch is for mkinitrd/nash; there's a short patch for the current init, as it will abort if policy is already loaded. We can't actually remove the code from init to load the policy, as there will always be older initramfses. Comments? Ideas for different ways to do this? It's sort of ugly with fork and chroot(), but to avoid that we'd have to reimplement most, if not all, of libselinux's policy loading code directly. Bill -------------- next part -------------- diff -up mkinitrd-6.0.28/nash/nash.c.foo mkinitrd-6.0.28/nash/nash.c --- mkinitrd-6.0.28/nash/nash.c.foo 2008-01-09 12:12:28.000000000 -0500 +++ mkinitrd-6.0.28/nash/nash.c 2008-01-23 16:59:15.000000000 -0500 @@ -60,6 +60,8 @@ #include +#include + #include #include @@ -1719,6 +1721,34 @@ mkdirCommand(char * cmd, char * end) } static int +loadPolicyCommand(char * cmd, char *end) +{ + int enforce = 0; + int pid, status; + + pid = fork(); + + if (pid == 0) { + if (chroot("/sysroot") != 0) { + eprintf("load_policy: chroot failed: %m\n"); + exit(0); + } + + if (selinux_init_load_policy(&enforce) != 0) { + if (enforce > 0) { + eprintf("Unable to load SELinux policy (%m). Halting now.\n"); + exit(1); + } + exit(0); + } + exit(0); + } + waitpid(pid, &status, 0); + if (!WIFEXITED(status) || WEXITSTATUS(status)) exit(1); + return 0; +} + +static int accessCommand(char * cmd, char * end) { char * permStr; @@ -2728,6 +2758,7 @@ static const struct commandHandler handl { "find", findCommand }, { "kernelopt", printKernelOpt }, { "loadDrivers", loadDriversCommand }, + { "loadpolicy", loadPolicyCommand }, { "mkblktab", mkblktabCommand }, { "mkblkdevs", mkblkdevsCommand }, { "mkdir", mkdirCommand }, diff -up mkinitrd-6.0.28/mkinitrd.foo mkinitrd-6.0.28/mkinitrd --- mkinitrd-6.0.28/mkinitrd.foo 2008-01-23 17:09:26.000000000 -0500 +++ mkinitrd-6.0.28/mkinitrd 2008-01-23 17:10:23.000000000 -0500 @@ -1692,6 +1692,13 @@ if [ -n "$dhclient_leases_cmd" ]; then emit "$dhclient_leases_cmd" fi +SELINUX= +[ -f /etc/selinux/config ] && . /etc/selinux/config +if [ -n "$SELINUX" -a "$SELINUX" != "disabled" ]; then + emit "echo Loading SELinux policy." + emit "loadpolicy" +fi + emit "echo Switching to new root and running init." emit "switchroot" emit "echo Booting has failed." -------------- next part -------------- diff -ru sysvinit-2.86/src/init.c sysvinit-2.86/src/init.c --- sysvinit-2.86/src/init.c 2008-01-23 17:10:45.000000000 -0500 +++ sysvinit-2.86/src/init.c 2008-01-23 16:26:07.000000000 -0500 @@ -2671,7 +2671,7 @@ maxproclen += strlen(argv[f]) + 1; } - if (getenv("SELINUX_INIT") == NULL) { + if (getenv("SELINUX_INIT") == NULL && !is_selinux_enabled()) { putenv("SELINUX_INIT=YES"); if (selinux_init_load_policy(&enforce) == 0 ) { execv(myname, argv); From jreiser at BitWagon.com Wed Jan 23 23:19:43 2008 From: jreiser at BitWagon.com (John Reiser) Date: Wed, 23 Jan 2008 15:19:43 -0800 Subject: [RFC] change policy loading to initramfs In-Reply-To: <20080123222955.GA10709@nostromo.devel.redhat.com> References: <20080123222955.GA10709@nostromo.devel.redhat.com> Message-ID: <4797CB8F.9030109@BitWagon.com> > So we might as well move to having the > policy loaded from the initramfs. How can this be debugged, particularly in the field? During the Fedora 8 development cycle I had some success running anaconda under strace, having booted with strace on a USB flash device, then going to a separate console, attaching strace to anaconda, and piping several GB of strace output through gzip onto the flash device. I'd like to be able to do something just as effective (or more) with loading policy from initramfs. > + if (selinux_init_load_policy(&enforce) != 0) { > + if (enforce > 0) { > + eprintf("Unable to load SELinux policy (%m). Halting now.\n"); > + exit(1); > + } > + exit(0); > + } Please enhance the error reporting so that when there is an error, then the error message is exquisitely explicit, and gives some hint of how to fix the problem. It is extremely frustrating to see only "There was an error. Bye." [Naturally, this is a joint effort between selinux_init_load_policy and its caller.] If the problem is a failed system call, then print the name of the system call, the errno, and the error string. (Even without national language support, for instance.) If the problem lies with a file or directory, then include the literal pathname which failed. I spent many hours chasing a missing file whose name did not appear in any message. -- From notting at redhat.com Thu Jan 24 01:11:12 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 23 Jan 2008 20:11:12 -0500 Subject: [RFC] change policy loading to initramfs In-Reply-To: <4797CB8F.9030109@BitWagon.com> References: <20080123222955.GA10709@nostromo.devel.redhat.com> <4797CB8F.9030109@BitWagon.com> Message-ID: <20080124011112.GA18736@nostromo.devel.redhat.com> John Reiser (jreiser at BitWagon.com) said: > If the problem is a failed system call, then print the name of the > system call, the errno, and the error string. (Even without national > language support, for instance.) If the problem lies with a file or > directory, then include the literal pathname which failed. I spent > many hours chasing a missing file whose name did not appear in > any message. The snippet you quoted *does* print strerror(errno)... there are various other errors that the SELinux routines catch, but they aren't propagated up in any way that that patch could catch. Bill From jreiser at BitWagon.com Thu Jan 24 02:00:22 2008 From: jreiser at BitWagon.com (John Reiser) Date: Wed, 23 Jan 2008 18:00:22 -0800 Subject: [RFC] change policy loading to initramfs In-Reply-To: <20080124011112.GA18736@nostromo.devel.redhat.com> References: <20080123222955.GA10709@nostromo.devel.redhat.com> <4797CB8F.9030109@BitWagon.com> <20080124011112.GA18736@nostromo.devel.redhat.com> Message-ID: <4797F136.6090101@BitWagon.com> Bill Nottingham wrote: > The snippet you quoted *does* print strerror(errno)... there are > various other errors that the SELinux routines catch, but they > aren't propagated up in any way that that patch could catch. So it looks like the message for a missing file might be: Unable to load SELinux policy (No such file or directory). Halting now. This is exactly what happened to me in F8, and it was horrible: https://bugzilla.redhat.com/show_bug.cgi?id=343861 The ultimate cause was a bug in pungi: https://bugzilla.redhat.com/show_bug.cgi?id=343851 but the error was not discovered until install time (anaconda), and the error message did not give the name of [any] missing file. It is unacceptable to say "No such file or directory" unless it also gives the full literal name of some such file that was sought, and could have been used (if present and correctly formatted, etc.) The missing filename turned out to be: /etc/selinux/targeted/policy/policy.21 *IF* that filename had appeared with the original message: Can't load policy: no such file or directory then it would have been *very* much easier to debug and fix. -- From sds at tycho.nsa.gov Thu Jan 24 13:26:16 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 24 Jan 2008 08:26:16 -0500 Subject: [RFC] change policy loading to initramfs In-Reply-To: <20080123222955.GA10709@nostromo.devel.redhat.com> References: <20080123222955.GA10709@nostromo.devel.redhat.com> Message-ID: <1201181176.21288.27.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-01-23 at 17:29 -0500, Bill Nottingham wrote: > We're looking to move to a different init system in Fedora - the > current work is going to be around upstart, most likely. upstart > does not have native code for loading the SELinux policy. > > We could modify every possible init to load the policy... but > that would be painful. So we might as well move to having the > policy loaded from the initramfs. The attached patches are the > first quick cut at doing that. > > The main patch is for mkinitrd/nash; there's a short patch for the > current init, as it will abort if policy is already loaded. We > can't actually remove the code from init to load the policy, as > there will always be older initramfses. > > Comments? Ideas for different ways to do this? It's sort of ugly > with fork and chroot(), but to avoid that we'd have to reimplement > most, if not all, of libselinux's policy loading code directly. Hmm...Chad Sellers was working on similar support for Ubuntu, but did it by adding a -i option to the load_policy program to perform an initial policy load so that you can just execute it from a script rather than requiring a direct patch to nash or anything else. cc'ing him. The load_policy -i support is upstream and should be in Fedora devel / rawhide too. > Bill > -- > 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 sds at tycho.nsa.gov Thu Jan 24 13:29:53 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 24 Jan 2008 08:29:53 -0500 Subject: [RFC] change policy loading to initramfs In-Reply-To: <4797F136.6090101@BitWagon.com> References: <20080123222955.GA10709@nostromo.devel.redhat.com> <4797CB8F.9030109@BitWagon.com> <20080124011112.GA18736@nostromo.devel.redhat.com> <4797F136.6090101@BitWagon.com> Message-ID: <1201181393.21288.30.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-01-23 at 18:00 -0800, John Reiser wrote: > Bill Nottingham wrote: > > The snippet you quoted *does* print strerror(errno)... there are > > various other errors that the SELinux routines catch, but they > > aren't propagated up in any way that that patch could catch. > > So it looks like the message for a missing file might be: > Unable to load SELinux policy (No such file or directory). Halting now. > > This is exactly what happened to me in F8, and it was horrible: > https://bugzilla.redhat.com/show_bug.cgi?id=343861 > The ultimate cause was a bug in pungi: > https://bugzilla.redhat.com/show_bug.cgi?id=343851 > but the error was not discovered until install time (anaconda), > and the error message did not give the name of [any] missing file. > > It is unacceptable to say "No such file or directory" unless > it also gives the full literal name of some such file that was > sought, and could have been used (if present and correctly formatted, etc.) > > The missing filename turned out to be: > /etc/selinux/targeted/policy/policy.21 > > *IF* that filename had appeared with the original message: > Can't load policy: no such file or directory > then it would have been *very* much easier to debug and fix. To do that, we'd need to modify the libselinux selinux_mkload_policy function rather than the caller, as the libselinux function encapsulates the policy file location these days. Certainly doable, just needs a patch to report that info on a failure. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Thu Jan 24 14:53:06 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 24 Jan 2008 09:53:06 -0500 Subject: SELinux is preventing dbus-daemon(/bin/dbus-daemon) (system_dbusd_t) "read" to (inotifyfs_t). In-Reply-To: <582220.31987.qm@web52608.mail.re2.yahoo.com> References: <582220.31987.qm@web52608.mail.re2.yahoo.com> Message-ID: <4798A652.2050001@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Antonio Olivares wrote: > Dear all, > > as of yesterday's updates, I get a bunch of > dbus-deamon denials, the cpu went to 99-100% during > the update and running top showed dbus-daemon to be up > there causing trouble. When I rebooted the machine, > Selinux caught the act which is summarized below. > > Thanks, > > Antonio > > Summary: > > SELinux is preventing dbus-daemon(/bin/dbus-daemon) > (system_dbusd_t) "read" to > (inotifyfs_t). > > Detailed Description: > > SELinux denied access requested by > dbus-daemon(/bin/dbus-daemon). It is not > expected that this access is required by > dbus-daemon(/bin/dbus-daemon) 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 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:system_dbusd_t > Target Context > system_u:object_r:inotifyfs_t > Target Objects None [ dir ] > Source > dbus-daemon(/bin/dbus-daemon) > Port > Host localhost > Source RPM Packages > Target RPM Packages > Policy RPM > selinux-policy-3.2.5-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.24-0.155.rc7.git6.fc9 #1 SMP > Tue Jan 15 17:52:31 EST > 2008 i686 athlon > Alert Count 1026 > First Seen Mon 21 Jan 2008 07:18:32 > AM CST > Last Seen Mon 21 Jan 2008 07:19:08 > AM CST > Local ID > 4b1ce20c-c683-40fb-a014-85dbe8d69052 > Line Numbers > > Raw Audit Messages > > host=localhost type=AVC > msg=audit(1200921548.546:1057): avc: denied { read } > for pid=1898 comm="dbus-daemon" path="inotify" > dev=inotifyfs ino=1 > scontext=system_u:system_r:system_dbusd_t:s0 > tcontext=system_u:object_r:inotifyfs_t:s0 tclass=dir > > host=localhost type=SYSCALL > msg=audit(1200921548.546:1057): arch=40000003 > syscall=3 success=no exit=-13 a0=5 a1=bfae1fe0 a2=10 > a3=b8608508 items=0 ppid=1 pid=1898 auid=4294967295 > uid=81 gid=81 euid=81 suid=81 fsuid=81 egid=81 sgid=81 > fsgid=81 tty=(none) comm="dbus-daemon" > exe="/bin/dbus-daemon" > subj=system_u:system_r:system_dbusd_t:s0 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 Should be fixed now. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeYplIACgkQrlYvE4MpobPiqQCg3wY5BStNnz29ewUf5+lDxd3M gkoAoNRnaYq5fO9ANF+QZSiq4xWyn1mo =XY5g -----END PGP SIGNATURE----- From dwalsh at redhat.com Thu Jan 24 15:25:52 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 24 Jan 2008 10:25:52 -0500 Subject: Nother selinux denial to be dealt with. In-Reply-To: <200801221037.24051.gene.heskett@verizon.net> References: <200801221037.24051.gene.heskett@verizon.net> Message-ID: <4798AE00.1020304@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gene Heskett wrote: > Greetings; > > Verizon makes life a bitch by violating common carrier rules when the block > port 80 to keep their customers from running a web server. But port 85 > appears to be an unassigned port, and I have successfully used it to test when > selinux, privoxy and squid were not running. Now they are, and an attempted > connect to http://gene.homelinux.net:85 now gets a 503 cuz selinux denies it. > > As saved from setroubleshooter: > ================= > Summary: > > SELinux is preventing the privoxy(/usr/sbin/privoxy) (privoxy_t) from connecting > to port 85. > > Detailed Description: > > SELinux has denied the privoxy(/usr/sbin/privoxy) from connecting to a network > port 85 which does not have an SELinux type associated with it. If > privoxy(/usr/sbin/privoxy) is supposed to be allowed to connect on this port, > you can use the semanage command to add this port to a port type that privoxy_t > can connect to. semanage port -L will list all port types. Please file a bug > report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against the > selinux-policy package. If privoxy(/usr/sbin/privoxy) is not supposed to bind to > this port, this could signal a intrusion attempt. > > Allowing Access: > > If you want to allow privoxy(/usr/sbin/privoxy) to connect to this port semanage > port -a -t PORT_TYPE -p PROTOCOL 85 Where PORT_TYPE is a type that privoxy_t can > connect. > > Additional Information: > > Source Context system_u:system_r:privoxy_t:s0 > Target Context system_u:object_r:reserved_port_t:s0 > Target Objects None [ tcp_socket ] > Source privoxy(/usr/sbin/privoxy) > Port 85 > Host coyote.coyote.den > Source RPM Packages > Target RPM Packages > Policy RPM selinux-policy-3.0.8-76.fc8 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name connect_ports > Host Name coyote.coyote.den > Platform Linux coyote.coyote.den 2.6.24-rc8 #2 SMP Wed Jan > 16 22:47:57 EST 2008 i686 athlon > Alert Count 4 > First Seen Tue 22 Jan 2008 10:10:07 AM EST > Last Seen Tue 22 Jan 2008 10:11:16 AM EST > Local ID 748d1fcf-28fe-4b1b-87c3-40a0b272393d > Line Numbers > > Raw Audit Messages > > host=coyote.coyote.den type=AVC msg=audit(1201014676.609:434): avc: denied { name_connect } for pid=14357 > comm="privoxy" dest=85 scontext=system_u:system_r:privoxy_t:s0 tcontext=system_u:object_r:reserved_port_t:s0 > tclass=tcp_socket > > host=coyote.coyote.den type=SYSCALL msg=audit(1201014676.609:434): arch=40000003 syscall=102 success=no exit=-13 a0=3 > a1=b67366e0 a2=b6736798 a3=0 items=0 ppid=1 pid=14357 auid=4294967295 uid=73 gid=73 euid=73 suid=73 fsuid=73 egid=73 > sgid=73 fsgid=73 tty=(none) comm="privoxy" exe="/usr/sbin/privoxy" subj=system_u:system_r:privoxy_t:s0 key=(null) > > ================== > What can I do to allow this? The above isn't precise enough for me to go stumbling around. > > 2nd, do these mailing lists echo each other? If so, sorry about hitting both. > The best way to handle this is to define port 85 as an http_port_t, this way all domains that can use http_port_t will gain access. semanage port -a -t http_port_t -p tcp 85 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeYrf8ACgkQrlYvE4MpobNfywCeKO39DQKjtgoLPgyGrp2LkRk4 1u0AoJxex/fafIhBW/vuKSwrCNmHQv5R =W6Wm -----END PGP SIGNATURE----- From dwalsh at redhat.com Thu Jan 24 15:28:42 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 24 Jan 2008 10:28:42 -0500 Subject: AVC denial with bugzilla from epel In-Reply-To: <47974B62.3070302@city-fan.org> References: <200801231140.36508.tony.molloy@ul.ie> <47973072.20600@fedoraproject.org> <47974B62.3070302@city-fan.org> Message-ID: <4798AEAA.6010607@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Howarth wrote: > Rahul Sundaram wrote: >> Tony Molloy wrote: >>> Hi, >>> >>> I'm installing bugzilla from epel-5 onto a Centos-5 Server. I'm >>> getting the following AVC denied message: >>> >>> Summary >>> SELinux prevented httpd reading and writing access to http files. >>> >>> Detailed Description >>> SELinux prevented httpd reading and writing access to http files. >>> Ordinarily >>> httpd is allowed full access to all files labeled with http file >>> context. >>> This machine has a tightened security policy with the >>> httpd_unified turned >>> off, This requires explicit labeling of all files. If a file is >>> a cgi >>> script it needs to be labeled with httpd_TYPE_script_exec_t in >>> order to be >>> executed. If it is read only content, it needs to be labeled >>> httpd_TYPE_content_t, it is writable content. it needs to be labeled >>> httpd_TYPE_script_rw_t or httpd_TYPE_script_ra_t. You can use the >>> chcon >>> command to change these context. Please refer to the man page "man >>> httpd_selinux" or >>> http://fedora.redhat.com/docs/selinux-apache-fc3 "TYPE" >>> refers toi one of "sys", "user" or "staff" or potentially other >>> script >>> types. >>> >>> Allowing Access >>> Changing the "httpd_unified" boolean to true will allow this access: >>> "setsebool -P httpd_unified=1" >>> >>> The following command will allow this access: >>> setsebool -P httpd_unified=1 >>> >>> Additional Information Source Context >>> root:system_r:httpd_bugzilla_script_t >>> Target Context root:object_r:httpd_tmp_t >>> Target Objects /tmp/.NSPR-AFM-6806-97520c8.0 (deleted) >>> [ file ] >>> Affected RPM Packages Policy RPM >>> selinux-policy-2.4.6-106.el5_1.3 >>> Selinux Enabled True >>> Policy Type targeted >>> MLS Enabled True >>> Enforcing Mode Enforcing >>> Plugin Name plugins.httpd_unified >>> Host Name richmond.csis.ul.ie >>> Platform Linux richmond.csis.ul.ie >>> 2.6.18-53.1.4.el5 #1 SMP >>> Fri Nov 30 00:45:16 EST 2007 i686 i686 >>> Alert Count 21 >>> Line Numbers >>> Raw Audit Messages avc: denied { read, write } for >>> comm="index.cgi" dev=sda6 egid=48 euid=48 >>> exe="/usr/bin/perl" exit=0 fsgid=48 fsuid=48 gid=48 items=0 >>> path=2F746D702F2E4E5 >>> 350522D41464D2D363830362D393735323063382E30202864656C6574656429 >>> pid=12090 >>> scontext=root:system_r:httpd_bugzilla_script_t:s0 sgid=48 >>> subj=root:system_r:httpd_bugzilla_script_t:s0 suid=48 tclass=file >>> tcontext=root:object_r:httpd_tmp_t:s0 tty=(none) uid=48 >>> >>> This seems to a denial to r/w a file in /tmp >>> >>> I can generate a local policy to allow this access with audit2allow >>> but what is the correct way to handle this. >> >> The answer was within the report itself >> >> # setsebool -P httpd_unified=1 > > What's probably needed is for the bugzilla policy to have: > > allow httpd_bugzilla_script_t httpd_tmp_t:dir manage_dir_perms; > allow httpd_bugzilla_script_t httpd_tmp_t:file manage_file_perms; > files_tmp_filetrans(httpd_bugzilla_script_t,httpd_bugzilla_script_rw_t,{ > dir file lnk_file sock_file fifo_file }) > > This is in line with existing policy for httpd_sys_script_t I believe > (and what I'm using in the fastcgi policy in mod_fcgid-selinux). It > should be possible to use bugzilla without having httpd_unified set. > > Paul. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Who is creating the httpd_tmp_t files? Is this a cgi that should be labeled httpd_bugzilla_script_t. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeYrqoACgkQrlYvE4MpobNUfwCfSda6EL8h9tieGHDZD8WJqj9I hAMAoKSQzRYfthJxusWW7iIrV/UPz6Xr =p7rZ -----END PGP SIGNATURE----- From dwalsh at redhat.com Thu Jan 24 15:34:16 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 24 Jan 2008 10:34:16 -0500 Subject: [RFC] change policy loading to initramfs In-Reply-To: <1201181176.21288.27.camel@moss-spartans.epoch.ncsc.mil> References: <20080123222955.GA10709@nostromo.devel.redhat.com> <1201181176.21288.27.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4798AFF8.1040204@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Smalley wrote: > On Wed, 2008-01-23 at 17:29 -0500, Bill Nottingham wrote: >> We're looking to move to a different init system in Fedora - the >> current work is going to be around upstart, most likely. upstart >> does not have native code for loading the SELinux policy. >> >> We could modify every possible init to load the policy... but >> that would be painful. So we might as well move to having the >> policy loaded from the initramfs. The attached patches are the >> first quick cut at doing that. >> >> The main patch is for mkinitrd/nash; there's a short patch for the >> current init, as it will abort if policy is already loaded. We >> can't actually remove the code from init to load the policy, as >> there will always be older initramfses. >> >> Comments? Ideas for different ways to do this? It's sort of ugly >> with fork and chroot(), but to avoid that we'd have to reimplement >> most, if not all, of libselinux's policy loading code directly. > > Hmm...Chad Sellers was working on similar support for Ubuntu, but did it > by adding a -i option to the load_policy program to perform an initial > policy load so that you can just execute it from a script rather than > requiring a direct patch to nash or anything else. cc'ing him. The > load_policy -i support is upstream and should be in Fedora devel / > rawhide too. > >> Bill >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list load_policy -i is available in rawhide -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeYr/gACgkQrlYvE4MpobN3QwCfd0uwUYidaa2vtko9hj6swa9e zeQAoN4kFHUtrS0wkUNDEOLuwcu0gfOd =wCNH -----END PGP SIGNATURE----- From dwalsh at redhat.com Thu Jan 24 15:35:42 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 24 Jan 2008 10:35:42 -0500 Subject: [RFC] change policy loading to initramfs In-Reply-To: <20080123222955.GA10709@nostromo.devel.redhat.com> References: <20080123222955.GA10709@nostromo.devel.redhat.com> Message-ID: <4798B04E.8060106@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Nottingham wrote: > We're looking to move to a different init system in Fedora - the > current work is going to be around upstart, most likely. upstart > does not have native code for loading the SELinux policy. > > We could modify every possible init to load the policy... but > that would be painful. So we might as well move to having the > policy loaded from the initramfs. The attached patches are the > first quick cut at doing that. > > The main patch is for mkinitrd/nash; there's a short patch for the > current init, as it will abort if policy is already loaded. We > can't actually remove the code from init to load the policy, as > there will always be older initramfses. > > Comments? Ideas for different ways to do this? It's sort of ugly > with fork and chroot(), but to avoid that we'd have to reimplement > most, if not all, of libselinux's policy loading code directly. > > Bill > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list We also have to worry about transitions. init_t -> initrc_t -> httpd_t If an init program (initng) does not do a fork/exec of the initrc_t script then transitions will not work properly. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeYsE4ACgkQrlYvE4MpobMGWACdEY83lBoOFrZOlrZ11gIPy5BK zB8AnRx6jJKOuleoAAyfQNqaYvkKPb6Z =o9RX -----END PGP SIGNATURE----- From notting at redhat.com Thu Jan 24 16:11:49 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 24 Jan 2008 11:11:49 -0500 Subject: [RFC] change policy loading to initramfs In-Reply-To: <1201181176.21288.27.camel@moss-spartans.epoch.ncsc.mil> References: <20080123222955.GA10709@nostromo.devel.redhat.com> <1201181176.21288.27.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20080124161149.GA30947@nostromo.devel.redhat.com> Stephen Smalley (sds at tycho.nsa.gov) said: > Hmm...Chad Sellers was working on similar support for Ubuntu, but did it > by adding a -i option to the load_policy program to perform an initial > policy load so that you can just execute it from a script rather than > requiring a direct patch to nash or anything else. cc'ing him. The > load_policy -i support is upstream and should be in Fedora devel / > rawhide too. This would still need to be done chroot()ed into the system (there's no way to set the base path for filename resoution), correct? Bill From sds at tycho.nsa.gov Thu Jan 24 16:19:14 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 24 Jan 2008 11:19:14 -0500 Subject: [RFC] change policy loading to initramfs In-Reply-To: <20080124161149.GA30947@nostromo.devel.redhat.com> References: <20080123222955.GA10709@nostromo.devel.redhat.com> <1201181176.21288.27.camel@moss-spartans.epoch.ncsc.mil> <20080124161149.GA30947@nostromo.devel.redhat.com> Message-ID: <1201191554.21288.62.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2008-01-24 at 11:11 -0500, Bill Nottingham wrote: > Stephen Smalley (sds at tycho.nsa.gov) said: > > Hmm...Chad Sellers was working on similar support for Ubuntu, but did it > > by adding a -i option to the load_policy program to perform an initial > > policy load so that you can just execute it from a script rather than > > requiring a direct patch to nash or anything else. cc'ing him. The > > load_policy -i support is upstream and should be in Fedora devel / > > rawhide too. > > This would still need to be done chroot()ed into the system (there's no > way to set the base path for filename resoution), correct? Not presently. -- Stephen Smalley National Security Agency From notting at redhat.com Thu Jan 24 16:48:12 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 24 Jan 2008 11:48:12 -0500 Subject: [RFC] change policy loading to initramfs In-Reply-To: <4798C086.2000008@redhat.com> References: <20080123222955.GA10709@nostromo.devel.redhat.com> <4798C086.2000008@redhat.com> Message-ID: <20080124164812.GD30947@nostromo.devel.redhat.com> Peter Jones (pjones at redhat.com) said: > int loadPolicyCommand(char *cmd, char *end) > { > int enforce = 0; > int rootfd; > > rootfd = open("/", O_DIRECTORY|O_RDONLY); > if (rootfd < 0) { > eprintf("loadpolicy: could not open directory: %m\n"); > exit(1); > } > if (chroot("/sysroot") != 0) { > eprintf("loadpolicy: chroot failed: %m\n"); > exit(1); > } > if (selinux_init_policy(&enforce) != 0) { > eprintf("Unable to load SELinux policy (%m). Halting now.\n"); > exit(1); > } selinux_init_load_policy is what handles enforcing=0/selinux=0 on the commandline - you only want to halt if you get back that it failed and you're in enforcing mode. (Similarly, not sure if chdir/chroot should be fatal errors.) Bill From dwalsh at redhat.com Thu Jan 24 17:22:16 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 24 Jan 2008 12:22:16 -0500 Subject: [RFC] change policy loading to initramfs In-Reply-To: <20080124161149.GA30947@nostromo.devel.redhat.com> References: <20080123222955.GA10709@nostromo.devel.redhat.com> <1201181176.21288.27.camel@moss-spartans.epoch.ncsc.mil> <20080124161149.GA30947@nostromo.devel.redhat.com> Message-ID: <4798C948.5080809@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Nottingham wrote: > Stephen Smalley (sds at tycho.nsa.gov) said: >> Hmm...Chad Sellers was working on similar support for Ubuntu, but did it >> by adding a -i option to the load_policy program to perform an initial >> policy load so that you can just execute it from a script rather than >> requiring a direct patch to nash or anything else. cc'ing him. The >> load_policy -i support is upstream and should be in Fedora devel / >> rawhide too. > > This would still need to be done chroot()ed into the system (there's no > way to set the base path for filename resoution), correct? > > Bill > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list You would still want to read the /etc/selinux/config file to figure out which policy to load. chroot PATH load_policy -i should work. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeYyUgACgkQrlYvE4MpobMkGwCfd1bU2WGZnxwWc1FpTzu5if9v +NQAoMhIyXI+INgRUc+l8F5CoIJz2TbA =R9oH -----END PGP SIGNATURE----- From csellers at tresys.com Thu Jan 24 17:38:20 2008 From: csellers at tresys.com (Chad Sellers) Date: Thu, 24 Jan 2008 12:38:20 -0500 Subject: [RFC] change policy loading to initramfs In-Reply-To: <20080124161149.GA30947@nostromo.devel.redhat.com> Message-ID: On 1/24/08 11:11 AM, "Bill Nottingham" wrote: > Stephen Smalley (sds at tycho.nsa.gov) said: >> Hmm...Chad Sellers was working on similar support for Ubuntu, but did it >> by adding a -i option to the load_policy program to perform an initial >> policy load so that you can just execute it from a script rather than >> requiring a direct patch to nash or anything else. cc'ing him. The >> load_policy -i support is upstream and should be in Fedora devel / >> rawhide too. > > This would still need to be done chroot()ed into the system (there's no > way to set the base path for filename resoution), correct? > Yes, I have to chroot to make this work. The current working initramfs script that I've been using in Ubuntu looks like this (at least the important parts): set +e chroot /root /usr/sbin/load_policy -i RET=$? if [ $RET -eq 3 ]; then echo "SELinux policy load failed and enforcing mode requested, halting now"; kill -INT 1; elif [ $RET -ne 0 ]; then echo "SELinux policy load failed, continuing"; fi So, I just call load_policy -i from a chroot, and then save off the return value. load_policy -i has a separate return value (3) if the system should halt (i.e. enforcing requested but policy load failed). If that occurs, I kill the initramfs init process. Note that Ubuntu uses busybox init for it's initrd, which seems quite buggy when it comes to signal handling. It apparently ignores SIGKILL, but dies on SIGINT. Eventually I plan to debug this further to figure out why this is the case and send a patch to the busybox guys, but I haven't had time yet. ---------------------- Chad Sellers csellers at tresys.com http://www.tresys.com From tony.molloy at ul.ie Thu Jan 24 18:44:53 2008 From: tony.molloy at ul.ie (Tony Molloy) Date: Thu, 24 Jan 2008 18:44:53 +0000 Subject: AVC denial with bugzilla from epel In-Reply-To: <4798AEAA.6010607@redhat.com> References: <200801231140.36508.tony.molloy@ul.ie> <47974B62.3070302@city-fan.org> <4798AEAA.6010607@redhat.com> Message-ID: <200801241844.53629.tony.molloy@ul.ie> On Thursday 24 January 2008 15:28:42 Daniel J Walsh wrote: > Paul Howarth wrote: > > Rahul Sundaram wrote: > >> Tony Molloy wrote: > >>> Hi, > >>> > >>> I'm installing bugzilla from epel-5 onto a Centos-5 Server. I'm > >>> getting the following AVC denied message: > >>> > >>> Summary > >>> SELinux prevented httpd reading and writing access to http files. > >>> > >>> Detailed Description > >>> SELinux prevented httpd reading and writing access to http files. > >>> Ordinarily > >>> httpd is allowed full access to all files labeled with http file > >>> context. > >>> This machine has a tightened security policy with the > >>> httpd_unified turned > >>> off, This requires explicit labeling of all files. If a file is > >>> a cgi > >>> script it needs to be labeled with httpd_TYPE_script_exec_t in > >>> order to be > >>> executed. If it is read only content, it needs to be labeled > >>> httpd_TYPE_content_t, it is writable content. it needs to be > >>> labeled httpd_TYPE_script_rw_t or httpd_TYPE_script_ra_t. You can use > >>> the chcon > >>> command to change these context. Please refer to the man page "man > >>> httpd_selinux" or > >>> http://fedora.redhat.com/docs/selinux-apache-fc3 "TYPE" > >>> refers toi one of "sys", "user" or "staff" or potentially other > >>> script > >>> types. > >>> > >>> Allowing Access > >>> Changing the "httpd_unified" boolean to true will allow this > >>> access: "setsebool -P httpd_unified=1" > >>> > >>> The following command will allow this access: > >>> setsebool -P httpd_unified=1 > >>> > >>> Additional Information Source Context > >>> root:system_r:httpd_bugzilla_script_t > >>> Target Context root:object_r:httpd_tmp_t > >>> Target Objects /tmp/.NSPR-AFM-6806-97520c8.0 (deleted) > >>> [ file ] > >>> Affected RPM Packages Policy RPM > >>> selinux-policy-2.4.6-106.el5_1.3 > >>> Selinux Enabled True > >>> Policy Type targeted > >>> MLS Enabled True > >>> Enforcing Mode Enforcing > >>> Plugin Name plugins.httpd_unified > >>> Host Name richmond.csis.ul.ie > >>> Platform Linux richmond.csis.ul.ie > >>> 2.6.18-53.1.4.el5 #1 SMP > >>> Fri Nov 30 00:45:16 EST 2007 i686 i686 > >>> Alert Count 21 > >>> Line Numbers > >>> Raw Audit Messages avc: denied { read, write } for > >>> comm="index.cgi" dev=sda6 egid=48 euid=48 > >>> exe="/usr/bin/perl" exit=0 fsgid=48 fsuid=48 gid=48 items=0 > >>> path=2F746D702F2E4E5 > >>> 350522D41464D2D363830362D393735323063382E30202864656C6574656429 > >>> pid=12090 > >>> scontext=root:system_r:httpd_bugzilla_script_t:s0 sgid=48 > >>> subj=root:system_r:httpd_bugzilla_script_t:s0 suid=48 tclass=file > >>> tcontext=root:object_r:httpd_tmp_t:s0 tty=(none) uid=48 > >>> > >>> This seems to a denial to r/w a file in /tmp > >>> > >>> I can generate a local policy to allow this access with audit2allow > >>> but what is the correct way to handle this. > >> > >> The answer was within the report itself > >> > >> # setsebool -P httpd_unified=1 > > >Who is creating the httpd_tmp_t files? Is this a cgi that should be >labeled httpd_bugzilla_script_t. Several perl cgi scripts create tmp files. >From the above it's index.cgi. The permissions on all these scripts are the same. -rwxr-x--- root apache system_u:object_r:httpd_bugzilla_script_exec_t index.cgi I created a local policy and bugzilla is working. I also submitted this as bug 429879 to bugzilla. Thanks, Tony From csellers at tresys.com Thu Jan 24 20:34:27 2008 From: csellers at tresys.com (Chad Sellers) Date: Thu, 24 Jan 2008 15:34:27 -0500 Subject: [RFC] change policy loading to initramfs In-Reply-To: <20080124164812.GD30947@nostromo.devel.redhat.com> Message-ID: On 1/24/08 11:48 AM, "Bill Nottingham" wrote: > Peter Jones (pjones at redhat.com) said: >> int loadPolicyCommand(char *cmd, char *end) >> { >> int enforce = 0; >> int rootfd; >> >> rootfd = open("/", O_DIRECTORY|O_RDONLY); >> if (rootfd < 0) { >> eprintf("loadpolicy: could not open directory: %m\n"); >> exit(1); >> } >> if (chroot("/sysroot") != 0) { >> eprintf("loadpolicy: chroot failed: %m\n"); >> exit(1); >> } >> if (selinux_init_policy(&enforce) != 0) { >> eprintf("Unable to load SELinux policy (%m). Halting now.\n"); >> exit(1); >> } > > selinux_init_load_policy is what handles enforcing=0/selinux=0 on the > commandline - you only want to halt if you get back that it failed > and you're in enforcing mode. (Similarly, not sure if chdir/chroot > should be fatal errors.) > A good point. I handle this (in my script from the other post) by only dying if the return code is 3 (meaning we're supposed to be enforcing and loading policy failed). I didn't consider all the error conditions due to chroot itself. I believe the list of return codes to consider (thanks to Steve) is: chroot: 0 success 1 (various failures, including usage, failure to chroot, failure to chdir) 126 (any failure on exec except for ENOENT) 127 (ENOENT on the exec, i.e. couldn't find load_policy) load_policy -i: 0 success 1 usage 2 can't load policy but proceed 3 can't load policy and die The security guy in me says die on ay return value besides 0 or 2, but that's probably too draconian. At the very least, we should continue on 127 (if load_policy is not installed). Thoughts? Thanks, Chad From notting at redhat.com Thu Jan 24 21:31:49 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 24 Jan 2008 16:31:49 -0500 Subject: [RFC] change policy loading to initramfs In-Reply-To: <4798C42C.8030601@redhat.com> References: <20080123222955.GA10709@nostromo.devel.redhat.com> <4798C086.2000008@redhat.com> <20080124164812.GD30947@nostromo.devel.redhat.com> <4798C42C.8030601@redhat.com> Message-ID: <20080124213149.GA16259@nostromo.devel.redhat.com> Peter Jones (pjones at redhat.com) said: > This is what I get for coding during budget meetings. Here's an updated patch (tested) that incorporates your changes. At the moment, while load_policy -i would work, I'm not sure it's best for Fedora right now as it would require pulling chroot into the initrd, and handling return code checking in nash's not-quite-a-shell environment. It's actually simpler to just call the policy load directly. Bill -------------- next part -------------- diff -up mkinitrd-6.0.28/nash/nash.c.foo mkinitrd-6.0.28/nash/nash.c --- mkinitrd-6.0.28/nash/nash.c.foo 2008-01-09 12:12:28.000000000 -0500 +++ mkinitrd-6.0.28/nash/nash.c 2008-01-24 16:28:20.000000000 -0500 @@ -60,6 +60,8 @@ #include +#include + #include #include @@ -1718,6 +1720,54 @@ mkdirCommand(char * cmd, char * end) return 0; } + +static int +loadPolicyCommand(char * cmd, char *end) +{ + int enforce = 0; + int rootfd; + + rootfd = open("/", O_DIRECTORY|O_RDONLY); + + if (rootfd < 0) { + eprintf("loadpolicy: could not open directory: %m\n"); + return 1; + } + + if (chdir("/sysroot") != 0) { + eprintf("loadpolicy: unable to change directory: %m\n"); + close(rootfd); + return 1; + } + + if (chroot("/sysroot") != 0) { + eprintf("loadpolicy: chroot failed: %m\n"); + close(rootfd); + return 1; + } + + if (selinux_init_load_policy(&enforce) != 0 && enforce > 0) { + eprintf("Unable to load SELinux policy (%m). Halting now.\n"); + sleep(-1); + exit(1); + } + + if (fchdir(rootfd) < 0) { + eprintf("loadpolicy: unable to change directory: %m\n"); + sleep(-1); + exit(1); + } + + if (chroot("..") < 0) { + eprintf("loadpolicy: chroot failed: %m\n"); + sleep(-1); + exit(1); + } + + close(rootfd); + return 0; +} + static int accessCommand(char * cmd, char * end) { @@ -2728,6 +2778,7 @@ static const struct commandHandler handl { "find", findCommand }, { "kernelopt", printKernelOpt }, { "loadDrivers", loadDriversCommand }, + { "loadpolicy", loadPolicyCommand }, { "mkblktab", mkblktabCommand }, { "mkblkdevs", mkblkdevsCommand }, { "mkdir", mkdirCommand }, diff -up mkinitrd-6.0.28/mkinitrd.foo mkinitrd-6.0.28/mkinitrd --- mkinitrd-6.0.28/mkinitrd.foo 2008-01-23 17:09:26.000000000 -0500 +++ mkinitrd-6.0.28/mkinitrd 2008-01-23 17:10:23.000000000 -0500 @@ -1692,6 +1692,13 @@ if [ -n "$dhclient_leases_cmd" ]; then emit "$dhclient_leases_cmd" fi +SELINUX= +[ -f /etc/selinux/config ] && . /etc/selinux/config +if [ -n "$SELINUX" -a "$SELINUX" != "disabled" ]; then + emit "echo Loading SELinux policy." + emit "loadpolicy" +fi + emit "echo Switching to new root and running init." emit "switchroot" emit "echo Booting has failed." From notting at redhat.com Thu Jan 24 21:34:00 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 24 Jan 2008 16:34:00 -0500 Subject: [RFC] change policy loading to initramfs In-Reply-To: References: <20080124164812.GD30947@nostromo.devel.redhat.com> Message-ID: <20080124213400.GB16259@nostromo.devel.redhat.com> Chad Sellers (csellers at tresys.com) said: > A good point. I handle this (in my script from the other post) by only dying > if the return code is 3 (meaning we're supposed to be enforcing and loading > policy failed). I didn't consider all the error conditions due to chroot > itself. I believe the list of return codes to consider (thanks to Steve) is: > > chroot: > 0 success > 1 (various failures, including usage, failure to chroot, failure to > chdir) > 126 (any failure on exec except for ENOENT) > 127 (ENOENT on the exec, i.e. couldn't find load_policy) > > load_policy -i: > 0 success > 1 usage > 2 can't load policy but proceed > 3 can't load policy and die > > The security guy in me says die on ay return value besides 0 or 2, but > that's probably too draconian. At the very least, we should continue on 127 > (if load_policy is not installed). > > Thoughts? If load_policy isn't installed, you want to proceed. If chroot outright fails, you'll almost certainly fail later in your boot anyway, so I don't know if you need to explicitly handle that. Bill From cra at WPI.EDU Thu Jan 24 23:31:42 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 24 Jan 2008 18:31:42 -0500 Subject: [RFC] change policy loading to initramfs In-Reply-To: <20080124213149.GA16259@nostromo.devel.redhat.com> References: <20080123222955.GA10709@nostromo.devel.redhat.com> <4798C086.2000008@redhat.com> <20080124164812.GD30947@nostromo.devel.redhat.com> <4798C42C.8030601@redhat.com> <20080124213149.GA16259@nostromo.devel.redhat.com> Message-ID: <20080124233142.GA31359@angus.ind.WPI.EDU> On Thu, Jan 24, 2008 at 04:31:49PM -0500, Bill Nottingham wrote: > --- mkinitrd-6.0.28/mkinitrd.foo 2008-01-23 17:09:26.000000000 -0500 > +++ mkinitrd-6.0.28/mkinitrd 2008-01-23 17:10:23.000000000 -0500 > @@ -1692,6 +1692,13 @@ if [ -n "$dhclient_leases_cmd" ]; then > emit "$dhclient_leases_cmd" > fi > > +SELINUX= > +[ -f /etc/selinux/config ] && . /etc/selinux/config > +if [ -n "$SELINUX" -a "$SELINUX" != "disabled" ]; then > + emit "echo Loading SELinux policy." > + emit "loadpolicy" > +fi > + > emit "echo Switching to new root and running init." > emit "switchroot" > emit "echo Booting has failed." Shouldn't you always add loadpolicy to the initrd? The SELinux config might change between when the initrd was generated and when you boot the system. From paul at city-fan.org Fri Jan 25 00:13:07 2008 From: paul at city-fan.org (Paul Howarth) Date: Fri, 25 Jan 2008 00:13:07 +0000 Subject: AVC denial with bugzilla from epel In-Reply-To: <4798AEAA.6010607@redhat.com> References: <200801231140.36508.tony.molloy@ul.ie> <47973072.20600@fedoraproject.org> <47974B62.3070302@city-fan.org> <4798AEAA.6010607@redhat.com> Message-ID: <20080125001307.4a93f610@metropolis.intra.city-fan.org> On Thu, 24 Jan 2008 10:28:42 -0500 Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Paul Howarth wrote: > > Rahul Sundaram wrote: > >> Tony Molloy wrote: > >>> Hi, > >>> > >>> I'm installing bugzilla from epel-5 onto a Centos-5 Server. I'm > >>> getting the following AVC denied message: > >>> > >>> Summary > >>> SELinux prevented httpd reading and writing access to http > >>> files. > >>> > >>> Detailed Description > >>> SELinux prevented httpd reading and writing access to http > >>> files. Ordinarily > >>> httpd is allowed full access to all files labeled with http > >>> file context. > >>> This machine has a tightened security policy with the > >>> httpd_unified turned > >>> off, This requires explicit labeling of all files. If a > >>> file is a cgi > >>> script it needs to be labeled with httpd_TYPE_script_exec_t in > >>> order to be > >>> executed. If it is read only content, it needs to be labeled > >>> httpd_TYPE_content_t, it is writable content. it needs to be > >>> labeled httpd_TYPE_script_rw_t or httpd_TYPE_script_ra_t. You can > >>> use the chcon > >>> command to change these context. Please refer to the man > >>> page "man httpd_selinux" or > >>> http://fedora.redhat.com/docs/selinux-apache-fc3 "TYPE" > >>> refers toi one of "sys", "user" or "staff" or potentially > >>> other script > >>> types. > >>> > >>> Allowing Access > >>> Changing the "httpd_unified" boolean to true will allow this > >>> access: "setsebool -P httpd_unified=1" > >>> > >>> The following command will allow this access: > >>> setsebool -P httpd_unified=1 > >>> > >>> Additional Information Source Context > >>> root:system_r:httpd_bugzilla_script_t > >>> Target Context root:object_r:httpd_tmp_t > >>> Target Objects /tmp/.NSPR-AFM-6806-97520c8.0 > >>> (deleted) [ file ] > >>> Affected RPM Packages Policy RPM > >>> selinux-policy-2.4.6-106.el5_1.3 > >>> Selinux Enabled True > >>> Policy Type targeted > >>> MLS Enabled True > >>> Enforcing Mode Enforcing > >>> Plugin Name plugins.httpd_unified > >>> Host Name richmond.csis.ul.ie > >>> Platform Linux richmond.csis.ul.ie > >>> 2.6.18-53.1.4.el5 #1 SMP > >>> Fri Nov 30 00:45:16 EST 2007 i686 > >>> i686 Alert Count 21 > >>> Line Numbers > >>> Raw Audit Messages avc: denied { read, write } for > >>> comm="index.cgi" dev=sda6 egid=48 euid=48 > >>> exe="/usr/bin/perl" exit=0 fsgid=48 fsuid=48 gid=48 items=0 > >>> path=2F746D702F2E4E5 > >>> 350522D41464D2D363830362D393735323063382E30202864656C6574656429 > >>> pid=12090 > >>> scontext=root:system_r:httpd_bugzilla_script_t:s0 sgid=48 > >>> subj=root:system_r:httpd_bugzilla_script_t:s0 suid=48 tclass=file > >>> tcontext=root:object_r:httpd_tmp_t:s0 tty=(none) uid=48 > >>> > >>> This seems to a denial to r/w a file in /tmp > >>> > >>> I can generate a local policy to allow this access with > >>> audit2allow but what is the correct way to handle this. > >> > >> The answer was within the report itself > >> > >> # setsebool -P httpd_unified=1 > > > > What's probably needed is for the bugzilla policy to have: > > > > allow httpd_bugzilla_script_t httpd_tmp_t:dir manage_dir_perms; > > allow httpd_bugzilla_script_t httpd_tmp_t:file manage_file_perms; > > files_tmp_filetrans(httpd_bugzilla_script_t,httpd_bugzilla_script_rw_t,{ > > dir file lnk_file sock_file fifo_file }) > > > > This is in line with existing policy for httpd_sys_script_t I > > believe (and what I'm using in the fastcgi policy in > > mod_fcgid-selinux). It should be possible to use bugzilla without > > having httpd_unified set. > > > > Paul. > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Who is creating the httpd_tmp_t files? Is this a cgi that should be > labeled httpd_bugzilla_script_t. Bugzilla is a perl CGI that is labelled httpd_bugzilla_script_exec_t I believe and runs as httpd_bugzilla_script_t. I'm not entirely sure what's happening in this case but I had an almost exactly the same issue with httpd_fastcgi_script_t (policy in the mod_fcgid-selinux package) when running the moin wiki (python-based) using mod_fcgid, which runs the web app as a CGI. The problem I had was creating attachments in the wiki, which generated the same sort of failures. I noticed the following in the apache policy on Fedora: # php uploads a file to /tmp and then execs programs to acton them manage_dirs_pattern(httpd_sys_script_t,httpd_tmp_t,httpd_tmp_t) manage_files_pattern(httpd_sys_script_t,httpd_tmp_t,httpd_tmp_t) files_tmp_filetrans(httpd_sys_script_t,httpd_sys_script_rw_t,{ dir file lnk_file sock_file fifo_file }) That looked very similar to the issue I had so I replicated this bit of policy for httpd_fastcgi_script_t and indeed it fixed the problem. And in fact I now see that the Fedora policy already has this: manage_dirs_pattern(httpd_bugzilla_script_t,httpd_bugzilla_tmp_t,httpd_bugzilla_tmp_t) manage_files_pattern(httpd_bugzilla_script_t,httpd_bugzilla_tmp_t,httpd_bugzilla_tmp_t) files_tmp_filetrans(httpd_bugzilla_script_t,httpd_bugzilla_tmp_t,{ file dir }) So maybe this issue is already fixed in Fedora but not EPEL? Paul. From tony.molloy at ul.ie Fri Jan 25 08:26:24 2008 From: tony.molloy at ul.ie (Tony Molloy) Date: Fri, 25 Jan 2008 08:26:24 +0000 Subject: Fwd: Re: AVC denial with bugzilla from epel Message-ID: <200801250826.24726.tony.molloy@ul.ie> Don't know why this didn't get through last night ( my time ;-0 ) ---------- Forwarded Message ---------- Subject: Re: AVC denial with bugzilla from epel Date: Thursday 24 January 2008 From: Tony Molloy To: fedora-selinux-list at redhat.com On Thursday 24 January 2008 15:28:42 Daniel J Walsh wrote: > Paul Howarth wrote: > > Rahul Sundaram wrote: > >> Tony Molloy wrote: > >>> Hi, > >>> > >>> I'm installing bugzilla from epel-5 onto a Centos-5 Server. I'm > >>> getting the following AVC denied message: > >>> > >>> Summary > >>> SELinux prevented httpd reading and writing access to http files. > >>> > >>> Detailed Description > >>> SELinux prevented httpd reading and writing access to http files. > >>> Ordinarily > >>> httpd is allowed full access to all files labeled with http file > >>> context. > >>> This machine has a tightened security policy with the > >>> httpd_unified turned > >>> off, This requires explicit labeling of all files. If a file is > >>> a cgi > >>> script it needs to be labeled with httpd_TYPE_script_exec_t in > >>> order to be > >>> executed. If it is read only content, it needs to be labeled > >>> httpd_TYPE_content_t, it is writable content. it needs to be > >>> labeled httpd_TYPE_script_rw_t or httpd_TYPE_script_ra_t. You can use > >>> the chcon > >>> command to change these context. Please refer to the man page "man > >>> httpd_selinux" or > >>> http://fedora.redhat.com/docs/selinux-apache-fc3 "TYPE" > >>> refers toi one of "sys", "user" or "staff" or potentially other > >>> script > >>> types. > >>> > >>> Allowing Access > >>> Changing the "httpd_unified" boolean to true will allow this > >>> access: "setsebool -P httpd_unified=1" > >>> > >>> The following command will allow this access: > >>> setsebool -P httpd_unified=1 > >>> > >>> Additional Information Source Context > >>> root:system_r:httpd_bugzilla_script_t > >>> Target Context root:object_r:httpd_tmp_t > >>> Target Objects /tmp/.NSPR-AFM-6806-97520c8.0 (deleted) > >>> [ file ] > >>> Affected RPM Packages Policy RPM > >>> selinux-policy-2.4.6-106.el5_1.3 > >>> Selinux Enabled True > >>> Policy Type targeted > >>> MLS Enabled True > >>> Enforcing Mode Enforcing > >>> Plugin Name plugins.httpd_unified > >>> Host Name richmond.csis.ul.ie > >>> Platform Linux richmond.csis.ul.ie > >>> 2.6.18-53.1.4.el5 #1 SMP > >>> Fri Nov 30 00:45:16 EST 2007 i686 i686 > >>> Alert Count 21 > >>> Line Numbers > >>> Raw Audit Messages avc: denied { read, write } for > >>> comm="index.cgi" dev=sda6 egid=48 euid=48 > >>> exe="/usr/bin/perl" exit=0 fsgid=48 fsuid=48 gid=48 items=0 > >>> path=2F746D702F2E4E5 > >>> 350522D41464D2D363830362D393735323063382E30202864656C6574656429 > >>> pid=12090 > >>> scontext=root:system_r:httpd_bugzilla_script_t:s0 sgid=48 > >>> subj=root:system_r:httpd_bugzilla_script_t:s0 suid=48 tclass=file > >>> tcontext=root:object_r:httpd_tmp_t:s0 tty=(none) uid=48 > >>> > >>> This seems to a denial to r/w a file in /tmp > >>> > >>> I can generate a local policy to allow this access with audit2allow > >>> but what is the correct way to handle this. > >> > >> The answer was within the report itself > >> > >> # setsebool -P httpd_unified=1 > > >Who is creating the httpd_tmp_t files? Is this a cgi that should be >labeled httpd_bugzilla_script_t. Several perl cgi scripts create tmp files. >From the above it's index.cgi. The permissions on all these scripts are the same. -rwxr-x--- root apache system_u:object_r:httpd_bugzilla_script_exec_t index.cgi I created a local policy and bugzilla is working. I also submitted this as bug 429879 to bugzilla. Thanks, Tony ------------------------------------------------------- From tony.molloy at ul.ie Fri Jan 25 16:39:29 2008 From: tony.molloy at ul.ie (Tony Molloy) Date: Fri, 25 Jan 2008 16:39:29 +0000 Subject: AVC denial with bugzilla from epel In-Reply-To: <20080125001307.4a93f610@metropolis.intra.city-fan.org> References: <200801231140.36508.tony.molloy@ul.ie> <4798AEAA.6010607@redhat.com> <20080125001307.4a93f610@metropolis.intra.city-fan.org> Message-ID: <200801251639.29455.tony.molloy@ul.ie> On Friday 25 January 2008 00:13:07 Paul Howarth wrote: > On Thu, 24 Jan 2008 10:28:42 -0500 > > Daniel J Walsh wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Paul Howarth wrote: > > > Rahul Sundaram wrote: > > >> Tony Molloy wrote: > > >>> Hi, > > >>> > > >>> I'm installing bugzilla from epel-5 onto a Centos-5 Server. I'm > > >>> getting the following AVC denied message: > > >>> > > >>> Summary > > >>> SELinux prevented httpd reading and writing access to http > > >>> files. > > >>> > > >>> Detailed Description > > >>> SELinux prevented httpd reading and writing access to http > > >>> files. Ordinarily > > >>> httpd is allowed full access to all files labeled with http > > >>> file context. > > >>> This machine has a tightened security policy with the > > >>> httpd_unified turned > > >>> off, This requires explicit labeling of all files. If a > > >>> file is a cgi > > >>> script it needs to be labeled with httpd_TYPE_script_exec_t in > > >>> order to be > > >>> executed. If it is read only content, it needs to be labeled > > >>> httpd_TYPE_content_t, it is writable content. it needs to be > > >>> labeled httpd_TYPE_script_rw_t or httpd_TYPE_script_ra_t. You can > > >>> use the chcon > > >>> command to change these context. Please refer to the man > > >>> page "man httpd_selinux" or > > >>> http://fedora.redhat.com/docs/selinux-apache-fc3 "TYPE" > > >>> refers toi one of "sys", "user" or "staff" or potentially > > >>> other script > > >>> types. > > >>> > > >>> Allowing Access > > >>> Changing the "httpd_unified" boolean to true will allow this > > >>> access: "setsebool -P httpd_unified=1" > > >>> > > >>> The following command will allow this access: > > >>> setsebool -P httpd_unified=1 > > >>> > > >>> Additional Information Source Context > > >>> root:system_r:httpd_bugzilla_script_t > > >>> Target Context root:object_r:httpd_tmp_t > > >>> Target Objects /tmp/.NSPR-AFM-6806-97520c8.0 > > >>> (deleted) [ file ] > > >>> Affected RPM Packages Policy RPM > > >>> selinux-policy-2.4.6-106.el5_1.3 > > >>> Selinux Enabled True > > >>> Policy Type targeted > > >>> MLS Enabled True > > >>> Enforcing Mode Enforcing > > >>> Plugin Name plugins.httpd_unified > > >>> Host Name richmond.csis.ul.ie > > >>> Platform Linux richmond.csis.ul.ie > > >>> 2.6.18-53.1.4.el5 #1 SMP > > >>> Fri Nov 30 00:45:16 EST 2007 i686 > > >>> i686 Alert Count 21 > > >>> Line Numbers > > >>> Raw Audit Messages avc: denied { read, write } for > > >>> comm="index.cgi" dev=sda6 egid=48 euid=48 > > >>> exe="/usr/bin/perl" exit=0 fsgid=48 fsuid=48 gid=48 items=0 > > >>> path=2F746D702F2E4E5 > > >>> 350522D41464D2D363830362D393735323063382E30202864656C6574656429 > > >>> pid=12090 > > >>> scontext=root:system_r:httpd_bugzilla_script_t:s0 sgid=48 > > >>> subj=root:system_r:httpd_bugzilla_script_t:s0 suid=48 tclass=file > > >>> tcontext=root:object_r:httpd_tmp_t:s0 tty=(none) uid=48 > > >>> > > >>> This seems to a denial to r/w a file in /tmp > > >>> > > >>> I can generate a local policy to allow this access with > > >>> audit2allow but what is the correct way to handle this. > > >> > > >> The answer was within the report itself > > >> > > >> # setsebool -P httpd_unified=1 > > > > > > What's probably needed is for the bugzilla policy to have: > > > > > > allow httpd_bugzilla_script_t httpd_tmp_t:dir manage_dir_perms; > > > allow httpd_bugzilla_script_t httpd_tmp_t:file manage_file_perms; > > > files_tmp_filetrans(httpd_bugzilla_script_t,httpd_bugzilla_script_rw_t, > > >{ dir file lnk_file sock_file fifo_file }) > > > > > > This is in line with existing policy for httpd_sys_script_t I > > > believe (and what I'm using in the fastcgi policy in > > > mod_fcgid-selinux). It should be possible to use bugzilla without > > > having httpd_unified set. > > > > > > Paul. > > > > > > -- > > > fedora-selinux-list mailing list > > > fedora-selinux-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > Who is creating the httpd_tmp_t files? Is this a cgi that should be > > labeled httpd_bugzilla_script_t. > > Bugzilla is a perl CGI that is labelled httpd_bugzilla_script_exec_t I > believe and runs as httpd_bugzilla_script_t. > > I'm not entirely sure what's happening in this case but I had an almost > exactly the same issue with httpd_fastcgi_script_t (policy in the > mod_fcgid-selinux package) when running the moin wiki (python-based) > using mod_fcgid, which runs the web app as a CGI. The problem I had was > creating attachments in the wiki, which generated the same sort of > failures. I noticed the following in the apache policy on Fedora: > > # php uploads a file to /tmp and then execs programs to acton them > manage_dirs_pattern(httpd_sys_script_t,httpd_tmp_t,httpd_tmp_t) > manage_files_pattern(httpd_sys_script_t,httpd_tmp_t,httpd_tmp_t) > files_tmp_filetrans(httpd_sys_script_t,httpd_sys_script_rw_t,{ dir file > lnk_file sock_file fifo_file }) > > > That looked very similar to the issue I had so I replicated this bit of > policy for httpd_fastcgi_script_t and indeed it fixed the problem. And > in fact I now see that the Fedora policy already has this: > > manage_dirs_pattern(httpd_bugzilla_script_t,httpd_bugzilla_tmp_t,httpd_bugz >illa_tmp_t) > manage_files_pattern(httpd_bugzilla_script_t,httpd_bugzilla_tmp_t,httpd_bug >zilla_tmp_t) > files_tmp_filetrans(httpd_bugzilla_script_t,httpd_bugzilla_tmp_t,{ file dir > }) > > So maybe this issue is already fixed in Fedora but not EPEL? > > Paul. > Thanks for the explanation Paul. What I did was create a local policy using audit2allow and it works fine now. Tony > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From selinux at gmail.com Sat Jan 26 18:56:03 2008 From: selinux at gmail.com (Tom London) Date: Sat, 26 Jan 2008 10:56:03 -0800 Subject: Rawhide kernel/etc. breaks sound, system_dbusd_t AVCs Message-ID: <4c4ba1530801261056s100e7e38j367abd84d4649f9f@mail.gmail.com> Running today's rawhide, targeted/enforcing. Booting up after applying today's updates, sound is disabled, and the following AVCs: type=AVC msg=audit(1201370968.279:17): avc: denied { execute } for pid=3936 comm="dbus-daemon-lau" name="console-kit-daemon" dev=dm-0 ino=5490198 scontext=system_u:system_r:system_dbusd_t:s0 tcontext=system_u:object_r:consolekit_exec_t:s0 tclass=file type=SYSCALL msg=audit(1201370968.279:17): arch=40000003 syscall=11 success=no exit=-13 a0=9253c30 a1=9253bb0 a2=9253008 a3=de799c items=0 ppid=3935 pid=3936 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="dbus-daemon-lau" exe="/lib/dbus-1/dbus-daemon-launch-helper" subj=system_u:system_r:system_dbusd_t:s0 key=(null) type=AVC msg=audit(1201370973.064:18): avc: denied { execute } for pid=4149 comm="dbus-daemon-lau" name="console-kit-daemon" dev=dm-0 ino=5490198 scontext=system_u:system_r:system_dbusd_t:s0 tcontext=system_u:object_r:consolekit_exec_t:s0 tclass=file type=SYSCALL msg=audit(1201370973.064:18): arch=40000003 syscall=11 success=no exit=-13 a0=9113c30 a1=9113bb0 a2=9113008 a3=de799c items=0 ppid=4148 pid=4149 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="dbus-daemon-lau" exe="/lib/dbus-1/dbus-daemon-launch-helper" subj=system_u:system_r:system_dbusd_t:s0 key=(null) <<< REPEATS >>> #============= system_dbusd_t ============== allow system_dbusd_t consolekit_exec_t:file execute; Rebooting in permissive mode enables sound, but produces a host of AVCs (/var/log/audit/audit.log attached): #============= system_dbusd_t ============== allow system_dbusd_t NetworkManager_t:dir search; allow system_dbusd_t NetworkManager_t:file { read getattr }; allow system_dbusd_t NetworkManager_t:process ptrace; allow system_dbusd_t consolekit_exec_t:file { read execute execute_no_trans }; allow system_dbusd_t hald_t:dbus send_msg; allow system_dbusd_t hald_t:dir search; allow system_dbusd_t hald_t:file { read getattr }; allow system_dbusd_t hald_t:process ptrace; allow system_dbusd_t polkit_auth_t:dbus send_msg; allow system_dbusd_t polkit_auth_t:dir search; allow system_dbusd_t polkit_auth_t:file { read getattr }; allow system_dbusd_t self:capability { sys_nice sys_ptrace }; allow system_dbusd_t self:fifo_file getattr; allow system_dbusd_t self:process getsched; allow system_dbusd_t system_crond_var_lib_t:dir search; allow system_dbusd_t system_crond_var_lib_t:file read; allow system_dbusd_t tty_device_t:chr_file { read ioctl }; allow system_dbusd_t unconfined_t:dbus send_msg; allow system_dbusd_t unconfined_t:dir search; allow system_dbusd_t unconfined_t:file { read getattr }; allow system_dbusd_t unconfined_t:process ptrace; allow system_dbusd_t var_log_t:dir search; allow system_dbusd_t var_log_t:file { read getattr append setattr }; allow system_dbusd_t xdm_t:dbus send_msg; allow system_dbusd_t xdm_t:dir search; allow system_dbusd_t xdm_t:file { read getattr }; allow system_dbusd_t xdm_t:process ptrace; Nothing seems mislabeled in /etc, /*bin, /lib, /usr/*bin, .... tom -- Tom London -------------- next part -------------- A non-text attachment was scrubbed... Name: log2 Type: application/octet-stream Size: 33113 bytes Desc: not available URL: From selinux at gmail.com Sat Jan 26 20:20:39 2008 From: selinux at gmail.com (Tom London) Date: Sat, 26 Jan 2008 12:20:39 -0800 Subject: Rawhide kernel/etc. breaks sound, system_dbusd_t AVCs In-Reply-To: <4c4ba1530801261056s100e7e38j367abd84d4649f9f@mail.gmail.com> References: <4c4ba1530801261056s100e7e38j367abd84d4649f9f@mail.gmail.com> Message-ID: <4c4ba1530801261220x7b690d90td563672f621b45ba@mail.gmail.com> Appears a bit more complicated..... Even after adding all the above, sound is still disabled. Here is the AVC: type=AVC msg=audit(1201376293.488:17): avc: denied { ptrace } for pid=2471 comm="console-kit-dae" scontext=system_u:system_r:system_dbusd_t:s0 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tclass=process type=SYSCALL msg=audit(1201376293.488:17): arch=40000003 syscall=3 success=no exit=-3 a0=e a1=bfa13948 a2=1000 a3=0 items=0 ppid=1 pid=2471 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="console-kit-dae" exe="/usr/sbin/console-kit-daemon" subj=system_u:system_r:system_dbusd_t:s0 key=(null) I tried removing the above rule, setting "allow_ptrace=1" and reinserting the allow rule, but no joy. Still get this AVC and no sound. Also, the new "shutdown" menu item generates lots of AVCs: #============= system_dbusd_t ============== allow system_dbusd_t init_exec_t:file { read execute execute_no_trans }; allow system_dbusd_t initctl_t:fifo_file write; allow system_dbusd_t initrc_var_run_t:file { read write lock }; allow system_dbusd_t lib_t:file execute_no_trans; allow system_dbusd_t polkit_auth_exec_t:file { read execute execute_no_trans }; allow system_dbusd_t polkit_var_lib_t:dir search; allow system_dbusd_t polkit_var_lib_t:file { read getattr }; allow system_dbusd_t polkit_var_run_t:dir search; allow system_dbusd_t shell_exec_t:file { read execute }; allow system_dbusd_t tty_device_t:chr_file { write getattr }; After adding these, still doesn't work. Will try "semodule -DB"...... From olivares14031 at yahoo.com Sat Jan 26 20:26:22 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Sat, 26 Jan 2008 12:26:22 -0800 (PST) Subject: SELinux is preventing dbus-daemon-lau(/lib/dbus-1/dbus-daemon-launch-helper) Message-ID: <128080.38790.qm@web52605.mail.re2.yahoo.com> Dear all, As of updates to machine rawhide report 20080126, I get the following warning from setroubleshoot: Is it related to the previous one, dbus-daemon, or is it a new one? Thanks, Antonio Summary: SELinux is preventing dbus-daemon-lau(/lib/dbus-1/dbus-daemon-launch-helper) (system_dbusd_t) "execute" to (consolekit_exec_t). Detailed Description: SELinux denied access requested by dbus-daemon-lau(/lib/dbus-1/dbus-daemon-launch-helper). It is not expected that this access is required by dbus-daemon-lau(/lib/dbus-1/dbus-daemon-launch-helper) 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 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:system_dbusd_t Target Context system_u:object_r:consolekit_exec_t Target Objects None [ file ] Source dbus-daemon-lau(/lib/dbus-1/dbus-daemon-launch- helper) Port Host localhost Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.2.5-19.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.24-2.fc9 #1 SMP Fri Jan 25 13:14:54 EST 2008 i686 athlon Alert Count 17 First Seen Sat 26 Jan 2008 02:17:08 PM CST Last Seen Sat 26 Jan 2008 02:18:52 PM CST Local ID 49f54895-d96b-44a0-8144-e7c4e8b3965f Line Numbers Raw Audit Messages host=localhost type=AVC msg=audit(1201378732.288:37): avc: denied { execute } for pid=2640 comm="dbus-daemon-lau" name="console-kit-daemon" dev=dm-0 ino=32542536 scontext=system_u:system_r:system_dbusd_t:s0 tcontext=system_u:object_r:consolekit_exec_t:s0 tclass=file host=localhost type=SYSCALL msg=audit(1201378732.288:37): arch=40000003 syscall=11 success=no exit=-13 a0=9750020 a1=974fc80 a2=974f008 a3=60099c items=0 ppid=2639 pid=2640 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="dbus-daemon-lau" exe="/lib/dbus-1/dbus-daemon-launch-helper" subj=system_u:system_r:system_dbusd_t:s0 key=(null) ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From selinux at gmail.com Sat Jan 26 21:02:41 2008 From: selinux at gmail.com (Tom London) Date: Sat, 26 Jan 2008 13:02:41 -0800 Subject: Rawhide kernel/etc. breaks sound, system_dbusd_t AVCs In-Reply-To: <4c4ba1530801261220x7b690d90td563672f621b45ba@mail.gmail.com> References: <4c4ba1530801261056s100e7e38j367abd84d4649f9f@mail.gmail.com> <4c4ba1530801261220x7b690d90td563672f621b45ba@mail.gmail.com> Message-ID: <4c4ba1530801261302u7c6b4cb6kd5c2eba6485d58d0@mail.gmail.com> On Jan 26, 2008 12:20 PM, Tom London wrote: > Appears a bit more complicated..... > > Even after adding all the above, sound is still disabled. > > Here is the AVC: > type=AVC msg=audit(1201376293.488:17): avc: denied { ptrace } for > pid=2471 comm="console-kit-dae" > scontext=system_u:system_r:system_dbusd_t:s0 > tcontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tclass=process > type=SYSCALL msg=audit(1201376293.488:17): arch=40000003 syscall=3 > success=no exit=-3 a0=e a1=bfa13948 a2=1000 a3=0 items=0 ppid=1 > pid=2471 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=(none) comm="console-kit-dae" > exe="/usr/sbin/console-kit-daemon" > subj=system_u:system_r:system_dbusd_t:s0 key=(null) > > I tried removing the above rule, setting "allow_ptrace=1" and > reinserting the allow rule, but no joy. Still get this AVC and no > sound. > > Also, the new "shutdown" menu item generates lots of AVCs: > > > #============= system_dbusd_t ============== > allow system_dbusd_t init_exec_t:file { read execute execute_no_trans }; > allow system_dbusd_t initctl_t:fifo_file write; > allow system_dbusd_t initrc_var_run_t:file { read write lock }; > allow system_dbusd_t lib_t:file execute_no_trans; > allow system_dbusd_t polkit_auth_exec_t:file { read execute execute_no_trans }; > allow system_dbusd_t polkit_var_lib_t:dir search; > allow system_dbusd_t polkit_var_lib_t:file { read getattr }; > allow system_dbusd_t polkit_var_run_t:dir search; > allow system_dbusd_t shell_exec_t:file { read execute }; > allow system_dbusd_t tty_device_t:chr_file { write getattr }; > > After adding these, still doesn't work. > > Will try "semodule -DB"...... > Wow.... lots of stuff generated by -DB. I attach /var/log/audit/audit.log. Not sure its relevant, but the only extra console-kit AVC is: type=AVC msg=audit(1201380675.325:136): avc: denied { sys_tty_config } for pid=2728 comm="console-kit-dae" capability=26 scontext=system_u:system_r:system_dbusd_t:s0 tcontext=system_u:system_r:system_dbusd_t:s0 tclass=capability Something else? tom -- Tom London From dant at cdkkt.com Sat Jan 26 22:04:05 2008 From: dant at cdkkt.com (Dan Thurman) Date: Sat, 26 Jan 2008 14:04:05 -0800 Subject: spamass-milter initrc_t issues Message-ID: <200801261404.06090.dant@cdkkt.com> I have tried in vain to resolve the spamass-milter issue and selinux. Nothing I have tried manually, worked to resolve this issue. The specific issues that I had was that selinux was expecting spamass-milter to be of type initrc_t. I have simply turned off spamass-milter in my sendmail.mc file until I can get this issue resolved. Here are some examples of complaints: /var/log/maillog: ======================== Jan 26 13:56:47 gold sendmail[2408]: m0QLuhZk002408: from=dant, size=53, class=0, nrcpts=1, msgid=<200801262156.m0QLuhZk002408 at gold.cdkkt.com>, relay=dant at localhost Jan 26 13:56:47 gold sendmail[2410]: m0QLulQ9002410: Milter (spamassassin): error connecting to filter: Permission denied Jan 26 13:56:47 gold sendmail[2410]: m0QLulQ9002410: Milter (spamassassin): to error state Jan 26 13:56:47 gold sendmail[2410]: STARTTLS=server, relay=localhost.localdomain [127.0.0.1], version=TLSv1/SSLv3, verify=NO, cipher=DHE-RSA-AES256-SHA, bits=256/256 Jan 26 13:56:47 gold sendmail[2408]: STARTTLS=client, relay=[127.0.0.1], version=TLSv1/SSLv3, verify=FAIL, cipher=DHE-RSA-AES256-SHA, bits=256/256 Jan 26 13:56:50 gold sendmail[2410]: m0QLulQA002410: from=, size=332, class=0, nrcpts=1, msgid=<200801262156.m0QLuhZk002408 at gold.cdkkt.com>, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1] Jan 26 13:56:50 gold sendmail[2410]: m0QLulQA002410: Milter add: header: X-Virus-Scanned: ClamAV 0.92/5562/Sat Jan 26 03:34:23 2008 on gold.cdkkt.com Jan 26 13:56:50 gold sendmail[2410]: m0QLulQA002410: Milter add: header: X-Virus-Status: Clean Jan 26 13:56:50 gold sendmail[2408]: m0QLuhZk002408: to=dbthurman at hotmail.com, ctladdr=dant (500/500), delay=00:00:07, xdelay=00:00:03, mailer=relay, pri=30053, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (m0QLulQA002410 Message accepted for delivery) Jan 26 13:57:12 gold sendmail[2414]: m0QLulQA002410: to=, ctladdr= (500/500), delay=00:00:23, xdelay=00:00:22, mailer=esmtp, pri=120332, relay=mx3.hotmail.com. [65.54.244.200], dsn=2.0.0, stat=Sent ( <200801262156.m0QLuhZk002408 at gold.cdkkt.com> Queued mail for delivery) ======================== /var/log/messages: ======================== Jan 26 13:56:53 gold setroubleshoot: #012 SELinux is preventing /usr/sbin/sendmail.sendmail (sendmail_t) "connectto" to /var/run/spamass-milter/spamass-milter.sock (initrc_t).#012 For complete SELinux messages. run sealert -l a82ae4e6-5276-4fe6-9db0-44af64ea413d ======================== sealert -l a82ae4e6-5276-4fe6-9db0-44af64ea413d ======================== Summary SELinux is preventing /usr/sbin/sendmail.sendmail (sendmail_t) "connectto" to /var/run/spamass-milter/spamass-milter.sock (initrc_t). Detailed Description SELinux denied access requested by /usr/sbin/sendmail.sendmail. It is not expected that this access is required by /usr/sbin/sendmail.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. Allowing Access 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:sendmail_t:s0 Target Context system_u:system_r:initrc_t:s0 Target Objects /var/run/spamass-milter/spamass-milter.sock [ unix_stream_socket ] Affected RPM Packages sendmail-8.14.2-1.fc8 [application] Policy RPM selinux-policy-3.0.8-76.fc8 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.catchall Host Name gold.cdkkt.com Platform Linux gold.cdkkt.com 2.6.23.14-107.fc8 #1 SMP Mon Jan 14 21:37:30 EST 2008 i686 i686 Alert Count 1 First Seen Sat Jan 26 13:56:47 2008 Last Seen Sat Jan 26 13:56:47 2008 Local ID a82ae4e6-5276-4fe6-9db0-44af64ea413d Line Numbers Raw Audit Messages avc: denied { connectto } for comm=sendmail egid=51 euid=0 exe=/usr/sbin/sendmail.sendmail exit=-13 fsgid=51 fsuid=0 gid=0 items=0 path=/var/run/spamass-milter/spamass-milter.sock pid=2410 scontext=system_u:system_r:sendmail_t:s0 sgid=51 subj=system_u:system_r:sendmail_t:s0 suid=0 tclass=unix_stream_socket tcontext=system_u:system_r:initrc_t:s0 tty=(none) uid=0 ======================== From selinux at gmail.com Sat Jan 26 23:27:21 2008 From: selinux at gmail.com (Tom London) Date: Sat, 26 Jan 2008 15:27:21 -0800 Subject: Rawhide kernel/etc. breaks sound, system_dbusd_t AVCs In-Reply-To: <4c4ba1530801261302u7c6b4cb6kd5c2eba6485d58d0@mail.gmail.com> References: <4c4ba1530801261056s100e7e38j367abd84d4649f9f@mail.gmail.com> <4c4ba1530801261220x7b690d90td563672f621b45ba@mail.gmail.com> <4c4ba1530801261302u7c6b4cb6kd5c2eba6485d58d0@mail.gmail.com> Message-ID: <4c4ba1530801261527q526dd36dhb4812ee12b2e9a79@mail.gmail.com> On Jan 26, 2008 1:02 PM, Tom London wrote: > > Wow.... lots of stuff generated by -DB. I attach /var/log/audit/audit.log. > > Not sure its relevant, but the only extra console-kit AVC is: > > type=AVC msg=audit(1201380675.325:136): avc: denied { sys_tty_config > } for pid=2728 comm="console-kit-dae" capability=26 > scontext=system_u:system_r:system_dbusd_t:s0 > tcontext=system_u:system_r:system_dbusd_t:s0 tclass=capability > > Something else? > Ooops.... forgot to attach AVCs... Here is output from 'audit2allow', I attach the complete log. [root at localhost ~]# audit2allow -i logDB #============= NetworkManager_t ============== allow NetworkManager_t dhcpc_t:process { siginh rlimitinh noatsecure }; allow NetworkManager_t ifconfig_t:process { siginh rlimitinh noatsecure }; allow NetworkManager_t initrc_t:process { siginh rlimitinh noatsecure }; allow NetworkManager_t nscd_t:process { siginh rlimitinh noatsecure }; allow NetworkManager_t security_t:dir { search getattr }; allow NetworkManager_t security_t:file read; #============= cupsd_t ============== allow cupsd_t default_context_t:dir search; allow cupsd_t file_context_t:dir search; allow cupsd_t file_context_t:file { read getattr }; allow cupsd_t krb5_conf_t:file write; allow cupsd_t self:process setfscreate; #============= dhcpc_t ============== allow dhcpc_t security_t:dir { search getattr }; allow dhcpc_t security_t:file read; allow dhcpc_t selinux_config_t:dir search; allow dhcpc_t selinux_config_t:file { read getattr }; #============= hald_acl_t ============== allow hald_acl_t polkit_auth_t:process { siginh rlimitinh noatsecure }; allow hald_acl_t security_t:dir { search getattr }; allow hald_acl_t security_t:file read; allow hald_acl_t security_t:filesystem getattr; allow hald_acl_t selinux_config_t:dir search; allow hald_acl_t selinux_config_t:file { read getattr }; #============= hald_t ============== allow hald_t dmidecode_t:process { siginh rlimitinh noatsecure }; allow hald_t hald_acl_t:process { siginh rlimitinh noatsecure }; allow hald_t polkit_auth_t:process { siginh rlimitinh noatsecure }; #============= ifconfig_t ============== allow ifconfig_t security_t:dir { search getattr }; allow ifconfig_t security_t:file read; allow ifconfig_t security_t:filesystem getattr; allow ifconfig_t selinux_config_t:dir search; allow ifconfig_t selinux_config_t:file { read getattr }; #============= init_t ============== allow init_t getty_t:process { siginh rlimitinh noatsecure }; allow init_t initrc_t:process { siginh rlimitinh noatsecure }; #============= insmod_t ============== allow insmod_t tty_device_t:chr_file { read write }; allow insmod_t xdm_xserver_t:tcp_socket { read write }; allow insmod_t xdm_xserver_t:unix_stream_socket { read write }; allow insmod_t xserver_log_t:file write; #============= pam_t ============== allow pam_t user_home_t:file read; #============= polkit_auth_t ============== allow polkit_auth_t security_t:dir { search getattr }; allow polkit_auth_t security_t:file read; allow polkit_auth_t security_t:filesystem getattr; allow polkit_auth_t selinux_config_t:dir search; allow polkit_auth_t selinux_config_t:file { read getattr }; #============= setroubleshootd_t ============== allow setroubleshootd_t rpm_var_lib_t:dir { write add_name }; allow setroubleshootd_t rpm_var_lib_t:file { write create }; #============= system_chkpwd_t ============== allow system_chkpwd_t security_t:dir { search getattr }; allow system_chkpwd_t security_t:file read; allow system_chkpwd_t security_t:filesystem getattr; #============= system_dbusd_t ============== allow system_dbusd_t NetworkManager_t:process { siginh rlimitinh noatsecure }; allow system_dbusd_t self:capability sys_tty_config; allow system_dbusd_t xdm_t:process ptrace; #============= udev_t ============== allow udev_t pam_console_t:process { siginh rlimitinh noatsecure }; #============= unconfined_chkpwd_t ============== allow unconfined_chkpwd_t security_t:dir { search getattr }; allow unconfined_chkpwd_t security_t:file read; allow unconfined_chkpwd_t security_t:filesystem getattr; #============= unconfined_dbusd_t ============== allow unconfined_dbusd_t unconfined_t:process { siginh rlimitinh noatsecure }; allow unconfined_dbusd_t user_home_t:file append; #============= xdm_t ============== allow xdm_t pam_console_t:process { siginh rlimitinh noatsecure }; allow xdm_t system_chkpwd_t:process { siginh rlimitinh noatsecure }; allow xdm_t unconfined_t:process { siginh noatsecure }; allow xdm_t xdm_dbusd_t:process { siginh rlimitinh noatsecure }; #============= xdm_xserver_t ============== allow xdm_xserver_t insmod_t:process { siginh rlimitinh noatsecure }; allow xdm_xserver_t mono_t:process ptrace; allow xdm_xserver_t security_t:dir { search getattr }; allow xdm_xserver_t security_t:file read; allow xdm_xserver_t security_t:filesystem getattr; allow xdm_xserver_t selinux_config_t:dir search; allow xdm_xserver_t selinux_config_t:file { read getattr }; allow xdm_xserver_t unconfined_execmem_t:process ptrace; allow xdm_xserver_t unconfined_t:process ptrace; allow xdm_xserver_t xdm_t:process ptrace; [root at localhost ~]# Any of these look suspicious? tom -- Tom London -------------- next part -------------- A non-text attachment was scrubbed... Name: logDB.gz Type: application/x-gzip Size: 6878 bytes Desc: not available URL: From selinux at gmail.com Sat Jan 26 23:56:13 2008 From: selinux at gmail.com (Tom London) Date: Sat, 26 Jan 2008 15:56:13 -0800 Subject: Rawhide kernel/etc. breaks sound, system_dbusd_t AVCs In-Reply-To: <4c4ba1530801261527q526dd36dhb4812ee12b2e9a79@mail.gmail.com> References: <4c4ba1530801261056s100e7e38j367abd84d4649f9f@mail.gmail.com> <4c4ba1530801261220x7b690d90td563672f621b45ba@mail.gmail.com> <4c4ba1530801261302u7c6b4cb6kd5c2eba6485d58d0@mail.gmail.com> <4c4ba1530801261527q526dd36dhb4812ee12b2e9a79@mail.gmail.com> Message-ID: <4c4ba1530801261556m7da02d47o2b0386e5aa447e4@mail.gmail.com> OK, through a process of elimination, it appears that the "missing AVC" is type=AVC msg=audit(1201380657.580:110): avc: denied { sys_tty_config } for pid=2474 comm="console-kit-dae" capability=26 scontext=system_u:system_r:system_dbusd_t:s0 tcontext=system_u:system_r:system_dbusd_t:s0 tclass=capability type=SYSCALL msg=audit(1201380657.580:110): arch=40000003 syscall=54 success=yes exit=0 a0=c a1=5603 a2=bfd48356 a3=c items=0 ppid=1 pid=2474 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="console-kit-dae" exe="/usr/sbin/console-kit-daemon" subj=system_u:system_r:system_dbusd_t:s0 key=(null) or #============= system_dbusd_t ============== allow system_dbusd_t self:capability sys_tty_config; If I haven't confused myself silly, adding this to the AVCs generated in permissive mode makes sound work. Suspect "shutdown" may need this too. tom From paul at city-fan.org Sun Jan 27 01:02:47 2008 From: paul at city-fan.org (Paul Howarth) Date: Sun, 27 Jan 2008 01:02:47 +0000 Subject: spamass-milter initrc_t issues In-Reply-To: <200801261404.06090.dant@cdkkt.com> References: <200801261404.06090.dant@cdkkt.com> Message-ID: <20080127010247.1d0c01fe@metropolis.intra.city-fan.org> On Sat, 26 Jan 2008 14:04:05 -0800 Dan Thurman wrote: > > I have tried in vain to resolve the spamass-milter issue and > selinux. Nothing I have tried manually, worked to resolve this > issue. The specific issues that I had was that selinux was expecting > spamass-milter to be of type initrc_t. > > I have simply turned off spamass-milter in my sendmail.mc file until > I can get this issue resolved. This is in bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=425958 It'll be fixed by the next selinux-policy update. You can get it here as it's not in updates-testing yet: http://koji.fedoraproject.org/koji/buildinfo?buildID=32698 Paul. From mike.clarkson at baesystems.com Mon Jan 28 17:18:12 2008 From: mike.clarkson at baesystems.com (Clarkson, Mike R (US SSA)) Date: Mon, 28 Jan 2008 09:18:12 -0800 Subject: module install during make not working correctly Message-ID: I have a simple helloworld example and policy module with the following line in the helloworldfile.fc file: /usr/local/test/HelloWorldFile -- gen_context(root:object_r:helloworld_exec_t,__SYSTEMLOW__) When I make the policy using "make load", it appears to install the helloworldfile.pp in /usr/share/selinux/mls and then install it using semodule. After doing this if I use restorecon to set the file context of /usr/local/test/HelloWorldFile, the context is incorrect. It has the type usr_t, which is the type for the /usr/local/test directory. If I then manually install the module using "/usr/sbin/semodule -i /usr/share/selinux/mls/helloworldfile.pp", and again use restorecon to reset the file context, it has the correct context. I have no idea why the module install during the "make" process is not working correctly. I'd appreciate any help in figuring out what is going on. I'm using RHEL5.1 with the mls policy. Below I have captured the sequence of commands described above, along with the output. Thanks [clarkson at m2ut5 test]# make load Compliling mls helloworldfile.mod module echo "ifdef(\`""helloworldfile""_per_role_template',\`" > tmp/helloworldfile.mod.role m4 -D strict_policy -D enable_mls -D mls_num_sens=5 -D mls_num_cats=256 -D mcs_num_cats=256 -D hide_broken_symptoms policy/rolemap | gawk '/^[[:blank:]]*[A-Za-z]/{ print "gen_require(type " $3 "; role " $1 ";)\nhelloworldfile_per_role_template(" $2 "," $3 "," $1 ")" }' >> tmp/helloworldfile.mod.role echo "')" >> tmp/helloworldfile.mod.role echo "ifdef(\`""helloworldfile""_per_userdomain_template',\`" >> tmp/helloworldfile.mod.role echo "errprint(\`Warning: per_userdomain_templates have been renamed to per_role_templates (""helloworldfile""_per_userdomain_template)'__endline__)" >> tmp/helloworldfile.mod.role m4 -D strict_policy -D enable_mls -D mls_num_sens=5 -D mls_num_cats=256 -D mcs_num_cats=256 -D hide_broken_symptoms policy/rolemap | gawk '/^[[:blank:]]*[A-Za-z]/{ print "gen_require(type " $3 "; role " $1 ";)\nhelloworldfile_per_userdomain_template(" $2 "," $3 "," $1 ")" }' >> tmp/helloworldfile.mod.role echo "')" >> tmp/helloworldfile.mod.role m4 -D strict_policy -D enable_mls -D mls_num_sens=5 -D mls_num_cats=256 -D mcs_num_cats=256 -D hide_broken_symptoms -s policy/support/fc_dir_variables.spt policy/support/file_patterns.spt policy/support/loadable_module.spt policy/support/misc_macros.spt policy/support/mls_mcs_macros.spt policy/support/obj_perm_sets.spt tmp/generated_definitions.conf tmp/all_interfaces.conf policy/modules/apps/helloworldfile.te tmp/helloworldfile.mod.role > tmp/helloworldfile.tmp /usr/bin/checkmodule -M -m tmp/helloworldfile.tmp -o tmp/helloworldfile.mod /usr/bin/checkmodule: loading policy configuration from tmp/helloworldfile.tmp /usr/bin/checkmodule: policy configuration loaded /usr/bin/checkmodule: writing binary representation (version 6) to tmp/helloworldfile.mod m4 -D strict_policy -D enable_mls -D mls_num_sens=5 -D mls_num_cats=256 -D mcs_num_cats=256 -D hide_broken_symptoms policy/support/fc_dir_variables.spt policy/support/file_patterns.spt policy/support/loadable_module.spt policy/support/misc_macros.spt policy/support/mls_mcs_macros.spt policy/support/obj_perm_sets.spt policy/support/fc_dir_variables.spt policy/support/file_patterns.spt policy/support/loadable_module.spt policy/support/misc_macros.spt policy/support/mls_mcs_macros.spt policy/support/obj_perm_sets.spt policy/modules/apps/helloworldfile.fc > tmp/helloworldfile.mod.fc Creating mls helloworldfile.pp policy package /usr/bin/semodule_package -o helloworldfile.pp -m tmp/helloworldfile.mod -f tmp/helloworldfile.mod.fc Installing mls helloworldfile.pp policy package. install -m 0644 helloworldfile.pp /usr/share/selinux/mls Loading configured modules. /usr/sbin/semodule -s mls -b /usr/share/selinux/mls/base.pp -i /usr/share/selinux/mls/acct.pp -i /usr/share/selinux/mls/ada.pp -i /usr/share/selinux/mls/afs.pp -i /usr/share/selinux/mls/aide.pp -i /usr/share/selinux/mls/alsa.pp -i /usr/share/selinux/mls/amanda.pp -i /usr/share/selinux/mls/amavis.pp -i /usr/share/selinux/mls/amtu.pp -i /usr/share/selinux/mls/anaconda.pp -i /usr/share/selinux/mls/apache.pp -i /usr/share/selinux/mls/apm.pp -i /usr/share/selinux/mls/apt.pp -i /usr/share/selinux/mls/arpwatch.pp -i /usr/share/selinux/mls/asterisk.pp -i /usr/share/selinux/mls/audioentropy.pp -i /usr/share/selinux/mls/audit.pp -i /usr/share/selinux/mls/authbind.pp -i /usr/share/selinux/mls/authlogin.pp -i /usr/share/selinux/mls/automount.pp -i /usr/share/selinux/mls/avahi.pp -i /usr/share/selinux/mls/backup.pp -i /usr/share/selinux/mls/bind.pp -i /usr/share/selinux/mls/bluetooth.pp -i /usr/share/selinux/mls/bootloader.pp -i /usr/share/selinux/mls/calamaris.pp -i /usr/share/selinux/mls/canna.pp -i /usr/share/selinux/mls/ccs.pp -i /usr/share/selinux/mls/cdrecord.pp -i /usr/share/selinux/mls/certwatch.pp -i /usr/share/selinux/mls/cipe.pp -i /usr/share/selinux/mls/clamav.pp -i /usr/share/selinux/mls/clock.pp -i /usr/share/selinux/mls/clockspeed.pp -i /usr/share/selinux/mls/comsat.pp -i /usr/share/selinux/mls/consoletype.pp -i /usr/share/selinux/mls/courier.pp -i /usr/share/selinux/mls/cpucontrol.pp -i /usr/share/selinux/mls/cron.pp -i /usr/share/selinux/mls/cups.pp -i /usr/share/selinux/mls/cvs.pp -i /usr/share/selinux/mls/cyrus.pp -i /usr/share/selinux/mls/daemontools.pp -i /usr/share/selinux/mls/dante.pp -i /usr/share/selinux/mls/dbskk.pp -i /usr/share/selinux/mls/dbus.pp -i /usr/share/selinux/mls/dcc.pp -i /usr/share/selinux/mls/ddclient.pp -i /usr/share/selinux/mls/ddcprobe.pp -i /usr/share/selinux/mls/dhcp.pp -i /usr/share/selinux/mls/dictd.pp -i /usr/share/selinux/mls/distcc.pp -i /usr/share/selinux/mls/djbdns.pp -i /usr/share/selinux/mls/dmesg.pp -i /usr/share/selinux/mls/dmidecode.pp -i /usr/share/selinux/mls/dnsmasq.pp -i /usr/share/selinux/mls/dovecot.pp -i /usr/share/selinux/mls/dpkg.pp -i /usr/share/selinux/mls/ethereal.pp -i /usr/share/selinux/mls/evolution.pp -i /usr/share/selinux/mls/export.pp -i /usr/share/selinux/mls/fail2ban.pp -i /usr/share/selinux/mls/fetchmail.pp -i /usr/share/selinux/mls/finger.pp -i /usr/share/selinux/mls/firstboot.pp -i /usr/share/selinux/mls/frontgate.pp -i /usr/share/selinux/mls/fstools.pp -i /usr/share/selinux/mls/ftp.pp -i /usr/share/selinux/mls/ftp_trans.pp -i /usr/share/selinux/mls/games.pp -i /usr/share/selinux/mls/gatekeeper.pp -i /usr/share/selinux/mls/getty.pp -i /usr/share/selinux/mls/gift.pp -i /usr/share/selinux/mls/gnome.pp -i /usr/share/selinux/mls/gpg.pp -i /usr/share/selinux/mls/gpm.pp -i /usr/share/selinux/mls/hal.pp -i /usr/share/selinux/mls/helloworldfile.pp -i /usr/share/selinux/mls/hostname.pp -i /usr/share/selinux/mls/hotplug.pp -i /usr/share/selinux/mls/howl.pp -i /usr/share/selinux/mls/i18n_input.pp -i /usr/share/selinux/mls/imaze.pp -i /usr/share/selinux/mls/import.pp -i /usr/share/selinux/mls/inetd.pp -i /usr/share/selinux/mls/init.pp -i /usr/share/selinux/mls/inn.pp -i /usr/share/selinux/mls/ipsec.pp -i /usr/share/selinux/mls/iptables.pp -i /usr/share/selinux/mls/irc.pp -i /usr/share/selinux/mls/ircd.pp -i /usr/share/selinux/mls/irqbalance.pp -i /usr/share/selinux/mls/iscsi.pp -i /usr/share/selinux/mls/jabber.pp -i /usr/share/selinux/mls/java.pp -i /usr/share/selinux/mls/kerberos.pp -i /usr/share/selinux/mls/ktalk.pp -i /usr/share/selinux/mls/kudzu.pp -i /usr/share/selinux/mls/ldap.pp -i /usr/share/selinux/mls/libraries.pp -i /usr/share/selinux/mls/loadkeys.pp -i /usr/share/selinux/mls/locallogin.pp -i /usr/share/selinux/mls/lockdev.pp -i /usr/share/selinux/mls/logging.pp -i /usr/share/selinux/mls/logrotate.pp -i /usr/share/selinux/mls/logwatch.pp -i /usr/share/selinux/mls/lpd.pp -i /usr/share/selinux/mls/lvm.pp -i /usr/share/selinux/mls/mailman.pp -i /usr/share/selinux/mls/miscfiles.pp -i /usr/share/selinux/mls/modutils.pp -i /usr/share/selinux/mls/mono.pp -i /usr/share/selinux/mls/monop.pp -i /usr/share/selinux/mls/mount.pp -i /usr/share/selinux/mls/mozilla.pp -i /usr/share/selinux/mls/mplayer.pp -i /usr/share/selinux/mls/mrtg.pp -i /usr/share/selinux/mls/mta.pp -i /usr/share/selinux/mls/munin.pp -i /usr/share/selinux/mls/mysql.pp -i /usr/share/selinux/mls/nagios.pp -i /usr/share/selinux/mls/nessus.pp -i /usr/share/selinux/mls/netlabel.pp -i /usr/share/selinux/mls/netutils.pp -i /usr/share/selinux/mls/networkmanager.pp -i /usr/share/selinux/mls/nis.pp -i /usr/share/selinux/mls/nscd.pp -i /usr/share/selinux/mls/nsd.pp -i /usr/share/selinux/mls/ntop.pp -i /usr/share/selinux/mls/ntp.pp -i /usr/share/selinux/mls/nx.pp -i /usr/share/selinux/mls/oav.pp -i /usr/share/selinux/mls/oddjob.pp -i /usr/share/selinux/mls/openca.pp -i /usr/share/selinux/mls/openct.pp -i /usr/share/selinux/mls/openvpn.pp -i /usr/share/selinux/mls/oracle_db.pp -i /usr/share/selinux/mls/oracle_sp.pp -i /usr/share/selinux/mls/pcmcia.pp -i /usr/share/selinux/mls/pcs.pp -i /usr/share/selinux/mls/pcscd.pp -i /usr/share/selinux/mls/pegasus.pp -i /usr/share/selinux/mls/perdition.pp -i /usr/share/selinux/mls/portage.pp -i /usr/share/selinux/mls/portmap.pp -i /usr/share/selinux/mls/portslave.pp -i /usr/share/selinux/mls/postfix.pp -i /usr/share/selinux/mls/postgresql.pp -i /usr/share/selinux/mls/postgrey.pp -i /usr/share/selinux/mls/ppp.pp -i /usr/share/selinux/mls/prelink.pp -i /usr/share/selinux/mls/privoxy.pp -i /usr/share/selinux/mls/procmail.pp -i /usr/share/selinux/mls/publicfile.pp -i /usr/share/selinux/mls/pxe.pp -i /usr/share/selinux/mls/pyzor.pp -i /usr/share/selinux/mls/qmail.pp -i /usr/share/selinux/mls/query.pp -i /usr/share/selinux/mls/quota.pp -i /usr/share/selinux/mls/radius.pp -i /usr/share/selinux/mls/radvd.pp -i /usr/share/selinux/mls/raid.pp -i /usr/share/selinux/mls/razor.pp -i /usr/share/selinux/mls/rdisc.pp -i /usr/share/selinux/mls/readahead.pp -i /usr/share/selinux/mls/remotelogin.pp -i /usr/share/selinux/mls/resmgr.pp -i /usr/share/selinux/mls/rhgb.pp -i /usr/share/selinux/mls/ricci.pp -i /usr/share/selinux/mls/rlogin.pp -i /usr/share/selinux/mls/roundup.pp -i /usr/share/selinux/mls/rpc.pp -i /usr/share/selinux/mls/rpm.pp -i /usr/share/selinux/mls/rshd.pp -i /usr/share/selinux/mls/rssh.pp -i /usr/share/selinux/mls/rsync.pp -i /usr/share/selinux/mls/samba.pp -i /usr/share/selinux/mls/sasl.pp -i /usr/share/selinux/mls/screen.pp -i /usr/share/selinux/mls/selinuxutil.pp -i /usr/share/selinux/mls/sendmail.pp -i /usr/share/selinux/mls/setcontest.pp -i /usr/share/selinux/mls/setrans.pp -i /usr/share/selinux/mls/setroubleshoot.pp -i /usr/share/selinux/mls/slocate.pp -i /usr/share/selinux/mls/slrnpull.pp -i /usr/share/selinux/mls/smartmon.pp -i /usr/share/selinux/mls/snmp.pp -i /usr/share/selinux/mls/snort.pp -i /usr/share/selinux/mls/soundserver.pp -i /usr/share/selinux/mls/spamassassin.pp -i /usr/share/selinux/mls/speedtouch.pp -i /usr/share/selinux/mls/squid.pp -i /usr/share/selinux/mls/ssh.pp -i /usr/share/selinux/mls/storage.pp -i /usr/share/selinux/mls/stunnel.pp -i /usr/share/selinux/mls/su.pp -i /usr/share/selinux/mls/sudo.pp -i /usr/share/selinux/mls/sxid.pp -i /usr/share/selinux/mls/sysnetwork.pp -i /usr/share/selinux/mls/sysstat.pp -i /usr/share/selinux/mls/tcpd.pp -i /usr/share/selinux/mls/telnet.pp -i /usr/share/selinux/mls/tftp.pp -i /usr/share/selinux/mls/thunderbird.pp -i /usr/share/selinux/mls/timidity.pp -i /usr/share/selinux/mls/tmpreaper.pp -i /usr/share/selinux/mls/tor.pp -i /usr/share/selinux/mls/transproxy.pp -i /usr/share/selinux/mls/tripwire.pp -i /usr/share/selinux/mls/tvtime.pp -i /usr/share/selinux/mls/tzdata.pp -i /usr/share/selinux/mls/ucspitcp.pp -i /usr/share/selinux/mls/udev.pp -i /usr/share/selinux/mls/uml.pp -i /usr/share/selinux/mls/unconfined.pp -i /usr/share/selinux/mls/updfstab.pp -i /usr/share/selinux/mls/uptime.pp -i /usr/share/selinux/mls/usbmodules.pp -i /usr/share/selinux/mls/userdomain.pp -i /usr/share/selinux/mls/userhelper.pp -i /usr/share/selinux/mls/usermanage.pp -i /usr/share/selinux/mls/usernetctl.pp -i /usr/share/selinux/mls/uucp.pp -i /usr/share/selinux/mls/uwimap.pp -i /usr/share/selinux/mls/vbetool.pp -i /usr/share/selinux/mls/vmware.pp -i /usr/share/selinux/mls/vpn.pp -i /usr/share/selinux/mls/watchdog.pp -i /usr/share/selinux/mls/webalizer.pp -i /usr/share/selinux/mls/weblogic.pp -i /usr/share/selinux/mls/wine.pp -i /usr/share/selinux/mls/xen.pp -i /usr/share/selinux/mls/xfs.pp -i /usr/share/selinux/mls/xprint.pp -i /usr/share/selinux/mls/xserver.pp -i /usr/share/selinux/mls/yam.pp -i /usr/share/selinux/mls/zebra.pp rm tmp/helloworldfile.mod.fc tmp/helloworldfile.mod [clarkson at m2ut5 policy]# cd /usr/local/test [clarkson at m2ut5 test]# /sbin/restorecon HelloWorldFile [clarkson at m2ut5 test]# ls -Z HelloWorldFile -rwxr-xr-x clarkson m2 system_u:object_r:usr_t:SystemLow HelloWorldFile [clarkson at m2ut5 test]# /usr/sbin/semodule -i /usr/share/selinux/mls/helloworldfile.pp [clarkson at m2ut5 test]# /sbin/restorecon HelloWorldFile [clarkson at m2ut5 test]# ls -Z HelloWorldFile -rwxr-xr-x clarkson m2 root:object_r:helloworld_exec_t:SystemLow HelloWorldFile From dpquigl at tycho.nsa.gov Mon Jan 28 17:06:54 2008 From: dpquigl at tycho.nsa.gov (Dave Quigley) Date: Mon, 28 Jan 2008 12:06:54 -0500 Subject: OLS 2008 SELinux Proposals for review and comments Message-ID: <1201540014.24702.331.camel@moss-terrapins.epoch.ncsc.mil> Hello Everyone, I have put together a series of proposals for OLS this year which include a talk on Labeled-NFS, an SELinux BOF, and an SELinux tutorial. You will find them attached to this email. If you have any questions/comments/and or complaints please feel free to make them. Dave Quigley -------------- next part -------------- BOF: NSA Security-Enhanced Linux (SELinux) The NSA Security-Enhanced Linux (SELinux) BOF is intended to provide a forum for people who are already working on SELinux or are interested in learning about the project. The BOF will begin with a short presentation that briefly describes the background and status of SELinux, reviews recent developments, and discusses current directions for the project. Then the BOF will be opened for discussion, including questions and feedback from developers and users. Likely topics will include: policy development environment and policy generation tools, SELinux administration, Distro integration, network storage support and usability issues. -------------- next part -------------- SELinux is the most widly deployed system for Mandatory Access Controls (MAC) in Linux. Since its debut much has changed as distributions continue to add functionality based on user feedback. Despite its growing availability some people dismiss SELinux because it is "too hard." This tutorial addresses these concerns by providing a basic understanding of SELinux and how to accomplish common SELinux tasks. Topics: How SELinux Works Enabling SELinux Checking for Unconfined Demons Debugging SELinux Policy Errors Using Booleans SELinux Daemons and What They Do Policy Development Considering SELinux in your Development Process Time: 4 hours -------------- next part -------------- As the use of SELinux expands in Enterprise environments customers are requesting the ability to use SELinux with their NFS based network storage. The labeled-nfs project seeks to extend the NFSv4 protocol to provide a generic mechanism for conveying process and file MAC security attribute information for use by security mechanisms employed on the client and server. In this paper we explore the design and implementation for the labeled-nfs effort. We discuss why certain design decisions were made and what impact they have on the implementation of NFS in the Linux kernel and NFS userland infrastructure. Finally we discuss how parts of the labeled-nfs infrastructure can be used in other remote file systems. From dwalsh at redhat.com Mon Jan 28 21:31:06 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 28 Jan 2008 16:31:06 -0500 Subject: Rawhide kernel/etc. breaks sound, system_dbusd_t AVCs In-Reply-To: <4c4ba1530801261056s100e7e38j367abd84d4649f9f@mail.gmail.com> References: <4c4ba1530801261056s100e7e38j367abd84d4649f9f@mail.gmail.com> Message-ID: <479E499A.5090401@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom London wrote: > Running today's rawhide, targeted/enforcing. > > Booting up after applying today's updates, sound is disabled, and the > following AVCs: > > type=AVC msg=audit(1201370968.279:17): avc: denied { execute } for > pid=3936 comm="dbus-daemon-lau" name="console-kit-daemon" dev=dm-0 > ino=5490198 scontext=system_u:system_r:system_dbusd_t:s0 > tcontext=system_u:object_r:consolekit_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1201370968.279:17): arch=40000003 syscall=11 > success=no exit=-13 a0=9253c30 a1=9253bb0 a2=9253008 a3=de799c items=0 > ppid=3935 pid=3936 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 > egid=0 sgid=0 fsgid=0 tty=(none) comm="dbus-daemon-lau" > exe="/lib/dbus-1/dbus-daemon-launch-helper" > subj=system_u:system_r:system_dbusd_t:s0 key=(null) > type=AVC msg=audit(1201370973.064:18): avc: denied { execute } for > pid=4149 comm="dbus-daemon-lau" name="console-kit-daemon" dev=dm-0 > ino=5490198 scontext=system_u:system_r:system_dbusd_t:s0 > tcontext=system_u:object_r:consolekit_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1201370973.064:18): arch=40000003 syscall=11 > success=no exit=-13 a0=9113c30 a1=9113bb0 a2=9113008 a3=de799c items=0 > ppid=4148 pid=4149 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 > egid=0 sgid=0 fsgid=0 tty=(none) comm="dbus-daemon-lau" > exe="/lib/dbus-1/dbus-daemon-launch-helper" > subj=system_u:system_r:system_dbusd_t:s0 key=(null) > <<< REPEATS >>> > > > > #============= system_dbusd_t ============== > allow system_dbusd_t consolekit_exec_t:file execute; > > Rebooting in permissive mode enables sound, but produces a host of > AVCs (/var/log/audit/audit.log attached): > > > #============= system_dbusd_t ============== > allow system_dbusd_t NetworkManager_t:dir search; > allow system_dbusd_t NetworkManager_t:file { read getattr }; > allow system_dbusd_t NetworkManager_t:process ptrace; > allow system_dbusd_t consolekit_exec_t:file { read execute execute_no_trans }; > allow system_dbusd_t hald_t:dbus send_msg; > allow system_dbusd_t hald_t:dir search; > allow system_dbusd_t hald_t:file { read getattr }; > allow system_dbusd_t hald_t:process ptrace; > allow system_dbusd_t polkit_auth_t:dbus send_msg; > allow system_dbusd_t polkit_auth_t:dir search; > allow system_dbusd_t polkit_auth_t:file { read getattr }; > allow system_dbusd_t self:capability { sys_nice sys_ptrace }; > allow system_dbusd_t self:fifo_file getattr; > allow system_dbusd_t self:process getsched; > allow system_dbusd_t system_crond_var_lib_t:dir search; > allow system_dbusd_t system_crond_var_lib_t:file read; > allow system_dbusd_t tty_device_t:chr_file { read ioctl }; > allow system_dbusd_t unconfined_t:dbus send_msg; > allow system_dbusd_t unconfined_t:dir search; > allow system_dbusd_t unconfined_t:file { read getattr }; > allow system_dbusd_t unconfined_t:process ptrace; > allow system_dbusd_t var_log_t:dir search; > allow system_dbusd_t var_log_t:file { read getattr append setattr }; > allow system_dbusd_t xdm_t:dbus send_msg; > allow system_dbusd_t xdm_t:dir search; > allow system_dbusd_t xdm_t:file { read getattr }; > allow system_dbusd_t xdm_t:process ptrace; > > Nothing seems mislabeled in /etc, /*bin, /lib, /usr/*bin, .... > > tom > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list A new transition from dbus to consolekit is necessary. I guess as of this update dbus now starts consolekit and policykit. So I updated tonights policy to provide the transition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeeSZoACgkQrlYvE4MpobODZwCg0ytSONLlrai05v4FLUy/KwYu p50Ani3GMrRnDLZW/jC2l5jbgp/Lyae3 =KN1n -----END PGP SIGNATURE----- From jmorris at namei.org Tue Jan 29 11:44:15 2008 From: jmorris at namei.org (James Morris) Date: Tue, 29 Jan 2008 22:44:15 +1100 (EST) Subject: [RFC] security: add iptables "security" table for MAC rules Message-ID: The following patch implements a new "security" table for iptables, so that MAC (SELinux etc.) networking rules can be managed separately to standard DAC rules. This is to help with distro integration of the new secmark-based network controls, per various previous discussions. The need for a separate table arises from the fact that existing tools and usage of iptables will likely clash with centralized MAC policy management. The SECMARK and CONNSECMARK targets will still be valid in the mangle table, to prevent breakage of existing users, although I suspect that these targets are not in significant use and we could probably make them valid only in the security table without major issues. (Comments?) I've set the table priority to just after NF_IP_FILTER, to allow DAC rules to take effect before MAC rules. There is also not (yet) any LSM hooking for modifying the MAC rules, as it will be more invasive, and we have coarse coverage via CAP_NET_ADMIN. (Comments?) IPv6 is not done yet as this is just at RFC stage. Please review and let me know if this looks like a viable approach for distro integration. If it is, we will then need to run it past the Netfilter & netdev folk. --- Add a "security" table to iptables for managing Mandatory Access Control (MAC) rules. This is intended for use with the SECMARK and CONNSECMARK targets. Signed-off-by: James Morris --- include/linux/netfilter_ipv4.h | 1 + net/ipv4/netfilter/Kconfig | 10 ++ net/ipv4/netfilter/Makefile | 1 + net/ipv4/netfilter/iptable_security.c | 181 +++++++++++++++++++++++++++++++++ net/netfilter/xt_CONNSECMARK.c | 10 ++- net/netfilter/xt_SECMARK.c | 10 ++- 6 files changed, 207 insertions(+), 6 deletions(-) create mode 100644 net/ipv4/netfilter/iptable_security.c diff --git a/include/linux/netfilter_ipv4.h b/include/linux/netfilter_ipv4.h index 1a63adf..aec8961 100644 --- a/include/linux/netfilter_ipv4.h +++ b/include/linux/netfilter_ipv4.h @@ -60,6 +60,7 @@ enum nf_ip_hook_priorities { NF_IP_PRI_MANGLE = -150, NF_IP_PRI_NAT_DST = -100, NF_IP_PRI_FILTER = 0, + NF_IP_PRI_SECURITY = 50, NF_IP_PRI_NAT_SRC = 100, NF_IP_PRI_SELINUX_LAST = 225, NF_IP_PRI_CONNTRACK_HELPER = INT_MAX - 2, diff --git a/net/ipv4/netfilter/Kconfig b/net/ipv4/netfilter/Kconfig index 9aca9c5..84d0d31 100644 --- a/net/ipv4/netfilter/Kconfig +++ b/net/ipv4/netfilter/Kconfig @@ -373,6 +373,16 @@ config IP_NF_RAW If you want to compile it as a module, say M here and read . If unsure, say `N'. +# security table for MAC policy +config IP_NF_SECURITY + tristate "Security table" + depends on IP_NF_IPTABLES + help + This option adds a `security' table to iptables, for use + with Mandatory Access Control (MAC) policy. + + If unsure, say N. + # ARP tables config IP_NF_ARPTABLES tristate "ARP tables support" diff --git a/net/ipv4/netfilter/Makefile b/net/ipv4/netfilter/Makefile index 7456833..90fcdd6 100644 --- a/net/ipv4/netfilter/Makefile +++ b/net/ipv4/netfilter/Makefile @@ -39,6 +39,7 @@ obj-$(CONFIG_IP_NF_FILTER) += iptable_filter.o obj-$(CONFIG_IP_NF_MANGLE) += iptable_mangle.o obj-$(CONFIG_NF_NAT) += iptable_nat.o obj-$(CONFIG_IP_NF_RAW) += iptable_raw.o +obj-$(CONFIG_IP_NF_SECURITY) += iptable_security.o # matches obj-$(CONFIG_IP_NF_MATCH_ADDRTYPE) += ipt_addrtype.o diff --git a/net/ipv4/netfilter/iptable_security.c b/net/ipv4/netfilter/iptable_security.c new file mode 100644 index 0000000..640f200 --- /dev/null +++ b/net/ipv4/netfilter/iptable_security.c @@ -0,0 +1,181 @@ +/* + * "security" table + * + * This is for use by Mandatory Access Control (MAC) security models, + * which need to be able to manage security policy in separate context + * to DAC. + * + * Based on iptable_mangle.c + * + * Copyright (C) 1999 Paul `Rusty' Russell & Michael J. Neuling + * Copyright (C) 2000-2004 Netfilter Core Team + * Copyright (C) 2008 Red Hat, Inc., James Morris + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#include +#include +#include +#include +#include +#include +#include +#include + +MODULE_LICENSE("GPL"); +MODULE_AUTHOR("James Morris "); +MODULE_DESCRIPTION("iptables security table, for MAC rules"); + +#define SECURITY_VALID_HOOKS (1 << NF_IP_LOCAL_IN) | \ + (1 << NF_IP_FORWARD) | \ + (1 << NF_IP_LOCAL_OUT) + +static struct +{ + struct ipt_replace repl; + struct ipt_standard entries[3]; + struct ipt_error term; +} initial_table __initdata = { + .repl = { + .name = "security", + .valid_hooks = SECURITY_VALID_HOOKS, + .num_entries = 4, + .size = sizeof(struct ipt_standard) * 3 + sizeof(struct ipt_error), + .hook_entry = { + [NF_IP_LOCAL_IN] = 0, + [NF_IP_FORWARD] = sizeof(struct ipt_standard), + [NF_IP_LOCAL_OUT] = sizeof(struct ipt_standard) * 2, + }, + .underflow = { + [NF_IP_LOCAL_IN] = 0, + [NF_IP_FORWARD] = sizeof(struct ipt_standard), + [NF_IP_LOCAL_OUT] = sizeof(struct ipt_standard) * 2, + }, + }, + .entries = { + IPT_STANDARD_INIT(NF_ACCEPT), /* LOCAL_IN */ + IPT_STANDARD_INIT(NF_ACCEPT), /* FORWARD */ + IPT_STANDARD_INIT(NF_ACCEPT), /* LOCAL_OUT */ + }, + .term = IPT_ERROR_INIT, /* ERROR */ +}; + +static struct xt_table security_mangler = { + .name = "security", + .valid_hooks = SECURITY_VALID_HOOKS, + .lock = RW_LOCK_UNLOCKED, + .me = THIS_MODULE, + .af = AF_INET, +}; + +/* The work comes in here from netfilter.c. */ +static unsigned int +ipt_route_hook(unsigned int hook, + struct sk_buff *skb, + const struct net_device *in, + const struct net_device *out, + int (*okfn)(struct sk_buff *)) +{ + return ipt_do_table(skb, hook, in, out, &security_mangler); +} + +static unsigned int +ipt_local_hook(unsigned int hook, + struct sk_buff *skb, + const struct net_device *in, + const struct net_device *out, + int (*okfn)(struct sk_buff *)) +{ + unsigned int ret; + const struct iphdr *iph; + u_int8_t tos; + __be32 saddr, daddr; + u_int32_t mark; + + /* Somebody is playing with raw sockets. */ + if (skb->len < sizeof(struct iphdr) + || ip_hdrlen(skb) < sizeof(struct iphdr)) { + if (net_ratelimit()) + printk(KERN_INFO "iptable_mangle: ignoring short " + "SOCK_RAW packet.\n"); + return NF_ACCEPT; + } + + /* Save things which could affect route */ + mark = skb->mark; + iph = ip_hdr(skb); + saddr = iph->saddr; + daddr = iph->daddr; + tos = iph->tos; + + ret = ipt_do_table(skb, hook, in, out, &security_mangler); + /* Reroute for ANY change. */ + if (ret != NF_DROP && ret != NF_STOLEN && ret != NF_QUEUE) { + iph = ip_hdr(skb); + + if (iph->saddr != saddr || + iph->daddr != daddr || + skb->mark != mark || + iph->tos != tos) + if (ip_route_me_harder(skb, RTN_UNSPEC)) + ret = NF_DROP; + } + + return ret; +} + +static struct nf_hook_ops ipt_ops[] = { + { + .hook = ipt_route_hook, + .owner = THIS_MODULE, + .pf = PF_INET, + .hooknum = NF_IP_LOCAL_IN, + .priority = NF_IP_PRI_SECURITY, + }, + { + .hook = ipt_route_hook, + .owner = THIS_MODULE, + .pf = PF_INET, + .hooknum = NF_IP_FORWARD, + .priority = NF_IP_PRI_SECURITY, + }, + { + .hook = ipt_local_hook, + .owner = THIS_MODULE, + .pf = PF_INET, + .hooknum = NF_IP_LOCAL_OUT, + .priority = NF_IP_PRI_SECURITY, + }, +}; + +static int __init iptable_security_init(void) +{ + int ret; + + /* Register table */ + ret = ipt_register_table(&security_mangler, &initial_table.repl); + if (ret < 0) + return ret; + + /* Register hooks */ + ret = nf_register_hooks(ipt_ops, ARRAY_SIZE(ipt_ops)); + if (ret < 0) + goto cleanup_table; + + return ret; + +cleanup_table: + ipt_unregister_table(&security_mangler); + return ret; +} + +static void __exit iptable_security_fini(void) +{ + nf_unregister_hooks(ipt_ops, ARRAY_SIZE(ipt_ops)); + ipt_unregister_table(&security_mangler); +} + +module_init(iptable_security_init); +module_exit(iptable_security_fini); diff --git a/net/netfilter/xt_CONNSECMARK.c b/net/netfilter/xt_CONNSECMARK.c index d8feba9..5dd584b 100644 --- a/net/netfilter/xt_CONNSECMARK.c +++ b/net/netfilter/xt_CONNSECMARK.c @@ -8,7 +8,7 @@ * Copyright (C) 2002,2004 MARA Systems AB * by Henrik Nordstrom * - * (C) 2006 Red Hat, Inc., James Morris + * (C) 2006,2008 Red Hat, Inc., James Morris * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as @@ -90,6 +90,12 @@ static bool checkentry(const char *tablename, const void *entry, { const struct xt_connsecmark_target_info *info = targinfo; + if (strcmp(tablename, "mangle") && strcmp(tablename, "security")) { + printk(KERN_INFO PFX "target only valid in the \'mangle\' " + "or \'security\' tables, not \'%s\'.\n", tablename); + return false; + } + switch (info->mode) { case CONNSECMARK_SAVE: case CONNSECMARK_RESTORE: @@ -122,7 +128,6 @@ static struct xt_target xt_connsecmark_target[] __read_mostly = { .destroy = destroy, .target = target, .targetsize = sizeof(struct xt_connsecmark_target_info), - .table = "mangle", .me = THIS_MODULE, }, { @@ -132,7 +137,6 @@ static struct xt_target xt_connsecmark_target[] __read_mostly = { .destroy = destroy, .target = target, .targetsize = sizeof(struct xt_connsecmark_target_info), - .table = "mangle", .me = THIS_MODULE, }, }; diff --git a/net/netfilter/xt_SECMARK.c b/net/netfilter/xt_SECMARK.c index 235806e..7c92d87 100644 --- a/net/netfilter/xt_SECMARK.c +++ b/net/netfilter/xt_SECMARK.c @@ -5,7 +5,7 @@ * Based on the nfmark match by: * (C) 1999-2001 Marc Boucher * - * (C) 2006 Red Hat, Inc., James Morris + * (C) 2006,2008 Red Hat, Inc., James Morris * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as @@ -87,6 +87,12 @@ static bool checkentry(const char *tablename, const void *entry, { struct xt_secmark_target_info *info = targinfo; + if (strcmp(tablename, "mangle") && strcmp(tablename, "security")) { + printk(KERN_INFO PFX "target only valid in the \'mangle\' " + "or \'security\' tables, not \'%s\'.\n", tablename); + return false; + } + if (mode && mode != info->mode) { printk(KERN_INFO PFX "mode already set to %hu cannot mix with " "rules for mode %hu\n", mode, info->mode); @@ -116,7 +122,6 @@ static struct xt_target xt_secmark_target[] __read_mostly = { .checkentry = checkentry, .target = target, .targetsize = sizeof(struct xt_secmark_target_info), - .table = "mangle", .me = THIS_MODULE, }, { @@ -125,7 +130,6 @@ static struct xt_target xt_secmark_target[] __read_mostly = { .checkentry = checkentry, .target = target, .targetsize = sizeof(struct xt_secmark_target_info), - .table = "mangle", .me = THIS_MODULE, }, }; -- 1.5.3.8 -- James Morris From jmorris at namei.org Tue Jan 29 20:51:55 2008 From: jmorris at namei.org (James Morris) Date: Wed, 30 Jan 2008 07:51:55 +1100 (EST) Subject: [RFC] security: add iptables "security" table for MAC rules In-Reply-To: <200801291237.37349.paul.moore@hp.com> References: <200801291237.37349.paul.moore@hp.com> Message-ID: On Tue, 29 Jan 2008, Paul Moore wrote: > I'm not sure if returning false and failing here is the best thing to do in > terms of backwards compatibility. I think we need some grace period where we > print a warning message and still allow the operation; after some period of > time we can then remove the ability completely and force users to use the > new "security" table. Currently, the patch allows the use of the mangle table, so it is backwards compatible. -- James Morris From shintaro.fujiwara at gmail.com Tue Jan 29 22:50:41 2008 From: shintaro.fujiwara at gmail.com (Shintaro Fujiwara) Date: Wed, 30 Jan 2008 07:50:41 +0900 Subject: How to modify port by semanage Message-ID: Hi, please tell me modifying port by semanage. I could add and delete port ok, but don't know how to modify it. I read man but -m example was not there. Thanks in advance. -- http://intrajp.no-ip.com/ Home Page -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmorris at namei.org Wed Jan 30 00:43:11 2008 From: jmorris at namei.org (James Morris) Date: Wed, 30 Jan 2008 11:43:11 +1100 (EST) Subject: [RFC] security: add iptables "security" table for MAC rules In-Reply-To: <200801291237.37349.paul.moore@hp.com> References: <200801291237.37349.paul.moore@hp.com> Message-ID: On Tue, 29 Jan 2008, Paul Moore wrote: > That seems reasonable. By the way, this isn't really related, but is it > possible to change the NF_IP_PRI_SELINUX_* constants to NF_IP_PRI_SECURITY_* > for the sake of consistency or are those values already visible to userspace? They are visible to userspace, and included in glibc headers, but I don't see any userland use of them via google codesearch or know of a possible valid use. > I suppose we could always rename them anyway and just add a #define for > compatibility ... Yep, if you want to. - James -- James Morris From mike.clarkson at baesystems.com Wed Jan 30 01:26:25 2008 From: mike.clarkson at baesystems.com (Clarkson, Mike R (US SSA)) Date: Tue, 29 Jan 2008 17:26:25 -0800 Subject: module install during make not working correctly References: Message-ID: Nevermind. This turned out to be a copy and paste error. I had the wrong module name at the top of my helloworldfile.te file, causing the weird behavior listed below. Sorry for the spam. > -----Original Message----- > From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux-list- > bounces at redhat.com] On Behalf Of Clarkson, Mike R (US SSA) > Sent: Monday, January 28, 2008 9:18 AM > To: fedora-selinux-list at redhat.com > Subject: module install during make not working correctly > > > I have a simple helloworld example and policy module with the following > line in the helloworldfile.fc file: > > /usr/local/test/HelloWorldFile -- > gen_context(root:object_r:helloworld_exec_t,__SYSTEMLOW__) > > When I make the policy using "make load", it appears to install the > helloworldfile.pp in /usr/share/selinux/mls and then install it using > semodule. After doing this if I use restorecon to set the file context > of /usr/local/test/HelloWorldFile, the context is incorrect. It has the > type usr_t, which is the type for the /usr/local/test directory. If I > then manually install the module using "/usr/sbin/semodule -i > /usr/share/selinux/mls/helloworldfile.pp", and again use restorecon to > reset the file context, it has the correct context. I have no idea why > the module install during the "make" process is not working correctly. > I'd appreciate any help in figuring out what is going on. > > I'm using RHEL5.1 with the mls policy. Below I have captured the > sequence of commands described above, along with the output. > > Thanks > > > [clarkson at m2ut5 test]# make load > Compliling mls helloworldfile.mod module > echo "ifdef(\`""helloworldfile""_per_role_template',\`" > > tmp/helloworldfile.mod.role > m4 -D strict_policy -D enable_mls -D mls_num_sens=5 -D mls_num_cats=256 > -D mcs_num_cats=256 -D hide_broken_symptoms policy/rolemap | gawk > '/^[[:blank:]]*[A-Za-z]/{ print "gen_require(type " $3 "; role " $1 > ";)\nhelloworldfile_per_role_template(" $2 "," $3 "," $1 ")" }' >> > tmp/helloworldfile.mod.role > echo "')" >> tmp/helloworldfile.mod.role > echo "ifdef(\`""helloworldfile""_per_userdomain_template',\`" >> > tmp/helloworldfile.mod.role > echo "errprint(\`Warning: per_userdomain_templates have been renamed to > per_role_templates > (""helloworldfile""_per_userdomain_template)'__endline__)" >> > tmp/helloworldfile.mod.role > m4 -D strict_policy -D enable_mls -D mls_num_sens=5 -D mls_num_cats=256 > -D mcs_num_cats=256 -D hide_broken_symptoms policy/rolemap | gawk > '/^[[:blank:]]*[A-Za-z]/{ print "gen_require(type " $3 "; role " $1 > ";)\nhelloworldfile_per_userdomain_template(" $2 "," $3 "," $1 ")" }' >> > tmp/helloworldfile.mod.role > echo "')" >> tmp/helloworldfile.mod.role > m4 -D strict_policy -D enable_mls -D mls_num_sens=5 -D mls_num_cats=256 > -D mcs_num_cats=256 -D hide_broken_symptoms -s > policy/support/fc_dir_variables.spt policy/support/file_patterns.spt > policy/support/loadable_module.spt policy/support/misc_macros.spt > policy/support/mls_mcs_macros.spt policy/support/obj_perm_sets.spt > tmp/generated_definitions.conf tmp/all_interfaces.conf > policy/modules/apps/helloworldfile.te tmp/helloworldfile.mod.role > > tmp/helloworldfile.tmp > /usr/bin/checkmodule -M -m tmp/helloworldfile.tmp -o > tmp/helloworldfile.mod > /usr/bin/checkmodule: loading policy configuration from > tmp/helloworldfile.tmp > /usr/bin/checkmodule: policy configuration loaded > /usr/bin/checkmodule: writing binary representation (version 6) to > tmp/helloworldfile.mod > m4 -D strict_policy -D enable_mls -D mls_num_sens=5 -D mls_num_cats=256 > -D mcs_num_cats=256 -D hide_broken_symptoms > policy/support/fc_dir_variables.spt policy/support/file_patterns.spt > policy/support/loadable_module.spt policy/support/misc_macros.spt > policy/support/mls_mcs_macros.spt policy/support/obj_perm_sets.spt > policy/support/fc_dir_variables.spt policy/support/file_patterns.spt > policy/support/loadable_module.spt policy/support/misc_macros.spt > policy/support/mls_mcs_macros.spt policy/support/obj_perm_sets.spt > policy/modules/apps/helloworldfile.fc > tmp/helloworldfile.mod.fc > Creating mls helloworldfile.pp policy package > /usr/bin/semodule_package -o helloworldfile.pp -m tmp/helloworldfile.mod > -f tmp/helloworldfile.mod.fc > Installing mls helloworldfile.pp policy package. > install -m 0644 helloworldfile.pp /usr/share/selinux/mls > Loading configured modules. > /usr/sbin/semodule -s mls -b /usr/share/selinux/mls/base.pp -i > /usr/share/selinux/mls/acct.pp -i /usr/share/selinux/mls/ada.pp -i > /usr/share/selinux/mls/afs.pp -i /usr/share/selinux/mls/aide.pp -i > /usr/share/selinux/mls/alsa.pp -i /usr/share/selinux/mls/amanda.pp -i > /usr/share/selinux/mls/amavis.pp -i /usr/share/selinux/mls/amtu.pp -i > /usr/share/selinux/mls/anaconda.pp -i /usr/share/selinux/mls/apache.pp > -i /usr/share/selinux/mls/apm.pp -i /usr/share/selinux/mls/apt.pp -i > /usr/share/selinux/mls/arpwatch.pp -i /usr/share/selinux/mls/asterisk.pp > -i /usr/share/selinux/mls/audioentropy.pp -i > /usr/share/selinux/mls/audit.pp -i /usr/share/selinux/mls/authbind.pp -i > /usr/share/selinux/mls/authlogin.pp -i > /usr/share/selinux/mls/automount.pp -i /usr/share/selinux/mls/avahi.pp > -i /usr/share/selinux/mls/backup.pp -i /usr/share/selinux/mls/bind.pp -i > /usr/share/selinux/mls/bluetooth.pp -i > /usr/share/selinux/mls/bootloader.pp -i > /usr/share/selinux/mls/calamaris.pp -i /usr/share/selinux/mls/canna.pp > -i /usr/share/selinux/mls/ccs.pp -i /usr/share/selinux/mls/cdrecord.pp > -i /usr/share/selinux/mls/certwatch.pp -i /usr/share/selinux/mls/cipe.pp > -i /usr/share/selinux/mls/clamav.pp -i /usr/share/selinux/mls/clock.pp > -i /usr/share/selinux/mls/clockspeed.pp -i > /usr/share/selinux/mls/comsat.pp -i > /usr/share/selinux/mls/consoletype.pp -i > /usr/share/selinux/mls/courier.pp -i > /usr/share/selinux/mls/cpucontrol.pp -i /usr/share/selinux/mls/cron.pp > -i /usr/share/selinux/mls/cups.pp -i /usr/share/selinux/mls/cvs.pp -i > /usr/share/selinux/mls/cyrus.pp -i /usr/share/selinux/mls/daemontools.pp > -i /usr/share/selinux/mls/dante.pp -i /usr/share/selinux/mls/dbskk.pp -i > /usr/share/selinux/mls/dbus.pp -i /usr/share/selinux/mls/dcc.pp -i > /usr/share/selinux/mls/ddclient.pp -i /usr/share/selinux/mls/ddcprobe.pp > -i /usr/share/selinux/mls/dhcp.pp -i /usr/share/selinux/mls/dictd.pp -i > /usr/share/selinux/mls/distcc.pp -i /usr/share/selinux/mls/djbdns.pp -i > /usr/share/selinux/mls/dmesg.pp -i /usr/share/selinux/mls/dmidecode.pp > -i /usr/share/selinux/mls/dnsmasq.pp -i > /usr/share/selinux/mls/dovecot.pp -i /usr/share/selinux/mls/dpkg.pp -i > /usr/share/selinux/mls/ethereal.pp -i > /usr/share/selinux/mls/evolution.pp -i /usr/share/selinux/mls/export.pp > -i /usr/share/selinux/mls/fail2ban.pp -i > /usr/share/selinux/mls/fetchmail.pp -i /usr/share/selinux/mls/finger.pp > -i /usr/share/selinux/mls/firstboot.pp -i > /usr/share/selinux/mls/frontgate.pp -i /usr/share/selinux/mls/fstools.pp > -i /usr/share/selinux/mls/ftp.pp -i /usr/share/selinux/mls/ftp_trans.pp > -i /usr/share/selinux/mls/games.pp -i > /usr/share/selinux/mls/gatekeeper.pp -i /usr/share/selinux/mls/getty.pp > -i /usr/share/selinux/mls/gift.pp -i /usr/share/selinux/mls/gnome.pp -i > /usr/share/selinux/mls/gpg.pp -i /usr/share/selinux/mls/gpm.pp -i > /usr/share/selinux/mls/hal.pp -i > /usr/share/selinux/mls/helloworldfile.pp -i > /usr/share/selinux/mls/hostname.pp -i /usr/share/selinux/mls/hotplug.pp > -i /usr/share/selinux/mls/howl.pp -i > /usr/share/selinux/mls/i18n_input.pp -i /usr/share/selinux/mls/imaze.pp > -i /usr/share/selinux/mls/import.pp -i /usr/share/selinux/mls/inetd.pp > -i /usr/share/selinux/mls/init.pp -i /usr/share/selinux/mls/inn.pp -i > /usr/share/selinux/mls/ipsec.pp -i /usr/share/selinux/mls/iptables.pp -i > /usr/share/selinux/mls/irc.pp -i /usr/share/selinux/mls/ircd.pp -i > /usr/share/selinux/mls/irqbalance.pp -i /usr/share/selinux/mls/iscsi.pp > -i /usr/share/selinux/mls/jabber.pp -i /usr/share/selinux/mls/java.pp -i > /usr/share/selinux/mls/kerberos.pp -i /usr/share/selinux/mls/ktalk.pp -i > /usr/share/selinux/mls/kudzu.pp -i /usr/share/selinux/mls/ldap.pp -i > /usr/share/selinux/mls/libraries.pp -i > /usr/share/selinux/mls/loadkeys.pp -i > /usr/share/selinux/mls/locallogin.pp -i > /usr/share/selinux/mls/lockdev.pp -i /usr/share/selinux/mls/logging.pp > -i /usr/share/selinux/mls/logrotate.pp -i > /usr/share/selinux/mls/logwatch.pp -i /usr/share/selinux/mls/lpd.pp -i > /usr/share/selinux/mls/lvm.pp -i /usr/share/selinux/mls/mailman.pp -i > /usr/share/selinux/mls/miscfiles.pp -i > /usr/share/selinux/mls/modutils.pp -i /usr/share/selinux/mls/mono.pp -i > /usr/share/selinux/mls/monop.pp -i /usr/share/selinux/mls/mount.pp -i > /usr/share/selinux/mls/mozilla.pp -i /usr/share/selinux/mls/mplayer.pp > -i /usr/share/selinux/mls/mrtg.pp -i /usr/share/selinux/mls/mta.pp -i > /usr/share/selinux/mls/munin.pp -i /usr/share/selinux/mls/mysql.pp -i > /usr/share/selinux/mls/nagios.pp -i /usr/share/selinux/mls/nessus.pp -i > /usr/share/selinux/mls/netlabel.pp -i /usr/share/selinux/mls/netutils.pp > -i /usr/share/selinux/mls/networkmanager.pp -i > /usr/share/selinux/mls/nis.pp -i /usr/share/selinux/mls/nscd.pp -i > /usr/share/selinux/mls/nsd.pp -i /usr/share/selinux/mls/ntop.pp -i > /usr/share/selinux/mls/ntp.pp -i /usr/share/selinux/mls/nx.pp -i > /usr/share/selinux/mls/oav.pp -i /usr/share/selinux/mls/oddjob.pp -i > /usr/share/selinux/mls/openca.pp -i /usr/share/selinux/mls/openct.pp -i > /usr/share/selinux/mls/openvpn.pp -i /usr/share/selinux/mls/oracle_db.pp > -i /usr/share/selinux/mls/oracle_sp.pp -i > /usr/share/selinux/mls/pcmcia.pp -i /usr/share/selinux/mls/pcs.pp -i > /usr/share/selinux/mls/pcscd.pp -i /usr/share/selinux/mls/pegasus.pp -i > /usr/share/selinux/mls/perdition.pp -i /usr/share/selinux/mls/portage.pp > -i /usr/share/selinux/mls/portmap.pp -i > /usr/share/selinux/mls/portslave.pp -i /usr/share/selinux/mls/postfix.pp > -i /usr/share/selinux/mls/postgresql.pp -i > /usr/share/selinux/mls/postgrey.pp -i /usr/share/selinux/mls/ppp.pp -i > /usr/share/selinux/mls/prelink.pp -i /usr/share/selinux/mls/privoxy.pp > -i /usr/share/selinux/mls/procmail.pp -i > /usr/share/selinux/mls/publicfile.pp -i /usr/share/selinux/mls/pxe.pp -i > /usr/share/selinux/mls/pyzor.pp -i /usr/share/selinux/mls/qmail.pp -i > /usr/share/selinux/mls/query.pp -i /usr/share/selinux/mls/quota.pp -i > /usr/share/selinux/mls/radius.pp -i /usr/share/selinux/mls/radvd.pp -i > /usr/share/selinux/mls/raid.pp -i /usr/share/selinux/mls/razor.pp -i > /usr/share/selinux/mls/rdisc.pp -i /usr/share/selinux/mls/readahead.pp > -i /usr/share/selinux/mls/remotelogin.pp -i > /usr/share/selinux/mls/resmgr.pp -i /usr/share/selinux/mls/rhgb.pp -i > /usr/share/selinux/mls/ricci.pp -i /usr/share/selinux/mls/rlogin.pp -i > /usr/share/selinux/mls/roundup.pp -i /usr/share/selinux/mls/rpc.pp -i > /usr/share/selinux/mls/rpm.pp -i /usr/share/selinux/mls/rshd.pp -i > /usr/share/selinux/mls/rssh.pp -i /usr/share/selinux/mls/rsync.pp -i > /usr/share/selinux/mls/samba.pp -i /usr/share/selinux/mls/sasl.pp -i > /usr/share/selinux/mls/screen.pp -i > /usr/share/selinux/mls/selinuxutil.pp -i > /usr/share/selinux/mls/sendmail.pp -i > /usr/share/selinux/mls/setcontest.pp -i > /usr/share/selinux/mls/setrans.pp -i > /usr/share/selinux/mls/setroubleshoot.pp -i > /usr/share/selinux/mls/slocate.pp -i /usr/share/selinux/mls/slrnpull.pp > -i /usr/share/selinux/mls/smartmon.pp -i /usr/share/selinux/mls/snmp.pp > -i /usr/share/selinux/mls/snort.pp -i > /usr/share/selinux/mls/soundserver.pp -i > /usr/share/selinux/mls/spamassassin.pp -i > /usr/share/selinux/mls/speedtouch.pp -i /usr/share/selinux/mls/squid.pp > -i /usr/share/selinux/mls/ssh.pp -i /usr/share/selinux/mls/storage.pp -i > /usr/share/selinux/mls/stunnel.pp -i /usr/share/selinux/mls/su.pp -i > /usr/share/selinux/mls/sudo.pp -i /usr/share/selinux/mls/sxid.pp -i > /usr/share/selinux/mls/sysnetwork.pp -i > /usr/share/selinux/mls/sysstat.pp -i /usr/share/selinux/mls/tcpd.pp -i > /usr/share/selinux/mls/telnet.pp -i /usr/share/selinux/mls/tftp.pp -i > /usr/share/selinux/mls/thunderbird.pp -i > /usr/share/selinux/mls/timidity.pp -i > /usr/share/selinux/mls/tmpreaper.pp -i /usr/share/selinux/mls/tor.pp -i > /usr/share/selinux/mls/transproxy.pp -i > /usr/share/selinux/mls/tripwire.pp -i /usr/share/selinux/mls/tvtime.pp > -i /usr/share/selinux/mls/tzdata.pp -i > /usr/share/selinux/mls/ucspitcp.pp -i /usr/share/selinux/mls/udev.pp -i > /usr/share/selinux/mls/uml.pp -i /usr/share/selinux/mls/unconfined.pp -i > /usr/share/selinux/mls/updfstab.pp -i /usr/share/selinux/mls/uptime.pp > -i /usr/share/selinux/mls/usbmodules.pp -i > /usr/share/selinux/mls/userdomain.pp -i > /usr/share/selinux/mls/userhelper.pp -i > /usr/share/selinux/mls/usermanage.pp -i > /usr/share/selinux/mls/usernetctl.pp -i /usr/share/selinux/mls/uucp.pp > -i /usr/share/selinux/mls/uwimap.pp -i /usr/share/selinux/mls/vbetool.pp > -i /usr/share/selinux/mls/vmware.pp -i /usr/share/selinux/mls/vpn.pp -i > /usr/share/selinux/mls/watchdog.pp -i > /usr/share/selinux/mls/webalizer.pp -i > /usr/share/selinux/mls/weblogic.pp -i /usr/share/selinux/mls/wine.pp -i > /usr/share/selinux/mls/xen.pp -i /usr/share/selinux/mls/xfs.pp -i > /usr/share/selinux/mls/xprint.pp -i /usr/share/selinux/mls/xserver.pp -i > /usr/share/selinux/mls/yam.pp -i /usr/share/selinux/mls/zebra.pp > rm tmp/helloworldfile.mod.fc tmp/helloworldfile.mod > [clarkson at m2ut5 policy]# cd /usr/local/test > [clarkson at m2ut5 test]# /sbin/restorecon HelloWorldFile > [clarkson at m2ut5 test]# ls -Z HelloWorldFile > -rwxr-xr-x clarkson m2 system_u:object_r:usr_t:SystemLow HelloWorldFile > [clarkson at m2ut5 test]# /usr/sbin/semodule -i > /usr/share/selinux/mls/helloworldfile.pp > [clarkson at m2ut5 test]# /sbin/restorecon HelloWorldFile > [clarkson at m2ut5 test]# ls -Z HelloWorldFile > -rwxr-xr-x clarkson m2 root:object_r:helloworld_exec_t:SystemLow > HelloWorldFile > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From dwalsh at redhat.com Wed Jan 30 14:48:18 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 30 Jan 2008 09:48:18 -0500 Subject: How to modify port by semanage In-Reply-To: References: Message-ID: <47A08E32.6030206@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Shintaro Fujiwara wrote: > Hi, please tell me modifying port by semanage. > > I could add and delete port ok, but don't know how to modify it. > > I read man but -m example was not there. > > Thanks in advance. > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Ports are defined by the number and the type (udp/tcp) So # /usr/sbin/semanage port -a -t http_port_t -p udp 9999 # /usr/sbin/semanage port -m -t ntp_port_t -p udp 9999 # /usr/sbin/semanage port -m -t ntp_port_t -p tcp 9999 /usr/sbin/semanage: Port tcp/9999 is not defined You can change the type of a port but not the protocol. You would have to delete and add. You can also NOT change the default ports that come with policy, only ones that you add. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkegjjIACgkQrlYvE4MpobMCogCffC9/7z4P+ra7D0ePWWM5j7hX gIgAn15FEVz94RMaTEjWy9+stdhkMwEs =XwtQ -----END PGP SIGNATURE----- From eric.anderson at plexsysipi.com Wed Jan 30 17:25:10 2008 From: eric.anderson at plexsysipi.com (Eric Anderson) Date: Wed, 30 Jan 2008 11:25:10 -0600 Subject: mounting of samba shares via fstab in F8 (and recently updated F7) Message-ID: <47A0B2F6.2000609@plexsysipi.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, ~ I have run into a problem with reading a credentials file from fstab at startup. I have been working with Dan Walsh and have at least a temporary resolution. Details of our e-mail conversation are below: The problem: I get Error 13 talking about access denied to the credentials file. If SELinux is sent to permissive, this is not an issue. I have tried 20 different searches on google, samba.org and several fedora sites to try to get the context required for the credentials file to be accessible to the startup scripts that process fstab. current SELinux context of credentials file: # ls -lZ /root/.smb/yyy - -rw-r----- root root system_u:object_r:user_home_t:s0 /root/.smb/yyy fstab entry: //mtc1-server/progs /media/mtc1-server/progs cifs ip=xxx.xxx.xxx.xxx,credentials=/root/.smb/yyy,uid=aaaa,gid=aaaa,file_mode=0664,dir_mode=0775 0 0 ~ If I use "su -" and manually mount the share, passing only the directory to the mount command, it completes with no errors. This is only an issue at startup. The Resolution: You should execute # grep mount_t /var/log/audit/audit.log | audit2allow -M mysamba # semodule -i mysamba.pp This will add the new rule. If anybody wants/needs more details, feel free to contact me. - -- Eric Anderson Communication Systems Engineer PLEXSYS Interface Products, Inc. E-mail: eric.anderson at plexsysipi.com Phone: (405) 734-6090 Fax: (405) 734-6153 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHoLLuZqXKXmrU3HIRAid1AJ0ZDQN3RnJSFQrEDlvhRsv89ZGfkQCeIiLa 4oJhf2TRRfM3T2xAToc+H0k= =0gZ4 -----END PGP SIGNATURE----- From paul at city-fan.org Wed Jan 30 17:33:56 2008 From: paul at city-fan.org (Paul Howarth) Date: Wed, 30 Jan 2008 17:33:56 +0000 Subject: mounting of samba shares via fstab in F8 (and recently updated F7) In-Reply-To: <47A0B2F6.2000609@plexsysipi.com> References: <47A0B2F6.2000609@plexsysipi.com> Message-ID: <47A0B504.5070305@city-fan.org> Eric Anderson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > All, > > ~ I have run into a problem with reading a credentials file from fstab > at startup. I have been working with Dan Walsh and have at least a > temporary resolution. Details of our e-mail conversation are below: > > The problem: > > I get Error 13 talking about access denied > to the credentials file. If SELinux is sent to permissive, this is not > an issue. I have tried 20 different searches on google, samba.org and > several fedora sites to try to get the context required for the > credentials file to be accessible to the startup scripts that process > fstab. > > current SELinux context of credentials file: > # ls -lZ /root/.smb/yyy > - -rw-r----- root root system_u:object_r:user_home_t:s0 /root/.smb/yyy > > fstab entry: > //mtc1-server/progs /media/mtc1-server/progs cifs > ip=xxx.xxx.xxx.xxx,credentials=/root/.smb/yyy,uid=aaaa,gid=aaaa,file_mode=0664,dir_mode=0775 > > 0 0 > > ~ If I use "su -" and manually mount the share, passing only the > directory to the mount command, it completes with no errors. This is > only an issue at startup. > > > The Resolution: > > > You should execute > # grep mount_t /var/log/audit/audit.log | audit2allow -M mysamba > # semodule -i mysamba.pp > > This will add the new rule. > > If anybody wants/needs more details, feel free to contact me. The solution I use, which I think is cleaner, is to put the credentials file in /etc/samba (where it should be labelled samba_etc_t) and to set the allow_mount_anyfile boolean: # setsebool -P allow_mount_anyfile 1 No local policy module needed. Paul. From eric.anderson at plexsysipi.com Wed Jan 30 17:43:59 2008 From: eric.anderson at plexsysipi.com (Eric Anderson) Date: Wed, 30 Jan 2008 11:43:59 -0600 Subject: mounting of samba shares via fstab in F8 (and recently updated F7) In-Reply-To: <47A0B504.5070305@city-fan.org> References: <47A0B2F6.2000609@plexsysipi.com> <47A0B504.5070305@city-fan.org> Message-ID: <47A0B75F.7060104@plexsysipi.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul, ~ I hadn't thought to try that, but I am very interested in keeping plaintext passwords out of /etc if at all possible. I would ideally like to also have a couple of shares mounted this way that relate to my "domain" user at login. Right now I leave the password out and have to type the cifs password for each share at startup. For example: mount via fstab the following share: //server/ ("Home Share") with the following credentials file: /home//.smb/server Eric Anderson Communication Systems Engineer PLEXSYS Interface Products, Inc. E-mail: eric.anderson at plexsysipi.com Phone: (405) 734-6090 Fax: (405) 734-6153 Paul Howarth wrote: | Eric Anderson wrote: |> -----BEGIN PGP SIGNED MESSAGE----- |> Hash: SHA1 |> |> All, |> |> ~ I have run into a problem with reading a credentials file from fstab |> at startup. I have been working with Dan Walsh and have at least a |> temporary resolution. Details of our e-mail conversation are below: |> |> The problem: |> |> I get Error 13 talking about access denied |> to the credentials file. If SELinux is sent to permissive, this is not |> an issue. I have tried 20 different searches on google, samba.org and |> several fedora sites to try to get the context required for the |> credentials file to be accessible to the startup scripts that process |> fstab. |> |> current SELinux context of credentials file: |> # ls -lZ /root/.smb/yyy |> - -rw-r----- root root system_u:object_r:user_home_t:s0 /root/.smb/yyy |> |> fstab entry: |> //mtc1-server/progs /media/mtc1-server/progs cifs |> ip=xxx.xxx.xxx.xxx,credentials=/root/.smb/yyy,uid=aaaa,gid=aaaa,file_mode=0664,dir_mode=0775 |> |> 0 0 |> |> ~ If I use "su -" and manually mount the share, passing only the |> directory to the mount command, it completes with no errors. This is |> only an issue at startup. |> |> |> The Resolution: |> |> |> You should execute |> # grep mount_t /var/log/audit/audit.log | audit2allow -M mysamba |> # semodule -i mysamba.pp |> |> This will add the new rule. |> |> If anybody wants/needs more details, feel free to contact me. | | The solution I use, which I think is cleaner, is to put the credentials | file in /etc/samba (where it should be labelled samba_etc_t) and to set | the allow_mount_anyfile boolean: | | # setsebool -P allow_mount_anyfile 1 | | No local policy module needed. | | Paul. | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHoLdXZqXKXmrU3HIRAntBAKCSOVLBR32pBT5Au+SQ7i6h6He4NACgo1q1 6Fqkw44fwsoIUDQCUE2aI2o= =hawW -----END PGP SIGNATURE----- From shintaro.fujiwara at gmail.com Wed Jan 30 21:04:34 2008 From: shintaro.fujiwara at gmail.com (Shintaro Fujiwara) Date: Thu, 31 Jan 2008 06:04:34 +0900 Subject: How to modify port by semanage In-Reply-To: <47A08E32.6030206@redhat.com> References: <47A08E32.6030206@redhat.com> Message-ID: 2008/1/30, Daniel J Walsh : > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Shintaro Fujiwara wrote: > > Hi, please tell me modifying port by semanage. > > > > I could add and delete port ok, but don't know how to modify it. > > > > I read man but -m example was not there. > > > > Thanks in advance. > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Ports are defined by the number and the type (udp/tcp) > > So > > > # /usr/sbin/semanage port -a -t http_port_t -p udp 9999 > # /usr/sbin/semanage port -m -t ntp_port_t -p udp 9999 > # /usr/sbin/semanage port -m -t ntp_port_t -p tcp 9999 > /usr/sbin/semanage: Port tcp/9999 is not defined > > You can change the type of a port but not the protocol. You would have > to delete and add. You can also NOT change the default ports that come > with policy, only ones that you add. I didn't know that much. Thank you very much. -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkegjjIACgkQrlYvE4MpobMCogCffC9/7z4P+ra7D0ePWWM5j7hX > gIgAn15FEVz94RMaTEjWy9+stdhkMwEs > =XwtQ > -----END PGP SIGNATURE----- > -- http://intrajp.no-ip.com/ Home Page -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivares14031 at yahoo.com Thu Jan 31 01:04:02 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Wed, 30 Jan 2008 17:04:02 -0800 (PST) Subject: SELinux is preventing console-kit-dae(/usr/sbin/console-kit-daemon) (consolekit_t) "execute" to (polkit_auth_exec_t). Message-ID: <577808.14961.qm@web52604.mail.re2.yahoo.com> Unknown, what is happening with console-kit-daemon? Summary: SELinux is preventing console-kit-dae(/usr/sbin/console-kit-daemon) (consolekit_t) "execute" to (polkit_auth_exec_t). Detailed Description: SELinux denied access requested by console-kit-dae(/usr/sbin/console-kit-daemon). It is not expected that this access is required by console-kit-dae(/usr/sbin/console-kit-daemon) 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 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:consolekit_t Target Context system_u:object_r:polkit_auth_exec_t Target Objects None [ file ] Source console-kit-dae(/usr/sbin/console-kit-daemon) Port Host localhost.localdomain Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.2.5-20.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.24-9.fc9 #1 SMP Tue Jan 29 18:08:15 EST 2008 i686 i686 Alert Count 1 First Seen Wed 30 Jan 2008 06:58:11 PM CST Last Seen Wed 30 Jan 2008 06:58:11 PM CST Local ID f1411c87-1b39-4d5a-bec3-67e1feb8ec07 Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1201741091.457:30): avc: denied { execute } for pid=2897 comm="console-kit-dae" name="polkit-read-auth-helper" dev=dm-0 ino=116712 scontext=system_u:system_r:consolekit_t:s0 tcontext=system_u:object_r:polkit_auth_exec_t:s0 tclass=file host=localhost.localdomain type=SYSCALL msg=audit(1201741091.457:30): arch=40000003 syscall=11 success=no exit=-13 a0=77097c a1=bff98da0 a2=bff9962c a3=0 items=0 ppid=2264 pid=2897 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="console-kit-dae" exe="/usr/sbin/console-kit-daemon" subj=system_u:system_r:consolekit_t:s0 key=(null) ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From dwalsh at redhat.com Thu Jan 31 19:25:08 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 31 Jan 2008 14:25:08 -0500 Subject: SELinux is preventing console-kit-dae(/usr/sbin/console-kit-daemon) (consolekit_t) "execute" to (polkit_auth_exec_t). In-Reply-To: <577808.14961.qm@web52604.mail.re2.yahoo.com> References: <577808.14961.qm@web52604.mail.re2.yahoo.com> Message-ID: <47A22094.30002@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Antonio Olivares wrote: > Unknown, > > what is happening with console-kit-daemon? > > Summary: > > SELinux is preventing > console-kit-dae(/usr/sbin/console-kit-daemon) > (consolekit_t) "execute" to > (polkit_auth_exec_t). > > Detailed Description: > > SELinux denied access requested by > console-kit-dae(/usr/sbin/console-kit-daemon). It is > not expected that this > access is required by > console-kit-dae(/usr/sbin/console-kit-daemon) 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 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:consolekit_t > Target Context > system_u:object_r:polkit_auth_exec_t > Target Objects None [ file ] > Source > console-kit-dae(/usr/sbin/console-kit-daemon) > Port > Host localhost.localdomain > Source RPM Packages > Target RPM Packages > Policy RPM > selinux-policy-3.2.5-20.fc9 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name catchall_file > Host Name localhost.localdomain > Platform Linux > localhost.localdomain 2.6.24-9.fc9 #1 SMP > Tue Jan 29 18:08:15 EST > 2008 i686 i686 > Alert Count 1 > First Seen Wed 30 Jan 2008 06:58:11 > PM CST > Last Seen Wed 30 Jan 2008 06:58:11 > PM CST > Local ID > f1411c87-1b39-4d5a-bec3-67e1feb8ec07 > Line Numbers > > Raw Audit Messages > > host=localhost.localdomain type=AVC > msg=audit(1201741091.457:30): avc: denied { execute > } for pid=2897 comm="console-kit-dae" > name="polkit-read-auth-helper" dev=dm-0 ino=116712 > scontext=system_u:system_r:consolekit_t:s0 > tcontext=system_u:object_r:polkit_auth_exec_t:s0 > tclass=file > > host=localhost.localdomain type=SYSCALL > msg=audit(1201741091.457:30): arch=40000003 syscall=11 > success=no exit=-13 a0=77097c a1=bff98da0 a2=bff9962c > a3=0 items=0 ppid=2264 pid=2897 auid=4294967295 uid=0 > gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 > tty=(none) comm="console-kit-dae" > exe="/usr/sbin/console-kit-daemon" > subj=system_u:system_r:consolekit_t:s0 key=(null) > > > > > > ____________________________________________________________________________________ > Be a better friend, newshound, and > know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Should be fixed by todays policy. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeiIJMACgkQrlYvE4MpobOJvQCfS0EE1PcEH7ccU4kAyOLk3/uS YK4An3GtK1EqLDXZOtrIOncYoY0xEeW7 =ZWl6 -----END PGP SIGNATURE----- From paul at city-fan.org Thu Jan 31 22:08:03 2008 From: paul at city-fan.org (Paul Howarth) Date: Thu, 31 Jan 2008 22:08:03 +0000 Subject: AVC from smartd Message-ID: <20080131220803.0612fddb@metropolis.intra.city-fan.org> One of the drives in my RAID1 array failed this evening, so smartd let me know about it by email. Along the way, it generated an AVC (F8): type=AVC msg=audit(1201808872.737:2426): avc: denied { read } for pid=27830 comm="sh" name="urandom" dev=tmpfs ino=2374 scontext=system_u:system_r:fsdaemon_t:s0 tcontext=system_u:object_r:urandom_device_t:s0 tclass=chr_file type=SYSCALL msg=audit(1201808872.737:2426): arch=c000003e syscall=2 success=no exit=-13 a0=48cb94 a1=0 a2=6cb6 a3=3324f529f0 items=0 ppid=27829 pid=27830 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="sh" exe="/bin/bash" subj=system_u:system_r:fsdaemon_t:s0 key=(null) Not quite sure why it needed to access /dev/urandom, and it doesn't appear to have stopped the mail being sent, so maybe this is one to be dontaudit-ed? Paul.