From lamont at lamontpeterson.org Fri Feb 1 18:31:07 2008 From: lamont at lamontpeterson.org (Lamont Peterson) Date: Fri, 1 Feb 2008 11:31:07 -0700 Subject: F8 avc: denied during NFS mount Message-ID: <200802011131.07727.lamont@lamontpeterson.org> All, I got this while mounting via "ls /net/server/": Summary SELinux is preventing rpc.statd (rpcd_t) "write" to pipe (automount_t). Detailed Description SELinux denied access requested by rpc.statd. It is not expected that this access is required by rpc.statd 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:rpcd_t:s0 Target Context system_u:system_r:automount_t:s0 Target Objects pipe [ fifo_file ] Affected RPM Packages Policy RPM selinux-policy-3.0.8-74.fc8 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.catchall Host Name reaver.lamontpeterson.net Platform Linux reaver.lamontpeterson.net 2.6.23.9-85.fc8 #1 SMP Fri Dec 7 15:49:36 EST 2007 x86_64 x86_64 Alert Count 1 First Seen Fri 18 Jan 2008 05:35:16 PM MST Last Seen Fri 18 Jan 2008 05:35:16 PM MST Local ID 1b3c736c-2edb-4c23-8440-c423dca231f0 Line Numbers Raw Audit Messages avc: denied { write } for comm=rpc.statd dev=pipefs path=pipe:[605687] pid=8732 scontext=system_u:system_r:rpcd_t:s0 tclass=fifo_file tcontext=system_u:system_r:automount_t:s0 -- Lamont Peterson From olivares14031 at yahoo.com Fri Feb 1 22:52:31 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Fri, 1 Feb 2008 14:52:31 -0800 (PST) Subject: flood of selinux alerts, SELinux is preventing console-kit-dae (consolekit_t) "read" to ? Message-ID: <956195.91237.qm@web52611.mail.re2.yahoo.com> There are too many to paste here :( http://www.geocities.com/olivares14031/selinux-alerts-20080201.html Thanks, Antonio ____________________________________________________________________________________ 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 Fri Feb 1 23:18:48 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Fri, 1 Feb 2008 15:18:48 -0800 (PST) Subject: firefox3beta and selinux Message-ID: <767182.6461.qm@web52607.mail.re2.yahoo.com> Dear all, When I try out the new firefox, setroubleshoot browser tells me \begin{QUOTE} Summary: SELinux is preventing firefox from making the program stack executable. Detailed Description: The 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 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 to run correctly, you can change the context of the executable to unconfined_execmem_exec_t. "chcon -t unconfined_execmem_exec_t '/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 '/usr/lib/firefox-3.0b3pre/firefox'" The following command will allow this access: chcon -t unconfined_execmem_exec_t '/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 Source Path /usr/lib/firefox-3.0b3pre/firefox Port Host localhost Source RPM Packages firefox-3.0-0.beta2.15.nightly20080130.fc9 Target RPM Packages Policy RPM selinux-policy-3.2.5-24.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-9.fc9 #1 SMP Tue Jan 29 18:08:15 EST 2008 i686 athlon Alert Count 2 First Seen Fri 01 Feb 2008 05:08:54 PM CST Last Seen Fri 01 Feb 2008 05:08:54 PM CST Local ID c4806f30-a6dc-43b0-8901-5531075795f7 Line Numbers Raw Audit Messages host=localhost type=AVC msg=audit(1201907334.440:23): avc: denied { execstack } for pid=2743 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(1201907334.440:23): arch=40000003 syscall=125 success=no exit=-13 a0=bfd47000 a1=1000 a2=1000007 a3=fffff000 items=0 ppid=2729 pid=2743 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) \end{QUOTE} I have done this two or three time so that I can use firefox-beta 3, is this by design or will it eventually be incorporated. If I decide to file a bug report, should it be against firefox, selinux-policy? see here ---------- The 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 web page explains how to remove this requirement. If 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 against this package. Thanks, Antonio ____________________________________________________________________________________ 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 Sat Feb 2 03:30:00 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 01 Feb 2008 22:30:00 -0500 Subject: F8 avc: denied during NFS mount In-Reply-To: <200802011131.07727.lamont@lamontpeterson.org> References: <200802011131.07727.lamont@lamontpeterson.org> Message-ID: <47A3E3B8.4070703@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lamont Peterson wrote: > All, > > I got this while mounting via "ls /net/server/": > > Summary > SELinux is preventing rpc.statd (rpcd_t) "write" to pipe (automount_t). > > Detailed Description > SELinux denied access requested by rpc.statd. It is not expected that this > access is required by rpc.statd 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:rpcd_t:s0 > Target Context system_u:system_r:automount_t:s0 > Target Objects pipe [ fifo_file ] > Affected RPM Packages > Policy RPM selinux-policy-3.0.8-74.fc8 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name plugins.catchall > Host Name reaver.lamontpeterson.net > Platform Linux reaver.lamontpeterson.net 2.6.23.9-85.fc8 > #1 > SMP Fri Dec 7 15:49:36 EST 2007 x86_64 x86_64 > Alert Count 1 > First Seen Fri 18 Jan 2008 05:35:16 PM MST > Last Seen Fri 18 Jan 2008 05:35:16 PM MST > Local ID 1b3c736c-2edb-4c23-8440-c423dca231f0 > Line Numbers > > Raw Audit Messages > > avc: denied { write } for comm=rpc.statd dev=pipefs path=pipe:[605687] > pid=8732 > scontext=system_u:system_r:rpcd_t:s0 tclass=fifo_file > tcontext=system_u:system_r:automount_t:s0 > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list This can be safely ignored and will be don't audited in the next release of policy. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkej47gACgkQrlYvE4MpobMHxwCgu4+hISYsqyJ6RDdkxXahpgVo bLEAnApL/HhQurypUIGCZPpvpdmi9gBf =F/Mu -----END PGP SIGNATURE----- From dwalsh at redhat.com Sat Feb 2 03:38:14 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 01 Feb 2008 22:38:14 -0500 Subject: firefox3beta and selinux In-Reply-To: <767182.6461.qm@web52607.mail.re2.yahoo.com> References: <767182.6461.qm@web52607.mail.re2.yahoo.com> Message-ID: <47A3E5A6.5040408@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Antonio Olivares wrote: > Dear all, > > When I try out the new firefox, setroubleshoot browser > tells me > > \begin{QUOTE} > > Summary: > > SELinux is preventing firefox from making the program > stack executable. > > Detailed Description: > > The 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 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 to > run correctly, you can change the context of the > executable to > unconfined_execmem_exec_t. "chcon -t > unconfined_execmem_exec_t > '/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 > '/usr/lib/firefox-3.0b3pre/firefox'" > > The following command will allow this access: > > chcon -t unconfined_execmem_exec_t > '/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 > Source Path > /usr/lib/firefox-3.0b3pre/firefox > Port > Host localhost > Source RPM Packages > firefox-3.0-0.beta2.15.nightly20080130.fc9 > Target RPM Packages > Policy RPM > selinux-policy-3.2.5-24.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-9.fc9 #1 SMP Tue Jan 29 > 18:08:15 EST 2008 i686 > athlon > Alert Count 2 > First Seen Fri 01 Feb 2008 05:08:54 > PM CST > Last Seen Fri 01 Feb 2008 05:08:54 > PM CST > Local ID > c4806f30-a6dc-43b0-8901-5531075795f7 > Line Numbers > > Raw Audit Messages > > host=localhost type=AVC msg=audit(1201907334.440:23): > avc: denied { execstack } for pid=2743 > 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(1201907334.440:23): arch=40000003 > syscall=125 success=no exit=-13 a0=bfd47000 a1=1000 > a2=1000007 a3=fffff000 items=0 ppid=2729 pid=2743 > 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) > > > > \end{QUOTE} > > I have done this two or three time so that I can use > firefox-beta 3, is this by design or will it > eventually be incorporated. > > If I decide to file a bug report, should it be against > firefox, selinux-policy? > > see here > ---------- > The 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 web > page explains how to remove this requirement. If > 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 against this package. > > firefox. It is doing something that it should not do and is quite dangerous. > Thanks, > > Antonio > > > ____________________________________________________________________________________ > 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkej5aYACgkQrlYvE4MpobMgvwCfYPpUZfHbLlZTm6zYGT5x+rmE CDAAn2y7SjdnAR0SWYjPl15TsS35svk8 =pzlp -----END PGP SIGNATURE----- From shintaro.fujiwara at gmail.com Sat Feb 2 08:02:39 2008 From: shintaro.fujiwara at gmail.com (Shintaro Fujiwara) Date: Sat, 2 Feb 2008 17:02:39 +0900 Subject: Question on semanage fcontext -a Message-ID: Hi, I read man semanage and found that semanage fcontext -a uses restorecon. Does that mean I don't have to restorecon after I semanage fcontext -a ? I just did restorecon fcontext -a and relabeled the system and found that file context survived. Thanks in advance. -- http://intrajp.no-ip.com/ Home Page -------------- next part -------------- An HTML attachment was scrubbed... URL: From selinux at gmail.com Sat Feb 2 18:43:58 2008 From: selinux at gmail.com (Tom London) Date: Sat, 2 Feb 2008 10:43:58 -0800 Subject: more AVCs from shutdown.... Message-ID: <4c4ba1530802021043i5eb95d7egd3bada26a021e60e@mail.gmail.com> Shutdown from gnome menu still doesn't work for me and generates an AVC: type=AVC msg=audit(1201976243.041:34): avc: denied { search } for pid=2470 comm="console-kit-dae" name="PolicyKit-public" dev=dm-0 ino=67632 scontext=system_u:system_r:consolekit_t:s0 tcontext=system_u:object_r:polkit_var_lib_t:s0 tclass=dir type=SYSCALL msg=audit(1201976243.041:34): arch=40000003 syscall=5 success=no exit=-13 a0=9c28880 a1=8000 a2=0 a3=8000 items=0 ppid=1 pid=2470 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) and [root at localhost ~]# locate PolicyKit-public /var/lib/PolicyKit-public [root at localhost ~]# Setting to permissive mode and retrying, shutdown works, but generates more AVC (attached): #============= consolekit_t ============== allow consolekit_t init_exec_t:file { read execute execute_no_trans }; allow consolekit_t initctl_t:fifo_file write; allow consolekit_t initrc_var_run_t:file { read write lock }; allow consolekit_t lib_t:file execute_no_trans; allow consolekit_t polkit_var_lib_t:dir search; allow consolekit_t shell_exec_t:file { read execute }; #============= vmware_host_t ============== allow vmware_host_t var_run_t:sock_file unlink; [vmware AVC seems not to bother anything, btw. dontaudit?] -- Tom London From selinux at gmail.com Sat Feb 2 20:28:23 2008 From: selinux at gmail.com (Tom London) Date: Sat, 2 Feb 2008 12:28:23 -0800 Subject: more AVCs from shutdown.... In-Reply-To: <4c4ba1530802021043i5eb95d7egd3bada26a021e60e@mail.gmail.com> References: <4c4ba1530802021043i5eb95d7egd3bada26a021e60e@mail.gmail.com> Message-ID: <4c4ba1530802021228k1ee2f69dt456509ace5109b1b@mail.gmail.com> On Sat, Feb 2, 2008 at 10:43 AM, Tom London wrote: > Shutdown from gnome menu still doesn't work for me and generates an AVC: > > type=AVC msg=audit(1201976243.041:34): avc: denied { search } for > pid=2470 comm="console-kit-dae" name="PolicyKit-public" dev=dm-0 > ino=67632 scontext=system_u:system_r:consolekit_t:s0 > tcontext=system_u:object_r:polkit_var_lib_t:s0 tclass=dir > type=SYSCALL msg=audit(1201976243.041:34): arch=40000003 syscall=5 > success=no exit=-13 a0=9c28880 a1=8000 a2=0 a3=8000 items=0 ppid=1 > pid=2470 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) > > and > [root at localhost ~]# locate PolicyKit-public > /var/lib/PolicyKit-public > [root at localhost ~]# > > Setting to permissive mode and retrying, shutdown works, but generates > more AVC (attached): > > > #============= consolekit_t ============== > allow consolekit_t init_exec_t:file { read execute execute_no_trans }; > allow consolekit_t initctl_t:fifo_file write; > allow consolekit_t initrc_var_run_t:file { read write lock }; > allow consolekit_t lib_t:file execute_no_trans; > allow consolekit_t polkit_var_lib_t:dir search; > allow consolekit_t shell_exec_t:file { read execute }; > > #============= vmware_host_t ============== > allow vmware_host_t var_run_t:sock_file unlink; > > [vmware AVC seems not to bother anything, btw. dontaudit?] > > -- Ooops, forgot to attach AVCs.... tom -- Tom London -------------- next part -------------- A non-text attachment was scrubbed... Name: log Type: application/octet-stream Size: 6407 bytes Desc: not available URL: From dtimms at iinet.net.au Sun Feb 3 03:49:28 2008 From: dtimms at iinet.net.au (David Timms) Date: Sun, 03 Feb 2008 14:49:28 +1100 Subject: sendmail avc's - on a system upgraded from f7 to f8 - in Message-ID: <47A539C8.9090705@iinet.net.au> AFAICS, I haven't made any configs to sendmail, yet I've started to get lots of AVC warnings in setroubleshoot, of three particular types: 1:======== Summary SELinux is preventing the /usr/sbin/sendmail.sendmail from using potentially mislabeled files (). Detailed Description SELinux has denied /usr/sbin/sendmail.sendmail access to potentially mislabeled file(s) (). This means that SELinux will not allow /usr/sbin/sendmail.sendmail 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 /usr/sbin/sendmail.sendmail 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:sendmail_t Target Context unconfined_u:object_r:rpm_script_tmp_t Target Objects None [ file ] Affected RPM Packages sendmail-8.14.2-1.fc8 [application] Policy RPM selinux-policy-3.0.8-81.fc8 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.home_tmp_bad_labels Host Name davidtdesktop Platform Linux davidtdesktop 2.6.23.14-107.fc8 #1 SMP Mon Jan 14 21:37:30 EST 2008 i686 athlon Alert Count 52 First Seen Mon 28 Jan 2008 18:32:36 EST Last Seen Sun 03 Feb 2008 14:31:08 EST Local ID e5d4104c-605b-473f-aa9a-0bc219636676 Line Numbers Raw Audit Messages avc: denied { read } for comm=sendmail dev=dm-0 egid=51 euid=51 exe=/usr/sbin/sendmail.sendmail exit=-13 fsgid=51 fsuid=51 gid=51 items=0 name=services pid=4791 scontext=system_u:system_r:sendmail_t:s0 sgid=51 subj=system_u:system_r:sendmail_t:s0 suid=51 tclass=file tcontext=unconfined_u:object_r:rpm_script_tmp_t:s0 tty=(none) uid=51 2:===== Summary SELinux is preventing the /usr/sbin/sendmail.sendmail from using potentially mislabeled files (). Detailed Description SELinux has denied /usr/sbin/sendmail.sendmail access to potentially mislabeled file(s) (). This means that SELinux will not allow /usr/sbin/sendmail.sendmail 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 /usr/sbin/sendmail.sendmail 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:system_mail_t:SystemLow- SystemHigh Target Context unconfined_u:object_r:rpm_script_tmp_t Target Objects None [ file ] Affected RPM Packages sendmail-8.14.2-1.fc8 [application] Policy RPM selinux-policy-3.0.8-81.fc8 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.home_tmp_bad_labels Host Name davidtdesktop Platform Linux davidtdesktop 2.6.23.14-107.fc8 #1 SMP Mon Jan 14 21:37:30 EST 2008 i686 athlon Alert Count 21 First Seen Mon 28 Jan 2008 00:00:02 EST Last Seen Sun 03 Feb 2008 12:00:01 EST Local ID 61f52ef3-2fca-4607-ade4-b8e117ca7a06 Line Numbers Raw Audit Messages avc: denied { read } for comm=sendmail dev=dm-0 egid=51 euid=51 exe=/usr/sbin/sendmail.sendmail exit=-13 fsgid=51 fsuid=51 gid=51 items=0 name=services pid=4402 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 sgid=51 subj=system_u:system_r:system_mail_t:s0-s0:c0.c1023 suid=51 tclass=file tcontext=unconfined_u:object_r:rpm_script_tmp_t:s0 tty=(none) uid=51 3:====== Summary SELinux is preventing the /usr/sbin/sendmail.sendmail from using potentially mislabeled files (). Detailed Description SELinux has denied /usr/sbin/sendmail.sendmail access to potentially mislabeled file(s) (). This means that SELinux will not allow /usr/sbin/sendmail.sendmail 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 /usr/sbin/sendmail.sendmail 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:system_mail_t Target Context unconfined_u:object_r:rpm_script_tmp_t Target Objects None [ file ] Affected RPM Packages sendmail-8.14.2-1.fc8 [application] Policy RPM selinux-policy-3.0.8-81.fc8 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.home_tmp_bad_labels Host Name davidtdesktop Platform Linux davidtdesktop 2.6.23.14-107.fc8 #1 SMP Mon Jan 14 21:37:30 EST 2008 i686 athlon Alert Count 14 First Seen Sun 27 Jan 2008 22:31:52 EST Last Seen Sun 03 Feb 2008 09:07:52 EST Local ID 426efd22-09c0-4e57-9975-03c2ec8ad840 Line Numbers Raw Audit Messages avc: denied { read } for comm=sendmail dev=dm-0 egid=51 euid=51 exe=/usr/sbin/sendmail.sendmail exit=-13 fsgid=51 fsuid=51 gid=51 items=0 name=services pid=3416 scontext=system_u:system_r:system_mail_t:s0 sgid=51 subj=system_u:system_r:system_mail_t:s0 suid=51 tclass=file tcontext=unconfined_u:object_r:rpm_script_tmp_t:s0 tty=(none) uid=51 ===== I'm not sure of the significance of in the report. But for eg: # rpm -V sendmail S.5....T c /var/log/mail/statistics #rpm -ql sendmail|xargs ls -lZ -rw-r--r-- root root system_u:object_r:etc_mail_t /etc/mail/access -rw-r----- root root system_u:object_r:etc_mail_t /etc/mail/access.db -rw-r--r-- root root system_u:object_r:etc_mail_t /etc/mail/domaintable -rw-r----- root root system_u:object_r:etc_mail_t /etc/mail/domaintable.db -r--r--r-- root root system_u:object_r:etc_mail_t /etc/mail/helpfile -rw-r--r-- root root system_u:object_r:etc_mail_t /etc/mail/local-host-names -rw-r--r-- root root system_u:object_r:etc_mail_t /etc/mail/mailertable -rw-r----- root root system_u:object_r:etc_mail_t /etc/mail/mailertable.db -rw-r--r-- root root system_u:object_r:etc_mail_t /etc/mail/Makefile -rw-r--r-- root root system_u:object_r:etc_mail_t /etc/mail/sendmail.cf -rw-r--r-- root root system_u:object_r:etc_mail_t /etc/mail/sendmail.mc -r--r--r-- root root system_u:object_r:etc_mail_t /etc/mail/submit.cf -rw-r--r-- root root system_u:object_r:etc_mail_t /etc/mail/submit.mc -rw-r--r-- root root system_u:object_r:etc_mail_t /etc/mail/trusted-users -rw-r--r-- root root system_u:object_r:etc_mail_t /etc/mail/virtusertable -rw-r----- root root system_u:object_r:etc_mail_t /etc/mail/virtusertable.db -rw-r--r-- root root system_u:object_r:etc_t /etc/pam.d/smtp.sendmail -rwxr-xr-x root root system_u:object_r:initrc_exec_t /etc/rc.d/init.d/sendmail -rw-r--r-- root root system_u:object_r:etc_t /etc/sysconfig/sendmail lrwxrwxrwx root root system_u:object_r:bin_t /usr/bin/hoststat lrwxrwxrwx root root system_u:object_r:bin_t /usr/bin/mailq.sendmail lrwxrwxrwx root root system_u:object_r:bin_t /usr/bin/makemap lrwxrwxrwx root root system_u:object_r:bin_t /usr/bin/newaliases.sendmail lrwxrwxrwx root root system_u:object_r:bin_t /usr/bin/purgestat -rwxr-xr-x root root system_u:object_r:bin_t /usr/bin/rmail.sendmail -rw-r--r-- root root system_u:object_r:lib_t /usr/lib/sasl2/Sendmail.conf lrwxrwxrwx root root system_u:object_r:lib_t /usr/lib/sendmail.sendmail -rwxr-xr-x root root system_u:object_r:bin_t /usr/sbin/mailstats -rwxr-xr-x root root system_u:object_r:bin_t /usr/sbin/makemap -rwxr-xr-x root root system_u:object_r:bin_t /usr/sbin/praliases -rwxr-sr-x root smmsp system_u:object_r:sendmail_exec_t /usr/sbin/sendmail.sendmail -rwxr-xr-x root root system_u:object_r:shell_exec_t /usr/sbin/smrsh -rw-r--r-- root root system_u:object_r:usr_t /usr/share/doc/sendmail-8.14.2/FAQ -rw-r--r-- root root system_u:object_r:usr_t /usr/share/doc/sendmail-8.14.2/KNOWNBUGS -rw-r--r-- root root system_u:object_r:usr_t /usr/share/doc/sendmail-8.14.2/LICENSE -rw-r--r-- root root system_u:object_r:usr_t /usr/share/doc/sendmail-8.14.2/README -rw-r--r-- root root system_u:object_r:usr_t /usr/share/doc/sendmail-8.14.2/RELEASE_NOTES -rw-r--r-- root root system_u:object_r:man_t /usr/share/man/man1/mailq.sendmail.1.gz -rw-r--r-- root root system_u:object_r:man_t /usr/share/man/man1/newaliases.sendmail.1.gz -rw-r--r-- root root system_u:object_r:man_t /usr/share/man/man5/aliases.sendmail.5.gz -rw-r--r-- root root system_u:object_r:man_t /usr/share/man/man8/mailstats.8.gz -rw-r--r-- root root system_u:object_r:man_t /usr/share/man/man8/makemap.8.gz -rw-r--r-- root root system_u:object_r:man_t /usr/share/man/man8/praliases.8.gz -rw-r--r-- root root system_u:object_r:man_t /usr/share/man/man8/rmail.8.gz -rw-r--r-- root root system_u:object_r:man_t /usr/share/man/man8/sendmail.sendmail.8.gz -rw-r--r-- root root system_u:object_r:man_t /usr/share/man/man8/smrsh.8.gz -rw------- root root system_u:object_r:sendmail_log_t /var/log/mail/statistics /etc/mail: -rw-r--r-- root root system_u:object_r:etc_mail_t access -rw-r----- root root system_u:object_r:etc_mail_t access.db -rw-r--r-- root root system_u:object_r:etc_mail_t domaintable -rw-r----- root root system_u:object_r:etc_mail_t domaintable.db -r--r--r-- root root system_u:object_r:etc_mail_t helpfile -rw-r--r-- root root system_u:object_r:etc_mail_t local-host-names -rw-r--r-- root root system_u:object_r:etc_mail_t mailertable -rw-r----- root root system_u:object_r:etc_mail_t mailertable.db -rw-r--r-- root root system_u:object_r:etc_mail_t Makefile -rw-r--r-- root root system_u:object_r:etc_mail_t sendmail.cf -rw-r--r-- root root system_u:object_r:etc_mail_t sendmail.mc drwxr-xr-x root root system_u:object_r:etc_mail_t spamassassin -r--r--r-- root root system_u:object_r:etc_mail_t submit.cf -rw-r--r-- root root system_u:object_r:etc_mail_t submit.mc -rw-r--r-- root root system_u:object_r:etc_mail_t trusted-users -rw-r--r-- root root system_u:object_r:etc_mail_t virtusertable -rw-r----- root root system_u:object_r:etc_mail_t virtusertable.db /etc/smrsh: /usr/share/doc/sendmail-8.14.2: -rw-r--r-- root root system_u:object_r:usr_t FAQ -rw-r--r-- root root system_u:object_r:usr_t KNOWNBUGS -rw-r--r-- root root system_u:object_r:usr_t LICENSE -rw-r--r-- root root system_u:object_r:usr_t README -rw-r--r-- root root system_u:object_r:usr_t RELEASE_NOTES /var/log/mail: -rw------- root root system_u:object_r:sendmail_log_t statistics /var/spool/clientmqueue: -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm0TAL2Z4002179 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm0TAL2Z5002179 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm0TAL2Z6002179 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm0TBuDQl003422 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm0TBvh2R003889 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm0TD017m005694 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm0TKmEhp002179 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm0TKmEhq002179 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm0TKmEhr002179 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm0U9cIeG006258 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm0U9ZDWF004246 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm0UA01ED006312 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm0V8sBCp002180 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm0V8sBCq002180 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm0V8sBCr002180 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm0VA02Ur004010 -rw-rw---- davidt smmsp system_u:object_r:mqueue_spool_t dfm0VAT2Kl005308 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm0VATPCh005580 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm0VAVCQU006128 -rw-rw---- davidt smmsp system_u:object_r:mqueue_spool_t dfm0VBe2tP006857 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm0VD02fi007007 -rw-rw---- davidt smmsp system_u:object_r:mqueue_spool_t dfm0VEe13G007185 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm0VEsBCp007222 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm0VEsBCq007222 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm0VEsBCr007222 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm0VEsBCs007222 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm0VFsBCp007322 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm0VG01XF007335 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm0VHsBCp008314 -rw-rw---- smmsp smmsp unconfined_u:object_r:mqueue_spool_t dfm0VHW6HF007736 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm0VHW8cm008025 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm0VIsBCp008420 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm0VJ01Xa008433 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm0VKsBCp008627 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm117jvOI002185 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm117jvOJ002185 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm117jvOK002185 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm11A01jB003317 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm11D03rF004596 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm11KVEe6002181 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm11KVEe7002181 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm11M01sH002693 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm11M6OET002942 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm11M7vs1003405 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm12102m9004637 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm122VEe6006707 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm122VEe7006707 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm122VEe8006707 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm12402pG008037 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm125VEe6009373 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm12701Q0010624 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm128VEe6011891 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm129VEe6012792 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm129VEe7012792 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm12A02F1013291 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm12AVEe6013796 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm12BVEe6017595 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm12D02Dr019018 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm12KV8PK002188 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm12KV8PL002188 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm12M01K2002693 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm12M6Jvg002942 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm12M7qnO003416 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm13101hF004402 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm132V8PK004643 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm132V8PL004643 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t dfm132V8PM004643 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0TAL2Z4002179 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0TAL2Z5002179 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0TAL2Z6002179 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0TBuDQl003422 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0TBvh2R003889 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0TD017m005694 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0TKmEhp002179 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0TKmEhq002179 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0TKmEhr002179 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0U9cIeG006258 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0U9ZDWF004246 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0UA01ED006312 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0V8sBCp002180 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0V8sBCq002180 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0V8sBCr002180 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0VA02Ur004010 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0VAT2Kl005308 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0VATPCh005580 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0VAVCQU006128 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0VBe2tP006857 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0VD02fi007007 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0VEe13G007185 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0VEsBCp007222 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0VEsBCq007222 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0VEsBCr007222 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0VEsBCs007222 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0VFsBCp007322 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0VG01XF007335 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0VHsBCp008314 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0VHW6HF007736 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0VHW8cm008025 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0VIsBCp008420 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0VJ01Xa008433 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm0VKsBCp008627 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm117jvOI002185 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm117jvOJ002185 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm117jvOK002185 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm11A01jB003317 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm11D03rF004596 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm11KVEe6002181 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm11KVEe7002181 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm11M01sH002693 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm11M6OET002942 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm11M7vs1003405 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm12102m9004637 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm122VEe6006707 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm122VEe7006707 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm122VEe8006707 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm12402pG008037 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm125VEe6009373 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm12701Q0010624 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm128VEe6011891 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm129VEe6012792 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm129VEe7012792 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm12A02F1013291 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm12AVEe6013796 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm12BVEe6017595 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm12D02Dr019018 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm12KV8PK002188 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm12KV8PL002188 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm12M01K2002693 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm12M6Jvg002942 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm12M7qnO003416 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm13101hF004402 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm132V8PK004643 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm132V8PL004643 -rw-rw---- smmsp smmsp system_u:object_r:mqueue_spool_t qfm132V8PM004643 /var/spool/mqueue: The counts are so high because cron jobs trigger the warnings. Is this a problem for others - or I have I messed something up. Note I'm not trying to use sendmail - cron tasks are. DaveT. From gene.heskett at verizon.net Sun Feb 3 11:05:26 2008 From: gene.heskett at verizon.net (Gene Heskett) Date: Sun, 03 Feb 2008 06:05:26 -0500 Subject: More selinux questions Message-ID: <200802030605.26253.gene.heskett@verizon.net> Greetings; After several failures on Sunday mornings to properly rotate some logs generated by fetchmail, I give up and need help. logrotate can kill fetchmail ok, but cannot restart it, and I've now tried both of these invocations in the postrotate script, and both fail, sending me emails to that effect: system_u:system_r:unconfined_t:s0 is not a valid context error: error running non-shared postrotate script for /var/log/fetchmail.log of '/var/log/fetchmail.log /var/log/procmail.log ' fetchmail: no process killed system_u:system_r:unconfined_t:s0 is not a valid context error: error running non-shared postrotate script for /var/log/procmail.log of '/var/log/fetchmail.log /var/log/procmail.log ' I had tried your recommended launching line this week after the su gene -c version failed last week: runcon -t unconfined_t -- runuser -l -c "fetchmail -d 90 --fetchmailrc /home/gene/.fetchmailrc" gene Which generated the above message, and this one: su gene -c "fetchmail -d 90 --fetchmailrc /home/gene/.fetchmailrc" which works to restart it from a shell just fine. The runcon version works at bootup time just fine, so why can't I use it in a logrotation script? I think I see one problem though, with both logs named in the same script, its doing 2 killalls of fetchmail, so I'll make those 2 separate scripts I guess. Done. But how DO I relaunch fetchmail in the postrotate section? Also, in /etc/croon.daily, tmpwatch is having trouble, from the same email from cron as above: /etc/cron.daily/tmpwatch: error: failed to lstat /tmp/.spamassassin5459PpduEPtmp: Permission denied What is this? I thought anything could use /tmp for anything... It exists: -rw------- 1 gene gene 3298 2008-01-07 20:49 .spamassassin5459PpduEPtmp Humm, from the cli: [root at coyote logrotate.d]# lstat /tmp/.spamassassin5459PpduEPtmp -bash: lstat: command not found But, take off the el and just run stat [root at coyote logrotate.d]# stat /tmp/.spamassassin5459PpduEPtmp File: `/tmp/.spamassassin5459PpduEPtmp' Size: 3298 Blocks: 8 IO Block: 4096 regular file Device: fe00h/65024d Inode: 26378244 Links: 1 Access: (0600/-rw-------) Uid: ( 500/ gene) Gid: ( 500/ gene) Access: 2008-02-01 02:24:19.000000000 -0500 Modify: 2008-01-07 20:49:23.000000000 -0500 Change: 2008-01-07 20:49:23.000000000 -0500 Typu in a script someplace? Thanks for any clarification offered here. -- 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) How much of their influence on you is a result of your influence on them? From sds at tycho.nsa.gov Mon Feb 4 13:26:39 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 04 Feb 2008 08:26:39 -0500 Subject: Question on semanage fcontext -a In-Reply-To: References: Message-ID: <1202131599.3070.17.camel@moss-spartans.epoch.ncsc.mil> On Sat, 2008-02-02 at 17:02 +0900, Shintaro Fujiwara wrote: > Hi, I read man semanage and found that semanage fcontext -a uses > restorecon. > > Does that mean I don't have to restorecon after I semanage fcontext > -a ? semanage fcontext -a adds entries to the local file contexts configuration. It doesn't directly relabel any files. Then, after you've run semanage fcontext -a to add the entry, you can run restorecon or other relabeling programs to actually relabel the files to the context you've specified in the entry. > I just did restorecon fcontext -a and relabeled the system and found > that file context survived. Yes, the relabeling programs (setfiles, restorecon, fixfiles) all consult the file contexts configuration, and semanage fcontext -a is how you add local entries to that configuration. The other way to add entries is by inserting a loadable policy module with its own .fc file. -- Stephen Smalley National Security Agency From shintaro.fujiwara at gmail.com Mon Feb 4 14:51:38 2008 From: shintaro.fujiwara at gmail.com (Shintaro Fujiwara) Date: Mon, 4 Feb 2008 23:51:38 +0900 Subject: Question on semanage fcontext -a In-Reply-To: <1202131599.3070.17.camel@moss-spartans.epoch.ncsc.mil> References: <1202131599.3070.17.camel@moss-spartans.epoch.ncsc.mil> Message-ID: 2008/2/4, Stephen Smalley : > > > On Sat, 2008-02-02 at 17:02 +0900, Shintaro Fujiwara wrote: > > Hi, I read man semanage and found that semanage fcontext -a uses > > restorecon. > > > > Does that mean I don't have to restorecon after I semanage fcontext > > -a ? > > semanage fcontext -a adds entries to the local file contexts > configuration. It doesn't directly relabel any files. Then, after > you've run semanage fcontext -a to add the entry, you can run restorecon > or other relabeling programs to actually relabel the files to the > context you've specified in the entry. OK, I understand. So, I have to relabel by restorecon after I semanage fcontext -a path, right ? I already re-written my program (segatex) to restorecon after semanage fcontext -a -m. Thank you very much. > I just did restorecon fcontext -a and relabeled the system and found > > that file context survived. > > Yes, the relabeling programs (setfiles, restorecon, fixfiles) all > consult the file contexts configuration, and semanage fcontext -a is how > you add local entries to that configuration. The other way to add > entries is by inserting a loadable policy module with its own .fc file. > > -- > Stephen Smalley > National Security Agency > > -- http://intrajp.no-ip.com/ Home Page -------------- next part -------------- An HTML attachment was scrubbed... URL: From sds at tycho.nsa.gov Mon Feb 4 15:01:34 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 04 Feb 2008 10:01:34 -0500 Subject: Question on semanage fcontext -a In-Reply-To: References: <1202131599.3070.17.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1202137294.3070.50.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2008-02-04 at 23:51 +0900, Shintaro Fujiwara wrote: > 2008/2/4, Stephen Smalley : > semanage fcontext -a adds entries to the local file contexts > configuration. It doesn't directly relabel any files. Then, > after > you've run semanage fcontext -a to add the entry, you can run > restorecon > or other relabeling programs to actually relabel the files to > the > context you've specified in the entry. > > OK, I understand. > So, I have to relabel by restorecon after I semanage fcontext -a path, > right ? Yes. You don't have to do a full relabel, of course, just a restorecon of the relevant directories and/or files. > I already re-written my program (segatex) to restorecon after semanage > fcontext -a -m. > > Thank you very much. -- Stephen Smalley National Security Agency From tibbs at math.uh.edu Mon Feb 4 16:09:27 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 04 Feb 2008 10:09:27 -0600 Subject: Denial when calling /bin/mail from initscripts Message-ID: This is a bit odd; I have my machines send an email when they reboot, and this worked previous to F8 but no F8 it seems that selinux is preventing that from working properly. rc.local has something like: HN=`hostname` date | mail -s $HN obscured at address When the mail is sent I get the following denial: audit(1202140440.123:4): avc: denied { read } for pid=2752 comm="sendmail" path=2F746D702F527357566E686E52202864656C6574656429 dev=dm-3 ino=98307 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=file and a message is sent, but it's mostly empty (no body and no subject). audit2allow just says #============= sendmail_t ============== allow sendmail_t initrc_tmp_t:file read; but as is unfortunately almost always the case with selinux things, I understand that would work but I don't understand if it exposes me to anything or could cause problems later. - J< From andreas at bawue.net Mon Feb 4 17:52:08 2008 From: andreas at bawue.net (Andreas Thienemann) Date: Mon, 4 Feb 2008 18:52:08 +0100 (CET) Subject: Exporting selinux labels via network file systems Message-ID: Hey, is there any way of exporting selinux labels via nfs or any other network file systems? I've found some statements on the NSA selinux page indicating that NFS4 might be able to do this, but does current fedora and rhel support this? I know about the workaround of setting a general filecontext through the context mount option, but I'm looking at something a bit more fine-grained. regards, andreas From sds at tycho.nsa.gov Mon Feb 4 18:42:59 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 04 Feb 2008 13:42:59 -0500 Subject: Exporting selinux labels via network file systems In-Reply-To: References: Message-ID: <1202150579.3070.115.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2008-02-04 at 18:52 +0100, Andreas Thienemann wrote: > Hey, > > is there any way of exporting selinux labels via nfs or any other network > file systems? > > I've found some statements on the NSA selinux page indicating that NFS4 > might be able to do this, but does current fedora and rhel support this? > > I know about the workaround of setting a general filecontext through the > context mount option, but I'm looking at something a bit more > fine-grained. There is ongoing work to provide such support, but it isn't complete yet. -- Stephen Smalley National Security Agency From dtimms at iinet.net.au Mon Feb 4 21:23:43 2008 From: dtimms at iinet.net.au (David Timms) Date: Tue, 05 Feb 2008 08:23:43 +1100 Subject: sendmail avc's - on a system upgraded from f7 to f8 - in In-Reply-To: <47A72FE2.2010708@redhat.com> References: <47A539C8.9090705@iinet.net.au> <47A72FE2.2010708@redhat.com> Message-ID: <47A7825F.9030203@iinet.net.au> Daniel J Walsh wrote: > David Timms wrote: >> AFAICS, I haven't made any configs to sendmail, yet I've started to get >> lots of AVC warnings in setroubleshoot, of three particular types: >> >> 1:======== >> Summary >> SELinux is preventing the /usr/sbin/sendmail.sendmail from using >> potentially mislabeled files (). >> >> Detailed Description >> SELinux has denied /usr/sbin/sendmail.sendmail access to potentially >> mislabeled file(s) (). This means that SELinux will not allow > A postinstall script has ruined the labeling on your /etc/services file. > > # restorecon -v /etc/services > will fix # ls -lZ /etc/services -rw-r--r-- root root unconfined_u:object_r:rpm_script_tmp_t /etc/services Yes, you are correct. # restorecon -v /etc/services restorecon reset /etc/services context unconfined_u:object_r:rpm_script_tmp_t:s0->system_u:object_r:etc_t:s0 I guess experience rather than reading the troubleshoot message led you to /etc/services ? > If you any idea which rpm did this. I would like to know. yum.logs--- I'l try to narrow it down, not sure how. I can't remember now exactly what I was doing around the date that it started occurring. === Jan 27 18:17:06 Installed: apr-util - 1.2.10-2.fc8.i386 Jan 27 18:17:10 Installed: subversion - 1.4.4-7.i386 Jan 27 18:21:36 Installed: libxkbfile - 1.0.4-3.fc8.i386 Jan 27 18:21:37 Installed: xorg-x11-xkb-utils - 7.2-3.fc8.i386 Jan 27 18:23:39 Installed: wireshark - 0.99.7-2.fc8.i386 Jan 27 18:25:58 Installed: torcs-data - 1.3.0-2.noarch Jan 27 18:26:58 Installed: libgnomeui-devel - 2.20.1.1-1.fc8.i386 Jan 27 18:30:28 Installed: libcaca - 0.99-0.3.beta11.fc8.i386 Jan 27 18:30:31 Installed: xine - 0.99.5-1.fc7.i386 Jan 27 18:33:26 Installed: gettext - 0.16.1-12.fc8.i386 Jan 27 18:33:27 Installed: redhat-lsb - 3.1-19.fc8.i386 Jan 27 18:34:23 Installed: bluez-libs - 3.20-1.fc8.i386 Jan 27 18:34:25 Installed: gnokii - 0.6.18-3.fc8.i386 Jan 27 18:37:01 Installed: ffmpeg - 0.4.9-0.8.20070530.fc7.i386 Jan 27 18:42:45 Installed: indent - 2.2.9-16.fc7.i386 Jan 27 18:48:09 Erased: perl-LDAP Jan 27 18:50:05 Installed: fuse - 2.7.0-8.fc8.i386 Jan 27 18:51:32 Erased: audacity Jan 27 18:52:00 Installed: compat-wxGTK26 - 2.6.4-0.8.i386 Jan 27 18:52:03 Installed: audacity - 1.3.2-17.fc8.i386 Jan 27 18:53:02 Erased: dvdrip Jan 27 18:53:04 Erased: subtitleripper Jan 27 18:53:06 Erased: transcode Jan 27 18:53:43 Installed: ffmpeg-libpostproc - 0.4.9-0.8.20070530.fc7.i386 Jan 27 18:53:48 Installed: transcode - 1.0.3-1.fc7.i386 Jan 27 18:54:20 Erased: x264-devel Jan 27 18:54:47 Installed: x264-devel - 0.0.0-0.3.20070529.fc7.i386 Jan 27 18:55:25 Erased: timmsy-servers Jan 27 18:59:20 Erased: gkrellm Jan 27 18:59:26 Erased: timmsy-apps Jan 27 18:59:58 Installed: lm_sensors - 2.10.5-1.fc8.i386 Jan 27 19:00:00 Installed: gkrellm - 2.3.0-4.fc8.i386 Jan 27 19:02:23 Erased: faad2-devel Jan 27 19:02:55 Installed: setroubleshoot-server - 1.10.7-1.fc8.noarch Jan 27 19:03:31 Erased: ocsinventory-client Jan 27 19:05:47 Installed: lincity-ng-data - 1.1.1-2.fc8.i386 Jan 27 19:10:25 Installed: libquicktime - 1.0.0-1.fc7.i386 Jan 27 19:11:45 Installed: tcl - 1:8.4.15-5.fc8.i386 Jan 27 19:11:49 Installed: ppracer - 0.3.1-13.fc8.i386 Jan 27 19:14:09 Erased: perl-AnyEvent Jan 27 19:14:10 Erased: perl-Event-ExecFlow Jan 27 19:14:11 Erased: perl-Coro Jan 27 19:15:04 Erased: perl-Net-Jabber Jan 27 19:15:06 Erased: perl-SOAP-Lite Jan 27 20:02:54 Installed: thunderbird-debuginfo - 2.0.0.9-1.fc8.i386 Jan 27 21:30:09 Erased: thunderbird Jan 27 21:35:35 Installed: thunderbird - 2.0.0.9-1.fc8.i386 Jan 27 22:31:47 Installed: tetex-fonts - 3.0-44.3.fc8.i386 ----started here for one of the 3. Yum log was rolled over at this time as well. Jan 27 22:37:03 Installed: pulseaudio-libs - 0.9.8-5.fc8.i386 Jan 27 22:41:21 Installed: dialog - 1.1-2.20070704.fc8.i386 Jan 27 22:44:43 Installed: fedora-screensaver-theme - 1.0.0-1.fc8.noarch Jan 27 22:46:53 Installed: SDL - 1.2.13-1.fc8.i386 Jan 27 23:06:07 Erased: libswscale0 Jan 27 23:09:38 Erased: kernel-devel Jan 27 23:09:43 Erased: timmsy-development Jan 28 00:04:30 Updated: pulseaudio-core-libs - 0.9.8-5.fc8.i386 Jan 28 00:04:33 Updated: glib-java - 0.2.6-10.fc8.i386 Jan 28 00:04:36 Updated: pulseaudio - 0.9.8-5.fc8.i386 Jan 28 00:04:38 Updated: cairo-java - 1.0.5-8.fc8.i386 Jan 28 00:04:40 Updated: libgtk-java - 2.8.7-5.fc8.i386 Jan 28 00:04:40 Updated: pulseaudio-module-x11 - 0.9.8-5.fc8.i386 Jan 28 00:04:41 Updated: pulseaudio-libs-zeroconf - 0.9.8-5.fc8.i386 Jan 28 00:04:42 Updated: glew - 1.4.0-5.fc8.i386 Jan 28 00:04:43 Updated: libbeagle - 0.2.18-4.fc8.i386 Jan 28 00:05:03 Updated: allegro - 4.2.2-7.fc8.i386 Jan 28 00:05:03 Updated: pulseaudio-libs-glib2 - 0.9.8-5.fc8.i386 Jan 28 00:05:05 Updated: libgconf-java - 2.12.4-9.fc8.i386 Jan 28 00:05:06 Updated: xterm - 231-1.fc8.i386 Jan 28 00:05:07 Updated: pulseaudio-esound-compat - 0.9.8-5.fc8.i386 Jan 28 00:05:50 Installed: kernel - 2.6.23.14-107.fc8.i686 Jan 28 00:05:51 Updated: hwdata - 0.215-1.fc8.noarch Jan 28 00:05:52 Updated: pulseaudio-module-gconf - 0.9.8-5.fc8.i386 Jan 28 00:05:53 Updated: pulseaudio-utils - 0.9.8-5.fc8.i386 Jan 28 00:05:56 Updated: liberation-fonts - 1.0-1.fc8.noarch Jan 28 00:06:08 Updated: docbook-style-xsl - 1.73.2-5.fc8.noarch Jan 28 00:06:08 Updated: python-turbokid - 1.0.4-1.fc8.noarch Jan 28 00:06:09 Updated: logrotate - 3.7.6-2.2.fc8.i386 Jan 28 00:06:17 Updated: kernel-headers - 2.6.23.14-107.fc8.i386 Jan 28 00:31:15 Installed: kernel-devel - 2.6.23.14-107.fc8.i686 Jan 28 10:13:10 Installed: memtest86+ - 1.70-4.fc8.i386 Jan 30 20:09:14 Updated: bash - 3.2-20.fc8.i386 Jan 30 20:09:18 Updated: libacl - 2.2.39-13.fc8.i386 From paul at city-fan.org Mon Feb 4 23:54:16 2008 From: paul at city-fan.org (Paul Howarth) Date: Mon, 4 Feb 2008 23:54:16 +0000 Subject: sendmail avc's - on a system upgraded from f7 to f8 - in In-Reply-To: <47A7825F.9030203@iinet.net.au> References: <47A539C8.9090705@iinet.net.au> <47A72FE2.2010708@redhat.com> <47A7825F.9030203@iinet.net.au> Message-ID: <20080204235416.58175257@metropolis.intra.city-fan.org> On Tue, 05 Feb 2008 08:23:43 +1100 David Timms wrote: > Daniel J Walsh wrote: > > David Timms wrote: > >> AFAICS, I haven't made any configs to sendmail, yet I've started > >> to get lots of AVC warnings in setroubleshoot, of three particular > >> types: > >> > >> 1:======== > >> Summary > >> SELinux is preventing the /usr/sbin/sendmail.sendmail from using > >> potentially mislabeled files (). > >> > >> Detailed Description > >> SELinux has denied /usr/sbin/sendmail.sendmail access to > >> potentially mislabeled file(s) (). This means that > >> SELinux will not allow > > > A postinstall script has ruined the labeling on your /etc/services > > file. > > > > # restorecon -v /etc/services > > will fix > # ls -lZ /etc/services > -rw-r--r-- root root > unconfined_u:object_r:rpm_script_tmp_t /etc/services Yes, you are > correct. > > # restorecon -v /etc/services > restorecon reset /etc/services context > unconfined_u:object_r:rpm_script_tmp_t:s0->system_u:object_r:etc_t:s0 > > I guess experience rather than reading the troubleshoot message led > you to /etc/services ? > > > If you any idea which rpm did this. I would like to know. > yum.logs--- I'l try to narrow it down, not sure how. I can't > remember now exactly what I was doing around the date that it started > occurring. === Might you have installed VMware? Mangling the context of /etc/services to rpm_script_tmp_t is a long-standing bug in the VMware package scripts. Paul. From dtimms at iinet.net.au Tue Feb 5 12:35:53 2008 From: dtimms at iinet.net.au (David Timms) Date: Tue, 05 Feb 2008 23:35:53 +1100 Subject: sendmail avc's - on a system upgraded from f7 to f8 - in In-Reply-To: <20080204235416.58175257@metropolis.intra.city-fan.org> References: <47A539C8.9090705@iinet.net.au> <47A72FE2.2010708@redhat.com> <47A7825F.9030203@iinet.net.au> <20080204235416.58175257@metropolis.intra.city-fan.org> Message-ID: <47A85829.2020306@iinet.net.au> Paul Howarth wrote: > Might you have installed VMware? Correct. > Mangling the context of /etc/services > to rpm_script_tmp_t is a long-standing bug in the VMware package > scripts. # ls -lZ /etc/serv* -rw-r--r-- root root system_u:object_r:etc_t /etc/services # rpm -Uvh --replacepkgs VMware-server-1.0.4-56528.i386.rpm Preparing... ########################################### [100%] 1:VMware-server ########################################### [100%] # ls -lZ /etc/serv* -rw-r--r-- root root unconfined_u:object_r:rpm_script_tmp_t /etc/services Searching the vmware forums found the identical cause leading to slghtly different selinux symptoms - logging not working, and a comment form myself in there: http://communities.vmware.com/message/856343#856343 referencing: http://www.redhat.com/archives/fedora-list/2007-April/msg00780.html ,794 and another on using vmware-server with F8: http://communities.vmware.com/message/856343#856343 which didn't stop me, but helped others. Actually, I submitted a vmware "defect report" to this effect. A secondary question: is there a way in which troubleshoot browser could be improved to point the finger at the correct cause / solution ? Or is the effort best spent in getting vmware to script the install more carefully ? DaveT. "short memory, must have a, short memory" - midnight oil From dwalsh at redhat.com Tue Feb 5 13:34:44 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 05 Feb 2008 08:34:44 -0500 Subject: sendmail avc's - on a system upgraded from f7 to f8 - in In-Reply-To: <47A7825F.9030203@iinet.net.au> References: <47A539C8.9090705@iinet.net.au> <47A72FE2.2010708@redhat.com> <47A7825F.9030203@iinet.net.au> Message-ID: <47A865F4.2000504@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Timms wrote: > Daniel J Walsh wrote: >> David Timms wrote: >>> AFAICS, I haven't made any configs to sendmail, yet I've started to get >>> lots of AVC warnings in setroubleshoot, of three particular types: >>> >>> 1:======== >>> Summary >>> SELinux is preventing the /usr/sbin/sendmail.sendmail from using >>> potentially mislabeled files (). >>> >>> Detailed Description >>> SELinux has denied /usr/sbin/sendmail.sendmail access to potentially >>> mislabeled file(s) (). This means that SELinux will not allow > >> A postinstall script has ruined the labeling on your /etc/services file. >> >> # restorecon -v /etc/services >> will fix > # ls -lZ /etc/services > -rw-r--r-- root root unconfined_u:object_r:rpm_script_tmp_t /etc/services > Yes, you are correct. > > # restorecon -v /etc/services > restorecon reset /etc/services context > unconfined_u:object_r:rpm_script_tmp_t:s0->system_u:object_r:etc_t:s0 > > I guess experience rather than reading the troubleshoot message led you > to /etc/services ? > >> Yes, although this is actually a bug in audit/setroubleshoot that is causing the target mislabeled file to be If the frame work had actually specified /etc/services, one of the plugins does a matchpatcon on the file and sees that the file context differs from the default and sets it correctly. Please report this as a bug on setroubleshoot and include the audit messages so we can see why setroubleshoot failed. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeoZfQACgkQrlYvE4MpobMgHQCbBbgrBQjhwI3dXojEdKYrTTQP GlsAoN4cCSvxzyguO77FVmdQzR2NbHPf =knPX -----END PGP SIGNATURE----- From dwalsh at redhat.com Tue Feb 5 13:35:43 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 05 Feb 2008 08:35:43 -0500 Subject: sendmail avc's - on a system upgraded from f7 to f8 - in In-Reply-To: <47A85829.2020306@iinet.net.au> References: <47A539C8.9090705@iinet.net.au> <47A72FE2.2010708@redhat.com> <47A7825F.9030203@iinet.net.au> <20080204235416.58175257@metropolis.intra.city-fan.org> <47A85829.2020306@iinet.net.au> Message-ID: <47A8662F.1070909@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Timms wrote: > Paul Howarth wrote: >> Might you have installed VMware? > Correct. > >> Mangling the context of /etc/services >> to rpm_script_tmp_t is a long-standing bug in the VMware package >> scripts. > > # ls -lZ /etc/serv* > -rw-r--r-- root root system_u:object_r:etc_t /etc/services > > # rpm -Uvh --replacepkgs VMware-server-1.0.4-56528.i386.rpm > Preparing... ########################################### [100%] > 1:VMware-server ########################################### [100%] > > # ls -lZ /etc/serv* > -rw-r--r-- root root unconfined_u:object_r:rpm_script_tmp_t /etc/services > > Searching the vmware forums found the identical cause leading to slghtly > different selinux symptoms - logging not working, and a comment form > myself in there: > http://communities.vmware.com/message/856343#856343 > referencing: > http://www.redhat.com/archives/fedora-list/2007-April/msg00780.html ,794 > > and another on using vmware-server with F8: > http://communities.vmware.com/message/856343#856343 > which didn't stop me, but helped others. > > Actually, I submitted a vmware "defect report" to this effect. > > A secondary question: is there a way in which troubleshoot browser could > be improved to point the finger at the correct cause / solution ? > Or is the effort best spent in getting vmware to script the install more > carefully ? > > DaveT. > "short memory, must have a, short memory" - midnight oil > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list You can also use restorecond to watch this file in the future. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeoZi8ACgkQrlYvE4MpobNlXACfdVrriTAJn8M75khsnvGSwf4R gd8An3+lsgyuJFqks3UHsf0pndc2dkZ7 =eTba -----END PGP SIGNATURE----- From dwalsh at redhat.com Tue Feb 5 13:37:06 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 05 Feb 2008 08:37:06 -0500 Subject: sendmail avc's - on a system upgraded from f7 to f8 - in In-Reply-To: <47A8662F.1070909@redhat.com> References: <47A539C8.9090705@iinet.net.au> <47A72FE2.2010708@redhat.com> <47A7825F.9030203@iinet.net.au> <20080204235416.58175257@metropolis.intra.city-fan.org> <47A85829.2020306@iinet.net.au> <47A8662F.1070909@redhat.com> Message-ID: <47A86682.1040100@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel J Walsh wrote: > David Timms wrote: >> Paul Howarth wrote: >>> Might you have installed VMware? >> Correct. > >>> Mangling the context of /etc/services >>> to rpm_script_tmp_t is a long-standing bug in the VMware package >>> scripts. >> # ls -lZ /etc/serv* >> -rw-r--r-- root root system_u:object_r:etc_t /etc/services > >> # rpm -Uvh --replacepkgs VMware-server-1.0.4-56528.i386.rpm >> Preparing... ########################################### [100%] >> 1:VMware-server ########################################### [100%] > >> # ls -lZ /etc/serv* >> -rw-r--r-- root root unconfined_u:object_r:rpm_script_tmp_t /etc/services > >> Searching the vmware forums found the identical cause leading to slghtly >> different selinux symptoms - logging not working, and a comment form >> myself in there: >> http://communities.vmware.com/message/856343#856343 >> referencing: >> http://www.redhat.com/archives/fedora-list/2007-April/msg00780.html ,794 > >> and another on using vmware-server with F8: >> http://communities.vmware.com/message/856343#856343 >> which didn't stop me, but helped others. > >> Actually, I submitted a vmware "defect report" to this effect. > >> A secondary question: is there a way in which troubleshoot browser could >> be improved to point the finger at the correct cause / solution ? >> Or is the effort best spent in getting vmware to script the install more >> carefully ? > >> DaveT. >> "short memory, must have a, short memory" - midnight oil > >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > You can also use restorecond to watch this file in the future. > > Or even better use xen of qemu for free:^) - -- 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 iEYEARECAAYFAkeoZoIACgkQrlYvE4MpobNydQCeKmmHw5VVduMJnFAOJo0kMf/a epQAnAiy+SuUaYp60Lu+nxGdR3wqSfzT =WkZO -----END PGP SIGNATURE----- From kwizart at gmail.com Tue Feb 5 14:02:45 2008 From: kwizart at gmail.com (Nicolas Chauvet) Date: Tue, 05 Feb 2008 15:02:45 +0100 Subject: postgresql with httpd and dotclear Message-ID: <47A86C85.7090000@gmail.com> Hello ! I try to use apache and postgresql with the dotclear blog engine. When I try to enter the database information from the admin config wizard within the browser, have a selinux denial : audit(1202182131.382:34): avc: denied { name_connect } for pid=2604 comm="httpd" dest=5432 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:postgresql_port_t:s0 tclass=tcp_socket [root at haderach ~]# ls -Z /home/www/ drwxr-xr-x root root system_u:object_r:httpd_sys_content_t:s0 dotclear [root at haderach ~]# rpm -q sepostgresql sepostgresql-8.2.6-1.158.fc8 selinux-policy-3.0.8-81.fc8 selinux-policy-targeted-3.0.8-81.fc8 [root at haderach data]# semodule -l |grep postgre sepostgresql 1.158 On the other hand, when i try to use phpPgAdmin, it works. But i need to change: /var/lib/pgsql/data/pg_hba.conf from ident sameuser to md5.(tryed the same for dotclear without sucess). Also, from: http://code.google.com/p/sepgsql/wiki/install_memo_Fedora7 As i'm using F-8, i expect not to need the additional recompiled selinux-policy-2.6.4-38.sepgsql.fc7.noarch.rpm. (don't know if current F-7 users will still need it?) - At least the .sepsql doen't fit the same version number Any tips for this ? Nicolas (kwizart) From kaigai at ak.jp.nec.com Tue Feb 5 14:54:06 2008 From: kaigai at ak.jp.nec.com (KaiGai Kohei) Date: Tue, 05 Feb 2008 23:54:06 +0900 Subject: postgresql with httpd and dotclear In-Reply-To: <47A86C85.7090000@gmail.com> References: <47A86C85.7090000@gmail.com> Message-ID: <47A8788E.7020700@ak.jp.nec.com> Nicolas Chauvet wrote: > Hello ! > > I try to use apache and postgresql with the dotclear blog engine. > When I try to enter the database information from the admin config > wizard within the browser, have a selinux denial : > > audit(1202182131.382:34): avc: denied { name_connect } for pid=2604 > comm="httpd" dest=5432 scontext=system_u:system_r:httpd_t:s0 > tcontext=system_u:object_r:postgresql_port_t:s0 tclass=tcp_socket > > [root at haderach ~]# ls -Z /home/www/ > drwxr-xr-x root root system_u:object_r:httpd_sys_content_t:s0 dotclear > > [root at haderach ~]# rpm -q sepostgresql > sepostgresql-8.2.6-1.158.fc8 > selinux-policy-3.0.8-81.fc8 > selinux-policy-targeted-3.0.8-81.fc8 > > [root at haderach data]# semodule -l |grep postgre > sepostgresql 1.158 Can the following command help you? # setsebool -P httpd_can_network_connect_db=1 > On the other hand, when i try to use phpPgAdmin, it works. But i need to > change: /var/lib/pgsql/data/pg_hba.conf from ident sameuser to > md5.(tryed the same for dotclear without sucess). > > Also, from: http://code.google.com/p/sepgsql/wiki/install_memo_Fedora7 > As i'm using F-8, i expect not to need the additional recompiled > selinux-policy-2.6.4-38.sepgsql.fc7.noarch.rpm. (don't know if current > F-7 users will still need it?) - At least the .sepsql doen't fit the > same version number The selinux-policy packages with ".sepgsql" are special care for Fedora 7 users, because selinux-policy-2.x series does not contain the definitions related to database objects (like, db_table, db_column, ...) You don't need to replace it, whenever sepostgresql works on Fedora 8. Thanks, > Any tips for this ? > > > Nicolas (kwizart) > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From sf181257 at students.mimuw.edu.pl Tue Feb 5 15:37:58 2008 From: sf181257 at students.mimuw.edu.pl (=?ISO-8859-2?Q?=22Stanis=B3aw_T=2E_Findeisen=22?=) Date: Tue, 05 Feb 2008 16:37:58 +0100 Subject: semanage segmentation fault? (awstats) Message-ID: <47A882D6.6010708@students.mimuw.edu.pl> Look I tried to intall awstats-6.6-1.fc7.noarch.rpm from Fedora release on Fedora 7 64-bit and got segmentation fault in semanage I think. First I tried this: [root at srv-1 download]# rpm --install ./awstats-6.6-1.fc7.noarch.rpm /var/tmp/rpm-tmp.71040: line 12: 3964 Segmentation fault semanage fcontext -a -t httpd_sys_script_exec_t '/usr/share/awstats/wwwroot/cgi-bin(/.*)?' 2> /dev/null /var/tmp/rpm-tmp.71040: line 13: 3965 Segmentation fault semanage fcontext -a -t httpd_sys_script_rw_t '/var/lib/awstats(/.*)?' 2> /dev/null Then I realised I have HTTP server on, so I thought I will turn it off and try again (on the way I had to erase the RPM because it was considered "installed"). Then this happened: [root at srv-1 download]# rpm --install ./awstats-6.6-1.fc7.noarch.rpm /var/tmp/rpm-tmp.21042: line 12: 3995 Segmentation fault semanage fcontext -a -t httpd_sys_script_exec_t '/usr/share/awstats/wwwroot/cgi-bin(/.*)?' 2> /dev/null /var/tmp/rpm-tmp.21042: line 13: 3996 Segmentation fault semanage fcontext -a -t httpd_sys_script_rw_t '/var/lib/awstats(/.*)?' 2> /dev/null I do not know what /var/tmp/rpm-tmp.* is, but I suppose that is an RPM install script or something which comes with RPM (right?). After these 2 steps the /var/tmp directory was empty so I couldn't examine that file. After that I downloaded awstats-6.7-2.fc7.noarch.rpm from Fedora updates and it installed fine (although I haven't tested it yet). I have also found this in /var/log/messages: Feb 5 15:53:44 srv-1 kernel: semanage[3964]: segfault at 0000000000000000 rip 00002b610d7e9b49 rsp 00007fffa20be6b0 error 4 Feb 5 15:53:44 srv-1 kernel: semanage[3965]: segfault at 0000000000000000 rip 00002b2754535b49 rsp 00007fff5b3744b0 error 4 Feb 5 15:56:33 srv-1 kernel: semanage[3995]: segfault at 0000000000000000 rip 00002b0a226c9b49 rsp 00007fff8d1e0300 error 4 Feb 5 15:56:33 srv-1 kernel: semanage[3996]: segfault at 0000000000000000 rip 00002b0feea21b49 rsp 00007fffc0e86fc0 error 4 What do you think guys? STF From sds at tycho.nsa.gov Tue Feb 5 15:47:13 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 05 Feb 2008 10:47:13 -0500 Subject: semanage segmentation fault? (awstats) In-Reply-To: <47A882D6.6010708@students.mimuw.edu.pl> References: <47A882D6.6010708@students.mimuw.edu.pl> Message-ID: <1202226433.27371.50.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2008-02-05 at 16:37 +0100, "Stanis?aw T. Findeisen" wrote: > Look I tried to intall awstats-6.6-1.fc7.noarch.rpm from Fedora release > on Fedora 7 64-bit and got segmentation fault in semanage I think. > > First I tried this: > > [root at srv-1 download]# rpm --install ./awstats-6.6-1.fc7.noarch.rpm > /var/tmp/rpm-tmp.71040: line 12: 3964 Segmentation fault semanage > fcontext -a -t httpd_sys_script_exec_t > '/usr/share/awstats/wwwroot/cgi-bin(/.*)?' 2> /dev/null > /var/tmp/rpm-tmp.71040: line 13: 3965 Segmentation fault semanage > fcontext -a -t httpd_sys_script_rw_t '/var/lib/awstats(/.*)?' 2> /dev/null > > Then I realised I have HTTP server on, so I thought I will turn it off > and try again (on the way I had to erase the RPM because it was > considered "installed"). > > Then this happened: > > [root at srv-1 download]# rpm --install ./awstats-6.6-1.fc7.noarch.rpm > /var/tmp/rpm-tmp.21042: line 12: 3995 Segmentation fault semanage > fcontext -a -t httpd_sys_script_exec_t > '/usr/share/awstats/wwwroot/cgi-bin(/.*)?' 2> /dev/null > /var/tmp/rpm-tmp.21042: line 13: 3996 Segmentation fault semanage > fcontext -a -t httpd_sys_script_rw_t '/var/lib/awstats(/.*)?' 2> /dev/null > > I do not know what /var/tmp/rpm-tmp.* is, but I suppose that is an RPM > install script or something which comes with RPM (right?). After these 2 > steps the /var/tmp directory was empty so I couldn't examine that file. > > After that I downloaded awstats-6.7-2.fc7.noarch.rpm from Fedora updates > and it installed fine (although I haven't tested it yet). > > I have also found this in /var/log/messages: > > Feb 5 15:53:44 srv-1 kernel: semanage[3964]: segfault at > 0000000000000000 rip 00002b610d7e9b49 rsp 00007fffa20be6b0 error 4 > Feb 5 15:53:44 srv-1 kernel: semanage[3965]: segfault at > 0000000000000000 rip 00002b2754535b49 rsp 00007fff5b3744b0 error 4 > Feb 5 15:56:33 srv-1 kernel: semanage[3995]: segfault at > 0000000000000000 rip 00002b0a226c9b49 rsp 00007fff8d1e0300 error 4 > Feb 5 15:56:33 srv-1 kernel: semanage[3996]: segfault at > 0000000000000000 rip 00002b0feea21b49 rsp 00007fffc0e86fc0 error 4 > > What do you think guys? Bugzilla it, please, against policycoreutils. Please include your versions of libsepol, libsemanage, and policycoreutils. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Tue Feb 5 16:17:00 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 05 Feb 2008 11:17:00 -0500 Subject: semanage segmentation fault? (awstats) In-Reply-To: <1202226433.27371.50.camel@moss-spartans.epoch.ncsc.mil> References: <47A882D6.6010708@students.mimuw.edu.pl> <1202226433.27371.50.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1202228220.27371.59.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2008-02-05 at 10:47 -0500, Stephen Smalley wrote: > On Tue, 2008-02-05 at 16:37 +0100, "Stanis?aw T. Findeisen" wrote: > > Look I tried to intall awstats-6.6-1.fc7.noarch.rpm from Fedora release > > on Fedora 7 64-bit and got segmentation fault in semanage I think. > > > > First I tried this: > > > > [root at srv-1 download]# rpm --install ./awstats-6.6-1.fc7.noarch.rpm > > /var/tmp/rpm-tmp.71040: line 12: 3964 Segmentation fault semanage > > fcontext -a -t httpd_sys_script_exec_t > > '/usr/share/awstats/wwwroot/cgi-bin(/.*)?' 2> /dev/null > > /var/tmp/rpm-tmp.71040: line 13: 3965 Segmentation fault semanage > > fcontext -a -t httpd_sys_script_rw_t '/var/lib/awstats(/.*)?' 2> /dev/null > > > > Then I realised I have HTTP server on, so I thought I will turn it off > > and try again (on the way I had to erase the RPM because it was > > considered "installed"). > > > > Then this happened: > > > > [root at srv-1 download]# rpm --install ./awstats-6.6-1.fc7.noarch.rpm > > /var/tmp/rpm-tmp.21042: line 12: 3995 Segmentation fault semanage > > fcontext -a -t httpd_sys_script_exec_t > > '/usr/share/awstats/wwwroot/cgi-bin(/.*)?' 2> /dev/null > > /var/tmp/rpm-tmp.21042: line 13: 3996 Segmentation fault semanage > > fcontext -a -t httpd_sys_script_rw_t '/var/lib/awstats(/.*)?' 2> /dev/null > > > > I do not know what /var/tmp/rpm-tmp.* is, but I suppose that is an RPM > > install script or something which comes with RPM (right?). After these 2 > > steps the /var/tmp directory was empty so I couldn't examine that file. > > > > After that I downloaded awstats-6.7-2.fc7.noarch.rpm from Fedora updates > > and it installed fine (although I haven't tested it yet). > > > > I have also found this in /var/log/messages: > > > > Feb 5 15:53:44 srv-1 kernel: semanage[3964]: segfault at > > 0000000000000000 rip 00002b610d7e9b49 rsp 00007fffa20be6b0 error 4 > > Feb 5 15:53:44 srv-1 kernel: semanage[3965]: segfault at > > 0000000000000000 rip 00002b2754535b49 rsp 00007fff5b3744b0 error 4 > > Feb 5 15:56:33 srv-1 kernel: semanage[3995]: segfault at > > 0000000000000000 rip 00002b0a226c9b49 rsp 00007fff8d1e0300 error 4 > > Feb 5 15:56:33 srv-1 kernel: semanage[3996]: segfault at > > 0000000000000000 rip 00002b0feea21b49 rsp 00007fffc0e86fc0 error 4 > > > > What do you think guys? > > Bugzilla it, please, against policycoreutils. Please include your > versions of libsepol, libsemanage, and policycoreutils. Also, can you reproduce it by hand now? i.e. running semanage with those arguments from the command line. -- Stephen Smalley National Security Agency From mcepl at redhat.com Tue Feb 5 14:59:38 2008 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 05 Feb 2008 15:59:38 +0100 Subject: SELinux is preventing console-kit-dae(/usr/sbin/console-kit-daemon) (consolekit_t) "execute" to (polkit_auth_exec_t). References: <577808.14961.qm@web52604.mail.re2.yahoo.com> Message-ID: On Wed, 30 Jan 2008 17:04:02 -0800, Antonio Olivares scripst: > Unknown, > > what is happening with console-kit-daemon? This list should really not be used as a replacement for bugzilla. I have searched for this bug in bugzilla, and when I have not found any, I filed a new one -- https://bugzilla.redhat.com/show_bug.cgi?id=431527 Please, keep the stuff in bugzilla. Mat?j -- The content of this message is licensed under a Creative Commons Attribution 3.0 License, Some Rights Reserved. http://creativecommons.org/licenses/by/3.0/us/ From sf181257 at students.mimuw.edu.pl Tue Feb 5 18:50:22 2008 From: sf181257 at students.mimuw.edu.pl (=?UTF-8?B?IlN0YW5pc8WCYXcgVC4gRmluZGVpc2VuIg==?=) Date: Tue, 05 Feb 2008 19:50:22 +0100 Subject: semanage segmentation fault? (awstats) In-Reply-To: <1202228220.27371.59.camel@moss-spartans.epoch.ncsc.mil> References: <47A882D6.6010708@students.mimuw.edu.pl> <1202226433.27371.50.camel@moss-spartans.epoch.ncsc.mil> <1202228220.27371.59.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <47A8AFEE.5040501@students.mimuw.edu.pl> Stephen Smalley wrote: > On Tue, 2008-02-05 at 10:47 -0500, Stephen Smalley wrote: >> On Tue, 2008-02-05 at 16:37 +0100, "Stanis?aw T. Findeisen" wrote: >>> Look I tried to intall awstats-6.6-1.fc7.noarch.rpm from Fedora release >>> on Fedora 7 64-bit and got segmentation fault in semanage I think. >>> >>> First I tried this: >>> >>> [root at srv-1 download]# rpm --install ./awstats-6.6-1.fc7.noarch.rpm >>> /var/tmp/rpm-tmp.71040: line 12: 3964 Segmentation fault semanage >>> fcontext -a -t httpd_sys_script_exec_t >>> '/usr/share/awstats/wwwroot/cgi-bin(/.*)?' 2> /dev/null >>> /var/tmp/rpm-tmp.71040: line 13: 3965 Segmentation fault semanage >>> fcontext -a -t httpd_sys_script_rw_t '/var/lib/awstats(/.*)?' 2> /dev/null >>> >>> Then I realised I have HTTP server on, so I thought I will turn it off >>> and try again (on the way I had to erase the RPM because it was >>> considered "installed"). >>> >>> Then this happened: >>> >>> [root at srv-1 download]# rpm --install ./awstats-6.6-1.fc7.noarch.rpm >>> /var/tmp/rpm-tmp.21042: line 12: 3995 Segmentation fault semanage >>> fcontext -a -t httpd_sys_script_exec_t >>> '/usr/share/awstats/wwwroot/cgi-bin(/.*)?' 2> /dev/null >>> /var/tmp/rpm-tmp.21042: line 13: 3996 Segmentation fault semanage >>> fcontext -a -t httpd_sys_script_rw_t '/var/lib/awstats(/.*)?' 2> /dev/null >>> >>> I do not know what /var/tmp/rpm-tmp.* is, but I suppose that is an RPM >>> install script or something which comes with RPM (right?). After these 2 >>> steps the /var/tmp directory was empty so I couldn't examine that file. >>> >>> After that I downloaded awstats-6.7-2.fc7.noarch.rpm from Fedora updates >>> and it installed fine (although I haven't tested it yet). >>> >>> I have also found this in /var/log/messages: >>> >>> Feb 5 15:53:44 srv-1 kernel: semanage[3964]: segfault at >>> 0000000000000000 rip 00002b610d7e9b49 rsp 00007fffa20be6b0 error 4 >>> Feb 5 15:53:44 srv-1 kernel: semanage[3965]: segfault at >>> 0000000000000000 rip 00002b2754535b49 rsp 00007fff5b3744b0 error 4 >>> Feb 5 15:56:33 srv-1 kernel: semanage[3995]: segfault at >>> 0000000000000000 rip 00002b0a226c9b49 rsp 00007fff8d1e0300 error 4 >>> Feb 5 15:56:33 srv-1 kernel: semanage[3996]: segfault at >>> 0000000000000000 rip 00002b0feea21b49 rsp 00007fffc0e86fc0 error 4 >>> >>> What do you think guys? >> Bugzilla it, please, against policycoreutils. Please include your >> versions of libsepol, libsemanage, and policycoreutils. > > Also, can you reproduce it by hand now? i.e. running semanage with > those arguments from the command line. Yes I can reproduce. This is what I run: semanage fcontext -a -t httpd_sys_script_exec_t '/usr/share/awstats/wwwroot/cgi-bin(/.*)?' Segmentation fault Feb 5 19:30:06 srv-1 kernel: semanage[2836]: segfault at 0000000000000000 rip 00002ba8f9fefb49 rsp 00007fffb58ba980 error 4 semanage fcontext -a -t httpd_sys_script_rw_t '/var/lib/awstats(/.*)?' Segmentation fault Feb 5 19:30:45 srv-1 kernel: semanage[2838]: segfault at 0000000000000000 rip 00002b66d32a8b49 rsp 00007fffdc5ff6e0 error 4 (The files are no longer there because I uninstalled awstats.) I can bugzilla it if you tell me where. And also how to check for those versions. Here is what I have: [stf at srv-1 ~]$ rpm -q -a | grep libsepol libsepol-devel-2.0.3-1.fc7 libsepol-2.0.3-1.fc7 libsepol-2.0.3-1.fc7 [stf at srv-1 ~]$ rpm -q -a --dump | grep libsepol /usr/lib64/libsepol.a 487254 1176813464 b093586e8172ed44b69555782eadfcd9 0100644 root root 0 0 0 X /usr/lib64/libsepol.so 25 1176813462 00000000000000000000000000000000 0120777 root root 0 0 0 ../../lib64/libsepol.so.1 /lib/libsepol.so.1 243928 1176813453 2dbc5ff32dac7e221bc45d9a345fe032 0100755 root root 0 0 0 X /lib64/libsepol.so.1 245264 1176813464 7fdfb902cee69191bc8cfd5de592b997 0100755 root root 0 0 0 X [stf at srv-1 ~]$ rpm -q -a | grep libsemanage libsemanage-2.0.1-2.fc7 [stf at srv-1 ~]$ rpm -q -a --dump | grep libsemanage /lib64/libsemanage.so.1 162376 1175025388 324af737c9e7cdc2ea6f0c800d1c2592 0100755 root root 0 0 0 X /usr/lib64/libsemanage.so 28 1175025376 00000000000000000000000000000000 0120777 root root 0 0 0 ../../lib64/libsemanage.so.1 [stf at srv-1 ~]$ rpm -q -a | grep policycoreutil policycoreutils-2.0.16-2.fc7 policycoreutils-gui-2.0.16-2.fc7 [stf at srv-1 ~]$ rpm -q --dump policycoreutils-2.0.16-2.fc7 /etc/pam.d/newrole 172 1179424355 f4a2547443ac34fb30b7d06719328570 0100644 root root 1 0 0 X /etc/pam.d/run_init 167 1179424355 ed90090331f922df29f123df2c59fd07 0100644 root root 1 0 0 X /etc/rc.d/init.d/restorecond 1793 1179424355 14c3e892eb2e3fa3be652e7f5d01a101 0100755 root root 0 0 0 X /etc/selinux/restorecond.conf 129 1179424355 50723af126ab5125ba3dbcf6a0f404c3 0100600 root root 1 0 0 X /etc/sestatus.conf 216 1179424355 8f42efd9d1efe717f27267e6a4286453 0100644 root root 1 0 0 X /sbin/fixfiles 6117 1179424355 89f4929d84d902326a1f87d8a4eaf43f 0100755 root root 0 0 0 X /sbin/restorecon 14688 1179424364 dfd69b4b2badbaadacf73603d5a88e70 0100755 root root 0 0 0 X /sbin/setfiles 18880 1179424364 613f2612e03b499001c7414c996f80fd 0100755 root root 0 0 0 X /usr/bin/audit2allow 9741 1179424355 cfd3ffd61d97a471c1b0ca748a81894b 0100755 root root 0 0 0 X /usr/bin/audit2why 166600 1179424364 5fb5ce264fac766a7002ecefacafa3bb 0100755 root root 0 0 0 X /usr/bin/chcat 13380 1179424355 57f143090f6cfed53031cb4980c1ef8e 0100755 root root 0 0 0 X /usr/bin/secon 22872 1179424364 d2819a5288c4e85d1c723ff7b0f4d7f3 0100755 root root 0 0 0 X /usr/bin/semodule_deps 191072 1179424364 d09c1aaa7798de943a538a64f765c668 0100755 root root 0 0 0 X /usr/bin/semodule_expand 10480 1179424364 f690819c6aa076725de6e3dc0d61aead 0100755 root root 0 0 0 X /usr/bin/semodule_link 10440 1179424364 54c2167e2055a46ca7c80af878e47f29 0100755 root root 0 0 0 X /usr/bin/semodule_package 14896 1179424364 c8765f8b78a128ab8fa63b870482b6ac 0100755 root root 0 0 0 X /usr/lib64/python2.5/site-packages/seobject.py 41562 1179424355 37434cf99914b882eddb10835f530807 0100755 root root 0 0 0 X /usr/lib64/python2.5/site-packages/seobject.pyc 44871 1179424364 68df49f338e61cee1e80bcd7a6267383 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/seobject.pyo 44871 1179424364 68df49f338e61cee1e80bcd7a6267383 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen 4096 1179424364 00000000000000000000000000000000 040755 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/__init__.py 0 1179424356 d41d8cd98f00b204e9800998ecf8427e 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/__init__.pyc 142 1179424364 a3814066c9659555d1e1acccd02e0709 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/__init__.pyo 142 1179424364 a3814066c9659555d1e1acccd02e0709 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/access.py 10486 1179424356 f13ccc9d9cdaf90ded1fffd91a555ac3 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/access.pyc 11114 1179424364 332ff6b9cbfc383187e7001d725e827b 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/access.pyo 11114 1179424364 332ff6b9cbfc383187e7001d725e827b 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/audit.py 16577 1179424356 d684d0c04cdcb564102587c53f9fe0cc 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/audit.pyc 16150 1179424364 c2413f05d5885e176ed30362a766c6e7 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/audit.pyo 16150 1179424364 c2413f05d5885e176ed30362a766c6e7 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/classperms.py 2801 1179424356 83fed846c9f1b94a6164af2378d6f82c 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/classperms.pyc 3202 1179424364 c8b5f3430b56ba2ba51bef4bb53df478 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/classperms.pyo 3202 1179424364 c8b5f3430b56ba2ba51bef4bb53df478 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/defaults.py 1222 1179424356 960b10c032a8a0f59b5748a60bcb127d 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/defaults.pyc 1326 1179424364 59cd68c51f51ab552e23ac370a051a34 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/defaults.pyo 1326 1179424364 59cd68c51f51ab552e23ac370a051a34 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/interfaces.py 14636 1179424356 f7414489bd3185263618f8f7a5bccc5c 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/interfaces.pyc 13746 1179424364 dc18a1ff631665f7f47984ec2c58c64f 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/interfaces.pyo 13746 1179424364 dc18a1ff631665f7f47984ec2c58c64f 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/lex.py 33586 1179424356 52198d247a2748e079a3d5651d61220e 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/lex.pyc 20098 1179424364 1ee0e47f4a83a469289cff6cf26896a8 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/lex.pyo 20098 1179424364 1ee0e47f4a83a469289cff6cf26896a8 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/matching.py 8559 1179424356 73ed249c60788cda3ef9d1e2c18bfb8d 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/matching.pyc 7456 1179424364 e5e3e26ac97a87a7cf688504530ce430 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/matching.pyo 7456 1179424364 e5e3e26ac97a87a7cf688504530ce430 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/module.py 7188 1179424356 7bda095cd5ab1f3aaa231ffdaf98485c 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/module.pyc 8532 1179424364 eeb52470d35378d4c282cfea805aacca 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/module.pyo 8532 1179424364 eeb52470d35378d4c282cfea805aacca 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/objectmodel.py 6524 1179424356 7e38c999bb77eb36bdf7af73d1a955ef 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/objectmodel.pyc 4809 1179424364 541bc378d96641799dbd366d58e8a5ba 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/objectmodel.pyo 4809 1179424364 541bc378d96641799dbd366d58e8a5ba 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/output.py 4690 1179424356 10a110c7a12c17187b61781f2653ecf3 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/output.pyc 4157 1179424364 8d4a453561d883b4fec2fbfc74f7f8d8 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/output.pyo 4157 1179424364 8d4a453561d883b4fec2fbfc74f7f8d8 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/policygen.py 11788 1179424356 80a397c5729c2faaa7c4728ca571065c 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/policygen.pyc 11549 1179424364 136eb443aff4d110d2c17acbd7365b12 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/policygen.pyo 11480 1179424364 4ff5f94249b3beaf04019e6697be878e 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/refparser.py 20740 1179424356 3a4f2e538132970b6ffe8749c606d5bb 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/refparser.pyc 24596 1179424364 0e18846491b74f1063588191a4910abb 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/refparser.pyo 24596 1179424364 0e18846491b74f1063588191a4910abb 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/refpolicy.py 22034 1179424356 09ae941281115922e9cd730d31b8a228 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/refpolicy.pyc 34740 1179424364 8cb48b8be765f5671e753457093b225c 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/refpolicy.pyo 34740 1179424364 8cb48b8be765f5671e753457093b225c 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/sepolgeni18n.py 912 1179424356 4556cd475f84671a697ad001cf78045c 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/sepolgeni18n.pyc 410 1179424364 d58cb047e57c14e3b9ac9bbe94d3d850 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/sepolgeni18n.pyo 410 1179424364 d58cb047e57c14e3b9ac9bbe94d3d850 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/util.py 2573 1179424356 c1eaf8c2aaba1919ae96a6ab88cc56ae 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/util.pyc 2727 1179424364 ed52569f1b0f5d4f0680e1594cb1dc53 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/util.pyo 2727 1179424364 ed52569f1b0f5d4f0680e1594cb1dc53 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/yacc.py 82064 1179424356 40486013e3b276767924708159ee01c7 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/yacc.pyc 43207 1179424364 6fb4c4645ef81f8b1b40e5c8b886b719 0100644 root root 0 0 0 X /usr/lib64/python2.5/site-packages/sepolgen/yacc.pyo 43207 1179424364 6fb4c4645ef81f8b1b40e5c8b886b719 0100644 root root 0 0 0 X /usr/sbin/genhomedircon 11573 1179424355 b4126259b4157f965e64b68a165a8494 0100755 root root 0 0 0 X /usr/sbin/load_policy 10360 1179424364 9eeb5e260398b5be18da571cae2ede02 0100755 root root 0 0 0 X /usr/sbin/open_init_pty 10448 1179424358 feec8e9ef703b00b36e5fb6d8567193a 0100555 root root 0 0 0 X /usr/sbin/restorecond 14760 1179424364 ce87e9431790b3641c3e843d33b7884c 0100755 root root 0 0 0 X /usr/sbin/run_init 10488 1179424358 dbca91f988ec480747af018181fcabed 0100555 root root 0 0 0 X /usr/sbin/semanage 8406 1179424355 67b2a699fbe69a698ed07029cacd3eb6 0100755 root root 0 0 0 X /usr/sbin/semodule 15080 1179424364 74fef3e09bbedf379f264a52a9e2de7b 0100755 root root 0 0 0 X /usr/sbin/sepolgen-ifgen 2735 1179424355 572178f7e8188bc735a9ab392aac6a9d 0100755 root root 0 0 0 X /usr/sbin/sestatus 14720 1179424364 a947ec566866129a0b3774f1e791b613 0100755 root root 0 0 0 X /usr/sbin/setsebool 14632 1179424364 f96c3a3e0b4c8bea8da21899db39f6f9 0100755 root root 0 0 0 X /usr/share/locale/af/LC_MESSAGES/policycoreutils.mo 367 1179424355 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/am/LC_MESSAGES/policycoreutils.mo 367 1179424355 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/ar/LC_MESSAGES/policycoreutils.mo 367 1179424355 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/as/LC_MESSAGES/policycoreutils.mo 388 1179424355 86b5b92d12b1ede5236eee8e2b893078 0100644 root root 0 0 0 X /usr/share/locale/be/LC_MESSAGES/policycoreutils.mo 367 1179424355 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/bg/LC_MESSAGES/policycoreutils.mo 25951 1179424355 72032e75767c05738090f134e63b723a 0100644 root root 0 0 0 X /usr/share/locale/bn/LC_MESSAGES/policycoreutils.mo 367 1179424355 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/bn_IN/LC_MESSAGES/policycoreutils.mo 31745 1179424355 2d79f5bcf57140b91e9672108048a914 0100644 root root 0 0 0 X /usr/share/locale/bs/LC_MESSAGES/policycoreutils.mo 20260 1179424355 e32412f800b274a06d09b3af34290bae 0100644 root root 0 0 0 X /usr/share/locale/ca/LC_MESSAGES/policycoreutils.mo 20798 1179424355 894304df574bf1a0398c4ddc5b59713d 0100644 root root 0 0 0 X /usr/share/locale/cs/LC_MESSAGES/policycoreutils.mo 367 1179424355 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/cy/LC_MESSAGES/policycoreutils.mo 367 1179424355 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/da/LC_MESSAGES/policycoreutils.mo 19152 1179424355 31539e9c4337d4ce9af5965e23ca822c 0100644 root root 0 0 0 X /usr/share/locale/de/LC_MESSAGES/policycoreutils.mo 20363 1179424355 107bc472a9e4c2f1b29d34a315302939 0100644 root root 0 0 0 X /usr/share/locale/el/LC_MESSAGES/policycoreutils.mo 900 1179424355 7ed6a267e1cbe50ce6a30af632fd8e1c 0100644 root root 0 0 0 X /usr/share/locale/en_GB/LC_MESSAGES/policycoreutils.mo 367 1179424355 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/es/LC_MESSAGES/policycoreutils.mo 19822 1179424355 4f8bdda8247a5aab916e7d22245c2593 0100644 root root 0 0 0 X /usr/share/locale/eu_ES/LC_MESSAGES/policycoreutils.mo 367 1179424355 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/fa/LC_MESSAGES/policycoreutils.mo 367 1179424355 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/fi/LC_MESSAGES/policycoreutils.mo 367 1179424355 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/fr/LC_MESSAGES/policycoreutils.mo 20716 1179424355 11d33722d12f8847c9369d96b76b0fd2 0100644 root root 0 0 0 X /usr/share/locale/gu/LC_MESSAGES/policycoreutils.mo 30161 1179424355 7905d54d4e3451ed951ac8501da9ffad 0100644 root root 0 0 0 X /usr/share/locale/he/LC_MESSAGES/policycoreutils.mo 367 1179424355 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/hi/LC_MESSAGES/policycoreutils.mo 28497 1179424355 f742df497b6cfca7777ddf01014836dc 0100644 root root 0 0 0 X /usr/share/locale/hr/LC_MESSAGES/policycoreutils.mo 20295 1179424355 0f634c19c331a53a410acca07b336736 0100644 root root 0 0 0 X /usr/share/locale/hu/LC_MESSAGES/policycoreutils.mo 21433 1179424355 2d573b1d1ac74e5b38c04d9c31e7a0d7 0100644 root root 0 0 0 X /usr/share/locale/hy/LC_MESSAGES/policycoreutils.mo 367 1179424355 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/is/LC_MESSAGES/policycoreutils.mo 367 1179424355 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/it/LC_MESSAGES/policycoreutils.mo 19914 1179424355 7391317a8cc9f2e5ac977bde1e121af6 0100644 root root 0 0 0 X /usr/share/locale/ja/LC_MESSAGES/policycoreutils.mo 23614 1179424355 4db507a33867fa92cc3b99e815832a66 0100644 root root 0 0 0 X /usr/share/locale/ka/LC_MESSAGES/policycoreutils.mo 367 1179424355 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/kn/LC_MESSAGES/policycoreutils.mo 367 1179424355 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/ko/LC_MESSAGES/policycoreutils.mo 22228 1179424355 8e89e5425060b68148e58c055bcf17b8 0100644 root root 0 0 0 X /usr/share/locale/ku/LC_MESSAGES/policycoreutils.mo 367 1179424355 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/lo/LC_MESSAGES/policycoreutils.mo 367 1179424355 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/lt/LC_MESSAGES/policycoreutils.mo 367 1179424356 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/lv/LC_MESSAGES/policycoreutils.mo 367 1179424356 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/mk/LC_MESSAGES/policycoreutils.mo 367 1179424356 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/ml/LC_MESSAGES/policycoreutils.mo 34812 1179424356 bc2caeff61257ac3c2ca1cbb6d599e2d 0100644 root root 0 0 0 X /usr/share/locale/mr/LC_MESSAGES/policycoreutils.mo 29016 1179424356 4dac8804ab7acacfcc613586d43404ca 0100644 root root 0 0 0 X /usr/share/locale/ms/LC_MESSAGES/policycoreutils.mo 5540 1179424356 3a00dbc4355b456c0ae077b6156f76ad 0100644 root root 0 0 0 X /usr/share/locale/my/LC_MESSAGES/policycoreutils.mo 367 1179424356 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/nb/LC_MESSAGES/policycoreutils.mo 401 1179424356 fff6ba224a9fc1cbc02075b54aeef3d1 0100644 root root 0 0 0 X /usr/share/locale/nl/LC_MESSAGES/policycoreutils.mo 19769 1179424356 481e86373446139210fd81b99acf42fd 0100644 root root 0 0 0 X /usr/share/locale/nn/LC_MESSAGES/policycoreutils.mo 367 1179424356 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/no/LC_MESSAGES/policycoreutils.mo 367 1179424356 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/nso/LC_MESSAGES/policycoreutils.mo 367 1179424356 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/or/LC_MESSAGES/policycoreutils.mo 34146 1179424356 de7ac6ce021c618549ad801cde13b932 0100644 root root 0 0 0 X /usr/share/locale/pa/LC_MESSAGES/policycoreutils.mo 1658 1179424356 ff38a65fd96c20a3b8508c53bc0600d7 0100644 root root 0 0 0 X /usr/share/locale/pl/LC_MESSAGES/policycoreutils.mo 20565 1179424356 cc8fa20c2cf51343cc0be516c6059056 0100644 root root 0 0 0 X /usr/share/locale/pt/LC_MESSAGES/policycoreutils.mo 21555 1179424356 d94f1e3d2a7ba25ae09c870863da92aa 0100644 root root 0 0 0 X /usr/share/locale/pt_BR/LC_MESSAGES/policycoreutils.mo 19722 1179424356 998166381d0d5c2e7f03efabc179eadf 0100644 root root 0 0 0 X /usr/share/locale/ro/LC_MESSAGES/policycoreutils.mo 367 1179424356 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/ru/LC_MESSAGES/policycoreutils.mo 25734 1179424356 719084bd43e8a450361198a19c8f3ebe 0100644 root root 0 0 0 X /usr/share/locale/si/LC_MESSAGES/policycoreutils.mo 367 1179424356 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/sk/LC_MESSAGES/policycoreutils.mo 19524 1179424356 2a0aa0e092be69a8b8e63c3818b6b49c 0100644 root root 0 0 0 X /usr/share/locale/sl/LC_MESSAGES/policycoreutils.mo 367 1179424356 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/sq/LC_MESSAGES/policycoreutils.mo 367 1179424356 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/sr/LC_MESSAGES/policycoreutils.mo 24819 1179424356 b179e37b507e04b7fbd98a42be7337fe 0100644 root root 0 0 0 X /usr/share/locale/sr at Latn/LC_MESSAGES/policycoreutils.mo 19476 1179424356 2b3c3c972f98623e24e3d1aae39122e4 0100644 root root 0 0 0 X /usr/share/locale/sv/LC_MESSAGES/policycoreutils.mo 19392 1179424356 a55ea16c8f43e705ff48b20707a640ad 0100644 root root 0 0 0 X /usr/share/locale/ta/LC_MESSAGES/policycoreutils.mo 31828 1179424356 38401ac9f6facb4f75b24e8792c048bc 0100644 root root 0 0 0 X /usr/share/locale/te/LC_MESSAGES/policycoreutils.mo 367 1179424356 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/th/LC_MESSAGES/policycoreutils.mo 367 1179424356 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/tr/LC_MESSAGES/policycoreutils.mo 367 1179424356 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/uk/LC_MESSAGES/policycoreutils.mo 25798 1179424356 dc0d024166fd3a953c6bec52ba47fff6 0100644 root root 0 0 0 X /usr/share/locale/ur/LC_MESSAGES/policycoreutils.mo 367 1179424356 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/vi/LC_MESSAGES/policycoreutils.mo 367 1179424356 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/locale/zh_CN/LC_MESSAGES/policycoreutils.mo 18102 1179424356 09731e548ffa383313920d5c5cd45b94 0100644 root root 0 0 0 X /usr/share/locale/zh_TW/LC_MESSAGES/policycoreutils.mo 18093 1179424356 38077974276f43387494340202f264b6 0100644 root root 0 0 0 X /usr/share/locale/zu/LC_MESSAGES/policycoreutils.mo 367 1179424356 43ae104d3ad1981c07ba36150e6deb17 0100644 root root 0 0 0 X /usr/share/man/man1/audit2allow.1.gz 2485 1179424355 be1dce544c4ace573ee4292047036af7 0100644 root root 0 1 0 X /usr/share/man/man1/secon.1.gz 949 1179424355 fddc86a3f8c3ff9b507b8b44b2b50905 0100644 root root 0 1 0 X /usr/share/man/man8/audit2why.8.gz 1692 1179424355 0e15601d053cb5b347b4b187e7ebb9da 0100644 root root 0 1 0 X /usr/share/man/man8/chcat.8.gz 587 1179424355 cfb7157f7e75ac18787d39916dbcf115 0100644 root root 0 1 0 X /usr/share/man/man8/fixfiles.8.gz 1049 1179424355 7a05775be113d689e86a5d85a93de6a8 0100644 root root 0 1 0 X /usr/share/man/man8/genhomedircon.8.gz 1504 1179424355 0e5b9c28fae637290fedfebf910b16f0 0100644 root root 0 1 0 X /usr/share/man/man8/load_policy.8.gz 408 1179424355 0dbf9e25088b09363228e037eca4fda6 0100644 root root 0 1 0 X /usr/share/man/man8/open_init_pty.8.gz 1056 1179424355 9143813ae0d9a2d04b290d1b13196a03 0100644 root root 0 1 0 X /usr/share/man/man8/restorecon.8.gz 864 1179424355 54d9aba6a8f2237d7576e454edfe09e4 0100644 root root 0 1 0 X /usr/share/man/man8/restorecond.8.gz 470 1179424355 919e3cab46ba0804912553b8f7c432cc 0100644 root root 0 1 0 X /usr/share/man/man8/run_init.8.gz 408 1179424355 86c6e79dbb7dddb414838286f048681b 0100644 root root 0 1 0 X /usr/share/man/man8/semanage.8.gz 1445 1179424355 2803f828a80000396781cbb95f1569f4 0100644 root root 0 1 0 X /usr/share/man/man8/semodule.8.gz 937 1179424355 b1187d15d0f5f913981995dc0df6dd8e 0100644 root root 0 1 0 X /usr/share/man/man8/semodule_deps.8.gz 750 1179424355 06aa9a11e27dce6ae0986229090f396d 0100644 root root 0 1 0 X /usr/share/man/man8/semodule_expand.8.gz 574 1179424355 c6f50dbad24bcf415cfb81004a507481 0100644 root root 0 1 0 X /usr/share/man/man8/semodule_link.8.gz 543 1179424355 fecf112643a873f1a18178e6724c63b2 0100644 root root 0 1 0 X /usr/share/man/man8/semodule_package.8.gz 688 1179424355 3d66c920f966a28edfddd157f2d97d72 0100644 root root 0 1 0 X /usr/share/man/man8/sestatus.8.gz 574 1179424355 4485d41d308fadbe893f677341bcd6fb 0100644 root root 0 1 0 X /usr/share/man/man8/setfiles.8.gz 1285 1179424355 8569fceb01aaa87e253151f185f9a9af 0100644 root root 0 1 0 X /usr/share/man/man8/setsebool.8.gz 508 1179424355 9b97e2a23434630c29ae0dbdcf91f857 0100644 root root 0 1 0 X /var/lib/sepolgen 4096 1179424356 00000000000000000000000000000000 040755 root root 0 0 0 X /var/lib/sepolgen/perm_map 33647 1179424356 cf41a3a25d94a8a50c009a6aa0505534 0100644 root root 0 0 0 X STF From sds at tycho.nsa.gov Tue Feb 5 19:11:14 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 05 Feb 2008 14:11:14 -0500 Subject: semanage segmentation fault? (awstats) In-Reply-To: <47A8AFEE.5040501@students.mimuw.edu.pl> References: <47A882D6.6010708@students.mimuw.edu.pl> <1202226433.27371.50.camel@moss-spartans.epoch.ncsc.mil> <1202228220.27371.59.camel@moss-spartans.epoch.ncsc.mil> <47A8AFEE.5040501@students.mimuw.edu.pl> Message-ID: <1202238674.27371.89.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2008-02-05 at 19:50 +0100, "Stanis?aw T. Findeisen" wrote: > Yes I can reproduce. This is what I run: > > semanage fcontext -a -t httpd_sys_script_exec_t > '/usr/share/awstats/wwwroot/cgi-bin(/.*)?' > Segmentation fault > Feb 5 19:30:06 srv-1 kernel: semanage[2836]: segfault at > 0000000000000000 rip 00002ba8f9fefb49 rsp 00007fffb58ba980 error 4 > > semanage fcontext -a -t httpd_sys_script_rw_t '/var/lib/awstats(/.*)?' > Segmentation fault > Feb 5 19:30:45 srv-1 kernel: semanage[2838]: segfault at > 0000000000000000 rip 00002b66d32a8b49 rsp 00007fffdc5ff6e0 error 4 > > (The files are no longer there because I uninstalled awstats.) > > I can bugzilla it if you tell me where. And also how to check for those > versions. Here is what I have: Just bugzilla.redhat.com, for Fedora 7, and with the rpm -q output you listed for libsepol, libsemanage, and policycoreutils (and verify that rpm -V libsepol libsemanage libselinux policycoreutils is clean). -- Stephen Smalley National Security Agency From kwizart at gmail.com Tue Feb 5 21:04:43 2008 From: kwizart at gmail.com (KH KH) Date: Tue, 5 Feb 2008 22:04:43 +0100 Subject: postgresql with httpd and dotclear In-Reply-To: <47A8788E.7020700@ak.jp.nec.com> References: <47A86C85.7090000@gmail.com> <47A8788E.7020700@ak.jp.nec.com> Message-ID: 2008/2/5, KaiGai Kohei : > Nicolas Chauvet wrote: > > Hello ! > > > > I try to use apache and postgresql with the dotclear blog engine. > > When I try to enter the database information from the admin config > > wizard within the browser, have a selinux denial : > > > > audit(1202182131.382:34): avc: denied { name_connect } for pid=2604 > > comm="httpd" dest=5432 scontext=system_u:system_r:httpd_t:s0 > > tcontext=system_u:object_r:postgresql_port_t:s0 tclass=tcp_socket > > > > [root at haderach ~]# ls -Z /home/www/ > > drwxr-xr-x root root system_u:object_r:httpd_sys_content_t:s0 dotclear > > > > [root at haderach ~]# rpm -q sepostgresql > > sepostgresql-8.2.6-1.158.fc8 > > selinux-policy-3.0.8-81.fc8 > > selinux-policy-targeted-3.0.8-81.fc8 > > > > [root at haderach data]# semodule -l |grep postgre > > sepostgresql 1.158 > > Can the following command help you? > > # setsebool -P httpd_can_network_connect_db=1 > I does: the error disappeared, but i have another: from /var/log/sepostgresql.log FATAL: sepgsql_system_getpeercon(734): 'user_u:user_r:user_t' is not a valid context I have also noticed an error in the same log file: LOG: could not open directory "/usr/share/sepgsql/timezone": File or directory doens't exist Where i've made a ln -s timezoneset /usr/share/sepgsql/timezone. About phpPgAdmin: now i can connect but i have this all the time: -------------- ERROR: SELinux: denied { set_param } scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:sepgsql_db_t:s0 tclass=db_database name=dotclear STATEMENT: set datestyle='ISO' -------------- Seems related to the command used to set the passwd ?! psql -d dotclear -c "alter user dotclear with password 'my_passwd'" I have used that previously from a wiki, without noticing well what means templates1: psql -d template1 -c "alter user dotclear with password 'my_passwd'" and the same error sometimes appears with template1 instead of dotclear > > On the other hand, when i try to use phpPgAdmin, it works. But i need to > > change: /var/lib/pgsql/data/pg_hba.conf from ident sameuser to > > md5.(tryed the same for dotclear without sucess). Was /var/lib/sepgsql/data/pg_hba.conf from the above From paul at city-fan.org Tue Feb 5 23:28:24 2008 From: paul at city-fan.org (Paul Howarth) Date: Tue, 5 Feb 2008 23:28:24 +0000 Subject: Fedora 8 odds and sods In-Reply-To: <478F95A5.3080305@redhat.com> References: <478E34CF.5000503@city-fan.org> <478F95A5.3080305@redhat.com> Message-ID: <20080205232824.0f6b4a64@metropolis.intra.city-fan.org> On Thu, 17 Jan 2008 12:51:33 -0500 Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Paul Howarth wrote: > > 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) > > > Already added. > > # 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; > > > Added. > > # 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 }; > > > Added Policy now has procmail_read_tmp_files(sendmail_t) but this doesn't allow write access by sendmail. Sendmail needs to write into procmail_tmp_t when a procmail recipe pipes a message into a filter and that filter creates a temp file I believe. I'm getting the AVCs anyway: type=AVC msg=audit(1202162399.034:320138): avc: denied { write } for pid=16452 comm="sendmail" path="/tmp/choplist.16383" dev=dm-1 ino=13 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:procmail_tmp_t:s0 tclass=file type=SYSCALL msg=audit(1202162399.034:320138): arch=40000003 syscall=11 success=yes exit=0 a0=bf8febff a1=84ffe44 a2=bf8fe3a4 a3=84ffe44 items=0 ppid=16384 pid=16452 auid=0 uid=502 gid=502 euid=502 suid=502 fsuid=502 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) type=AVC msg=audit(1202162401.083:320139): avc: denied { write } for pid=16453 comm="sendmail" path=2F746D702F63686F706C6973742E3136333833202864656C6574656429 dev=dm-1 ino=13 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:procmail_tmp_t:s0 tclass=file Paul. From sf181257 at students.mimuw.edu.pl Wed Feb 6 00:47:13 2008 From: sf181257 at students.mimuw.edu.pl (=?UTF-8?B?IlN0YW5pc8WCYXcgVC4gRmluZGVpc2VuIg==?=) Date: Wed, 06 Feb 2008 01:47:13 +0100 Subject: semanage segmentation fault? (awstats) In-Reply-To: <1202238674.27371.89.camel@moss-spartans.epoch.ncsc.mil> References: <47A882D6.6010708@students.mimuw.edu.pl> <1202226433.27371.50.camel@moss-spartans.epoch.ncsc.mil> <1202228220.27371.59.camel@moss-spartans.epoch.ncsc.mil> <47A8AFEE.5040501@students.mimuw.edu.pl> <1202238674.27371.89.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <47A90391.4070502@students.mimuw.edu.pl> Stephen Smalley wrote: > Just bugzilla.redhat.com, for Fedora 7, and with the rpm -q output you > listed for libsepol, libsemanage, and policycoreutils (and verify that > rpm -V libsepol libsemanage libselinux policycoreutils is clean). Done, Sir. https://bugzilla.redhat.com/show_bug.cgi?id=431627 --- please verify it. STF From kaigai at ak.jp.nec.com Wed Feb 6 01:02:03 2008 From: kaigai at ak.jp.nec.com (Kohei KaiGai) Date: Wed, 06 Feb 2008 10:02:03 +0900 Subject: postgresql with httpd and dotclear In-Reply-To: References: <47A86C85.7090000@gmail.com> <47A8788E.7020700@ak.jp.nec.com> Message-ID: <47A9070B.6020508@ak.jp.nec.com> KH KH wrote: > 2008/2/5, KaiGai Kohei : >> Nicolas Chauvet wrote: >>> Hello ! >>> >>> I try to use apache and postgresql with the dotclear blog engine. >>> When I try to enter the database information from the admin config >>> wizard within the browser, have a selinux denial : >>> >>> audit(1202182131.382:34): avc: denied { name_connect } for pid=2604 >>> comm="httpd" dest=5432 scontext=system_u:system_r:httpd_t:s0 >>> tcontext=system_u:object_r:postgresql_port_t:s0 tclass=tcp_socket >>> >>> [root at haderach ~]# ls -Z /home/www/ >>> drwxr-xr-x root root system_u:object_r:httpd_sys_content_t:s0 dotclear >>> >>> [root at haderach ~]# rpm -q sepostgresql >>> sepostgresql-8.2.6-1.158.fc8 >>> selinux-policy-3.0.8-81.fc8 >>> selinux-policy-targeted-3.0.8-81.fc8 >>> >>> [root at haderach data]# semodule -l |grep postgre >>> sepostgresql 1.158 >> Can the following command help you? >> >> # setsebool -P httpd_can_network_connect_db=1 >> > I does: the error disappeared, but i have another: > from /var/log/sepostgresql.log > FATAL: sepgsql_system_getpeercon(734): 'user_u:user_r:user_t' is not > a valid context I guess you try to connect SE-PostgreSQL runnung on another host without any labeled networking configuration. SE-PostgreSQL tries to apply fallbacked security context when it cannot obtain peer's context. The 'user_u:user_r:user_t' is default fallbacked context. Please confirm whether mcstransd is running, or not. If not running, please start it. > I have also noticed an error in the same log file: > LOG: could not open directory "/usr/share/sepgsql/timezone": File or > directory doens't exist > Where i've made a ln -s timezoneset /usr/share/sepgsql/timezone. It seems to me packageing error. I'll fix soon. > About phpPgAdmin: now i can connect but i have this all the time: > -------------- > ERROR: SELinux: denied { set_param } > scontext=system_u:system_r:httpd_t:s0 > tcontext=system_u:object_r:sepgsql_db_t:s0 tclass=db_database > name=dotclear > STATEMENT: set datestyle='ISO' > -------------- The default security policy for SE-PostgreSQL does not allow to execute "SET ..." statement by non-administratvie users. However, it might not be a appropriate policy. I'll update this part of policy on the next update. please wait for some days. > Seems related to the command used to set the passwd ?! > psql -d dotclear -c "alter user dotclear with password 'my_passwd'" > I have used that previously from a wiki, without noticing well what > means templates1: > psql -d template1 -c "alter user dotclear with password 'my_passwd'" > and the same error sometimes appears with template1 instead of dotclear Is it really same errors? tuple:{update} on sepgsql_sysobj_t should be evaluated with ALTER USER statement. If you want non-administrative users to execute the statement, "sepgsql_enable_users_ddl" boolean should be turned on. Thanks, >>> On the other hand, when i try to use phpPgAdmin, it works. But i need to >>> change: /var/lib/pgsql/data/pg_hba.conf from ident sameuser to >>> md5.(tryed the same for dotclear without sucess). > Was /var/lib/sepgsql/data/pg_hba.conf from the above -- OSS Platform Development Division, NEC KaiGai Kohei From olivares14031 at yahoo.com Wed Feb 6 01:51:07 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Tue, 5 Feb 2008 17:51:07 -0800 (PST) Subject: selinux/setroubleshoot reports trouble with nspluginscan, NetworkManager_t Message-ID: <407218.57511.qm@web52611.mail.re2.yahoo.com> Dear all, Upon applying todays updates rawhide report 20080205, and the failed update/conflicts \begin{QUOTE} xorg-x11-xinit-1.0.7-3.fc9.i386 from development has depsolving problems --> xorg-x11-xinit-1.0.7-3.fc9.i386 (development) conflicts with dbus < 1.1 .4-3.fc9 Error: xorg-x11-xinit-1.0.7-3.fc9.i386 (development) conflicts with dbus < 1. 1.4-3.fc9 \end{QUOTE} I get two denials from selinux Summary: SELinux is preventing nspluginscan from making the program stack executable. Detailed Description: The nspluginscan 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 nspluginscan 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 nspluginscan to run correctly, you can change the context of the executable to unconfined_execmem_exec_t. "chcon -t unconfined_execmem_exec_t '/usr/bin/nspluginscan'" 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 '/usr/bin/nspluginscan'" The following command will allow this access: chcon -t unconfined_execmem_exec_t '/usr/bin/nspluginscan' 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 nspluginscan Source Path /usr/bin/nspluginscan Port Host localhost.localdomain Source RPM Packages kdebase-4.0.1-3.fc9 Target RPM Packages Policy RPM selinux-policy-3.2.6-5.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name allow_execstack Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.24-17.fc9 #1 SMP Mon Feb 4 19:02:27 EST 2008 i686 i686 Alert Count 2 First Seen Tue 05 Feb 2008 07:13:02 AM CST Last Seen Tue 05 Feb 2008 07:41:42 PM CST Local ID 7afb3a36-5b69-486c-a93b-02e714040250 Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1202262102.930:20): avc: denied { execstack } for pid=2866 comm="nspluginscan" 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.localdomain type=SYSCALL msg=audit(1202262102.930:20): arch=40000003 syscall=125 success=no exit=-13 a0=bfce4000 a1=1000 a2=1000007 a3=fffff000 items=0 ppid=2855 pid=2866 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="nspluginscan" exe="/usr/bin/nspluginscan" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) Summary: SELinux is preventing the 00-netreport (NetworkManager_t) from executing ./init. Detailed Description: SELinux has denied the 00-netreport from executing ./init. If 00-netreport is supposed to be able to execute ./init, this could be a labeling problem. Most confined domains are allowed to execute files labeled bin_t. So you could change the labeling on this file to bin_t and retry the application. If this 00-netreport is not supposed to execute ./init, this could signal a intrusion attempt. Allowing Access: If you want to allow 00-netreport to execute ./init: chcon -t bin_t './init' If this fix works, please update the file context on disk, with the following command: semanage fcontext -a -t bin_t './init' Please specify the full path to the executable, Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this selinux-policy to make sure this becomes the default labeling. Additional Information: Source Context system_u:system_r:NetworkManager_t Target Context system_u:object_r:etc_t Target Objects ./init [ file ] Source 00-netreport Source Path /bin/bash Port Host localhost.localdomain Source RPM Packages bash-3.2-20.fc9 Target RPM Packages Policy RPM selinux-policy-3.2.6-5.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name execute Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.24-17.fc9 #1 SMP Mon Feb 4 19:02:27 EST 2008 i686 i686 Alert Count 1 First Seen Tue 05 Feb 2008 07:42:33 PM CST Last Seen Tue 05 Feb 2008 07:42:33 PM CST Local ID 9a1f71bd-9256-450a-bc0c-a7ebb115cacb Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1202262153.640:107): avc: denied { execute } for pid=3226 comm="00-netreport" name="init" dev=dm-0 ino=360497 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file host=localhost.localdomain type=SYSCALL msg=audit(1202262153.640:107): arch=40000003 syscall=33 success=no exit=-13 a0=9f7a370 a1=1 a2=11 a3=9f7a370 items=0 ppid=2385 pid=3226 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="00-netreport" exe="/bin/bash" subj=system_u:system_r:NetworkManager_t:s0 key=(null) Thanks, Antonio ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From kwizart at gmail.com Wed Feb 6 12:23:56 2008 From: kwizart at gmail.com (KH KH) Date: Wed, 6 Feb 2008 13:23:56 +0100 Subject: postgresql with httpd and dotclear In-Reply-To: <47A9070B.6020508@ak.jp.nec.com> References: <47A86C85.7090000@gmail.com> <47A8788E.7020700@ak.jp.nec.com> <47A9070B.6020508@ak.jp.nec.com> Message-ID: 2008/2/6, Kohei KaiGai : > KH KH wrote: > > 2008/2/5, KaiGai Kohei : > >> Nicolas Chauvet wrote: > >>> Hello ! > >>> > >>> I try to use apache and postgresql with the dotclear blog engine. > >>> When I try to enter the database information from the admin config > >>> wizard within the browser, have a selinux denial : > >>> > >>> audit(1202182131.382:34): avc: denied { name_connect } for pid=2604 > >>> comm="httpd" dest=5432 scontext=system_u:system_r:httpd_t:s0 > >>> tcontext=system_u:object_r:postgresql_port_t:s0 tclass=tcp_socket > >>> > >>> [root at haderach ~]# ls -Z /home/www/ > >>> drwxr-xr-x root root system_u:object_r:httpd_sys_content_t:s0 dotclear > >>> > >>> [root at haderach ~]# rpm -q sepostgresql > >>> sepostgresql-8.2.6-1.158.fc8 > >>> selinux-policy-3.0.8-81.fc8 > >>> selinux-policy-targeted-3.0.8-81.fc8 > >>> > >>> [root at haderach data]# semodule -l |grep postgre > >>> sepostgresql 1.158 > >> Can the following command help you? > >> > >> # setsebool -P httpd_can_network_connect_db=1 > >> > > I does: the error disappeared, but i have another: > > from /var/log/sepostgresql.log > > FATAL: sepgsql_system_getpeercon(734): 'user_u:user_r:user_t' is not > > a valid context > > I guess you try to connect SE-PostgreSQL runnung on another host without > any labeled networking configuration. > SE-PostgreSQL tries to apply fallbacked security context when it cannot > obtain peer's context. The 'user_u:user_r:user_t' is default fallbacked > context. > > Please confirm whether mcstransd is running, or not. > If not running, please start it. mcstans installed and started, this solved many problems. Actually i'm running SE-PostgreSQL on my server host with phpPgAdmin on the same host but browsed from my workstation. Now i can enter the parameters from the database and setup my blog engine, thx. It remains some Selinux denials with sendmail (dotclear want to send a mail to the admin of the blog engine and with phpPgAdmin Selinux denials with sendmail: ------------------- audit(1202299741.450:42): avc: denied { search } for pid=12667 comm="sendmail" name="mail" dev=sda6 ino=1573785 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:etc_mail_t:s0 tclass=dir audit(1202299741.450:43): avc: denied { search } for pid=12667 comm="sendmail" name="mail" dev=sda6 ino=1573785 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:etc_mail_t:s0 tclass=dir audit(1202299741.451:44): avc: denied { getattr } for pid=12667 comm="sendmail" path="/etc/mail" dev=sda6 ino=1573785 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:etc_mail_t:s0 tclass=dir ------------------- > > I have also noticed an error in the same log file: > > LOG: could not open directory "/usr/share/sepgsql/timezone": File or > > directory doens't exist > > Where i've made a ln -s timezoneset /usr/share/sepgsql/timezone. > > It seems to me packageing error. I'll fix soon. > > > About phpPgAdmin: now i can connect but i have this all the time: > > -------------- > > ERROR: SELinux: denied { set_param } > > scontext=system_u:system_r:httpd_t:s0 > > tcontext=system_u:object_r:sepgsql_db_t:s0 tclass=db_database > > name=dotclear > > STATEMENT: set datestyle='ISO' > > -------------- > > The default security policy for SE-PostgreSQL does not allow to execute > "SET ..." statement by non-administratvie users. > However, it might not be a appropriate policy. I'll update this part of > policy on the next update. please wait for some days. > > > Seems related to the command used to set the passwd ?! > > psql -d dotclear -c "alter user dotclear with password 'my_passwd'" > > I have used that previously from a wiki, without noticing well what > > means templates1: > > psql -d template1 -c "alter user dotclear with password 'my_passwd'" > > and the same error sometimes appears with template1 instead of dotclear > > Is it really same errors? This error also appears all the time with phpPgAdmin but with a different name={dotclear,template1} . The second one appears when I want to delete a unused database: ------------------------- Erreur SQL : ERROR: SELinux: denied { set_param } scontext=system_u:system_r:httpd_t tcontext=system_u:object_r:sepgsql_db_t tclass=db_database name=template1 Dans l'instruction : set datestyle='ISO' ------------------------- Erreur SQL : ERROR: SELinux: denied { drop } scontext=system_u:system_r:httpd_t tcontext=system_u:object_r:sepgsql_db_t tclass=db_database name=postgres Dans l'instruction : DROP DATABASE "postgres" -------------------------- > tuple:{update} on sepgsql_sysobj_t should be evaluated with ALTER USER statement. > > If you want non-administrative users to execute the statement, > "sepgsql_enable_users_ddl" boolean should be turned on. I have turn this on also, actually even connected from sepgsql user show the error. Thx for your help! Nicolas (kwizart ) From dwalsh at redhat.com Wed Feb 6 14:53:39 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 06 Feb 2008 09:53:39 -0500 Subject: selinux/setroubleshoot reports trouble with nspluginscan, NetworkManager_t In-Reply-To: <407218.57511.qm@web52611.mail.re2.yahoo.com> References: <407218.57511.qm@web52611.mail.re2.yahoo.com> Message-ID: <47A9C9F3.50903@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Antonio Olivares wrote: > Dear all, > > Upon applying todays updates rawhide report 20080205, > and the failed update/conflicts > \begin{QUOTE} > xorg-x11-xinit-1.0.7-3.fc9.i386 from development has > depsolving problems > --> xorg-x11-xinit-1.0.7-3.fc9.i386 (development) > conflicts with dbus < 1.1 > .4-3.fc9 > Error: xorg-x11-xinit-1.0.7-3.fc9.i386 (development) > conflicts with dbus < 1. > 1.4-3.fc9 > \end{QUOTE} > > I get two denials from selinux > > Summary: > > SELinux is preventing nspluginscan from making the > program stack executable. > > Detailed Description: > > The nspluginscan 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 nspluginscan 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 > nspluginscan to run correctly, you can change the > context of the executable to > unconfined_execmem_exec_t. "chcon -t > unconfined_execmem_exec_t > '/usr/bin/nspluginscan'" 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 > '/usr/bin/nspluginscan'" > > The following command will allow this access: > > chcon -t unconfined_execmem_exec_t > '/usr/bin/nspluginscan' > > 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 nspluginscan > Source Path /usr/bin/nspluginscan > Port > Host localhost.localdomain > Source RPM Packages kdebase-4.0.1-3.fc9 > Target RPM Packages > Policy RPM > selinux-policy-3.2.6-5.fc9 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name allow_execstack > Host Name localhost.localdomain > Platform Linux > localhost.localdomain 2.6.24-17.fc9 #1 SMP > Mon Feb 4 19:02:27 EST > 2008 i686 i686 > Alert Count 2 > First Seen Tue 05 Feb 2008 07:13:02 > AM CST > Last Seen Tue 05 Feb 2008 07:41:42 > PM CST > Local ID > 7afb3a36-5b69-486c-a93b-02e714040250 > Line Numbers > > Raw Audit Messages > > host=localhost.localdomain type=AVC > msg=audit(1202262102.930:20): avc: denied { > execstack } for pid=2866 comm="nspluginscan" > 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.localdomain type=SYSCALL > msg=audit(1202262102.930:20): arch=40000003 > syscall=125 success=no exit=-13 a0=bfce4000 a1=1000 > a2=1000007 a3=fffff000 items=0 ppid=2855 pid=2866 > auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 > egid=500 sgid=500 fsgid=500 tty=(none) > comm="nspluginscan" exe="/usr/bin/nspluginscan" > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > key=(null) > > > > Summary: > > SELinux is preventing the 00-netreport > (NetworkManager_t) from executing ./init. > > Detailed Description: > > SELinux has denied the 00-netreport from executing > ./init. If 00-netreport is > supposed to be able to execute ./init, this could be a > labeling problem. Most > confined domains are allowed to execute files labeled > bin_t. So you could change > the labeling on this file to bin_t and retry the > application. If this > 00-netreport is not supposed to execute ./init, this > could signal a intrusion > attempt. > > Allowing Access: > > If you want to allow 00-netreport to execute ./init: > chcon -t bin_t './init' If > this fix works, please update the file context on > disk, with the following > command: semanage fcontext -a -t bin_t './init' Please > specify the full path to > the executable, Please file a bug report > (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) > against this selinux-policy > to make sure this becomes the default labeling. > > Additional Information: > > Source Context > system_u:system_r:NetworkManager_t > Target Context system_u:object_r:etc_t > Target Objects ./init [ file ] > Source 00-netreport > Source Path /bin/bash > Port > Host localhost.localdomain > Source RPM Packages bash-3.2-20.fc9 > Target RPM Packages > Policy RPM > selinux-policy-3.2.6-5.fc9 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name execute > Host Name localhost.localdomain > Platform Linux > localhost.localdomain 2.6.24-17.fc9 #1 SMP > Mon Feb 4 19:02:27 EST > 2008 i686 i686 > Alert Count 1 > First Seen Tue 05 Feb 2008 07:42:33 > PM CST > Last Seen Tue 05 Feb 2008 07:42:33 > PM CST > Local ID > 9a1f71bd-9256-450a-bc0c-a7ebb115cacb > Line Numbers > > Raw Audit Messages > > host=localhost.localdomain type=AVC > msg=audit(1202262153.640:107): avc: denied { execute > } for pid=3226 comm="00-netreport" name="init" > dev=dm-0 ino=360497 > scontext=system_u:system_r:NetworkManager_t:s0 > tcontext=system_u:object_r:etc_t:s0 tclass=file > > host=localhost.localdomain type=SYSCALL > msg=audit(1202262153.640:107): arch=40000003 > syscall=33 success=no exit=-13 a0=9f7a370 a1=1 a2=11 > a3=9f7a370 items=0 ppid=2385 pid=3226 auid=4294967295 > uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 tty=(none) comm="00-netreport" exe="/bin/bash" > subj=system_u:system_r:NetworkManager_t:s0 key=(null) > > > > Thanks, > > > Antonio > > > ____________________________________________________________________________________ > 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 The 00-netreport should be fixed in todays update. nspluginscan requiring execstack should be reported as a bug against nsplugin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkepyfMACgkQrlYvE4MpobNrJgCdFPgj+T5YipVQc4AieQhUjd8R cTkAn3GU5rVGH+DlT5Sgfjlysnajlx/R =7p8L -----END PGP SIGNATURE----- From dwalsh at redhat.com Wed Feb 6 15:24:34 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 06 Feb 2008 10:24:34 -0500 Subject: Fedora 8 odds and sods In-Reply-To: <20080205232824.0f6b4a64@metropolis.intra.city-fan.org> References: <478E34CF.5000503@city-fan.org> <478F95A5.3080305@redhat.com> <20080205232824.0f6b4a64@metropolis.intra.city-fan.org> Message-ID: <47A9D132.2030900@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Howarth wrote: > On Thu, 17 Jan 2008 12:51:33 -0500 > Daniel J Walsh wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Paul Howarth wrote: >>> 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) >>> >> Already added. >>> # 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; >>> >> Added. >>> # 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 }; >>> >> Added > > Policy now has procmail_read_tmp_files(sendmail_t) but this doesn't > allow write access by sendmail. Sendmail needs to write into > procmail_tmp_t when a procmail recipe pipes a message into a filter and > that filter creates a temp file I believe. > > I'm getting the AVCs anyway: > type=AVC msg=audit(1202162399.034:320138): avc: denied { write } for > pid=16452 comm="sendmail" path="/tmp/choplist.16383" dev=dm-1 ino=13 > scontext=system_u:system_r:sendmail_t:s0 > tcontext=system_u:object_r:procmail_tmp_t:s0 tclass=file type=SYSCALL > msg=audit(1202162399.034:320138): arch=40000003 syscall=11 success=yes > exit=0 a0=bf8febff a1=84ffe44 a2=bf8fe3a4 a3=84ffe44 items=0 ppid=16384 > pid=16452 auid=0 uid=502 gid=502 euid=502 suid=502 fsuid=502 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) type=AVC msg=audit(1202162401.083:320139): avc: denied > { write } for pid=16453 comm="sendmail" > path=2F746D702F63686F706C6973742E3136333833202864656C6574656429 > dev=dm-1 ino=13 scontext=system_u:system_r:sendmail_t:s0 > tcontext=system_u:object_r:procmail_tmp_t:s0 tclass=file > > Paul. Fixed in selinux-policy-3.0.8-84.fc8 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkep0TIACgkQrlYvE4MpobObegCg52sdeWuVie1SjhBFUiolPp8i dDkAnRXyqFCr8KzE7y6dd7gktCciETgd =gLYk -----END PGP SIGNATURE----- From dwalsh at redhat.com Wed Feb 6 15:26:59 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 06 Feb 2008 10:26:59 -0500 Subject: postgresql with httpd and dotclear In-Reply-To: References: <47A86C85.7090000@gmail.com> <47A8788E.7020700@ak.jp.nec.com> <47A9070B.6020508@ak.jp.nec.com> Message-ID: <47A9D1C3.5040708@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 KH KH wrote: > 2008/2/6, Kohei KaiGai : >> KH KH wrote: >>> 2008/2/5, KaiGai Kohei : >>>> Nicolas Chauvet wrote: >>>>> Hello ! >>>>> >>>>> I try to use apache and postgresql with the dotclear blog engine. >>>>> When I try to enter the database information from the admin config >>>>> wizard within the browser, have a selinux denial : >>>>> >>>>> audit(1202182131.382:34): avc: denied { name_connect } for pid=2604 >>>>> comm="httpd" dest=5432 scontext=system_u:system_r:httpd_t:s0 >>>>> tcontext=system_u:object_r:postgresql_port_t:s0 tclass=tcp_socket >>>>> >>>>> [root at haderach ~]# ls -Z /home/www/ >>>>> drwxr-xr-x root root system_u:object_r:httpd_sys_content_t:s0 dotclear >>>>> >>>>> [root at haderach ~]# rpm -q sepostgresql >>>>> sepostgresql-8.2.6-1.158.fc8 >>>>> selinux-policy-3.0.8-81.fc8 >>>>> selinux-policy-targeted-3.0.8-81.fc8 >>>>> >>>>> [root at haderach data]# semodule -l |grep postgre >>>>> sepostgresql 1.158 >>>> Can the following command help you? >>>> >>>> # setsebool -P httpd_can_network_connect_db=1 >>>> >>> I does: the error disappeared, but i have another: >>> from /var/log/sepostgresql.log >>> FATAL: sepgsql_system_getpeercon(734): 'user_u:user_r:user_t' is not >>> a valid context >> I guess you try to connect SE-PostgreSQL runnung on another host without >> any labeled networking configuration. >> SE-PostgreSQL tries to apply fallbacked security context when it cannot >> obtain peer's context. The 'user_u:user_r:user_t' is default fallbacked >> context. >> >> Please confirm whether mcstransd is running, or not. >> If not running, please start it. > mcstans installed and started, this solved many problems. > Actually i'm running SE-PostgreSQL on my server host with phpPgAdmin > on the same host but browsed from my workstation. > > Now i can enter the parameters from the database and setup my blog engine, thx. > It remains some Selinux denials with sendmail (dotclear want to send a > mail to the admin of the blog engine and with phpPgAdmin > > Selinux denials with sendmail: > ------------------- > audit(1202299741.450:42): avc: denied { search } for pid=12667 > comm="sendmail" name="mail" dev=sda6 ino=1573785 > scontext=system_u:system_r:httpd_t:s0 > tcontext=system_u:object_r:etc_mail_t:s0 tclass=dir > audit(1202299741.450:43): avc: denied { search } for pid=12667 > comm="sendmail" name="mail" dev=sda6 ino=1573785 > scontext=system_u:system_r:httpd_t:s0 > tcontext=system_u:object_r:etc_mail_t:s0 tclass=dir > audit(1202299741.451:44): avc: denied { getattr } for pid=12667 > comm="sendmail" path="/etc/mail" dev=sda6 ino=1573785 > scontext=system_u:system_r:httpd_t:s0 > tcontext=system_u:object_r:etc_mail_t:s0 tclass=dir Turn on the httpd_can_sendmail boolean > ------------------- > >>> I have also noticed an error in the same log file: >>> LOG: could not open directory "/usr/share/sepgsql/timezone": File or >>> directory doens't exist >>> Where i've made a ln -s timezoneset /usr/share/sepgsql/timezone. >> It seems to me packageing error. I'll fix soon. >> >>> About phpPgAdmin: now i can connect but i have this all the time: >>> -------------- >>> ERROR: SELinux: denied { set_param } >>> scontext=system_u:system_r:httpd_t:s0 >>> tcontext=system_u:object_r:sepgsql_db_t:s0 tclass=db_database >>> name=dotclear >>> STATEMENT: set datestyle='ISO' >>> -------------- >> The default security policy for SE-PostgreSQL does not allow to execute >> "SET ..." statement by non-administratvie users. >> However, it might not be a appropriate policy. I'll update this part of >> policy on the next update. please wait for some days. >> >>> Seems related to the command used to set the passwd ?! >>> psql -d dotclear -c "alter user dotclear with password 'my_passwd'" >>> I have used that previously from a wiki, without noticing well what >>> means templates1: >>> psql -d template1 -c "alter user dotclear with password 'my_passwd'" >>> and the same error sometimes appears with template1 instead of dotclear >> Is it really same errors? > This error also appears all the time with phpPgAdmin but with a > different name={dotclear,template1} . The second one appears when I > want to delete a unused database: > ------------------------- > Erreur SQL : > > ERROR: SELinux: denied { set_param } > scontext=system_u:system_r:httpd_t > tcontext=system_u:object_r:sepgsql_db_t tclass=db_database > name=template1 > > Dans l'instruction : > set datestyle='ISO' > ------------------------- > Erreur SQL : > > ERROR: SELinux: denied { drop } scontext=system_u:system_r:httpd_t > tcontext=system_u:object_r:sepgsql_db_t tclass=db_database > name=postgres > > Dans l'instruction : > DROP DATABASE "postgres" > -------------------------- >> tuple:{update} on sepgsql_sysobj_t should be evaluated with ALTER USER statement. >> >> If you want non-administrative users to execute the statement, >> "sepgsql_enable_users_ddl" boolean should be turned on. > I have turn this on also, actually even connected from sepgsql user > show the error. > > Thx for your help! > > Nicolas (kwizart ) > > -- > 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 iEYEARECAAYFAkep0cMACgkQrlYvE4MpobNDTwCggfNV7xx00Qj60BSWQTBHVsLz 2AcAn0T/VNEYy/QFlp0ZdkXPLALcIwnu =tLmS -----END PGP SIGNATURE----- From olivares14031 at yahoo.com Wed Feb 6 16:36:15 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Wed, 6 Feb 2008 08:36:15 -0800 (PST) Subject: selinux/setroubleshoot reports trouble with nspluginscan, NetworkManager_t In-Reply-To: <47A9C9F3.50903@redhat.com> Message-ID: <502780.92817.qm@web52607.mail.re2.yahoo.com> --- Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Antonio Olivares wrote: > > Dear all, > > > > Upon applying todays updates rawhide report > 20080205, > > and the failed update/conflicts > > \begin{QUOTE} > > xorg-x11-xinit-1.0.7-3.fc9.i386 from development > has > > depsolving problems > > --> xorg-x11-xinit-1.0.7-3.fc9.i386 > (development) > > conflicts with dbus < 1.1 > > .4-3.fc9 > > Error: xorg-x11-xinit-1.0.7-3.fc9.i386 > (development) > > conflicts with dbus < 1. > > 1.4-3.fc9 > > \end{QUOTE} > > > > I get two denials from selinux > > > > Summary: > > > > SELinux is preventing nspluginscan from making the > > program stack executable. > > > > Detailed Description: > > > > The nspluginscan 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 nspluginscan 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 > > nspluginscan to run correctly, you can change the > > context of the executable to > > unconfined_execmem_exec_t. "chcon -t > > unconfined_execmem_exec_t > > '/usr/bin/nspluginscan'" 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 > > '/usr/bin/nspluginscan'" > > > > The following command will allow this access: > > > > chcon -t unconfined_execmem_exec_t > > '/usr/bin/nspluginscan' > > > > 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 nspluginscan > > Source Path > /usr/bin/nspluginscan > > Port > > Host > localhost.localdomain > > Source RPM Packages kdebase-4.0.1-3.fc9 > > Target RPM Packages > > Policy RPM > > selinux-policy-3.2.6-5.fc9 > > Selinux Enabled True > > Policy Type targeted > > MLS Enabled True > > Enforcing Mode Enforcing > > Plugin Name allow_execstack > > Host Name > localhost.localdomain > > Platform Linux > > localhost.localdomain 2.6.24-17.fc9 #1 SMP > > Mon Feb 4 19:02:27 > EST > > 2008 i686 i686 > > Alert Count 2 > > First Seen Tue 05 Feb 2008 > 07:13:02 > > AM CST > > Last Seen Tue 05 Feb 2008 > 07:41:42 > > PM CST > > Local ID > > 7afb3a36-5b69-486c-a93b-02e714040250 > > Line Numbers > > > > Raw Audit Messages > > > > host=localhost.localdomain type=AVC > > msg=audit(1202262102.930:20): avc: denied { > > execstack } for pid=2866 comm="nspluginscan" > > > 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.localdomain type=SYSCALL > > msg=audit(1202262102.930:20): arch=40000003 > > syscall=125 success=no exit=-13 a0=bfce4000 > a1=1000 > > a2=1000007 a3=fffff000 items=0 ppid=2855 pid=2866 > > auid=500 uid=500 gid=500 euid=500 suid=500 > fsuid=500 > > egid=500 sgid=500 fsgid=500 tty=(none) > > comm="nspluginscan" exe="/usr/bin/nspluginscan" > > > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > > key=(null) > > > > > > > > Summary: > > > > SELinux is preventing the 00-netreport > > (NetworkManager_t) from executing ./init. > > > > Detailed Description: > > > > SELinux has denied the 00-netreport from executing > > ./init. If 00-netreport is > > supposed to be able to execute ./init, this could > be a > > labeling problem. Most > > confined domains are allowed to execute files > labeled > > bin_t. So you could change > > the labeling on this file to bin_t and retry the > > application. If this > > 00-netreport is not supposed to execute ./init, > this > > could signal a intrusion > > attempt. > > > > Allowing Access: > > > > If you want to allow 00-netreport to execute > ./init: > > chcon -t bin_t './init' If > > this fix works, please update the file context on > > disk, with the following > > command: semanage fcontext -a -t bin_t './init' > Please > > specify the full path to > > the executable, Please file a bug report > > > (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) > > against this selinux-policy > > to make sure this becomes the default labeling. > > > > Additional Information: > > > > Source Context > > system_u:system_r:NetworkManager_t > === message truncated === Bug filed against nspluginwrapper since there is no nspluginscan https://bugzilla.redhat.com/show_bug.cgi?id=431708 Thanks, Antonio ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From ftaylor at redhat.com Fri Feb 8 14:42:51 2008 From: ftaylor at redhat.com (Forrest Taylor) Date: Fri, 08 Feb 2008 07:42:51 -0700 Subject: Changing policies, using enforcing=0 the first time Message-ID: <1202481771.3889.15.camel@localhost.localdomain> I am running into a strange occurrence running RHEL5.1 with an updated policy (2.4.6-106.el5_1.3). By default, it runs the targeted policy. I install the mls and the strict policy and touch /.autorelabel. The first time that I boot to one of these other policies, I get a kernel panic, and I have to use enforcing=0. The strange thing is that I can then go back and forth between any policy without setting permissive mode--that is, I only have to set enforcing=0 the first time that I make a policy change, but subsequent times it is not required. Does fixfiles change something the first time that allows the relabel to work subsequent times in enforcing mode? Any thoughts? Thanks, Forrest -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sds at tycho.nsa.gov Fri Feb 8 14:54:17 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 08 Feb 2008 09:54:17 -0500 Subject: Changing policies, using enforcing=0 the first time In-Reply-To: <1202481771.3889.15.camel@localhost.localdomain> References: <1202481771.3889.15.camel@localhost.localdomain> Message-ID: <1202482457.27371.338.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2008-02-08 at 07:42 -0700, Forrest Taylor wrote: > I am running into a strange occurrence running RHEL5.1 with an updated > policy (2.4.6-106.el5_1.3). By default, it runs the targeted policy. I > install the mls and the strict policy and touch /.autorelabel. The > first time that I boot to one of these other policies, I get a kernel > panic, and I have to use enforcing=0. The strange thing is that I can > then go back and forth between any policy without setting permissive > mode--that is, I only have to set enforcing=0 the first time that I make > a policy change, but subsequent times it is not required. Does fixfiles > change something the first time that allows the relabel to work > subsequent times in enforcing mode? Any thoughts? IIRC, RHEL5 still had separate shlib_t vs. lib_t types in the strict/mls policies, which means that when you first switch from targeted, you can't execute shared objects in enforcing mode until you've first relabeled. targeted policy aliases them into a single type, and upstream policy has done away with the distinction now as well, I believe. So, on the first conversion, the xattrs get reset from lib_t to shlib_t, then they stay that way because targeted views them as identical. -- Stephen Smalley National Security Agency From ftaylor at redhat.com Fri Feb 8 15:20:10 2008 From: ftaylor at redhat.com (Forrest Taylor) Date: Fri, 08 Feb 2008 08:20:10 -0700 Subject: Changing policies, using enforcing=0 the first time In-Reply-To: <1202482457.27371.338.camel@moss-spartans.epoch.ncsc.mil> References: <1202481771.3889.15.camel@localhost.localdomain> <1202482457.27371.338.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1202484010.4495.9.camel@localhost.localdomain> On Fri, 2008-02-08 at 09:54 -0500, Stephen Smalley wrote: > On Fri, 2008-02-08 at 07:42 -0700, Forrest Taylor wrote: > > I am running into a strange occurrence running RHEL5.1 with an updated > > policy (2.4.6-106.el5_1.3). By default, it runs the targeted policy. I > > install the mls and the strict policy and touch /.autorelabel. The > > first time that I boot to one of these other policies, I get a kernel > > panic, and I have to use enforcing=0. The strange thing is that I can > > then go back and forth between any policy without setting permissive > > mode--that is, I only have to set enforcing=0 the first time that I make > > a policy change, but subsequent times it is not required. Does fixfiles > > change something the first time that allows the relabel to work > > subsequent times in enforcing mode? Any thoughts? > > IIRC, RHEL5 still had separate shlib_t vs. lib_t types in the strict/mls > policies, which means that when you first switch from targeted, you > can't execute shared objects in enforcing mode until you've first > relabeled. targeted policy aliases them into a single type, and > upstream policy has done away with the distinction now as well, I > believe. > > So, on the first conversion, the xattrs get reset from lib_t to shlib_t, > then they stay that way because targeted views them as identical. AH! I knew it was something like that. I couldn't find the difference because shlib_t is a typealias to lib_t, so it always shows lib_t. Is there any way in the targeted policy to verify that it actually is shlib_t instead of lib_t? It obviously must have some difference for strict/mls to work. Thanks, Forrest -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sds at tycho.nsa.gov Fri Feb 8 15:39:01 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 08 Feb 2008 10:39:01 -0500 Subject: Changing policies, using enforcing=0 the first time In-Reply-To: <1202484010.4495.9.camel@localhost.localdomain> References: <1202481771.3889.15.camel@localhost.localdomain> <1202482457.27371.338.camel@moss-spartans.epoch.ncsc.mil> <1202484010.4495.9.camel@localhost.localdomain> Message-ID: <1202485141.27371.375.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2008-02-08 at 08:20 -0700, Forrest Taylor wrote: > On Fri, 2008-02-08 at 09:54 -0500, Stephen Smalley wrote: > > On Fri, 2008-02-08 at 07:42 -0700, Forrest Taylor wrote: > > > I am running into a strange occurrence running RHEL5.1 with an updated > > > policy (2.4.6-106.el5_1.3). By default, it runs the targeted policy. I > > > install the mls and the strict policy and touch /.autorelabel. The > > > first time that I boot to one of these other policies, I get a kernel > > > panic, and I have to use enforcing=0. The strange thing is that I can > > > then go back and forth between any policy without setting permissive > > > mode--that is, I only have to set enforcing=0 the first time that I make > > > a policy change, but subsequent times it is not required. Does fixfiles > > > change something the first time that allows the relabel to work > > > subsequent times in enforcing mode? Any thoughts? > > > > IIRC, RHEL5 still had separate shlib_t vs. lib_t types in the strict/mls > > policies, which means that when you first switch from targeted, you > > can't execute shared objects in enforcing mode until you've first > > relabeled. targeted policy aliases them into a single type, and > > upstream policy has done away with the distinction now as well, I > > believe. > > > > So, on the first conversion, the xattrs get reset from lib_t to shlib_t, > > then they stay that way because targeted views them as identical. > > AH! I knew it was something like that. I couldn't find the difference > because shlib_t is a typealias to lib_t, so it always shows lib_t. > > Is there any way in the targeted policy to verify that it actually is > shlib_t instead of lib_t? It obviously must have some difference for > strict/mls to work. No, the kernel canonicalizes the context to the policy's native form before returning it via getxattr. That was introduced to accomodate the transition from non-MCS/MLS to MCS/MLS, so that the kernel could auto-magically add the MCS/MLS field for files on filesystems created under the older policy (e.g. for going from RHEL4 -> RHEL5). But it also means that even if the on-disk xattr has shlib_t, the kernel will return lib_t under targeted policy due to the canonicalization. -- Stephen Smalley National Security Agency From sf181257 at students.mimuw.edu.pl Fri Feb 8 15:42:17 2008 From: sf181257 at students.mimuw.edu.pl (=?ISO-8859-2?Q?=22Stanis=B3aw_T=2E_Findeisen=22?=) Date: Fri, 08 Feb 2008 16:42:17 +0100 Subject: host certificates & keys Message-ID: <47AC7859.6050003@students.mimuw.edu.pl> Hello Are there any standard ways to add certificate and private key files to services like Postfix (SMTP) or Dovecot (POP3/IMAP) to enable them use TLS? STF From dwalsh at redhat.com Fri Feb 8 16:06:23 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 08 Feb 2008 11:06:23 -0500 Subject: host certificates & keys In-Reply-To: <47AC7859.6050003@students.mimuw.edu.pl> References: <47AC7859.6050003@students.mimuw.edu.pl> Message-ID: <47AC7DFF.40908@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stanis?aw T. Findeisen wrote: > Hello > > Are there any standard ways to add certificate and private key files to > services like Postfix (SMTP) or Dovecot (POP3/IMAP) to enable them use TLS? > > STF > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list I don't see this as an SELinux question? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkesff8ACgkQrlYvE4MpobPZrgCfZm7+AQ07pUryxQkNREwdBQwb QFgAoJ9elbi3sECKqz3P1/l3UOBhMVn7 =fAOw -----END PGP SIGNATURE----- From ftaylor at redhat.com Fri Feb 8 17:42:59 2008 From: ftaylor at redhat.com (Forrest Taylor) Date: Fri, 08 Feb 2008 10:42:59 -0700 Subject: Changing policies, using enforcing=0 the first time In-Reply-To: <1202485141.27371.375.camel@moss-spartans.epoch.ncsc.mil> References: <1202481771.3889.15.camel@localhost.localdomain> <1202482457.27371.338.camel@moss-spartans.epoch.ncsc.mil> <1202484010.4495.9.camel@localhost.localdomain> <1202485141.27371.375.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1202492579.4495.17.camel@localhost.localdomain> On Fri, 2008-02-08 at 10:39 -0500, Stephen Smalley wrote: > On Fri, 2008-02-08 at 08:20 -0700, Forrest Taylor wrote: > > On Fri, 2008-02-08 at 09:54 -0500, Stephen Smalley wrote: > > > On Fri, 2008-02-08 at 07:42 -0700, Forrest Taylor wrote: > > > > I am running into a strange occurrence running RHEL5.1 with an updated > > > > policy (2.4.6-106.el5_1.3). By default, it runs the targeted policy. I > > > > install the mls and the strict policy and touch /.autorelabel. The > > > > first time that I boot to one of these other policies, I get a kernel > > > > panic, and I have to use enforcing=0. The strange thing is that I can > > > > then go back and forth between any policy without setting permissive > > > > mode--that is, I only have to set enforcing=0 the first time that I make > > > > a policy change, but subsequent times it is not required. Does fixfiles > > > > change something the first time that allows the relabel to work > > > > subsequent times in enforcing mode? Any thoughts? > > > > > > IIRC, RHEL5 still had separate shlib_t vs. lib_t types in the strict/mls > > > policies, which means that when you first switch from targeted, you > > > can't execute shared objects in enforcing mode until you've first > > > relabeled. targeted policy aliases them into a single type, and > > > upstream policy has done away with the distinction now as well, I > > > believe. > > > > > > So, on the first conversion, the xattrs get reset from lib_t to shlib_t, > > > then they stay that way because targeted views them as identical. > > > > AH! I knew it was something like that. I couldn't find the difference > > because shlib_t is a typealias to lib_t, so it always shows lib_t. > > > > Is there any way in the targeted policy to verify that it actually is > > shlib_t instead of lib_t? It obviously must have some difference for > > strict/mls to work. > > No, the kernel canonicalizes the context to the policy's native form > before returning it via getxattr. That was introduced to accomodate the > transition from non-MCS/MLS to MCS/MLS, so that the kernel could > auto-magically add the MCS/MLS field for files on filesystems created > under the older policy (e.g. for going from RHEL4 -> RHEL5). But it > also means that even if the on-disk xattr has shlib_t, the kernel will > return lib_t under targeted policy due to the canonicalization. Ah, that makes sense. Just for future reference, I can change policies without setting permissive mode by changing the context to shlib_t on the following: /lib/libblkid.so* /lib/libc.so* /lib/libdevmapper.so* /lib/libdl.so* /lib/libselinux.so* /lib/libsepol.so /lib/libtermcap.so* /lib/libuuid.so* These came from the shared libraries needed for init, mount and sh. Once those are changed, the system can get far enough through rc.sysinit to run fixfiles. Thanks for the help, Forrest -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sf181257 at students.mimuw.edu.pl Fri Feb 8 19:00:10 2008 From: sf181257 at students.mimuw.edu.pl (=?ISO-8859-2?Q?=22Stanis=B3aw_T=2E_Findeisen=22?=) Date: Fri, 08 Feb 2008 20:00:10 +0100 Subject: host certificates & keys In-Reply-To: <47AC7DFF.40908@redhat.com> References: <47AC7859.6050003@students.mimuw.edu.pl> <47AC7DFF.40908@redhat.com> Message-ID: <47ACA6BA.8060000@students.mimuw.edu.pl> Daniel J Walsh wrote: >> Are there any standard ways to add certificate and private key files to >> services like Postfix (SMTP) or Dovecot (POP3/IMAP) to enable them use TLS? > > I don't see this as an SELinux question? Can I add them anywhere, name them as I wish, give them any SELinux labels and permissions and SELinux will allow read access to them? This would probably mean, that SELinux policies deployed in Fedora are somewhat too liberal?... STF From olivares14031 at yahoo.com Sat Feb 9 18:45:48 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Sat, 9 Feb 2008 10:45:48 -0800 (PST) Subject: firefox and selinux Message-ID: <990718.8178.qm@web52607.mail.re2.yahoo.com> Dear all, I have set settroubleshoot to allow the following: chcon -t unconfined_execmem_exec_t '/usr/lib/firefox-3.0b4pre/firefox' But it is happening again, I do not understand why I need to do it multiple of times. I see a pattern occuring: I have filed a bug report against firefox-b3 https://bugzilla.redhat.com/show_bug.cgi?id=432198 I hope that firefox and selinux start to work together and not against each other. :) Summary: SELinux is preventing firefox from making the program stack executable. Detailed Description: The 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 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 to run correctly, you can change the context of the executable to unconfined_execmem_exec_t. "chcon -t unconfined_execmem_exec_t '/usr/lib/firefox-3.0b4pre/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 '/usr/lib/firefox-3.0b4pre/firefox'" The following command will allow this access: chcon -t unconfined_execmem_exec_t '/usr/lib/firefox-3.0b4pre/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 Source Path /usr/lib/firefox-3.0b3pre/firefox Port Host localhost Source RPM Packages firefox-3.0-0.beta2.16.nightly20080206.fc9 Target RPM Packages Policy RPM selinux-policy-3.2.7-1.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-23.fc9 #1 SMP Wed Feb 6 11:36:31 EST 2008 i686 athlon Alert Count 11 First Seen Fri 01 Feb 2008 05:08:54 PM CST Last Seen Sat 09 Feb 2008 12:35:06 PM CST Local ID c4806f30-a6dc-43b0-8901-5531075795f7 Line Numbers Raw Audit Messages host=localhost type=AVC msg=audit(1202582106.621:28): avc: denied { execstack } for pid=9246 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(1202582106.621:28): arch=40000003 syscall=125 success=no exit=-13 a0=bfa71000 a1=1000 a2=1000007 a3=fffff000 items=0 ppid=9232 pid=9246 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.0b4pre/firefox" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) Regards, Antonio ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From fedora02 at grifent.com Sun Feb 10 20:14:33 2008 From: fedora02 at grifent.com (John Griffiths) Date: Sun, 10 Feb 2008 15:14:33 -0500 Subject: host certificates & keys In-Reply-To: <20080209170011.C842972F06@hormel.redhat.com> References: <20080209170011.C842972F06@hormel.redhat.com> Message-ID: <47AF5B29.6050804@grifent.com> An HTML attachment was scrubbed... URL: From selinux at gmail.com Sun Feb 10 20:34:57 2008 From: selinux at gmail.com (Tom London) Date: Sun, 10 Feb 2008 12:34:57 -0800 Subject: More consolekit_t and dbus_t AVCs (from today's Rawhide) Message-ID: <4c4ba1530802101234g6ace53b6w7f7f05cb22b0e61a@mail.gmail.com> After doing today's rawhide thing, get this on targeted/enforcing boot/login: #============= system_dbusd_t ============== allow system_dbusd_t NetworkManager_t:dbus send_msg; allow system_dbusd_t unconfined_t:dbus send_msg; #============= xdm_t ============== allow xdm_t consolekit_var_run_t:dir search; [copy of /var/log/audit/audit.log attached.] tom -- Tom London -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: log.txt URL: From selinux at gmail.com Sun Feb 10 20:47:40 2008 From: selinux at gmail.com (Tom London) Date: Sun, 10 Feb 2008 12:47:40 -0800 Subject: More consolekit_t and dbus_t AVCs (from today's Rawhide) In-Reply-To: <4c4ba1530802101234g6ace53b6w7f7f05cb22b0e61a@mail.gmail.com> References: <4c4ba1530802101234g6ace53b6w7f7f05cb22b0e61a@mail.gmail.com> Message-ID: <4c4ba1530802101247x2f5ae9cbx7703855cbaac08a1@mail.gmail.com> On Sun, Feb 10, 2008 at 12:34 PM, Tom London wrote: > After doing today's rawhide thing, get this on targeted/enforcing boot/login: > > #============= system_dbusd_t ============== > allow system_dbusd_t NetworkManager_t:dbus send_msg; > allow system_dbusd_t unconfined_t:dbus send_msg; > > #============= xdm_t ============== > allow xdm_t consolekit_var_run_t:dir search; > > [copy of /var/log/audit/audit.log attached.] > Sorry, got a few more in permissive mode: #============= system_dbusd_t ============== allow system_dbusd_t NetworkManager_t:dbus send_msg; allow system_dbusd_t unconfined_t:dbus send_msg; #============= xdm_t ============== allow xdm_t consolekit_var_run_t:dir search; allow xdm_t consolekit_var_run_t:file { read getattr }; [complete audit.log attached.] tom -- Tom London -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: log2.txt URL: From olivares14031 at yahoo.com Tue Feb 12 00:50:21 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Mon, 11 Feb 2008 16:50:21 -0800 (PST) Subject: selinux now causing trouble with seamonkey Message-ID: <943455.11238.qm@web52608.mail.re2.yahoo.com> Dear all, In addition to the bug filed https://bugzilla.redhat.com/show_bug.cgi?id=432198 selinux now is causing trouble with seamonkey. I deleted the ~/.mozilla/ directory and started from scratch. So the argument about the plugins will not work now :) Am I the only one seeing this? I feel kind of bad about complaining that selinux is doing this, but it did not happen before and now it does, both with firefox and with seamonkey. Here's the message Summary: SELinux is preventing seamonkey-bin from making the program stack executable. Detailed Description: The seamonkey-bin 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 seamonkey-bin 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 seamonkey-bin to run correctly, you can change the context of the executable to unconfined_execmem_exec_t. "chcon -t unconfined_execmem_exec_t '/usr/lib/seamonkey-1.1.8/seamonkey-bin'" 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 '/usr/lib/seamonkey-1.1.8/seamonkey-bin'" The following command will allow this access: chcon -t unconfined_execmem_exec_t '/usr/lib/seamonkey-1.1.8/seamonkey-bin' 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 Source Path /usr/lib/firefox-3.0b3pre/firefox Port Host localhost Source RPM Packages seamonkey-1.1.8-3.fc9 Target RPM Packages Policy RPM selinux-policy-3.2.7-1.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.1-28.fc9 #1 SMP Sun Feb 10 17:27:37 EST 2008 i686 athlon Alert Count 33 First Seen Fri 01 Feb 2008 05:08:54 PM CST Last Seen Mon 11 Feb 2008 06:39:47 PM CST Local ID c4806f30-a6dc-43b0-8901-5531075795f7 Line Numbers Raw Audit Messages host=localhost type=AVC msg=audit(1202776787.936:31): avc: denied { execstack } for pid=3481 comm="seamonkey-bin" 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(1202776787.936:31): arch=40000003 syscall=125 success=no exit=-13 a0=bff2d000 a1=1000 a2=1000007 a3=fffff000 items=0 ppid=1 pid=3481 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="seamonkey-bin" exe="/usr/lib/seamonkey-1.1.8/seamonkey-bin" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From olivares14031 at yahoo.com Tue Feb 12 00:54:26 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Mon, 11 Feb 2008 16:54:26 -0800 (PST) Subject: SELinux is preventing ck-history (xdm_t) "search" to ./ConsoleKit (consolekit_var_run_t). Message-ID: <901334.11478.qm@web52603.mail.re2.yahoo.com> Dear all, Setroubleshoot showed me the following: Should I disregard them, or is ConsoleKit important to the system. Summary: SELinux is preventing ck-history (xdm_t) "search" to ./ConsoleKit (consolekit_var_run_t). Detailed Description: SELinux denied access requested by ck-history. It is not expected that this access is required by ck-history 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 ./ConsoleKit, restorecon -v './ConsoleKit' 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_t:SystemLow-SystemHigh Target Context system_u:object_r:consolekit_var_run_t Target Objects ./ConsoleKit [ dir ] Source ck-history Source Path /usr/bin/ck-history Port Host localhost Source RPM Packages ConsoleKit-0.2.7-1.fc9 Target RPM Packages Policy RPM selinux-policy-3.2.7-1.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.1-28.fc9 #1 SMP Sun Feb 10 17:27:37 EST 2008 i686 athlon Alert Count 12 First Seen Mon 11 Feb 2008 07:05:42 AM CST Last Seen Mon 11 Feb 2008 02:35:06 PM CST Local ID 3cef7e4a-b1dc-4c27-83e3-91eccbb14047 Line Numbers Raw Audit Messages host=localhost type=AVC msg=audit(1202762106.60:13): avc: denied { search } for pid=2469 comm="ck-history" name="ConsoleKit" dev=dm-0 ino=3342348 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:consolekit_var_run_t:s0 tclass=dir host=localhost type=SYSCALL msg=audit(1202762106.60:13): arch=40000003 syscall=5 success=no exit=-13 a0=8fd3608 a1=0 a2=1b6 a3=0 items=0 ppid=1 pid=2469 auid=4294967295 uid=42 gid=42 euid=42 suid=42 fsuid=42 egid=42 sgid=42 fsgid=42 tty=(none) comm="ck-history" exe="/usr/bin/ck-history" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) TIA, Antonio ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From paul at city-fan.org Tue Feb 12 11:14:35 2008 From: paul at city-fan.org (Paul Howarth) Date: Tue, 12 Feb 2008 11:14:35 +0000 Subject: named avc (Fedora 8) Message-ID: <47B17F9B.9040302@city-fan.org> Got this one today: type=AVC msg=audit(1202724149.875:1426): avc: denied { name_bind } for pid=2468 comm="named" src=2605 scontext=system_u:system_r:named_t:s0 tcontext=system_u:object_r:bgp_port_t:s0 tclass=udp_socket type=SYSCALL msg=audit(1202724149.875:1426): arch=c000003e syscall=49 success=no exit=-13 a0=38 a1=41400d70 a2=1c a3=41400b6c items=0 ppid=1 pid=2468 auid=4294967295 uid=25 gid=25 euid=25 suid=25 fsuid=25 egid=25 sgid=25 fsgid=25 tty=(none) comm="named" exe="/usr/sbin/named" subj=system_u:system_r:named_t:s0 key=(null) I suspect that this snippet from the logwatch report is related: could not update an IPv6 random query port: permission denied: 1 Time(s) I guess I need to specify the query-source and query-source-v6 bind options to tie this down? Paul. From dwalsh at redhat.com Tue Feb 12 14:17:14 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 12 Feb 2008 09:17:14 -0500 Subject: firefox and selinux In-Reply-To: <990718.8178.qm@web52607.mail.re2.yahoo.com> References: <990718.8178.qm@web52607.mail.re2.yahoo.com> Message-ID: <47B1AA6A.7020404@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Antonio Olivares wrote: > Dear all, > > I have set settroubleshoot to allow the following: > chcon -t unconfined_execmem_exec_t > '/usr/lib/firefox-3.0b4pre/firefox' > > But it is happening again, I do not understand why I > need to do it multiple of times. I see a pattern > occuring: I have filed a bug report against > firefox-b3 > > https://bugzilla.redhat.com/show_bug.cgi?id=432198 > > I hope that firefox and selinux start to work together > and not against each other. :) > > Summary: > > SELinux is preventing firefox from making the program > stack executable. > > Detailed Description: > > The 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 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 to > run correctly, you can change the context of the > executable to > unconfined_execmem_exec_t. "chcon -t > unconfined_execmem_exec_t > '/usr/lib/firefox-3.0b4pre/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 > '/usr/lib/firefox-3.0b4pre/firefox'" > > The following command will allow this access: > > chcon -t unconfined_execmem_exec_t > '/usr/lib/firefox-3.0b4pre/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 > Source Path > /usr/lib/firefox-3.0b3pre/firefox > Port > Host localhost > Source RPM Packages > firefox-3.0-0.beta2.16.nightly20080206.fc9 > Target RPM Packages > Policy RPM > selinux-policy-3.2.7-1.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-23.fc9 #1 SMP Wed Feb 6 > 11:36:31 EST 2008 i686 > athlon > Alert Count 11 > First Seen Fri 01 Feb 2008 05:08:54 > PM CST > Last Seen Sat 09 Feb 2008 12:35:06 > PM CST > Local ID > c4806f30-a6dc-43b0-8901-5531075795f7 > Line Numbers > > Raw Audit Messages > > host=localhost type=AVC msg=audit(1202582106.621:28): > avc: denied { execstack } for pid=9246 > 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(1202582106.621:28): arch=40000003 > syscall=125 success=no exit=-13 a0=bfa71000 a1=1000 > a2=1000007 a3=fffff000 items=0 ppid=9232 pid=9246 > 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.0b4pre/firefox" > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > key=(null) > > > > Regards, > > Antonio > > > ____________________________________________________________________________________ > Never miss a thing. Make Yahoo your home page. > http://www.yahoo.com/r/hs > chcon -t unconfined_execmem_exec_t '/usr/lib/firefox-3.0b4pre/firefox' This will only survive until the next relabel. selinux-policy update can trigger partial relabels. # semanage fcontext -a -t unconfined_execmem_exec_t '/usr/lib/firefox-3.0b4pre/firefox' # restorecon '/usr/lib/firefox-3.0b4pre/firefox' Would set the file systems default labeling for firefox and make it survive a relabel. As other replies have indicated, this problem is probably a bad plugin. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkexqmoACgkQrlYvE4MpobPeAwCg4DfcKCUrh/31D5ktqc2vH6JL pqUAnRiP4HtUCMkKNxdK0xeT5+kVzIqA =dfRo -----END PGP SIGNATURE----- From dwalsh at redhat.com Tue Feb 12 14:33:20 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 12 Feb 2008 09:33:20 -0500 Subject: named avc (Fedora 8) In-Reply-To: <47B17F9B.9040302@city-fan.org> References: <47B17F9B.9040302@city-fan.org> Message-ID: <47B1AE30.5060700@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Howarth wrote: > Got this one today: > > type=AVC msg=audit(1202724149.875:1426): avc: denied { name_bind } for > pid=2468 comm="named" src=2605 scontext=system_u:system_r:named_t:s0 > tcontext=system_u:object_r:bgp_port_t:s0 tclass=udp_socket > type=SYSCALL msg=audit(1202724149.875:1426): arch=c000003e syscall=49 > success=no exit=-13 a0=38 a1=41400d70 a2=1c a3=41400b6c items=0 ppid=1 > pid=2468 auid=4294967295 uid=25 gid=25 euid=25 suid=25 fsuid=25 egid=25 > sgid=25 fsgid=25 tty=(none) comm="named" exe="/usr/sbin/named" > subj=system_u:system_r:named_t:s0 key=(null) > > > I suspect that this snippet from the logwatch report is related: > > could not update an IPv6 random query port: permission denied: 1 Time(s) > > I guess I need to specify the query-source and query-source-v6 bind > options to tie this down? > > Paul. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list This is an interesting bug, well at least to me. SELinux ports are labeled with a an attribute of port_type. Ports < 1024 are labeled as reserved_port_type. So we have a line in bind that says it can name_bind to all unreserved ports. And this calls into a interface that has this line allow $1 { port_type -reserved_port_type }:udb_socket name_bind; Everything looks good. Well not really because we also group a few ports with a single port type. network_port(bgp, tcp,179,s0, udp,179,s0, tcp,2605,s0, udp,2605,s0) The network_port macro assigns the examines the port numbers and if it finds one < 1024, it assigns the port type as reserved_port_type. As you can see bgp_port_t includes reserved_port_type ports and non reserved port types. So you were unlucky enough to hit on one of these ports. I have changed the interface to allow all ports > 1024 in todays rawhide. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkexrjAACgkQrlYvE4MpobP99QCg2iBmkKDTNNGOTGRuHVzy+ci5 UM4An20zuX0HjAp8uXrmB4Ty8M38u02b =mArL -----END PGP SIGNATURE----- From selinux at gmail.com Wed Feb 13 19:51:26 2008 From: selinux at gmail.com (Tom London) Date: Wed, 13 Feb 2008 11:51:26 -0800 Subject: qemu-kvm AVC Message-ID: <4c4ba1530802131151i29a2510q882575d7aec3d2b6@mail.gmail.com> Hadn't run qemu-kvm for a bit. Now get this AVC (both enforcing/targeted): type=AVC msg=audit(1202932089.281:48): avc: denied { execmem } for pid=10351 comm="qemu-kvm" scontext=unconfined_u:unconfined_r:unconfined_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process type=SYSCALL msg=audit(1202932089.281:48): arch=40000003 syscall=125 success=no exit=-13 a0=8df0000 a1=1001000 a2=7 a3=a7d5358 items=0 ppid=3049 pid=10351 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts1 comm="qemu-kvm" exe="/usr/bin/qemu-kvm" subj=unconfined_u:unconfined_r:unconfined_t:s0 key=(null) Not sure if it interferes with anything.... tom -- Tom London From sf181257 at students.mimuw.edu.pl Wed Feb 13 22:07:47 2008 From: sf181257 at students.mimuw.edu.pl (=?ISO-8859-2?Q?=22Stanis=B3aw_T=2E_Findeisen=22?=) Date: Wed, 13 Feb 2008 23:07:47 +0100 Subject: problems with sending emails from Apache Message-ID: <47B36A33.30005@students.mimuw.edu.pl> Hello, I am using Fedora 7 x86_64, have these packages installed: selinux-policy-2.6.4-70.fc7 selinux-policy-targeted-2.6.4-70.fc7 and get these errors: syslog: Feb 13 18:18:12 srv-1 kernel: audit(1202923092.221:5): avc: denied { search } for pid=8423 comm="sendmail" name="postfix" dev=sda1 ino=4935485 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:postfix_etc_t:s0 tclass=dir Apache error log: [Wed Feb 13 18:15:02 2008] [error] [client 84.10.17.54] File does not exist: /var/www/html/gnu-linux/favicon.ico sendmail: fatal: open /etc/postfix/main.cf: Permission denied [Wed Feb 13 20:27:16 2008] [info] [client 84.10.17.54] (70007)The timeout specified has expired: core_output_filter: writing data to the network I think that occured when PHP application tried to send email from within Apache HTTP server. STF From dwalsh at redhat.com Wed Feb 13 22:16:41 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 13 Feb 2008 17:16:41 -0500 Subject: problems with sending emails from Apache In-Reply-To: <47B36A33.30005@students.mimuw.edu.pl> References: <47B36A33.30005@students.mimuw.edu.pl> Message-ID: <47B36C49.4070407@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stanis?aw T. Findeisen wrote: > Hello, I am using Fedora 7 x86_64, have these packages installed: > > selinux-policy-2.6.4-70.fc7 > selinux-policy-targeted-2.6.4-70.fc7 > > and get these errors: > > syslog: > > Feb 13 18:18:12 srv-1 kernel: audit(1202923092.221:5): avc: denied { > search } for pid=8423 comm="sendmail" name="postfix" dev=sda1 > ino=4935485 scontext=system_u:system_r:httpd_t:s0 > tcontext=system_u:object_r:postfix_etc_t:s0 tclass=dir > > Apache error log: > > [Wed Feb 13 18:15:02 2008] [error] [client 84.10.17.54] File does not > exist: /var/www/html/gnu-linux/favicon.ico > sendmail: fatal: open /etc/postfix/main.cf: Permission denied > [Wed Feb 13 20:27:16 2008] [info] [client 84.10.17.54] (70007)The > timeout specified has expired: core_output_filter: writing data to the > network > > I think that occured when PHP application tried to send email from > within Apache HTTP server. > > STF > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Try setsebool -P httpd_can_sendmail=1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkezbEkACgkQrlYvE4MpobNzTQCfTZUta+WObtOb1s0B9eFpuj+g i5YAn1wQFtuOBUo/omhm2+ZROdM71yqI =teDZ -----END PGP SIGNATURE----- From dant at cdkkt.com Thu Feb 14 02:23:47 2008 From: dant at cdkkt.com (Daniel B. Thurman) Date: Wed, 13 Feb 2008 18:23:47 -0800 Subject: CVS Servers Message-ID: <1202955827.12883.34.camel@gold.cdkkt.com> In one of the Fedora CVS server setup, it says that if the administrator wants to use a simple pserver remote string such as: export CVSROOT=':pserver:@:/cvs' Then one has to: 1) /etc/xinetd.d/cvs: server_args = -f --allow-root=/cvs pserver 2) ln -s /var/cvs /cvs But the problem here is that SELinux has no context for the symbolic link /cvs, therefore deny's access. I tried setting context for /cvs by: 1) chcon -t cvs_data_t No dice. Does not work. To see if I can cvs login bypassing Selinux, I tried: 1) setenforce 0 2) cvs login (successfully) 3) setenforce 1 So, what can I do to get SElinux to authorize the /cvs symbolic link access to /var/cvs? Thanks- Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at city-fan.org Thu Feb 14 11:37:22 2008 From: paul at city-fan.org (Paul Howarth) Date: Thu, 14 Feb 2008 11:37:22 +0000 Subject: CVS Servers In-Reply-To: <1202955827.12883.34.camel@gold.cdkkt.com> References: <1202955827.12883.34.camel@gold.cdkkt.com> Message-ID: <47B427F2.8030409@city-fan.org> Daniel B. Thurman wrote: > In one of the Fedora CVS server setup, it says that if the > administrator wants to use a simple pserver remote string > such as: > > export CVSROOT=':pserver:@:/cvs' > > Then one has to: > > 1) /etc/xinetd.d/cvs: > server_args = -f --allow-root=/cvs pserver > 2) ln -s /var/cvs /cvs > > But the problem here is that SELinux has no context for > the symbolic link /cvs, therefore deny's access. > > I tried setting context for /cvs by: > 1) chcon -t cvs_data_t > > No dice. Does not work. > > To see if I can cvs login bypassing Selinux, I tried: > 1) setenforce 0 > 2) cvs login (successfully) > 3) setenforce 1 > > So, what can I do to get SElinux to authorize the /cvs symbolic link > access to /var/cvs? Maybe try a bind mount instead of a symlink? Paul. From sds at tycho.nsa.gov Thu Feb 14 12:30:10 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 14 Feb 2008 07:30:10 -0500 Subject: CVS Servers In-Reply-To: <1202955827.12883.34.camel@gold.cdkkt.com> References: <1202955827.12883.34.camel@gold.cdkkt.com> Message-ID: <1202992210.16038.67.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-02-13 at 18:23 -0800, Daniel B. Thurman wrote: > In one of the Fedora CVS server setup, it says that if the > administrator wants to use a simple pserver remote string > such as: > > export CVSROOT=':pserver:@:/cvs' > > Then one has to: > > 1) /etc/xinetd.d/cvs: > server_args = -f --allow-root=/cvs pserver > 2) ln -s /var/cvs /cvs > > But the problem here is that SELinux has no context for > the symbolic link /cvs, therefore deny's access. > > I tried setting context for /cvs by: > 1) chcon -t cvs_data_t > > No dice. Does not work. > > To see if I can cvs login bypassing Selinux, I tried: > 1) setenforce 0 > 2) cvs login (successfully) > 3) setenforce 1 > > So, what can I do to get SElinux to authorize the /cvs symbolic link > access to /var/cvs? What avc denial do you get (/sbin/ausearch -i -m AVC)? -- Stephen Smalley National Security Agency From selinux at gmail.com Thu Feb 14 15:58:47 2008 From: selinux at gmail.com (Tom London) Date: Thu, 14 Feb 2008 07:58:47 -0800 Subject: qemu-kvm AVC In-Reply-To: <4c4ba1530802131151i29a2510q882575d7aec3d2b6@mail.gmail.com> References: <4c4ba1530802131151i29a2510q882575d7aec3d2b6@mail.gmail.com> Message-ID: <4c4ba1530802140758q65527229o68f4711b6ed65951@mail.gmail.com> On Wed, Feb 13, 2008 at 11:51 AM, Tom London wrote: > Hadn't run qemu-kvm for a bit. > > Now get this AVC (both enforcing/targeted): > > > type=AVC msg=audit(1202932089.281:48): avc: denied { execmem } for > pid=10351 comm="qemu-kvm" > scontext=unconfined_u:unconfined_r:unconfined_t:s0 > tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process > type=SYSCALL msg=audit(1202932089.281:48): arch=40000003 syscall=125 > success=no exit=-13 a0=8df0000 a1=1001000 a2=7 a3=a7d5358 items=0 > ppid=3049 pid=10351 auid=500 uid=500 gid=500 euid=500 suid=500 > fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts1 comm="qemu-kvm" > exe="/usr/bin/qemu-kvm" subj=unconfined_u:unconfined_r:unconfined_t:s0 > key=(null) > > Not sure if it interferes with anything.... > Believe this causes this: Feb 14 07:55:10 localhost kernel: qemu-kvm[7350] general protection ip:80d6ffd sp:bfb48e40 error:0 in qemu-kvm[8047000+12d000] Feb 14 07:55:10 localhost setroubleshoot: SELinux is preventing qemu-kvm from changing a writable memory segment executable. For complete SELinux messages. run sealert -l f7ee40db-9506-48d2-bde6-396eb39ef085 -- Tom London From dant at cdkkt.com Thu Feb 14 18:16:55 2008 From: dant at cdkkt.com (Daniel B. Thurman) Date: Thu, 14 Feb 2008 10:16:55 -0800 Subject: CVS Servers In-Reply-To: <1202955827.12883.34.camel@gold.cdkkt.com> References: <1202955827.12883.34.camel@gold.cdkkt.com> Message-ID: <1203013015.12883.41.camel@gold.cdkkt.com> On Wed, 2008-02-13 at 18:23 -0800, Daniel B. Thurman wrote: > In one of the Fedora CVS server setup, it says that if the > administrator wants to use a simple pserver remote string > such as: > > export CVSROOT=':pserver:@:/cvs' > > Then one has to: > > 1) /etc/xinetd.d/cvs: > server_args = -f --allow-root=/cvs pserver > 2) ln -s /var/cvs /cvs > > But the problem here is that SELinux has no context for > the symbolic link /cvs, therefore deny's access. > > I tried setting context for /cvs by: > 1) chcon -t cvs_data_t > > No dice. Does not work. > > To see if I can cvs login bypassing Selinux, I tried: > 1) setenforce 0 > 2) cvs login (successfully) > 3) setenforce 1 > > So, what can I do to get SElinux to authorize the /cvs symbolic link > access to /var/cvs? > > Thanks- > Dan Apologies to all. It turns out that my email spam system was blocking me from receiving email responses I was waiting for! Geez, I will have to add another TODO to my list. To Paul: Can you explain what you mean by: "maybe try a bind mount instead of a symlink?" To Stephen: "/sbin/ausearch -i -m AVC" type=SYSCALL msg=audit(02/13/2008 19:17:32.484:5097) : arch=i386 syscall=open success=no exit=-13(Permission denied) a0=8faf660 a1=8000 a2=1b6 a3=8fafa58 items=0 ppid=25427 pid=27015 auid=dant uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) comm=cvs exe=/usr/bin/cvs subj=system_u:system_r:cvs_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(02/13/2008 19:17:32.484:5097) : avc: denied { read } for pid=27015 comm=cvs name=cvs dev=sdb5 ino=49172 scontext=system_u:system_r:cvs_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=lnk_file Thanks for responding! Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sds at tycho.nsa.gov Thu Feb 14 18:56:25 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 14 Feb 2008 13:56:25 -0500 Subject: CVS Servers In-Reply-To: <1203013015.12883.41.camel@gold.cdkkt.com> References: <1202955827.12883.34.camel@gold.cdkkt.com> <1203013015.12883.41.camel@gold.cdkkt.com> Message-ID: <1203015385.16038.149.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2008-02-14 at 10:16 -0800, Daniel B. Thurman wrote: > > On Wed, 2008-02-13 at 18:23 -0800, Daniel B. Thurman wrote: > > In one of the Fedora CVS server setup, it says that if the > > administrator wants to use a simple pserver remote string > > such as: > > > > export CVSROOT=':pserver:@:/cvs' > > > > Then one has to: > > > > 1) /etc/xinetd.d/cvs: > > server_args = -f --allow-root=/cvs pserver > > 2) ln -s /var/cvs /cvs > > > > But the problem here is that SELinux has no context for > > the symbolic link /cvs, therefore deny's access. > > > > I tried setting context for /cvs by: > > 1) chcon -t cvs_data_t > > > > No dice. Does not work. > > > > To see if I can cvs login bypassing Selinux, I tried: > > 1) setenforce 0 > > 2) cvs login (successfully) > > 3) setenforce 1 > > > > So, what can I do to get SElinux to authorize the /cvs symbolic link > > access to /var/cvs? > > > > Thanks- > > Dan > > Apologies to all. It turns out that my email spam system was blocking > me from > receiving email responses I was waiting for! Geez, I will have to add > another > TODO to my list. > > To Paul: Can you explain what you mean by: "maybe try a bind mount > instead of a symlink?" > > To Stephen: "/sbin/ausearch -i -m AVC" > type=SYSCALL msg=audit(02/13/2008 19:17:32.484:5097) : arch=i386 > syscall=open success=no exit=-13(Permission denied) a0=8faf660 a1=8000 > a2=1b6 a3=8fafa58 items=0 ppid=25427 pid=27015 auid=dant uid=root > gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root > tty=(none) comm=cvs exe=/usr/bin/cvs > subj=system_u:system_r:cvs_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(02/13/2008 19:17:32.484:5097) : avc: denied > { read } for pid=27015 comm=cvs name=cvs dev=sdb5 ino=49172 > scontext=system_u:system_r:cvs_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:default_t:s0 tclass=lnk_file semanage fcontext -a -t cvs_data_t "/cvs" /sbin/restorecon -v /cvs -- Stephen Smalley National Security Agency From dant at cdkkt.com Thu Feb 14 19:13:36 2008 From: dant at cdkkt.com (Daniel B. Thurman) Date: Thu, 14 Feb 2008 11:13:36 -0800 Subject: CVS Servers In-Reply-To: <1203013015.12883.41.camel@gold.cdkkt.com> References: <1202955827.12883.34.camel@gold.cdkkt.com> <1203013015.12883.41.camel@gold.cdkkt.com> Message-ID: <1203016416.12883.46.camel@gold.cdkkt.com> On Thu, 2008-02-14 at 10:16 -0800, Daniel B. Thurman wrote: > > On Wed, 2008-02-13 at 18:23 -0800, Daniel B. Thurman wrote: > > > In one of the Fedora CVS server setup, it says that if the > > administrator wants to use a simple pserver remote string > > such as: > > > > export CVSROOT=':pserver:@:/cvs' > > > > Then one has to: > > > > 1) /etc/xinetd.d/cvs: > > server_args = -f --allow-root=/cvs pserver > > 2) ln -s /var/cvs /cvs > > > > But the problem here is that SELinux has no context for > > the symbolic link /cvs, therefore deny's access. > > > > I tried setting context for /cvs by: > > 1) chcon -t cvs_data_t > > > > No dice. Does not work. > > > > To see if I can cvs login bypassing Selinux, I tried: > > 1) setenforce 0 > > 2) cvs login (successfully) > > 3) setenforce 1 > > > > So, what can I do to get SElinux to authorize the /cvs symbolic link > > access to /var/cvs? > > > > Thanks- > > Dan > > > Apologies to all. It turns out that my email spam system was blocking > me from > receiving email responses I was waiting for! Geez, I will have to add > another > TODO to my list. > > To Paul: Can you explain what you mean by: "maybe try a bind mount > instead of a symlink?" I looked it up and understood a bind mount. Answer is nope! Bind mount: ======== mount --bind /var/cvs /cvs ls -ldZ /cvs: ======= drwxr-xr-x cvs cvs system_u:object_r:cvs_t:s0 /cvs So, the context is right, but still get a Permissions denied. /sbin/ausearch -i -m AVC ================ type=SYSCALL msg=audit(02/14/2008 11:08:09.984:7732) : arch=i386 syscall=fchmodat success=no exit=-13(Permission denied) a0=ffffff9c a1=94848d8 a2=1fd a3=94848d8 items=0 ppid=23862 pid=20445 auid=dant uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts7 comm=chmod exe=/bin/chmod subj=system_u:system_r:unconfined_t:s0 key=(null) type=AVC msg=audit(02/14/2008 11:08:09.984:7732) : avc: denied { setattr } for pid=20445 comm=chmod name=cvs dev=sdb5 ino=819450 scontext=system_u:system_r:unconfined_t:s0 tcontext=system_u:object_r:cvs_t:s0 tclass=dir > To Stephen: "/sbin/ausearch -i -m AVC" > type=SYSCALL msg=audit(02/13/2008 19:17:32.484:5097) : arch=i386 > syscall=open success=no exit=-13(Permission denied) a0=8faf660 a1=8000 > a2=1b6 a3=8fafa58 items=0 ppid=25427 pid=27015 auid=dant uid=root > gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root > tty=(none) comm=cvs exe=/usr/bin/cvs > subj=system_u:system_r:cvs_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(02/13/2008 19:17:32.484:5097) : avc: denied > { read } for pid=27015 comm=cvs name=cvs dev=sdb5 ino=49172 > scontext=system_u:system_r:cvs_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:default_t:s0 tclass=lnk_file > > Thanks for responding! > Dan > > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.20.4/1277 - Release Date: > 2/13/2008 8:00 PM > > > plain text document attachment (ATT00516.txt), "ATT00516.txt" > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From dant at cdkkt.com Thu Feb 14 19:19:26 2008 From: dant at cdkkt.com (Daniel B. Thurman) Date: Thu, 14 Feb 2008 11:19:26 -0800 Subject: CVS Servers In-Reply-To: <1203016416.12883.46.camel@gold.cdkkt.com> References: <1202955827.12883.34.camel@gold.cdkkt.com> <1203013015.12883.41.camel@gold.cdkkt.com> <1203016416.12883.46.camel@gold.cdkkt.com> Message-ID: <1203016766.12883.50.camel@gold.cdkkt.com> On Thu, 2008-02-14 at 11:13 -0800, Daniel B. Thurman wrote: > > On Thu, 2008-02-14 at 10:16 -0800, Daniel B. Thurman wrote: > > > > > On Wed, 2008-02-13 at 18:23 -0800, Daniel B. Thurman wrote: > > > > > In one of the Fedora CVS server setup, it says that if the > > > administrator wants to use a simple pserver remote string > > > such as: > > > > > > export CVSROOT=':pserver:@:/cvs' > > > > > > Then one has to: > > > > > > 1) /etc/xinetd.d/cvs: > > > server_args = -f --allow-root=/cvs pserver > > > 2) ln -s /var/cvs /cvs > > > > > > But the problem here is that SELinux has no context for > > > the symbolic link /cvs, therefore deny's access. > > > > > > I tried setting context for /cvs by: > > > 1) chcon -t cvs_data_t > > > > > > No dice. Does not work. > > > > > > To see if I can cvs login bypassing Selinux, I tried: > > > 1) setenforce 0 > > > 2) cvs login (successfully) > > > 3) setenforce 1 > > > > > > So, what can I do to get SElinux to authorize the /cvs symbolic > > > link access to /var/cvs? > > > > > > Thanks- > > > Dan > > > > > > Apologies to all. It turns out that my email spam system was > > blocking me from > > receiving email responses I was waiting for! Geez, I will have to > > add another > > TODO to my list. > > > > To Paul: Can you explain what you mean by: "maybe try a bind mount > > instead of a symlink?" > > > I looked it up and understood a bind mount. Answer is nope! > > Bind mount: > ======== > mount --bind /var/cvs /cvs > > ls -ldZ /cvs: > ======= > drwxr-xr-x cvs cvs system_u:object_r:cvs_t:s0 /cvs > So, the context is right, but still get a Permissions denied. > > /sbin/ausearch -i -m AVC > ================ > type=SYSCALL msg=audit(02/14/2008 11:08:09.984:7732) : arch=i386 > syscall=fchmodat success=no exit=-13(Permission denied) a0=ffffff9c > a1=94848d8 a2=1fd a3=94848d8 items=0 ppid=23862 pid=20445 auid=dant > uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root > fsgid=root tty=pts7 comm=chmod exe=/bin/chmod > subj=system_u:system_r:unconfined_t:s0 key=(null) > type=AVC msg=audit(02/14/2008 11:08:09.984:7732) : avc: denied > { setattr } for pid=20445 comm=chmod name=cvs dev=sdb5 ino=819450 > scontext=system_u:system_r:unconfined_t:s0 > tcontext=system_u:object_r:cvs_t:s0 tclass=dir Oh rats! This error above was for something else! My mistake!!!! I had to trying logging in at the remote system but failed several times, but after the 3rd try, I finally got in. Not sure why the login process stumbled. So, It DOES work! > > To Stephen: "/sbin/ausearch -i -m AVC" > > type=SYSCALL msg=audit(02/13/2008 19:17:32.484:5097) : arch=i386 > > syscall=open success=no exit=-13(Permission denied) a0=8faf660 > > a1=8000 a2=1b6 a3=8fafa58 items=0 ppid=25427 pid=27015 auid=dant > > uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root > > fsgid=root tty=(none) comm=cvs exe=/usr/bin/cvs > > subj=system_u:system_r:cvs_t:s0-s0:c0.c1023 key=(null) > > type=AVC msg=audit(02/13/2008 19:17:32.484:5097) : avc: denied > > { read } for pid=27015 comm=cvs name=cvs dev=sdb5 ino=49172 > > scontext=system_u:system_r:cvs_t:s0-s0:c0.c1023 > > tcontext=system_u:object_r:default_t:s0 tclass=lnk_file > > > > Thanks for responding! > > Dan > > > > > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.5.516 / Virus Database: 269.20.4/1277 - Release Date: > > 2/13/2008 8:00 PM > > > > > > plain text document attachment (ATT00516.txt), "ATT00516.txt" > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.20.4/1277 - Release Date: > 2/13/2008 8:00 PM > > > plain text document attachment (ATT00538.txt), "ATT00538.txt" > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From dant at cdkkt.com Thu Feb 14 19:25:46 2008 From: dant at cdkkt.com (Daniel B. Thurman) Date: Thu, 14 Feb 2008 11:25:46 -0800 Subject: CVS Servers In-Reply-To: <1203016766.12883.50.camel@gold.cdkkt.com> References: <1202955827.12883.34.camel@gold.cdkkt.com> <1203013015.12883.41.camel@gold.cdkkt.com> <1203016416.12883.46.camel@gold.cdkkt.com> <1203016766.12883.50.camel@gold.cdkkt.com> Message-ID: <1203017146.12883.54.camel@gold.cdkkt.com> On Thu, 2008-02-14 at 11:19 -0800, Daniel B. Thurman wrote: > > On Thu, 2008-02-14 at 11:13 -0800, Daniel B. Thurman wrote: > > > > > On Thu, 2008-02-14 at 10:16 -0800, Daniel B. Thurman wrote: > > > > > > > > On Wed, 2008-02-13 at 18:23 -0800, Daniel B. Thurman wrote: > > > > > > > In one of the Fedora CVS server setup, it says that if the > > > > administrator wants to use a simple pserver remote string > > > > such as: > > > > > > > > export CVSROOT=':pserver:@:/cvs' > > > > > > > > Then one has to: > > > > > > > > 1) /etc/xinetd.d/cvs: > > > > server_args = -f --allow-root=/cvs pserver > > > > 2) ln -s /var/cvs /cvs > > > > > > > > But the problem here is that SELinux has no context for > > > > the symbolic link /cvs, therefore deny's access. > > > > > > > > I tried setting context for /cvs by: > > > > 1) chcon -t cvs_data_t > > > > > > > > No dice. Does not work. > > > > > > > > To see if I can cvs login bypassing Selinux, I tried: > > > > 1) setenforce 0 > > > > 2) cvs login (successfully) > > > > 3) setenforce 1 > > > > > > > > So, what can I do to get SElinux to authorize the /cvs symbolic > > > > link access to /var/cvs? > > > > > > > > Thanks- > > > > Dan > > > > > > > > > Apologies to all. It turns out that my email spam system was > > > blocking me from > > > receiving email responses I was waiting for! Geez, I will have to > > > add another > > > TODO to my list. > > > > > > To Paul: Can you explain what you mean by: "maybe try a bind mount > > > instead of a symlink?" > > > > > > I looked it up and understood a bind mount. Answer is nope! > > > > Bind mount: > > ======== > > mount --bind /var/cvs /cvs > > > > ls -ldZ /cvs: > > ======= > > drwxr-xr-x cvs cvs system_u:object_r:cvs_t:s0 /cvs > > So, the context is right, but still get a Permissions denied. > > > > /sbin/ausearch -i -m AVC > > ================ > > type=SYSCALL msg=audit(02/14/2008 11:08:09.984:7732) : arch=i386 > > syscall=fchmodat success=no exit=-13(Permission denied) a0=ffffff9c > > a1=94848d8 a2=1fd a3=94848d8 items=0 ppid=23862 pid=20445 auid=dant > > uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root > > fsgid=root tty=pts7 comm=chmod exe=/bin/chmod > > subj=system_u:system_r:unconfined_t:s0 key=(null) > > type=AVC msg=audit(02/14/2008 11:08:09.984:7732) : avc: denied > > { setattr } for pid=20445 comm=chmod name=cvs dev=sdb5 ino=819450 > > scontext=system_u:system_r:unconfined_t:s0 > > tcontext=system_u:object_r:cvs_t:s0 tclass=dir > > > Oh rats! This error above was for something else! My mistake!!!! > > I had to trying logging in at the remote system but failed several > times, > but after the 3rd try, I finally got in. Not sure why the login > process > stumbled. > > So, It DOES work! > But I am having a problem with getting Eclipse's SVN to open a single file: The server reported an error while performing the "cvs status" command. HelloWorld: cvs status: failed to create lock directory for `/cvs/Eclipse/C/Examples/HelloWorld' (/cvs/Eclipse/C/Examples/HelloWorld/#cvs.lock): Permission denied HelloWorld: cvs status: failed to obtain dir lock in repository `/cvs/Eclipse/C/Examples/HelloWorld' HelloWorld: cvs [status aborted]: read lock failed - giving up Not sure why it is not able to lock this file for checkout/examination. Any ideas? > > > To Stephen: "/sbin/ausearch -i -m AVC" > > > type=SYSCALL msg=audit(02/13/2008 19:17:32.484:5097) : arch=i386 > > > syscall=open success=no exit=-13(Permission denied) a0=8faf660 > > > a1=8000 a2=1b6 a3=8fafa58 items=0 ppid=25427 pid=27015 auid=dant > > > uid=root gid=root euid=root suid=root fsuid=root egid=root > > > sgid=root fsgid=root tty=(none) comm=cvs exe=/usr/bin/cvs > > > subj=system_u:system_r:cvs_t:s0-s0:c0.c1023 key=(null) > > > type=AVC msg=audit(02/13/2008 19:17:32.484:5097) : avc: denied > > > { read } for pid=27015 comm=cvs name=cvs dev=sdb5 ino=49172 > > > scontext=system_u:system_r:cvs_t:s0-s0:c0.c1023 > > > tcontext=system_u:object_r:default_t:s0 tclass=lnk_file > > > > > > Thanks for responding! > > > Dan > > > > > > > > > No virus found in this incoming message. > > > Checked by AVG Free Edition. > > > Version: 7.5.516 / Virus Database: 269.20.4/1277 - Release Date: > > > 2/13/2008 8:00 PM > > > > > > > > > plain text document attachment (ATT00516.txt), "ATT00516.txt" > > > > > > -- > > > fedora-selinux-list mailing list > > > fedora-selinux-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > > > > > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.5.516 / Virus Database: 269.20.4/1277 - Release Date: > > 2/13/2008 8:00 PM > > > > > > plain text document attachment (ATT00538.txt), "ATT00538.txt" > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.20.4/1277 - Release Date: > 2/13/2008 8:00 PM > > > plain text document attachment (ATT00558.txt), "ATT00558.txt" > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From dant at cdkkt.com Thu Feb 14 19:47:39 2008 From: dant at cdkkt.com (Daniel B. Thurman) Date: Thu, 14 Feb 2008 11:47:39 -0800 Subject: CVS Servers [SOLVED] In-Reply-To: <1203017146.12883.54.camel@gold.cdkkt.com> References: <1202955827.12883.34.camel@gold.cdkkt.com> <1203013015.12883.41.camel@gold.cdkkt.com> <1203016416.12883.46.camel@gold.cdkkt.com> <1203016766.12883.50.camel@gold.cdkkt.com> <1203017146.12883.54.camel@gold.cdkkt.com> Message-ID: <1203018459.12883.61.camel@gold.cdkkt.com> On Thu, 2008-02-14 at 11:25 -0800, Daniel B. Thurman wrote: > > On Thu, 2008-02-14 at 11:19 -0800, Daniel B. Thurman wrote: > > > > > On Thu, 2008-02-14 at 11:13 -0800, Daniel B. Thurman wrote: > > > > > > > > On Thu, 2008-02-14 at 10:16 -0800, Daniel B. Thurman wrote: > > > > > > > > > > > On Wed, 2008-02-13 at 18:23 -0800, Daniel B. Thurman wrote: > > > > > > > > > In one of the Fedora CVS server setup, it says that if the > > > > > administrator wants to use a simple pserver remote string > > > > > such as: > > > > > > > > > > export CVSROOT=':pserver:@:/cvs' > > > > > > > > > > Then one has to: > > > > > > > > > > 1) /etc/xinetd.d/cvs: > > > > > server_args = -f --allow-root=/cvs pserver > > > > > 2) ln -s /var/cvs /cvs > > > > > > > > > > But the problem here is that SELinux has no context for > > > > > the symbolic link /cvs, therefore deny's access. > > > > > > > > > > I tried setting context for /cvs by: > > > > > 1) chcon -t cvs_data_t > > > > > > > > > > No dice. Does not work. > > > > > > > > > > To see if I can cvs login bypassing Selinux, I tried: > > > > > 1) setenforce 0 > > > > > 2) cvs login (successfully) > > > > > 3) setenforce 1 > > > > > > > > > > So, what can I do to get SElinux to authorize the /cvs > > > > > symbolic link access to /var/cvs? > > > > > > > > > > Thanks- > > > > > Dan > > > > > > > > > > > > Apologies to all. It turns out that my email spam system was > > > > blocking me from > > > > receiving email responses I was waiting for! Geez, I will have > > > > to add another > > > > TODO to my list. > > > > > > > > To Paul: Can you explain what you mean by: "maybe try a bind > > > > mount instead of a symlink?" > > > > > > > > > I looked it up and understood a bind mount. Answer is nope! > > > > > > Bind mount: > > > ======== Ok, the issue is solved. What I did not know is, you need to make sure that when you create an empty directory, you also need to make sure that the ownership of that directory is: cvs:cvs before bind mounting. So: 1) mkdir /cvs 2) chown cvs:cvs /cvs then 3) mount --bind /var/cvs /cvs it all works now! > > > mount --bind /var/cvs /cvs > > > > > > ls -ldZ /cvs: > > > ======= > > > drwxr-xr-x cvs cvs system_u:object_r:cvs_t:s0 /cvs > > > So, the context is right, but still get a Permissions denied. > > > > > > /sbin/ausearch -i -m AVC > > > ================ > > > type=SYSCALL msg=audit(02/14/2008 11:08:09.984:7732) : arch=i386 > > > syscall=fchmodat success=no exit=-13(Permission denied) > > > a0=ffffff9c a1=94848d8 a2=1fd a3=94848d8 items=0 ppid=23862 > > > pid=20445 auid=dant uid=root gid=root euid=root suid=root > > > fsuid=root egid=root sgid=root fsgid=root tty=pts7 comm=chmod > > > exe=/bin/chmod subj=system_u:system_r:unconfined_t:s0 key=(null) > > > type=AVC msg=audit(02/14/2008 11:08:09.984:7732) : avc: denied > > > { setattr } for pid=20445 comm=chmod name=cvs dev=sdb5 ino=819450 > > > scontext=system_u:system_r:unconfined_t:s0 > > > tcontext=system_u:object_r:cvs_t:s0 tclass=dir > > > > > > Oh rats! This error above was for something else! My mistake!!!! > > > > I had to trying logging in at the remote system but failed several > > times, > > but after the 3rd try, I finally got in. Not sure why the login > > process > > stumbled. > > > > So, It DOES work! > > > > > But I am having a problem with getting Eclipse's SVN to open a single > file: > > The server reported an error while performing the "cvs status" > command. > HelloWorld: cvs status: failed to create lock directory for > `/cvs/Eclipse/C/Examples/HelloWorld' (/cvs/Eclipse/C/Examples/HelloWorld/#cvs.lock): Permission denied > HelloWorld: cvs status: failed to obtain dir lock in repository > `/cvs/Eclipse/C/Examples/HelloWorld' > HelloWorld: cvs [status aborted]: read lock failed - giving up > > Not sure why it is not able to lock this file for > checkout/examination. Any ideas? See note above... > > > > To Stephen: "/sbin/ausearch -i -m AVC" > > > > type=SYSCALL msg=audit(02/13/2008 19:17:32.484:5097) : arch=i386 > > > > syscall=open success=no exit=-13(Permission denied) a0=8faf660 > > > > a1=8000 a2=1b6 a3=8fafa58 items=0 ppid=25427 pid=27015 auid=dant > > > > uid=root gid=root euid=root suid=root fsuid=root egid=root > > > > sgid=root fsgid=root tty=(none) comm=cvs exe=/usr/bin/cvs > > > > subj=system_u:system_r:cvs_t:s0-s0:c0.c1023 key=(null) > > > > type=AVC msg=audit(02/13/2008 19:17:32.484:5097) : avc: denied > > > > { read } for pid=27015 comm=cvs name=cvs dev=sdb5 ino=49172 > > > > scontext=system_u:system_r:cvs_t:s0-s0:c0.c1023 > > > > tcontext=system_u:object_r:default_t:s0 tclass=lnk_file > > > > > > > > Thanks for responding! > > > > Dan But of course, what about the symlink method? Is this now a moot issue and can be ignored? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwalsh at redhat.com Thu Feb 14 20:21:43 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 14 Feb 2008 15:21:43 -0500 Subject: qemu-kvm AVC In-Reply-To: <4c4ba1530802140758q65527229o68f4711b6ed65951@mail.gmail.com> References: <4c4ba1530802131151i29a2510q882575d7aec3d2b6@mail.gmail.com> <4c4ba1530802140758q65527229o68f4711b6ed65951@mail.gmail.com> Message-ID: <47B4A2D7.4090001@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom London wrote: > On Wed, Feb 13, 2008 at 11:51 AM, Tom London wrote: >> Hadn't run qemu-kvm for a bit. >> >> Now get this AVC (both enforcing/targeted): >> >> >> type=AVC msg=audit(1202932089.281:48): avc: denied { execmem } for >> pid=10351 comm="qemu-kvm" >> scontext=unconfined_u:unconfined_r:unconfined_t:s0 >> tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process >> type=SYSCALL msg=audit(1202932089.281:48): arch=40000003 syscall=125 >> success=no exit=-13 a0=8df0000 a1=1001000 a2=7 a3=a7d5358 items=0 >> ppid=3049 pid=10351 auid=500 uid=500 gid=500 euid=500 suid=500 >> fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts1 comm="qemu-kvm" >> exe="/usr/bin/qemu-kvm" subj=unconfined_u:unconfined_r:unconfined_t:s0 >> key=(null) >> >> Not sure if it interferes with anything.... >> > Believe this causes this: > > Feb 14 07:55:10 localhost kernel: qemu-kvm[7350] general protection > ip:80d6ffd sp:bfb48e40 error:0 in qemu-kvm[8047000+12d000] > Feb 14 07:55:10 localhost setroubleshoot: SELinux is preventing > qemu-kvm from changing a writable memory segment executable. For > complete SELinux messages. run sealert -l > f7ee40db-9506-48d2-bde6-396eb39ef085 > > There is a new boolean allow_unconfined_qemu_transition That will run qemu under a confined domain. So if you turn it on, you get execmem. Todays rawhide should give it execmem if the transition is off also. I use virt-manager to start my qemu. which runs them in a confined domain. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAke0otcACgkQrlYvE4MpobMCMgCgnsnXewf7pKdOS/HKf4+KUlNe ZcoAn2px7fqoSpEGnpJuQZ3jpMZqF+p8 =EsjB -----END PGP SIGNATURE----- From sds at tycho.nsa.gov Fri Feb 15 13:13:26 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 15 Feb 2008 08:13:26 -0500 Subject: CVS Servers [SOLVED] In-Reply-To: <1203018459.12883.61.camel@gold.cdkkt.com> References: <1202955827.12883.34.camel@gold.cdkkt.com> <1203013015.12883.41.camel@gold.cdkkt.com> <1203016416.12883.46.camel@gold.cdkkt.com> <1203016766.12883.50.camel@gold.cdkkt.com> <1203017146.12883.54.camel@gold.cdkkt.com> <1203018459.12883.61.camel@gold.cdkkt.com> Message-ID: <1203081206.16038.157.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2008-02-14 at 11:47 -0800, Daniel B. Thurman wrote: > > On Thu, 2008-02-14 at 11:25 -0800, Daniel B. Thurman wrote: > > > > On Thu, 2008-02-14 at 11:19 -0800, Daniel B. Thurman wrote: > > > > > > On Thu, 2008-02-14 at 11:13 -0800, Daniel B. Thurman wrote: > > > > > > > > On Thu, 2008-02-14 at 10:16 -0800, Daniel B. Thurman wrote: > > > > > > > > > > On Wed, 2008-02-13 at 18:23 -0800, Daniel B. Thurman wrote: > > > > > > In one of the Fedora CVS server setup, it says that if the > > > > > > administrator wants to use a simple pserver remote string > > > > > > such as: > > > > > > > > > > > > export CVSROOT=':pserver:@:/cvs' > > > > > > > > > > > > Then one has to: > > > > > > > > > > > > 1) /etc/xinetd.d/cvs: > > > > > > server_args = -f --allow-root=/cvs pserver > > > > > > 2) ln -s /var/cvs /cvs > > > > > > > > > > > > But the problem here is that SELinux has no context for > > > > > > the symbolic link /cvs, therefore deny's access. > > > > > > > > > > > > I tried setting context for /cvs by: > > > > > > 1) chcon -t cvs_data_t > > > > > > > > > > > > No dice. Does not work. > > > > > > > > > > > > To see if I can cvs login bypassing Selinux, I tried: > > > > > > 1) setenforce 0 > > > > > > 2) cvs login (successfully) > > > > > > 3) setenforce 1 > > > > > > > > > > > > So, what can I do to get SElinux to authorize the /cvs > > > > > > symbolic link access to /var/cvs? > > > > > > > > > > > > Thanks- > > > > > > Dan > > > > > > > > > > Apologies to all. It turns out that my email spam system was > > > > > blocking me from > > > > > receiving email responses I was waiting for! Geez, I will > > > > > have to add another > > > > > TODO to my list. > > > > > > > > > > To Paul: Can you explain what you mean by: "maybe try a bind > > > > > mount instead of a symlink?" > > > > > > > > I looked it up and understood a bind mount. Answer is nope! > > > > > > > > Bind mount: > > > > ======== > > Ok, the issue is solved. What I did not know is, you need to make > sure that when > you create an empty directory, you also need to make sure that the > ownership > of that directory is: cvs:cvs before bind mounting. So: > > 1) mkdir /cvs > 2) chown cvs:cvs /cvs > > then > > 3) mount --bind /var/cvs /cvs > > it all works now! > > > > > mount --bind /var/cvs /cvs > > > > > > > > ls -ldZ /cvs: > > > > ======= > > > > drwxr-xr-x cvs cvs system_u:object_r:cvs_t:s0 /cvs > > > > So, the context is right, but still get a Permissions denied. > > > > > > > > /sbin/ausearch -i -m AVC > > > > ================ > > > > type=SYSCALL msg=audit(02/14/2008 11:08:09.984:7732) : arch=i386 > > > > syscall=fchmodat success=no exit=-13(Permission denied) > > > > a0=ffffff9c a1=94848d8 a2=1fd a3=94848d8 items=0 ppid=23862 > > > > pid=20445 auid=dant uid=root gid=root euid=root suid=root > > > > fsuid=root egid=root sgid=root fsgid=root tty=pts7 comm=chmod > > > > exe=/bin/chmod subj=system_u:system_r:unconfined_t:s0 > > > > key=(null) > > > > type=AVC msg=audit(02/14/2008 11:08:09.984:7732) : avc: denied > > > > { setattr } for pid=20445 comm=chmod name=cvs dev=sdb5 > > > > ino=819450 scontext=system_u:system_r:unconfined_t:s0 > > > > tcontext=system_u:object_r:cvs_t:s0 tclass=dir > > > > > > Oh rats! This error above was for something else! My mistake!!!! > > > > > > I had to trying logging in at the remote system but failed several > > > times, > > > but after the 3rd try, I finally got in. Not sure why the login > > > process > > > stumbled. > > > > > > So, It DOES work! > > > > > > > But I am having a problem with getting Eclipse's SVN to open a > > single file: > > > > The server reported an error while performing the "cvs status" > > command. > > HelloWorld: cvs status: failed to create lock directory for > > `/cvs/Eclipse/C/Examples/HelloWorld' (/cvs/Eclipse/C/Examples/HelloWorld/#cvs.lock): Permission denied > > HelloWorld: cvs status: failed to obtain dir lock in repository > > `/cvs/Eclipse/C/Examples/HelloWorld' > > HelloWorld: cvs [status aborted]: read lock failed - giving up > > > > Not sure why it is not able to lock this file for > > checkout/examination. Any ideas? > > See note above... > > > > > > To Stephen: "/sbin/ausearch -i -m AVC" > > > > > type=SYSCALL msg=audit(02/13/2008 19:17:32.484:5097) : > > > > > arch=i386 syscall=open success=no exit=-13(Permission denied) > > > > > a0=8faf660 a1=8000 a2=1b6 a3=8fafa58 items=0 ppid=25427 > > > > > pid=27015 auid=dant uid=root gid=root euid=root suid=root > > > > > fsuid=root egid=root sgid=root fsgid=root tty=(none) comm=cvs > > > > > exe=/usr/bin/cvs subj=system_u:system_r:cvs_t:s0-s0:c0.c1023 > > > > > key=(null) > > > > > type=AVC msg=audit(02/13/2008 19:17:32.484:5097) : avc: > > > > > denied { read } for pid=27015 comm=cvs name=cvs dev=sdb5 > > > > > ino=49172 scontext=system_u:system_r:cvs_t:s0-s0:c0.c1023 > > > > > tcontext=system_u:object_r:default_t:s0 tclass=lnk_file > > > > > > > > > > Thanks for responding! > > > > > Dan > > But of course, what about the symlink method? > Is this now a moot issue and can be ignored? Did you try what I suggested for it? # semanage fcontext -a -t cvs_data_t /cvs # /sbin/restorecon -v /cvs -- Stephen Smalley National Security Agency From paul at city-fan.org Fri Feb 15 13:52:30 2008 From: paul at city-fan.org (Paul Howarth) Date: Fri, 15 Feb 2008 13:52:30 +0000 Subject: CVS Servers [SOLVED] In-Reply-To: <1203018459.12883.61.camel@gold.cdkkt.com> References: <1202955827.12883.34.camel@gold.cdkkt.com> <1203013015.12883.41.camel@gold.cdkkt.com> <1203016416.12883.46.camel@gold.cdkkt.com> <1203016766.12883.50.camel@gold.cdkkt.com> <1203017146.12883.54.camel@gold.cdkkt.com> <1203018459.12883.61.camel@gold.cdkkt.com> Message-ID: <47B5991E.7000702@city-fan.org> Daniel B. Thurman wrote: (snip) >>>> Bind mount: >>>> ======== > > > Ok, the issue is solved. What I did not know is, you need to make sure > that when > you create an empty directory, you also need to make sure that the > ownership > of that directory is: cvs:cvs before bind mounting. So: > > 1) mkdir /cvs > 2) chown cvs:cvs /cvs > > then > > 3) mount --bind /var/cvs /cvs > > it all works now! > > >>>> mount --bind /var/cvs /cvs >>>> >>>> ls -ldZ /cvs: >>>> ======= >>>> drwxr-xr-x cvs cvs system_u:object_r:cvs_t:s0 /cvs >>>> So, the context is right, but still get a Permissions denied. >>>> >>>> /sbin/ausearch -i -m AVC >>>> ================ >>>> type=SYSCALL msg=audit(02/14/2008 11:08:09.984:7732) : arch=i386 >>>> syscall=fchmodat success=no exit=-13(Permission denied) >>>> a0=ffffff9c a1=94848d8 a2=1fd a3=94848d8 items=0 ppid=23862 >>>> pid=20445 auid=dant uid=root gid=root euid=root suid=root >>>> fsuid=root egid=root sgid=root fsgid=root tty=pts7 comm=chmod >>>> exe=/bin/chmod subj=system_u:system_r:unconfined_t:s0 key=(null) >>>> type=AVC msg=audit(02/14/2008 11:08:09.984:7732) : avc: denied >>>> { setattr } for pid=20445 comm=chmod name=cvs dev=sdb5 ino=819450 >>>> scontext=system_u:system_r:unconfined_t:s0 >>>> tcontext=system_u:object_r:cvs_t:s0 tclass=dir >>> >>> Oh rats! This error above was for something else! My mistake!!!! >>> >>> I had to trying logging in at the remote system but failed several >>> times, >>> but after the 3rd try, I finally got in. Not sure why the login >>> process >>> stumbled. >>> >>> So, It DOES work! >>> >> >> But I am having a problem with getting Eclipse's SVN to open a single >> file: >> >> The server reported an error while performing the "cvs status" >> command. >> HelloWorld: cvs status: failed to create lock directory for >> `/cvs/Eclipse/C/Examples/HelloWorld' (/cvs/Eclipse/C/Examples/HelloWorld/#cvs.lock): Permission denied >> HelloWorld: cvs status: failed to obtain dir lock in repository >> `/cvs/Eclipse/C/Examples/HelloWorld' >> HelloWorld: cvs [status aborted]: read lock failed - giving up >> >> Not sure why it is not able to lock this file for >> checkout/examination. Any ideas? > > > See note above... > > >>>>> To Stephen: "/sbin/ausearch -i -m AVC" >>>>> type=SYSCALL msg=audit(02/13/2008 19:17:32.484:5097) : arch=i386 >>>>> syscall=open success=no exit=-13(Permission denied) a0=8faf660 >>>>> a1=8000 a2=1b6 a3=8fafa58 items=0 ppid=25427 pid=27015 auid=dant >>>>> uid=root gid=root euid=root suid=root fsuid=root egid=root >>>>> sgid=root fsgid=root tty=(none) comm=cvs exe=/usr/bin/cvs >>>>> subj=system_u:system_r:cvs_t:s0-s0:c0.c1023 key=(null) >>>>> type=AVC msg=audit(02/13/2008 19:17:32.484:5097) : avc: denied >>>>> { read } for pid=27015 comm=cvs name=cvs dev=sdb5 ino=49172 >>>>> scontext=system_u:system_r:cvs_t:s0-s0:c0.c1023 >>>>> tcontext=system_u:object_r:default_t:s0 tclass=lnk_file >>>>> >>>>> Thanks for responding! >>>>> Dan > > > But of course, what about the symlink method? > Is this now a moot issue and can be ignored? The policy rules for symlinks are distinct from those for regular files, directories etc. So when the usual, expected filesystem layout for an application and its data doesn't use a symlink, there's unlikely to be selinux policy for following syminks for that application. The admin's old trick of shuffling data around and putting a symlink to the new location from the old location probably needs to be accompanied in most cases by local policy modifications to establish the contexts for files in the new locations, and to allow the symlink to be followed. Paul. From dwalsh at redhat.com Fri Feb 15 14:29:37 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 15 Feb 2008 09:29:37 -0500 Subject: CVS Servers [SOLVED] In-Reply-To: <47B5991E.7000702@city-fan.org> References: <1202955827.12883.34.camel@gold.cdkkt.com> <1203013015.12883.41.camel@gold.cdkkt.com> <1203016416.12883.46.camel@gold.cdkkt.com> <1203016766.12883.50.camel@gold.cdkkt.com> <1203017146.12883.54.camel@gold.cdkkt.com> <1203018459.12883.61.camel@gold.cdkkt.com> <47B5991E.7000702@city-fan.org> Message-ID: <47B5A1D1.9050604@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Howarth wrote: > Daniel B. Thurman wrote: > (snip) > >>>>> Bind mount: >>>>> ======== >> >> >> Ok, the issue is solved. What I did not know is, you need to make sure >> that when >> you create an empty directory, you also need to make sure that the >> ownership >> of that directory is: cvs:cvs before bind mounting. So: >> >> 1) mkdir /cvs >> 2) chown cvs:cvs /cvs >> >> then >> >> 3) mount --bind /var/cvs /cvs >> >> it all works now! >> >> >>>>> mount --bind /var/cvs /cvs >>>>> >>>>> ls -ldZ /cvs: >>>>> ======= >>>>> drwxr-xr-x cvs cvs system_u:object_r:cvs_t:s0 /cvs >>>>> So, the context is right, but still get a Permissions denied. >>>>> >>>>> /sbin/ausearch -i -m AVC >>>>> ================ >>>>> type=SYSCALL msg=audit(02/14/2008 11:08:09.984:7732) : arch=i386 >>>>> syscall=fchmodat success=no exit=-13(Permission denied) >>>>> a0=ffffff9c a1=94848d8 a2=1fd a3=94848d8 items=0 ppid=23862 >>>>> pid=20445 auid=dant uid=root gid=root euid=root suid=root >>>>> fsuid=root egid=root sgid=root fsgid=root tty=pts7 comm=chmod >>>>> exe=/bin/chmod subj=system_u:system_r:unconfined_t:s0 key=(null) >>>>> type=AVC msg=audit(02/14/2008 11:08:09.984:7732) : avc: denied >>>>> { setattr } for pid=20445 comm=chmod name=cvs dev=sdb5 ino=819450 >>>>> scontext=system_u:system_r:unconfined_t:s0 >>>>> tcontext=system_u:object_r:cvs_t:s0 tclass=dir >>>> >>>> Oh rats! This error above was for something else! My mistake!!!! >>>> >>>> I had to trying logging in at the remote system but failed several >>>> times, >>>> but after the 3rd try, I finally got in. Not sure why the login >>>> process >>>> stumbled. >>>> >>>> So, It DOES work! >>>> >>> >>> But I am having a problem with getting Eclipse's SVN to open a single >>> file: >>> >>> The server reported an error while performing the "cvs status" >>> command. >>> HelloWorld: cvs status: failed to create lock directory for >>> `/cvs/Eclipse/C/Examples/HelloWorld' >>> (/cvs/Eclipse/C/Examples/HelloWorld/#cvs.lock): Permission denied >>> HelloWorld: cvs status: failed to obtain dir lock in repository >>> `/cvs/Eclipse/C/Examples/HelloWorld' >>> HelloWorld: cvs [status aborted]: read lock failed - giving up >>> >>> Not sure why it is not able to lock this file for >>> checkout/examination. Any ideas? >> >> >> See note above... >> >> >>>>>> To Stephen: "/sbin/ausearch -i -m AVC" >>>>>> type=SYSCALL msg=audit(02/13/2008 19:17:32.484:5097) : arch=i386 >>>>>> syscall=open success=no exit=-13(Permission denied) a0=8faf660 >>>>>> a1=8000 a2=1b6 a3=8fafa58 items=0 ppid=25427 pid=27015 auid=dant >>>>>> uid=root gid=root euid=root suid=root fsuid=root egid=root >>>>>> sgid=root fsgid=root tty=(none) comm=cvs exe=/usr/bin/cvs >>>>>> subj=system_u:system_r:cvs_t:s0-s0:c0.c1023 key=(null) type=AVC >>>>>> msg=audit(02/13/2008 19:17:32.484:5097) : avc: denied >>>>>> { read } for pid=27015 comm=cvs name=cvs dev=sdb5 ino=49172 >>>>>> scontext=system_u:system_r:cvs_t:s0-s0:c0.c1023 >>>>>> tcontext=system_u:object_r:default_t:s0 tclass=lnk_file >>>>>> Thanks for responding! >>>>>> Dan >> >> >> But of course, what about the symlink method? >> Is this now a moot issue and can be ignored? > > The policy rules for symlinks are distinct from those for regular files, > directories etc. So when the usual, expected filesystem layout for an > application and its data doesn't use a symlink, there's unlikely to be > selinux policy for following syminks for that application. > > The admin's old trick of shuffling data around and putting a symlink to > the new location from the old location probably needs to be accompanied > in most cases by local policy modifications to establish the contexts > for files in the new locations, and to allow the symlink to be followed. > > Paul. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Or use newer methods use LVM to easily add disk space or bind mounts. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAke1odEACgkQrlYvE4MpobNCCwCfSWXY6DwUBG0q7mIOnX95yDHF rIwAnj5DiPbuhOy3vw2aKK9sBHPDypge =fXrb -----END PGP SIGNATURE----- From dant at cdkkt.com Fri Feb 15 16:49:46 2008 From: dant at cdkkt.com (Daniel B. Thurman) Date: Fri, 15 Feb 2008 08:49:46 -0800 Subject: CVS Servers [SOLVED] Message-ID: <021126B987E43D44A860139823C079110E2CBC@ns1.cdkkt.com> Daniel J Walsh wrote: >Paul Howarth wrote: >> Daniel B. Thurman wrote: >>>>>> Bind mount: >>>>>> ======== >>> >>> Ok, the issue is solved. What I did not know is, you >>> need to make sure that when you create an empty directory, >>> you also need to make sure that the ownership of that >>> directory is: cvs:cvs before bind mounting. So: >>> >>> 1) mkdir /cvs >>> 2) chown cvs:cvs /cvs >>> >>> then >>> >>> 3) mount --bind /var/cvs /cvs >>> >>> it all works now! >>> >>>>>> mount --bind /var/cvs /cvs >>>>>> [snip!] One more issue: How to I make the bind-mount permenant, i.e. do I need to add this to fstab and if so, how? Dan: As far a LVM, I do not use it. I haven't yet learned of it's benefits so I have not applied it to my current filesystems for fear of blowing up my current installation. No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.5/1279 - Release Date: 2/14/2008 6:35 PM From paul at city-fan.org Fri Feb 15 16:56:20 2008 From: paul at city-fan.org (Paul Howarth) Date: Fri, 15 Feb 2008 16:56:20 +0000 Subject: CVS Servers [SOLVED] In-Reply-To: <021126B987E43D44A860139823C079110E2CBC@ns1.cdkkt.com> References: <021126B987E43D44A860139823C079110E2CBC@ns1.cdkkt.com> Message-ID: <47B5C434.9050303@city-fan.org> Daniel B. Thurman wrote: > Daniel J Walsh wrote: >> Paul Howarth wrote: >>> Daniel B. Thurman wrote: >>>>>>> Bind mount: >>>>>>> ====== >>>> Ok, the issue is solved. What I did not know is, you >>>> need to make sure that when you create an empty directory, >>>> you also need to make sure that the ownership of that >>>> directory is: cvs:cvs before bind mounting. So: >>>> >>>> 1) mkdir /cvs >>>> 2) chown cvs:cvs /cvs >>>> >>>> then >>>> >>>> 3) mount --bind /var/cvs /cvs >>>> >>>> it all works now! >>>> >>>>>>> mount --bind /var/cvs /cvs >>>>>>> > [snip!] > > One more issue: How to I make the bind-mount permenant, > i.e. do I need to add this to fstab and if so, how? Here's an example from one of my boxes: /home/local /usr/local auto bind 0 0 > Dan: As far a LVM, I do not use it. I haven't yet learned of > it's benefits so I have not applied it to my current filesystems > for fear of blowing up my current installation. I use LVM over RADI1 on most of my machines these days. I use separate filesystems for /, /usr, /tmp, /home, /var, swap, and /srv, only make them as big as I expect them to be in the medium term (i.e. leaving unallocated space in the volume group) and then extend their sizes as and when it's necessary. Paul. From cmadams at hiwaay.net Fri Feb 15 17:03:20 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 15 Feb 2008 11:03:20 -0600 Subject: SELinux module to allow a single network port? Message-ID: <20080215170320.GA1336794@hiwaay.net> I originally posted this to the RHEL5 list, but someone pointed me to this list (I didn't realize there was an SELinux list). I have done some minor SELinux customizations with a module, and now I'm trying to do something a little more complicated. I want to allow a CGI to do a "whois" lookup. It is a perl script that is attempting to open a TCP socket to port 43. I ran audit2allow, but I think the generated rule allows CGIs to open outbound sockets to any port. I'd rather just allow TCP to port 43. I don't see a defined whois port type, and I don't know quite how to define it myself in a module. Help? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From sds at tycho.nsa.gov Fri Feb 15 18:26:42 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 15 Feb 2008 13:26:42 -0500 Subject: SELinux module to allow a single network port? In-Reply-To: <20080215170320.GA1336794@hiwaay.net> References: <20080215170320.GA1336794@hiwaay.net> Message-ID: <1203100002.16038.230.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2008-02-15 at 11:03 -0600, Chris Adams wrote: > I originally posted this to the RHEL5 list, but someone pointed me to > this list (I didn't realize there was an SELinux list). > > I have done some minor SELinux customizations with a module, and now I'm > trying to do something a little more complicated. > > I want to allow a CGI to do a "whois" lookup. It is a perl script that > is attempting to open a TCP socket to port 43. I ran audit2allow, but I > think the generated rule allows CGIs to open outbound sockets to any > port. I'd rather just allow TCP to port 43. > > I don't see a defined whois port type, and I don't know quite how to > define it myself in a module. > > Help? Possibly something like this: $ vi whois.te policy_module(whois, 1.0) type whois_port_t, port_type; :wq $ make -f /usr/share/selinux/devel/Makefile whois.pp $ su # semodule -i whois.pp # semanage port -a -t whois_port_t -p tcp 43 -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Fri Feb 15 18:33:47 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 15 Feb 2008 13:33:47 -0500 Subject: SELinux module to allow a single network port? In-Reply-To: <1203100002.16038.230.camel@moss-spartans.epoch.ncsc.mil> References: <20080215170320.GA1336794@hiwaay.net> <1203100002.16038.230.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1203100427.16038.236.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2008-02-15 at 13:26 -0500, Stephen Smalley wrote: > On Fri, 2008-02-15 at 11:03 -0600, Chris Adams wrote: > > I originally posted this to the RHEL5 list, but someone pointed me to > > this list (I didn't realize there was an SELinux list). > > > > I have done some minor SELinux customizations with a module, and now I'm > > trying to do something a little more complicated. > > > > I want to allow a CGI to do a "whois" lookup. It is a perl script that > > is attempting to open a TCP socket to port 43. I ran audit2allow, but I > > think the generated rule allows CGIs to open outbound sockets to any > > port. I'd rather just allow TCP to port 43. > > > > I don't see a defined whois port type, and I don't know quite how to > > define it myself in a module. > > > > Help? > > Possibly something like this: > > $ vi whois.te > policy_module(whois, 1.0) You'd also need a require statement here, ala: require { attribute port_type; } > type whois_port_t, port_type; > :wq > $ make -f /usr/share/selinux/devel/Makefile whois.pp > $ su > # semodule -i whois.pp > # semanage port -a -t whois_port_t -p tcp 43 > -- Stephen Smalley National Security Agency From cmadams at hiwaay.net Fri Feb 15 19:16:34 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 15 Feb 2008 13:16:34 -0600 Subject: SELinux module to allow a single network port? In-Reply-To: <1203100002.16038.230.camel@moss-spartans.epoch.ncsc.mil> References: <20080215170320.GA1336794@hiwaay.net> <1203100002.16038.230.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20080215191634.GC1336794@hiwaay.net> Once upon a time, Stephen Smalley said: > # semanage port -a -t whois_port_t -p tcp 43 This was the part I was missing; I have it working now. Thanks! -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From shintaro.fujiwara at gmail.com Sat Feb 16 23:12:56 2008 From: shintaro.fujiwara at gmail.com (Shintaro Fujiwara) Date: Sun, 17 Feb 2008 08:12:56 +0900 Subject: [ANN]segatex-4.90 released Message-ID: I released segatex-4.90. Incorporated policygentool. It generates files, but when you do not set path, modules will fail when you try to install it. I will fix this problem on segatex-5.0. Please wait. But, you can edit files so if you are interested, please try and have some fun. -- http://intrajp.no-ip.com/ Home Page -------------- next part -------------- An HTML attachment was scrubbed... URL: From dant at cdkkt.com Sun Feb 17 22:28:32 2008 From: dant at cdkkt.com (Daniel B. Thurman) Date: Sun, 17 Feb 2008 14:28:32 -0800 Subject: [F8] (Re)Starting httpd reveals php pdf.so stack permission errors... Message-ID: <1203287312.21982.3.camel@gold.cdkkt.com> # setenforce 1 (If set to 0, no following errors are generated) # service httpd restart /etc/log/httpd/errors_log: ================= PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/pdf.so' - libpdf.so.6: cannot enable executable stack as shared object requires: Permission denied in Unknown on line 0 # ls -lZ /usr/lib/php/modules/pdf.so -rwxr-xr-x root root system_u:object_r:textrel_shlib_t:s0 /usr/lib/php/modules/pdf.so # find / -xdev -name libpdf.so.6 /etc/log/audit/audit_log: =============== type=AVC msg=audit(1203285527.123:3893): avc: denied { execstack } for pid=21241 comm="httpd" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_t:s0 tclass=process type=SYSCALL msg=audit(1203285527.123:3893): arch=40000003 syscall=125 success=no exit=-13 a0=bfca1000 a1=1000 a2=1000007 a3=fffff000 items=0 ppid=1 pid=21241 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="httpd" exe="/usr/sbin/httpd" subj=system_u:system_r:httpd_t:s0 key=(null) SEAlert: ================================================= Summary SELinux is preventing /usr/sbin/httpd (httpd_t) "execstack" to (httpd_t). Detailed Description SELinux denied access requested by /usr/sbin/httpd. It is not expected that this access is required by /usr/sbin/httpd 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:httpd_t:s0 Target Context system_u:system_r:httpd_t:s0 Target Objects None [ process ] Affected RPM Packages httpd-2.2.8-1.fc8 [application] Policy RPM selinux-policy-3.0.8-84.fc8 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.catchall Host Name gold.cdkkt.com Platform Linux gold.cdkkt.com 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:48:34 EST 2008 i686 i686 Alert Count 10 First Seen Sun 17 Feb 2008 04:50:41 AM PST Last Seen Sun 17 Feb 2008 01:46:21 PM PST Local ID b2d0de85-f78b-4945-8d01-1ef26660fe47 Line Numbers Raw Audit Messages avc: denied { execstack } for comm=httpd egid=0 euid=0 exe=/usr/sbin/httpd exit=-13 fsgid=0 fsuid=0 gid=0 items=0 pid=20396 scontext=system_u:system_r:httpd_t:s0 sgid=0 subj=system_u:system_r:httpd_t:s0 suid=0 tclass=process tcontext=system_u:system_r:httpd_t:s0 tty=(none) uid=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwalsh at redhat.com Mon Feb 18 14:31:45 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 18 Feb 2008 09:31:45 -0500 Subject: [F8] (Re)Starting httpd reveals php pdf.so stack permission errors... In-Reply-To: <1203287312.21982.3.camel@gold.cdkkt.com> References: <1203287312.21982.3.camel@gold.cdkkt.com> Message-ID: <47B996D1.2040003@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel B. Thurman wrote: > # setenforce 1 (If set to 0, no following errors are generated) > # service httpd restart > > > /etc/log/httpd/errors_log: > ================= > PHP Warning: PHP Startup: Unable to load dynamic library > '/usr/lib/php/modules/pdf.so' - libpdf.so.6: cannot enable executable > stack as shared object requires: Permission denied in Unknown on line 0 > > # ls -lZ /usr/lib/php/modules/pdf.so > -rwxr-xr-x root root > system_u:object_r:textrel_shlib_t:s0 /usr/lib/php/modules/pdf.so > > # find / -xdev -name libpdf.so.6 > > > /etc/log/audit/audit_log: > =============== > type=AVC msg=audit(1203285527.123:3893): avc: denied { execstack } for > pid=21241 comm="httpd" scontext=system_u:system_r:httpd_t:s0 > tcontext=system_u:system_r:httpd_t:s0 tclass=process > type=SYSCALL msg=audit(1203285527.123:3893): arch=40000003 syscall=125 > success=no exit=-13 a0=bfca1000 a1=1000 a2=1000007 a3=fffff000 items=0 > ppid=1 pid=21241 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=(none) comm="httpd" exe="/usr/sbin/httpd" > subj=system_u:system_r:httpd_t:s0 key=(null) > > SEAlert: > ================================================= > Summary > SELinux is preventing /usr/sbin/httpd (httpd_t) "execstack" to > > (httpd_t). > > Detailed Description > SELinux denied access requested by /usr/sbin/httpd. It is not > expected that > this access is required by /usr/sbin/httpd 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:httpd_t:s0 > Target Context system_u:system_r:httpd_t:s0 > Target Objects None [ process ] > Affected RPM Packages httpd-2.2.8-1.fc8 [application] > Policy RPM selinux-policy-3.0.8-84.fc8 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name plugins.catchall > Host Name gold.cdkkt.com > Platform Linux gold.cdkkt.com 2.6.23.15-137.fc8 #1 > SMP Sun > Feb 10 17:48:34 EST 2008 i686 i686 > Alert Count 10 > First Seen Sun 17 Feb 2008 04:50:41 AM PST > Last Seen Sun 17 Feb 2008 01:46:21 PM PST > Local ID b2d0de85-f78b-4945-8d01-1ef26660fe47 > Line Numbers > > Raw Audit Messages > > avc: denied { execstack } for comm=httpd egid=0 euid=0 > exe=/usr/sbin/httpd > exit=-13 fsgid=0 fsuid=0 gid=0 items=0 pid=20396 > scontext=system_u:system_r:httpd_t:s0 sgid=0 > subj=system_u:system_r:httpd_t:s0 > suid=0 tclass=process tcontext=system_u:system_r:httpd_t:s0 tty=(none) > uid=0 > > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list This should be reported as a bug to whoever supplied /usr/lib/php/modules/pdf.so You can try execstack -c /usr/lib/php/modules/pdf.so And see if that removes th problem. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAke5ltAACgkQrlYvE4MpobMdyACeKMpU5KQQYKxXsuC/6dEflZhh N1wAoINBYK6BTSuYC/9Kcg4zuW//9D9w =n+th -----END PGP SIGNATURE----- From dant at cdkkt.com Mon Feb 18 16:57:23 2008 From: dant at cdkkt.com (Daniel B. Thurman) Date: Mon, 18 Feb 2008 08:57:23 -0800 Subject: [F8] (Re)Starting httpd reveals php pdf.so stack permission errors... In-Reply-To: <47B996D1.2040003@redhat.com> References: <1203287312.21982.3.camel@gold.cdkkt.com> <47B996D1.2040003@redhat.com> Message-ID: <1203353843.21982.5.camel@gold.cdkkt.com> On Mon, 2008-02-18 at 06:31 -0800, Daniel J Walsh wrote: > execstack -c /usr/lib/php/modules/pdf.so I tried it. No change. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekuns at kilroy.chi.il.us Mon Feb 18 19:29:04 2008 From: ekuns at kilroy.chi.il.us (Edward Kuns) Date: Mon, 18 Feb 2008 13:29:04 -0600 Subject: mailman doesn't receive messages from sendmail on fresh F8 install Message-ID: <1203362944.3900.21.camel@kilroy.chi.il.us> I freshly installed F8 on a new box, then copied the mailman and sendmail configuration over from the old box. I made sure everything was labeled correctly with "restorecon -r -v /etc" and the same for /var where mailman lives. The web pages work, but if I try to send a message to any list, I get SELinux alerts that prevent the message from going through. I don't believe I was using selinux on the old machine. I know I could just set selinux to permissive mode and this would probably work, but I'd rather understand what the problem is and fix it. Below are the selinux complaints generated from trying to send to the mailman test list on my server: Any ideas on what I can do to fix this? I've been googling for a couple hours and haven't found anything that fits this situation exactly. Thanks Eddie Summary SELinux is preventing python (sendmail_t) "search" to (mailman_log_t). Detailed Description SELinux denied access requested by python. It is not expected that this access is required by python and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for , restorecon -v If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Additional Information Source Context system_u:system_r:sendmail_t:s0 Target Context system_u:object_r:mailman_log_t:s0 Target Objects None [ dir ] Affected RPM Packages Policy RPM selinux-policy-3.0.8-84.fc8 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.catchall_file Host Name kilroy.chi.il.us Platform Linux kilroy.chi.il.us 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:48:34 EST 2008 i686 i686 Alert Count 15 First Seen Mon 18 Feb 2008 09:18:28 AM CST Last Seen Mon 18 Feb 2008 01:06:39 PM CST Local ID 78d260f8-f1d3-49b3-bea6-bc0cc400735c Line Numbers Raw Audit Messages avc: denied { search } for comm=python dev=dm-2 egid=41 euid=8 exe=/usr/bin/python exit=-13 fsgid=41 fsuid=8 gid=41 items=0 name=mailman pid=12198 scontext=system_u:system_r:sendmail_t:s0 sgid=41 subj=system_u:system_r:sendmail_t:s0 suid=8 tclass=dir tcontext=system_u:object_r:mailman_log_t:s0 tty=(none) uid=8 Summary SELinux is preventing python (sendmail_t) "getattr" to /var/lib/mailman/lists/mailman/config.pck (mailman_data_t). Detailed Description SELinux denied access requested by python. It is not expected that this access is required by python and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /var/lib/mailman/lists/mailman/config.pck, restorecon -v /var/lib/mailman/lists/mailman/config.pck If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Additional Information Source Context system_u:system_r:sendmail_t:s0 Target Context system_u:object_r:mailman_data_t:s0 Target Objects /var/lib/mailman/lists/mailman/config.pck [ file ] Affected RPM Packages Policy RPM selinux-policy-3.0.8-84.fc8 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.catchall_file Host Name kilroy.chi.il.us Platform Linux kilroy.chi.il.us 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:48:34 EST 2008 i686 i686 Alert Count 1 First Seen Mon 18 Feb 2008 01:06:39 PM CST Last Seen Mon 18 Feb 2008 01:06:39 PM CST Local ID 5d954998-3826-4af2-9569-0295ae134c27 Line Numbers Raw Audit Messages avc: denied { getattr } for comm=python dev=dm-2 egid=41 euid=8 exe=/usr/bin/python exit=-13 fsgid=41 fsuid=8 gid=41 items=0 path=/var/lib/mailman/lists/mailman/config.pck pid=12198 scontext=system_u:system_r:sendmail_t:s0 sgid=41 subj=system_u:system_r:sendmail_t:s0 suid=8 tclass=file tcontext=system_u:object_r:mailman_data_t:s0 tty=(none) uid=8 Summary SELinux is preventing python (sendmail_t) "getattr" to /var/lib/mailman/lists/mailman/config.pck.last (mailman_data_t). Detailed Description SELinux denied access requested by python. It is not expected that this access is required by python and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /var/lib/mailman/lists/mailman/config.pck.last, restorecon -v /var/lib/mailman/lists/mailman/config.pck.last If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Additional Information Source Context system_u:system_r:sendmail_t:s0 Target Context system_u:object_r:mailman_data_t:s0 Target Objects /var/lib/mailman/lists/mailman/config.pck.last [ file ] Affected RPM Packages Policy RPM selinux-policy-3.0.8-84.fc8 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.catchall_file Host Name kilroy.chi.il.us Platform Linux kilroy.chi.il.us 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:48:34 EST 2008 i686 i686 Alert Count 1 First Seen Mon 18 Feb 2008 01:06:39 PM CST Last Seen Mon 18 Feb 2008 01:06:39 PM CST Local ID 37d2b949-06bf-4cb0-845e-6aa41a16076c Line Numbers Raw Audit Messages avc: denied { getattr } for comm=python dev=dm-2 egid=41 euid=8 exe=/usr/bin/python exit=-13 fsgid=41 fsuid=8 gid=41 items=0 path=/var/lib/mailman/lists/mailman/config.pck.last pid=12198 scontext=system_u:system_r:sendmail_t:s0 sgid=41 subj=system_u:system_r:sendmail_t:s0 suid=8 tclass=file tcontext=system_u:object_r:mailman_data_t:s0 tty=(none) uid=8 From dwalsh at redhat.com Mon Feb 18 20:32:38 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 18 Feb 2008 15:32:38 -0500 Subject: [F8] (Re)Starting httpd reveals php pdf.so stack permission errors... In-Reply-To: <1203353843.21982.5.camel@gold.cdkkt.com> References: <1203287312.21982.3.camel@gold.cdkkt.com> <47B996D1.2040003@redhat.com> <1203353843.21982.5.camel@gold.cdkkt.com> Message-ID: <47B9EB66.4000806@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel B. Thurman wrote: > On Mon, 2008-02-18 at 06:31 -0800, Daniel J Walsh wrote: > >> execstack -c /usr/lib/php/modules/pdf.so > > > I tried it. No change. > > Ok you can add this rule via audit2allow # grep execstack /var/log/audit/audit.log | audit2allow -m myphp # semodule -i myphp.pp But you should report this as a bug against /usr/lib/php/modules/pdf.so Attach this link http://people.redhat.com/~drepper/selinux-mem.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAke562YACgkQrlYvE4MpobNgTgCguCSkIHwux+3o1xWZ8BVKXT81 NSYAniS2zPG9LDJzKEdtU52SAiibYA5W =2rZG -----END PGP SIGNATURE----- From dant at cdkkt.com Mon Feb 18 23:53:37 2008 From: dant at cdkkt.com (Daniel B. Thurman) Date: Mon, 18 Feb 2008 15:53:37 -0800 Subject: [F8] (Re)Starting httpd reveals php pdf.so stack permission errors... In-Reply-To: <47B9EB66.4000806@redhat.com> References: <1203287312.21982.3.camel@gold.cdkkt.com> <47B996D1.2040003@redhat.com> <1203353843.21982.5.camel@gold.cdkkt.com> <47B9EB66.4000806@redhat.com> Message-ID: <1203378817.21982.8.camel@gold.cdkkt.com> On Mon, 2008-02-18 at 12:32 -0800, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Daniel B. Thurman wrote: > > On Mon, 2008-02-18 at 06:31 -0800, Daniel J Walsh wrote: > > > >> execstack -c /usr/lib/php/modules/pdf.so > > > > > > I tried it. No change. > > > > > Ok you can add this rule via audit2allow > > # grep execstack /var/log/audit/audit.log | audit2allow -m myphp > # semodule -i myphp.pp > > But you should report this as a bug > against /usr/lib/php/modules/pdf.so > > Attach this link Uh, I did the following steps: 1) execstack -c /usr/lib/php/modules/pdf.so 2) grep execstack /var/log/audit/audit.log | grep audit2allow -m myphp grep: invalid max count 3) semodule -i myphp.pp semodule: Could not read file 'myphp.pp': No such file or directory Somehow, this is not what you wanted? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmz at pobox.com Tue Feb 19 00:43:51 2008 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 18 Feb 2008 19:43:51 -0500 Subject: [F8] (Re)Starting httpd reveals php pdf.so stack permission errors... In-Reply-To: <1203378817.21982.8.camel@gold.cdkkt.com> References: <1203287312.21982.3.camel@gold.cdkkt.com> <47B996D1.2040003@redhat.com> <1203353843.21982.5.camel@gold.cdkkt.com> <47B9EB66.4000806@redhat.com> <1203378817.21982.8.camel@gold.cdkkt.com> Message-ID: <20080219004351.GC3875@inocybe.teonanacatl.org> Daniel B. Thurman wrote: > 1) execstack -c /usr/lib/php/modules/pdf.so > > 2) grep execstack /var/log/audit/audit.log | grep audit2allow -m myphp this > ^^^^ causes this: > grep: invalid max count You're calling grep rather than audit2allow as intended. Remove the grep after the pipe. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ You can get more with a kind word and a gun than you can with a kind word alone. -- Al Capone (1899-1947) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From dant at cdkkt.com Tue Feb 19 00:56:13 2008 From: dant at cdkkt.com (Daniel B. Thurman) Date: Mon, 18 Feb 2008 16:56:13 -0800 Subject: [F8] (Re)Starting httpd reveals php pdf.so stack permission errors... In-Reply-To: <20080219004351.GC3875@inocybe.teonanacatl.org> References: <1203287312.21982.3.camel@gold.cdkkt.com> <47B996D1.2040003@redhat.com> <1203353843.21982.5.camel@gold.cdkkt.com> <47B9EB66.4000806@redhat.com> <1203378817.21982.8.camel@gold.cdkkt.com> <20080219004351.GC3875@inocybe.teonanacatl.org> Message-ID: <1203382573.21982.11.camel@gold.cdkkt.com> On Mon, 2008-02-18 at 16:43 -0800, Todd Zullinger wrote: > Daniel B. Thurman wrote: > > 1) execstack -c /usr/lib/php/modules/pdf.so > > > > 2) grep execstack /var/log/audit/audit.log | grep audit2allow -m > myphp > this > ^^^^ > > causes this: > > > grep: invalid max count > > You're calling grep rather than audit2allow as intended. Remove the > grep after the pipe. > Ok.... I tried: 1) grep execstack /var/log/audit/audit.log | audit2allow -m myphp module myphp 1.0; 2) semodule -i myphp.pp semodule: Could not read file 'myphp.pp': No such file or directory Seems that the myphp.pp file is never created, at least I cannot find it.... -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmz at pobox.com Tue Feb 19 01:14:36 2008 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 18 Feb 2008 20:14:36 -0500 Subject: [F8] (Re)Starting httpd reveals php pdf.so stack permission errors... In-Reply-To: <1203382573.21982.11.camel@gold.cdkkt.com> References: <1203287312.21982.3.camel@gold.cdkkt.com> <47B996D1.2040003@redhat.com> <1203353843.21982.5.camel@gold.cdkkt.com> <47B9EB66.4000806@redhat.com> <1203378817.21982.8.camel@gold.cdkkt.com> <20080219004351.GC3875@inocybe.teonanacatl.org> <1203382573.21982.11.camel@gold.cdkkt.com> Message-ID: <20080219011436.GD3875@inocybe.teonanacatl.org> Daniel B. Thurman wrote: > Ok.... > > I tried: > > 1) grep execstack /var/log/audit/audit.log | audit2allow -m myphp > > module myphp 1.0; > > 2) semodule -i myphp.pp > semodule: Could not read file 'myphp.pp': No such file or directory > > Seems that the myphp.pp file is never created, at least I cannot > find it.... You want -M instead of -m as the argument to audit2allow AFAIK. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Many people are secretly interested in life. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From dant at cdkkt.com Tue Feb 19 01:35:48 2008 From: dant at cdkkt.com (Daniel B. Thurman) Date: Mon, 18 Feb 2008 17:35:48 -0800 Subject: [F8] (Re)Starting httpd reveals php pdf.so stack permission errors... In-Reply-To: <20080219011436.GD3875@inocybe.teonanacatl.org> References: <1203287312.21982.3.camel@gold.cdkkt.com> <47B996D1.2040003@redhat.com> <1203353843.21982.5.camel@gold.cdkkt.com> <47B9EB66.4000806@redhat.com> <1203378817.21982.8.camel@gold.cdkkt.com> <20080219004351.GC3875@inocybe.teonanacatl.org> <1203382573.21982.11.camel@gold.cdkkt.com> <20080219011436.GD3875@inocybe.teonanacatl.org> Message-ID: <1203384948.21982.17.camel@gold.cdkkt.com> On Mon, 2008-02-18 at 17:14 -0800, Todd Zullinger wrote: > Daniel B. Thurman wrote: > > Ok.... > > > > I tried: > > > > 1) grep execstack /var/log/audit/audit.log | audit2allow -m myphp > > > > module myphp 1.0; > > > > 2) semodule -i myphp.pp > > semodule: Could not read file 'myphp.pp': No such file or > directory > > > > Seems that the myphp.pp file is never created, at least I cannot > > find it.... > > You want -M instead of -m as the argument to audit2allow AFAIK. > ok... 3rd try: 1) grep execstack /var/log/audit/audit.log | audit2allow -M myphp compilation failed: (unknown source)::ERROR 'syntax error' at token '' on line 6: /usr/bin/checkmodule: error(s) encountered while parsing configuration /usr/bin/checkmodule: loading policy configuration from myphp.te 2) semodule -i myphp.pp semodule: Could not read file 'myphp.pp': No such file or directory -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekuns at kilroy.chi.il.us Tue Feb 19 02:09:00 2008 From: ekuns at kilroy.chi.il.us (Edward Kuns) Date: Mon, 18 Feb 2008 20:09:00 -0600 Subject: Selinux config to get linuxprinter working under Fedora 8 Message-ID: <1203386940.3900.58.camel@kilroy.chi.il.us> I added the following configuration (via system-config-selinux) to /etc/selinux/targeted/contexts/files/file_contexts.local and this appears sufficient to get printing working for my Samsung CLP-500 printer using the drivers provided by the manufacturer. These drivers install partially under /opt/Samsung/mfp/ and partially under /usr/local/linuxprinter/ (including -- under the bin directory listed below -- a file "lpr" and a file "llpr"). I notice that settings already exist for Brother printers, so how do I get these settings added to file_contexts officially for those printers that use the linuxprinter framework? /usr/local/linuxprinter/ppd/.* -- system_u:object_r:cupsd_rw_etc_t:s0 /usr/local/linuxprinter/bin/l?lpr -- system_u:object_r:lpr_exec_t:s0 /usr/local/linuxprinter/filters(/.*)? -- system_u:object_r:bin_t:s0 Thanks Eddie -- Edward Kuns From arifsaha at yahoo.com Tue Feb 19 01:58:52 2008 From: arifsaha at yahoo.com (S P Arif Sahari Wibowo) Date: Mon, 18 Feb 2008 20:58:52 -0500 (EST) Subject: Relocate directories (e.g. tmp): how? Message-ID: Hi! Is there any generic and straighforward way to adjust SELinux to allow a functional directories replaced by a symlink to other location? For example, I have always been relocate the tmp and var directories in one separate volume (rapid changing content). Usually the volume will be mounted on /var and /tmp is a symlink to var/tmp. This arrangement has been working well for me until RHEL / CentOS 4. Then when I tried Fedora 8, this setup stop working: SELinux stop some program - e.g. Xorg and dhcp client - to work with this tmp symlink. Is there a mechanism to tell SELinux to treat everything under /var/tmp the same as under /tmp? Thanks! -- (stephan paul) Arif Sahari Wibowo _____ _____ _____ _____ /____ /____/ /____/ /____ _____/ / / / _____/ http://www.arifsaha.com/ Xinnian Kuaile! ???? Gongxi Facai ???? From cmadams at hiwaay.net Tue Feb 19 03:39:50 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 18 Feb 2008 21:39:50 -0600 Subject: Relocate directories (e.g. tmp): how? In-Reply-To: References: Message-ID: <20080219033950.GC1078472@hiwaay.net> Once upon a time, S P Arif Sahari Wibowo said: > For example, I have always been relocate the tmp and var > directories in one separate volume (rapid changing content). > Usually the volume will be mounted on /var and /tmp is a symlink > to var/tmp. This arrangement has been working well for me until > RHEL / CentOS 4. Then when I tried Fedora 8, this setup stop > working: SELinux stop some program - e.g. Xorg and dhcp client - > to work with this tmp symlink. I hit this too; my solution was to bind mount /tmp onto /var/tmp. My /etc/fstab has: /tmp /var/tmp none bind -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jmorris at namei.org Tue Feb 19 04:25:28 2008 From: jmorris at namei.org (James Morris) Date: Tue, 19 Feb 2008 15:25:28 +1100 (EST) Subject: SELinux smolt stats Message-ID: It seems that the SELinux enablement stats are now online -- thanks! I have a question about what the numbers mean. The current values are: SELinux Enabled False 185085 53.3 % True 162262 46.7 % for 347347 registered hosts. Now, the "OS" column include several distros and versions, including FC5, Centos5 through to current rawhide, with the same number of total hosts. As the SELinux figures have only been collected since F8, does this mean that we should calculate "total SELinux enabled" only for: OS Hosts F8 130282 F7.x (rawhide) 5517 F8.x (rawhide) 920 ---------------------------- 136719 (actually providing SELinux stats) ---------------------------- where the percentage enabled is actually thus at least 74% ? - James -- James Morris From jmorris at namei.org Tue Feb 19 13:39:29 2008 From: jmorris at namei.org (James Morris) Date: Wed, 20 Feb 2008 00:39:29 +1100 (EST) Subject: SELinux smolt stats In-Reply-To: <7f692fec0802182045h777935b4s3defc4a577d40de6@mail.gmail.com> References: <7f692fec0802182045h777935b4s3defc4a577d40de6@mail.gmail.com> Message-ID: On Mon, 18 Feb 2008, Yaakov Nemoy wrote: > > where the percentage enabled is actually thus at least 74% ? > > We probably need more detailed reporting for this sort of thing. I'll > put it on a TODO, for after FOSDEM. I wanted to get this draft out, > so we can decide what reporting we need on a more evolutionary basis. > (Or by intelligent design if you hold by that sort of thing.) Ok, can we simply get an answer on how the numbers are arrived at for cases prior to when SELinux reporting started? i.e. if not reporting SELinux (F7 etc), is the default to present it on the site as "Disabled" ? Knowing that, we can simply derive the correct value. Also, could a note be added to that page so that people don't assume it is fully correct as stated ? We've had enough problems historically with people adopting one benchmark result from a range of results as being the overall result, for example. - James -- James Morris From dwalsh at redhat.com Tue Feb 19 14:52:54 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 19 Feb 2008 09:52:54 -0500 Subject: [F8] (Re)Starting httpd reveals php pdf.so stack permission errors... In-Reply-To: <1203384948.21982.17.camel@gold.cdkkt.com> References: <1203287312.21982.3.camel@gold.cdkkt.com> <47B996D1.2040003@redhat.com> <1203353843.21982.5.camel@gold.cdkkt.com> <47B9EB66.4000806@redhat.com> <1203378817.21982.8.camel@gold.cdkkt.com> <20080219004351.GC3875@inocybe.teonanacatl.org> <1203382573.21982.11.camel@gold.cdkkt.com> <20080219011436.GD3875@inocybe.teonanacatl.org> <1203384948.21982.17.camel@gold.cdkkt.com> Message-ID: <47BAED46.3090008@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel B. Thurman wrote: > On Mon, 2008-02-18 at 17:14 -0800, Todd Zullinger wrote: > >> Daniel B. Thurman wrote: >>> Ok.... >>> >>> I tried: >>> >>> 1) grep execstack /var/log/audit/audit.log | audit2allow -m myphp >>> >>> module myphp 1.0; >>> >>> 2) semodule -i myphp.pp >>> semodule: Could not read file 'myphp.pp': No such file or >> directory >>> Seems that the myphp.pp file is never created, at least I cannot >>> find it.... >> You want -M instead of -m as the argument to audit2allow AFAIK. >> > > > ok... 3rd try: > > 1) grep execstack /var/log/audit/audit.log | audit2allow -M myphp > compilation failed: > (unknown source)::ERROR 'syntax error' at token '' on line 6: > > > /usr/bin/checkmodule: error(s) encountered while parsing configuration > /usr/bin/checkmodule: loading policy configuration from myphp.te > > 2) semodule -i myphp.pp > semodule: Could not read file 'myphp.pp': No such file or directory > > > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Sorry Daniel, it was probably my typing that caused the problem. Could you attach the myphp.te file that audit2allow created? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAke67UYACgkQrlYvE4MpobMzlwCeMplYAYlckgfU/1sD0zgRn+bg WR8AoI8rNbvSSihROKB0INKmZv9p1laH =pfEu -----END PGP SIGNATURE----- From dwalsh at redhat.com Tue Feb 19 14:55:11 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 19 Feb 2008 09:55:11 -0500 Subject: mailman doesn't receive messages from sendmail on fresh F8 install In-Reply-To: <1203362944.3900.21.camel@kilroy.chi.il.us> References: <1203362944.3900.21.camel@kilroy.chi.il.us> Message-ID: <47BAEDCF.6000602@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Edward Kuns wrote: > I freshly installed F8 on a new box, then copied the mailman and > sendmail configuration over from the old box. I made sure everything > was labeled correctly with "restorecon -r -v /etc" and the same for /var > where mailman lives. > > The web pages work, but if I try to send a message to any list, I get > SELinux alerts that prevent the message from going through. I don't > believe I was using selinux on the old machine. I know I could just set > selinux to permissive mode and this would probably work, but I'd rather > understand what the problem is and fix it. > > Below are the selinux complaints generated from trying to send to the > mailman test list on my server: > > Any ideas on what I can do to fix this? I've been googling for a couple > hours and haven't found anything that fits this situation exactly. > > Thanks > > Eddie > > > Summary > SELinux is preventing python (sendmail_t) "search" to > (mailman_log_t). > > Detailed Description > SELinux denied access requested by python. It is not expected that > this > access is required by python and this access may signal an intrusion > attempt. It is also possible that the specific version or > configuration of > the application is causing it to require additional access. > > Allowing Access > Sometimes labeling problems can cause SELinux denials. You could > try to > restore the default system file context for , restorecon -v > If this does not work, there is currently no automatic way > to > allow this access. Instead, you can generate a local policy module > to allow > this access - see > http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 > Or you can disable SELinux protection altogether. Disabling SELinux > protection is not recommended. Please file a > http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this > package. > > Additional Information > > Source Context system_u:system_r:sendmail_t:s0 > Target Context system_u:object_r:mailman_log_t:s0 > Target Objects None [ dir ] > Affected RPM Packages > Policy RPM selinux-policy-3.0.8-84.fc8 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name plugins.catchall_file > Host Name kilroy.chi.il.us > Platform Linux kilroy.chi.il.us 2.6.23.15-137.fc8 > #1 SMP > Sun Feb 10 17:48:34 EST 2008 i686 i686 > Alert Count 15 > First Seen Mon 18 Feb 2008 09:18:28 AM CST > Last Seen Mon 18 Feb 2008 01:06:39 PM CST > Local ID 78d260f8-f1d3-49b3-bea6-bc0cc400735c > Line Numbers > > Raw Audit Messages > > avc: denied { search } for comm=python dev=dm-2 egid=41 euid=8 > exe=/usr/bin/python exit=-13 fsgid=41 fsuid=8 gid=41 items=0 > name=mailman > pid=12198 scontext=system_u:system_r:sendmail_t:s0 sgid=41 > subj=system_u:system_r:sendmail_t:s0 suid=8 tclass=dir > tcontext=system_u:object_r:mailman_log_t:s0 tty=(none) uid=8 > > > Summary > SELinux is preventing python (sendmail_t) "getattr" to > /var/lib/mailman/lists/mailman/config.pck (mailman_data_t). > > Detailed Description > SELinux denied access requested by python. It is not expected that > this > access is required by python and this access may signal an intrusion > attempt. It is also possible that the specific version or > configuration of > the application is causing it to require additional access. > > Allowing Access > Sometimes labeling problems can cause SELinux denials. You could > try to > restore the default system file context for > /var/lib/mailman/lists/mailman/config.pck, restorecon -v > /var/lib/mailman/lists/mailman/config.pck If this does not work, > there is > currently no automatic way to allow this access. Instead, you can > generate > a local policy module to allow this access - see > http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can > disable > SELinux protection altogether. Disabling SELinux protection is not > recommended. Please file a > http://bugzilla.redhat.com/bugzilla/enter_bug.cgi > against this package. > > Additional Information > > Source Context system_u:system_r:sendmail_t:s0 > Target Context system_u:object_r:mailman_data_t:s0 > Target Objects /var/lib/mailman/lists/mailman/config.pck > [ file ] > Affected RPM Packages > Policy RPM selinux-policy-3.0.8-84.fc8 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name plugins.catchall_file > Host Name kilroy.chi.il.us > Platform Linux kilroy.chi.il.us 2.6.23.15-137.fc8 > #1 SMP > Sun Feb 10 17:48:34 EST 2008 i686 i686 > Alert Count 1 > First Seen Mon 18 Feb 2008 01:06:39 PM CST > Last Seen Mon 18 Feb 2008 01:06:39 PM CST > Local ID 5d954998-3826-4af2-9569-0295ae134c27 > Line Numbers > > Raw Audit Messages > > avc: denied { getattr } for comm=python dev=dm-2 egid=41 euid=8 > exe=/usr/bin/python exit=-13 fsgid=41 fsuid=8 gid=41 items=0 > path=/var/lib/mailman/lists/mailman/config.pck pid=12198 > scontext=system_u:system_r:sendmail_t:s0 sgid=41 > subj=system_u:system_r:sendmail_t:s0 suid=8 tclass=file > tcontext=system_u:object_r:mailman_data_t:s0 tty=(none) uid=8 > > > Summary > SELinux is preventing python (sendmail_t) "getattr" to > /var/lib/mailman/lists/mailman/config.pck.last (mailman_data_t). > > Detailed Description > SELinux denied access requested by python. It is not expected that > this > access is required by python and this access may signal an intrusion > attempt. It is also possible that the specific version or > configuration of > the application is causing it to require additional access. > > Allowing Access > Sometimes labeling problems can cause SELinux denials. You could > try to > restore the default system file context for > /var/lib/mailman/lists/mailman/config.pck.last, restorecon -v > /var/lib/mailman/lists/mailman/config.pck.last If this does not > work, there > is currently no automatic way to allow this access. Instead, you > can > generate a local policy module to allow this access - see > http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can > disable > SELinux protection altogether. Disabling SELinux protection is not > recommended. Please file a > http://bugzilla.redhat.com/bugzilla/enter_bug.cgi > against this package. > > Additional Information > > Source Context system_u:system_r:sendmail_t:s0 > Target Context system_u:object_r:mailman_data_t:s0 > Target > Objects /var/lib/mailman/lists/mailman/config.pck.last [ > file ] > Affected RPM Packages > Policy RPM selinux-policy-3.0.8-84.fc8 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name plugins.catchall_file > Host Name kilroy.chi.il.us > Platform Linux kilroy.chi.il.us 2.6.23.15-137.fc8 > #1 SMP > Sun Feb 10 17:48:34 EST 2008 i686 i686 > Alert Count 1 > First Seen Mon 18 Feb 2008 01:06:39 PM CST > Last Seen Mon 18 Feb 2008 01:06:39 PM CST > Local ID 37d2b949-06bf-4cb0-845e-6aa41a16076c > Line Numbers > > Raw Audit Messages > > avc: denied { getattr } for comm=python dev=dm-2 egid=41 euid=8 > exe=/usr/bin/python exit=-13 fsgid=41 fsuid=8 gid=41 items=0 > path=/var/lib/mailman/lists/mailman/config.pck.last pid=12198 > scontext=system_u:system_r:sendmail_t:s0 sgid=41 > subj=system_u:system_r:sendmail_t:s0 suid=8 tclass=file > tcontext=system_u:object_r:mailman_data_t:s0 tty=(none) uid=8 > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list THese look liked leaked file descriptors from mailman, but not sure they are preventing sendmail from running. Could you put the machine into permissive mode and verify the mailman is working. Did you change the configuration to use sendmail rather then using the default internal mechanism of mailman to send mail. (I am not a mailman expert, so I am relaying questions from some co-workers.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAke67c8ACgkQrlYvE4MpobONFgCfRDICXR/sIo2gwQSyGpvN/iAX hpQAn0OBj15Y4P8AZIDWgu4KXUvrXabA =JGyF -----END PGP SIGNATURE----- From dant at cdkkt.com Tue Feb 19 15:02:49 2008 From: dant at cdkkt.com (Daniel B. Thurman) Date: Tue, 19 Feb 2008 07:02:49 -0800 Subject: [F8] (Re)Starting httpd reveals php pdf.so stack permission errors... In-Reply-To: <47BAED46.3090008@redhat.com> References: <1203287312.21982.3.camel@gold.cdkkt.com> <47B996D1.2040003@redhat.com> <1203353843.21982.5.camel@gold.cdkkt.com> <47B9EB66.4000806@redhat.com> <1203378817.21982.8.camel@gold.cdkkt.com> <20080219004351.GC3875@inocybe.teonanacatl.org> <1203382573.21982.11.camel@gold.cdkkt.com> <20080219011436.GD3875@inocybe.teonanacatl.org> <1203384948.21982.17.camel@gold.cdkkt.com> <47BAED46.3090008@redhat.com> Message-ID: <1203433369.21982.20.camel@gold.cdkkt.com> On Tue, 2008-02-19 at 06:52 -0800, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Daniel B. Thurman wrote: > > On Mon, 2008-02-18 at 17:14 -0800, Todd Zullinger wrote: > > > >> Daniel B. Thurman wrote: > >>> Ok.... > >>> > >>> I tried: > >>> > >>> 1) grep execstack /var/log/audit/audit.log | audit2allow -m myphp > >>> > >>> module myphp 1.0; > >>> > >>> 2) semodule -i myphp.pp > >>> semodule: Could not read file 'myphp.pp': No such file or > >> directory > >>> Seems that the myphp.pp file is never created, at least I cannot > >>> find it.... > >> You want -M instead of -m as the argument to audit2allow AFAIK. > >> > > > > > > ok... 3rd try: > > > > 1) grep execstack /var/log/audit/audit.log | audit2allow -M myphp > > compilation failed: > > (unknown source)::ERROR 'syntax error' at token '' on line 6: > > > > > > /usr/bin/checkmodule: error(s) encountered while parsing > configuration > > /usr/bin/checkmodule: loading policy configuration from myphp.te > > > > 2) semodule -i myphp.pp > > semodule: Could not read file 'myphp.pp': No such file or directory > > > > > Sorry Daniel, it was probably my typing that caused the problem. > Could > you attach the myphp.te file that audit2allow created? OK, not much there but here is the attachment! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- module myphp 1.0; From dbartmess at denver.oilfield.slb.com Tue Feb 19 16:36:39 2008 From: dbartmess at denver.oilfield.slb.com (David Bartmess) Date: Tue, 19 Feb 2008 09:36:39 -0700 Subject: Problem with apache accessing files outside of /var/www/html directory Message-ID: <008601c87315$9a73ffe0$9938b9a3@nam.slb.com> I'm trying to get apache to serve up via a CGI script the formatted contents of a directory outside of the DocumentRoot directory structure, and SELinux is giving me a "Permissions Denied" error. How can I modify the SELinux context on the files being shown to fix this? The current files/dirs have the following context: drwxr-xr-x apache apache system_u:object_r:default_t v1x3x3_R3-6 drwxr-xr-x apache apache system_u:object_r:default_t v1x3x4-R1-0 drwxr-xr-x apache apache system_u:object_r:default_t v1x3x4-R2-0 -rwxr-xr-x apache apache system_u:object_r:default_t ASUCTests_v1-2-3_b1x3x4.R2_JUnitReport.zip -rwxr-xr-x apache apache system_u:object_r:default_t Emma_Acquisition_Configuration_v2-3-0.zip I'm a newbie at this SELinux stuff, so please speak clearly David Bartmess. Configuration Manager Cell: +1 (303) 883-9117 Office:+1 (303) 256-5123 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwalsh at redhat.com Tue Feb 19 16:47:09 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 19 Feb 2008 11:47:09 -0500 Subject: Problem with apache accessing files outside of /var/www/html directory In-Reply-To: <008601c87315$9a73ffe0$9938b9a3@nam.slb.com> References: <008601c87315$9a73ffe0$9938b9a3@nam.slb.com> Message-ID: <47BB080D.9010606@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Bartmess wrote: > I'm trying to get apache to serve up via a CGI script the formatted contents > of a directory outside of the DocumentRoot directory structure, and SELinux > is giving me a "Permissions Denied" error. > > > > How can I modify the SELinux context on the files being shown to fix this? > > > > The current files/dirs have the following context: > > > > drwxr-xr-x apache apache system_u:object_r:default_t v1x3x3_R3-6 > > drwxr-xr-x apache apache system_u:object_r:default_t v1x3x4-R1-0 > > drwxr-xr-x apache apache system_u:object_r:default_t v1x3x4-R2-0 > > -rwxr-xr-x apache apache system_u:object_r:default_t > ASUCTests_v1-2-3_b1x3x4.R2_JUnitReport.zip > > -rwxr-xr-x apache apache system_u:object_r:default_t > Emma_Acquisition_Configuration_v2-3-0.zip > > > > I'm a newbie at this SELinux stuff, so please speak clearly > > > > David Bartmess. Configuration Manager > > Cell: +1 (303) 883-9117 > > Office:+1 (303) 256-5123 > > > > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list # semanage fcontext -a -t httpd_sys_content_t '/TOPDIR(/.*)?' # restorecon -R -v /TOPDIR -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAke7CAwACgkQrlYvE4MpobN4ugCg3fM0avkmNxnXx+I27h/2dFpY ZfAAnRqhxF3TYh161FVH85t23dOUGEA0 =ftfn -----END PGP SIGNATURE----- From ekuns at kilroy.chi.il.us Tue Feb 19 16:53:34 2008 From: ekuns at kilroy.chi.il.us (Edward Kuns) Date: Tue, 19 Feb 2008 10:53:34 -0600 Subject: mailman doesn't receive messages from sendmail on fresh F8 install In-Reply-To: <47BAEDCF.6000602@redhat.com> References: <1203362944.3900.21.camel@kilroy.chi.il.us> <47BAEDCF.6000602@redhat.com> Message-ID: <1203440014.15324.16.camel@kilroy.chi.il.us> On Tue, 2008-02-19 at 09:55 -0500, Daniel J Walsh wrote: > THese look liked leaked file descriptors from mailman, but not sure they > are preventing sendmail from running. Could you put the machine into > permissive mode and verify the mailman is working. Done and yes it is working fine in permissive mode. Note: Sendmail is working perfectly except for an inability to forward messages to mailman. The problem is that when messages arrive for a mailman mailing list, somewhere while being passed from sendmail to mailman, we get the selinux rejection quoted in my first Email. My aliases file has: mailman: "|/usr/lib/mailman/mail/mailman post mailman" (this alias having been added by mailman) and when I post a message to that EMail address, I get the complaints quoted in the earlier EMail. In permissive mode, it works. Thus, the complaint that python running with sendmail's ssecurity token needs to access something with a mailman-related security token. > Did you change the configuration to use sendmail rather then using the > default internal mechanism of mailman to send mail. (I am not a mailman > expert, so I am relaying questions from some co-workers.) As you suggest, I have *not* changed mailman to use sendmail. Thanks, Eddie -- Edward Kuns From jkubin at redhat.com Tue Feb 19 16:52:50 2008 From: jkubin at redhat.com (Josef Kubin) Date: Tue, 19 Feb 2008 17:52:50 +0100 Subject: Problem with apache accessing files outside of /var/www/html directory In-Reply-To: <008601c87315$9a73ffe0$9938b9a3@nam.slb.com> References: <008601c87315$9a73ffe0$9938b9a3@nam.slb.com> Message-ID: <47BB0962.2010306@redhat.com> Hello David, consider using the default directory /var/www/cgi-bin/ for your CGI scripts. If you have moved some files you should also fix context # restorecon -Rv /var/www/cgi-bin/ Note, cp and mv behaves differently on files as regards of security context. Josef David Bartmess wrote: > I?m trying to get apache to serve up via a CGI script the formatted > contents of a directory outside of the DocumentRoot directory structure, > and SELinux is giving me a ?Permissions Denied? error. > > > > How can I modify the SELinux context on the files being shown to fix this? > > > > The current files/dirs have the following context: > > > > drwxr-xr-x apache apache system_u:object_r:default_t v1x3x3_R3-6 > > drwxr-xr-x apache apache system_u:object_r:default_t v1x3x4-R1-0 > > drwxr-xr-x apache apache system_u:object_r:default_t v1x3x4-R2-0 > > -rwxr-xr-x apache apache system_u:object_r:default_t > ASUCTests_v1-2-3_b1x3x4.R2_JUnitReport.zip > > -rwxr-xr-x apache apache system_u:object_r:default_t > Emma_Acquisition_Configuration_v2-3-0.zip > > > > I?m a newbie at this SELinux stuff, so please speak clearly > > > > David Bartmess. Configuration Manager > > Cell: +1 (303) 883-9117 > > Office:+1 (303) 256-5123 > > > > > ------------------------------------------------------------------------ > > -- > 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 Feb 19 19:00:31 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 19 Feb 2008 14:00:31 -0500 Subject: mailman doesn't receive messages from sendmail on fresh F8 install In-Reply-To: <1203440014.15324.16.camel@kilroy.chi.il.us> References: <1203362944.3900.21.camel@kilroy.chi.il.us> <47BAEDCF.6000602@redhat.com> <1203440014.15324.16.camel@kilroy.chi.il.us> Message-ID: <47BB274F.9000105@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Edward Kuns wrote: > On Tue, 2008-02-19 at 09:55 -0500, Daniel J Walsh wrote: >> THese look liked leaked file descriptors from mailman, but not sure they >> are preventing sendmail from running. Could you put the machine into >> permissive mode and verify the mailman is working. > > Done and yes it is working fine in permissive mode. > > Note: Sendmail is working perfectly except for an inability to forward > messages to mailman. The problem is that when messages arrive for a > mailman mailing list, somewhere while being passed from sendmail to > mailman, we get the selinux rejection quoted in my first Email. > > My aliases file has: > > mailman: "|/usr/lib/mailman/mail/mailman post mailman" > > (this alias having been added by mailman) and when I post a message to > that EMail address, I get the complaints quoted in the earlier EMail. > In permissive mode, it works. > > Thus, the complaint that python running with sendmail's ssecurity token > needs to access something with a mailman-related security token. > >> Did you change the configuration to use sendmail rather then using the >> default internal mechanism of mailman to send mail. (I am not a mailman >> expert, so I am relaying questions from some co-workers.) > > As you suggest, I have *not* changed mailman to use sendmail. > > Thanks, > > Eddie Ok could you run # grep mailman /var/log/audit/audit.log | audit2allow -M mymailman # semodule -i mymailman.pp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAke7J04ACgkQrlYvE4MpobN93QCfcTffGdbywM0B32yPEVQTEZYx cM8An3UpNTZf5RKgJQ18zrj3LmSgZ9nU =j6JP -----END PGP SIGNATURE----- From dwalsh at redhat.com Tue Feb 19 19:29:43 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 19 Feb 2008 14:29:43 -0500 Subject: mailman doesn't receive messages from sendmail on fresh F8 install In-Reply-To: <1203440014.15324.16.camel@kilroy.chi.il.us> References: <1203362944.3900.21.camel@kilroy.chi.il.us> <47BAEDCF.6000602@redhat.com> <1203440014.15324.16.camel@kilroy.chi.il.us> Message-ID: <47BB2E27.9000205@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Edward Kuns wrote: > On Tue, 2008-02-19 at 09:55 -0500, Daniel J Walsh wrote: >> THese look liked leaked file descriptors from mailman, but not sure they >> are preventing sendmail from running. Could you put the machine into >> permissive mode and verify the mailman is working. > > Done and yes it is working fine in permissive mode. > > Note: Sendmail is working perfectly except for an inability to forward > messages to mailman. The problem is that when messages arrive for a > mailman mailing list, somewhere while being passed from sendmail to > mailman, we get the selinux rejection quoted in my first Email. > > My aliases file has: > > mailman: "|/usr/lib/mailman/mail/mailman post mailman" > > (this alias having been added by mailman) and when I post a message to > that EMail address, I get the complaints quoted in the earlier EMail. > In permissive mode, it works. > > Thus, the complaint that python running with sendmail's ssecurity token > needs to access something with a mailman-related security token. > >> Did you change the configuration to use sendmail rather then using the >> default internal mechanism of mailman to send mail. (I am not a mailman >> expert, so I am relaying questions from some co-workers.) > > As you suggest, I have *not* changed mailman to use sendmail. > > Thanks, > > Eddie if you chcon -t mailman_mail_exec_t /usr/lib/mailman/mail/mailman Does it work? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAke7LiYACgkQrlYvE4MpobONpQCgzBVP3caS5iegsGsme+o1ZzWK PZUAoNcFxlU8WQ4kwi74GLGgVSmr/9Ow =yNfm -----END PGP SIGNATURE----- From ekuns at kilroy.chi.il.us Tue Feb 19 20:50:01 2008 From: ekuns at kilroy.chi.il.us (Edward Kuns) Date: Tue, 19 Feb 2008 14:50:01 -0600 Subject: mailman doesn't receive messages from sendmail on fresh F8 install In-Reply-To: <47BB274F.9000105@redhat.com> References: <1203362944.3900.21.camel@kilroy.chi.il.us> <47BAEDCF.6000602@redhat.com> <1203440014.15324.16.camel@kilroy.chi.il.us> <47BB274F.9000105@redhat.com> Message-ID: <1203454201.20617.17.camel@kilroy.chi.il.us> On Tue, 2008-02-19 at 14:00 -0500, Daniel J Walsh wrote: > if you > > chcon -t mailman_mail_exec_t /usr/lib/mailman/mail/mailman > > Does it work? Yes, I assume so, as there is no output complaining that it failed, and: # ls -lZ /usr/lib/mailman/mail/mailman -rwxr-sr-x root mailman system_u:object_r:mailman_mail_exec_t:s0 /usr/lib/mailman/mail/mailman > Ok could you run > > # grep mailman /var/log/audit/audit.log | audit2allow -M mymailman > # semodule -i mymailman.pp Thanks. This appears to have fixed the problem. I have not exhaustively tested, but everything appears to be working now. I see that there is a mymailman.te file created as a result of the above. This file contains the text: module mymailman 1.0; require { type sendmail_t; type mailman_log_t; type mailman_data_t; class dir { write remove_name search add_name }; class file { write rename getattr read create append }; } #============= sendmail_t ============== allow sendmail_t mailman_data_t:dir { write remove_name add_name }; allow sendmail_t mailman_data_t:file { write rename getattr create }; allow sendmail_t mailman_log_t:dir search; allow sendmail_t mailman_log_t:file { read getattr append }; Am I the first to try to get mailman and sendmail working together under selinux with Fedora? Either way, something resembling the above should probably become a default policy, as, if I'm the first I won't be the last! What can I do to help refine the above into a genuine and genuinely useful policy? I am clearly still learning about selinux! Thanks, Eddie -- Edward Kuns From dwalsh at redhat.com Tue Feb 19 22:03:34 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 19 Feb 2008 17:03:34 -0500 Subject: mailman doesn't receive messages from sendmail on fresh F8 install In-Reply-To: <1203454201.20617.17.camel@kilroy.chi.il.us> References: <1203362944.3900.21.camel@kilroy.chi.il.us> <47BAEDCF.6000602@redhat.com> <1203440014.15324.16.camel@kilroy.chi.il.us> <47BB274F.9000105@redhat.com> <1203454201.20617.17.camel@kilroy.chi.il.us> Message-ID: <47BB5236.5030404@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Edward Kuns wrote: > On Tue, 2008-02-19 at 14:00 -0500, Daniel J Walsh wrote: >> if you >> >> chcon -t mailman_mail_exec_t /usr/lib/mailman/mail/mailman >> >> Does it work? > > Yes, I assume so, as there is no output complaining that it failed, and: > > # ls -lZ /usr/lib/mailman/mail/mailman > -rwxr-sr-x root mailman > system_u:object_r:mailman_mail_exec_t:s0 /usr/lib/mailman/mail/mailman > >> Ok could you run >> >> # grep mailman /var/log/audit/audit.log | audit2allow -M mymailman >> # semodule -i mymailman.pp > > Thanks. This appears to have fixed the problem. I have not > exhaustively tested, but everything appears to be working now. I see > that there is a mymailman.te file created as a result of the above. > This file contains the text: > > > module mymailman 1.0; > > require { > type sendmail_t; > type mailman_log_t; > type mailman_data_t; > class dir { write remove_name search add_name }; > class file { write rename getattr read create append }; > } > > #============= sendmail_t ============== > allow sendmail_t mailman_data_t:dir { write remove_name add_name }; > allow sendmail_t mailman_data_t:file { write rename getattr create }; > allow sendmail_t mailman_log_t:dir search; > allow sendmail_t mailman_log_t:file { read getattr append }; > > > Am I the first to try to get mailman and sendmail working together under > selinux with Fedora? Either way, something resembling the above should > probably become a default policy, as, if I'm the first I won't be the > last! What can I do to help refine the above into a genuine and > genuinely useful policy? > > I am clearly still learning about selinux! > > Thanks, > > Eddie > Check to see if the relabel worked without the module # semodule -r mymailman Now try it again. This should work without AVC messages -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAke7UjYACgkQrlYvE4MpobPabwCeMBF9Sc1d98dVL9+W3rFmWshw CA8AnisU+qObDiR5js/iFjkBN2khZvV1 =o13c -----END PGP SIGNATURE----- From ekuns at kilroy.chi.il.us Wed Feb 20 03:31:26 2008 From: ekuns at kilroy.chi.il.us (Edward Kuns) Date: Tue, 19 Feb 2008 21:31:26 -0600 Subject: mailman doesn't receive messages from sendmail on fresh F8 install In-Reply-To: <47BB5236.5030404@redhat.com> References: <1203362944.3900.21.camel@kilroy.chi.il.us> <47BAEDCF.6000602@redhat.com> <1203440014.15324.16.camel@kilroy.chi.il.us> <47BB274F.9000105@redhat.com> <1203454201.20617.17.camel@kilroy.chi.il.us> <47BB5236.5030404@redhat.com> Message-ID: <1203478286.29184.44.camel@kilroy.chi.il.us> On Tue, 2008-02-19 at 17:03 -0500, Daniel J Walsh wrote: > Check to see if the relabel worked without the module > > # semodule -r mymailman > > Now try it again. This should work without AVC messages Interestingly, this does work and doesn't work, but it fails at a later stage than it used to. What does this mean? The message appears to get delivered, but I also get an selinux complaint referring to the mail spool file: Summary SELinux is preventing /usr/lib/mailman/mail/mailman (mailman_mail_t) "read" to /var/spool/mqueue/dfm1K3MwNg031190 (mqueue_spool_t). Detailed Description SELinux denied access requested by /usr/lib/mailman/mail/mailman. It is not expected that this access is required by /usr/lib/mailman/mail/mailman and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /var/spool/mqueue/dfm1K3MwNg031190, restorecon -v /var/spool/mqueue/dfm1K3MwNg031190 If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see http://fedora.redhat.com/docs /selinux-faq-fc5/#id2961385 Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Additional Information Source Context system_u:system_r:mailman_mail_t:s0 Target Context system_u:object_r:mqueue_spool_t:s0 Target Objects /var/spool/mqueue/dfm1K3MwNg031190 [ file ] Affected RPM Packages mailman-2.1.9-8.2.fc8 [application] Policy RPM selinux-policy-3.0.8-84.fc8 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.catchall_file Host Name kilroy.chi.il.us Platform Linux kilroy.chi.il.us 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:48:34 EST 2008 i686 i686 Alert Count 1 First Seen Tue 19 Feb 2008 09:22:58 PM CST Last Seen Tue 19 Feb 2008 09:22:58 PM CST Local ID c52fd5cd-781f-4178-ae56-dd979cb54ab6 Line Numbers Raw Audit Messages avc: denied { read } for comm=mailman dev=dm-2 egid=41 euid=8 exe=/usr/lib/mailman/mail/mailman exit=0 fsgid=41 fsuid=8 gid=12 items=0 path=/var/spool/mqueue/dfm1K3MwNg031190 pid=31193 scontext=system_u:system_r:mailman_mail_t:s0 sgid=41 subj=system_u:system_r:mailman_mail_t:s0 suid=8 tclass=file tcontext=system_u:object_r:mqueue_spool_t:s0 tty=(none) uid=8 Summary SELinux is preventing /usr/lib/mailman/mail/mailman (mailman_mail_t) "read" to /var/spool/mqueue/dfm1K3MwNg031190 (mqueue_spool_t). Detailed Description SELinux denied access requested by /usr/lib/mailman/mail/mailman. It is not expected that this access is required by /usr/lib/mailman/mail/mailman and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /var/spool/mqueue/dfm1K3MwNg031190, restorecon -v /var/spool/mqueue/dfm1K3MwNg031190 If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see http://fedora.redhat.com/docs /selinux-faq-fc5/#id2961385 Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Additional Information Source Context system_u:system_r:mailman_mail_t:s0 Target Context system_u:object_r:mqueue_spool_t:s0 Target Objects /var/spool/mqueue/dfm1K3MwNg031190 [ file ] Affected RPM Packages mailman-2.1.9-8.2.fc8 [application] Policy RPM selinux-policy-3.0.8-84.fc8 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.catchall_file Host Name kilroy.chi.il.us Platform Linux kilroy.chi.il.us 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:48:34 EST 2008 i686 i686 Alert Count 1 First Seen Tue 19 Feb 2008 09:22:58 PM CST Last Seen Tue 19 Feb 2008 09:22:58 PM CST Local ID c52fd5cd-781f-4178-ae56-dd979cb54ab6 Line Numbers Raw Audit Messages avc: denied { read } for comm=mailman dev=dm-2 egid=41 euid=8 exe=/usr/lib/mailman/mail/mailman exit=0 fsgid=41 fsuid=8 gid=12 items=0 path=/var/spool/mqueue/dfm1K3MwNg031190 pid=31193 scontext=system_u:system_r:mailman_mail_t:s0 sgid=41 subj=system_u:system_r:mailman_mail_t:s0 suid=8 tclass=file tcontext=system_u:object_r:mqueue_spool_t:s0 tty=(none) uid=8 If I repeat the procedure from earlier, I get a longer mymailman.te file that contains the following: module mymailman2 1.0; require { type sendmail_t; type mailman_mail_t; type mailman_log_t; type mailman_data_t; type mqueue_spool_t; class unix_stream_socket { read write }; class dir { write remove_name search add_name }; class file { write rename getattr read create append }; } #============= mailman_mail_t ============== allow mailman_mail_t mqueue_spool_t:file { read write }; allow mailman_mail_t sendmail_t:unix_stream_socket { read write }; #============= sendmail_t ============== allow sendmail_t mailman_data_t:dir { write remove_name add_name }; allow sendmail_t mailman_data_t:file { write rename getattr create }; allow sendmail_t mailman_log_t:dir search; allow sendmail_t mailman_log_t:file { read getattr append }; It appears that I don't need all of these rules. Looking at the two files, I see a *.pp file that appears to be a binary file and a *.te file that is human readable. But I'm not sure how to create a policy file that's just the text file. I also don't know why mailman wants access to the spool file, but with the above I get no complaints when I send mail to the list. Without the above I still get a complaint, although the mail appears to get delivered OK. Eddie -- Edward Kuns From ekuns at kilroy.chi.il.us Wed Feb 20 04:07:08 2008 From: ekuns at kilroy.chi.il.us (Edward Kuns) Date: Tue, 19 Feb 2008 22:07:08 -0600 Subject: Problem with apache accessing files outside of /var/www/html directory In-Reply-To: <47BB0962.2010306@redhat.com> References: <008601c87315$9a73ffe0$9938b9a3@nam.slb.com> <47BB0962.2010306@redhat.com> Message-ID: <1203480428.32130.12.camel@kilroy.chi.il.us> David Bartmess wrote: > I?m trying to get apache to serve up via a CGI script the formatted > contents of a directory outside of the DocumentRoot directory structure, > and SELinux is giving me a ?Permissions Denied? error. > How can I modify the SELinux context on the files being shown to fix this? I'm also a newbie at this, but what I did to fix something similar was bring up system-config-selinux and looked at the configuration of files in the "correct" area, then I replicated that configuration on the place where I put my /var/www directory. (Because /var/www can grow so much larger than the rest of my /var, I put it outside of /var with a symlink.) The tool added my changes to the file /etc/selinux/targeted/contexts/files/file_contexts.local Thus, to fix your problem, do something like: grep cgi /etc/selinux/targeted/contexts/files/file_contexts This will show you all rules pertaining to directories that contain "cgi" in them and/or rules that contain "cgi" in them. From that shorter list of rules, you should be able to figure out how to craft a rule for the location where you put CGI files. You can manually add those to the file_contexts.local file (but I don't know if you then need to do something special to activate those changes) or you can use system-config-selinux, which is what I did. Then to make the changes in labeling occur, I: restorecon -r -v /path/to/directory/where/you/put/cgi where you put your cgi. And remember that you need permissions the whole directory tree down, so if you put your cgi files in /opt/special/active/cgi then you need labeling on /opt and on /opt/special (and so on, all the way down) so that the programs in question can navigate all the way down from "/" to your cgi files. To figure out what is required, you can look at what labeling is done in the directories /var and /var/www (in file_contexts) and experiment a little. I was able to figure out how to put /var/www successfully in a different location by doing this, but I don't really have any cgi scripts, so you have a slightly different situation. Good luck. Eddie -- Edward Kuns From arifsaha at yahoo.com Wed Feb 20 04:36:45 2008 From: arifsaha at yahoo.com (S P Arif Sahari Wibowo) Date: Tue, 19 Feb 2008 23:36:45 -0500 (EST) Subject: Relocate directories (e.g. tmp): how? In-Reply-To: <20080219033950.GC1078472@hiwaay.net> References: <20080219033950.GC1078472@hiwaay.net> Message-ID: On Mon, 18 Feb 2008, Chris Adams wrote: > I hit this too; my solution was to bind mount /tmp onto > /var/tmp. My /etc/fstab has: > /tmp /var/tmp none bind Thanks! I was thinking about this before but somehow my fstab configuration was incorrect. I copy yours and now it works nicely. That said, I still interested in "SELinux solution". This one seems to be a work-around and SELinux may actually block it in the future. Furthermore, there is a small inconvenience that if I boot from rescue CD, the tmp directory probably won't be mounted. -- (stephan paul) Arif Sahari Wibowo _____ _____ _____ _____ /____ /____/ /____/ /____ _____/ / / / _____/ http://www.arifsaha.com/ Xinnian Kuaile! ???? Gongxi Facai ???? From dwalsh at redhat.com Wed Feb 20 13:14:22 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 20 Feb 2008 08:14:22 -0500 Subject: mailman doesn't receive messages from sendmail on fresh F8 install In-Reply-To: <1203478286.29184.44.camel@kilroy.chi.il.us> References: <1203362944.3900.21.camel@kilroy.chi.il.us> <47BAEDCF.6000602@redhat.com> <1203440014.15324.16.camel@kilroy.chi.il.us> <47BB274F.9000105@redhat.com> <1203454201.20617.17.camel@kilroy.chi.il.us> <47BB5236.5030404@redhat.com> <1203478286.29184.44.camel@kilroy.chi.il.us> Message-ID: <47BC27AE.2000301@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Edward Kuns wrote: > On Tue, 2008-02-19 at 17:03 -0500, Daniel J Walsh wrote: >> Check to see if the relabel worked without the module >> >> # semodule -r mymailman >> >> Now try it again. This should work without AVC messages > > Interestingly, this does work and doesn't work, but it fails at a later > stage than it used to. What does this mean? The message appears to get > delivered, but I also get an selinux complaint referring to the mail > spool file: > Could mean that sendmail has an open file descriptor to a file in the mqueue_spool and it leaked it to mailman. I don't think mailman reads /var/spool/mqueue/dfm1K3MwNg031190 directly. > Summary > SELinux is preventing /usr/lib/mailman/mail/mailman (mailman_mail_t) > "read" > to /var/spool/mqueue/dfm1K3MwNg031190 (mqueue_spool_t). > > Detailed Description > SELinux denied access requested by /usr/lib/mailman/mail/mailman. It > is not > expected that this access is required > by /usr/lib/mailman/mail/mailman and > this access may signal an intrusion attempt. It is also possible > that the > specific version or configuration of the application is causing it > to > require additional access. > > Allowing Access > Sometimes labeling problems can cause SELinux denials. You could > try to > restore the default system file context for > /var/spool/mqueue/dfm1K3MwNg031190, restorecon -v > /var/spool/mqueue/dfm1K3MwNg031190 If this does not work, there is > currently > no automatic way to allow this access. Instead, you can generate a > local > policy module to allow this access - see > http://fedora.redhat.com/docs > /selinux-faq-fc5/#id2961385 Or you can disable SELinux protection > altogether. Disabling SELinux protection is not recommended. Please > file a > http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this > package. > > Additional Information > > Source Context system_u:system_r:mailman_mail_t:s0 > Target Context system_u:object_r:mqueue_spool_t:s0 > Target Objects /var/spool/mqueue/dfm1K3MwNg031190 > [ file ] > Affected RPM Packages mailman-2.1.9-8.2.fc8 [application] > Policy RPM selinux-policy-3.0.8-84.fc8 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name plugins.catchall_file > Host Name kilroy.chi.il.us > Platform Linux kilroy.chi.il.us 2.6.23.15-137.fc8 > #1 SMP > Sun Feb 10 17:48:34 EST 2008 i686 i686 > Alert Count 1 > First Seen Tue 19 Feb 2008 09:22:58 PM CST > Last Seen Tue 19 Feb 2008 09:22:58 PM CST > Local ID c52fd5cd-781f-4178-ae56-dd979cb54ab6 > Line Numbers > > Raw Audit Messages > > avc: denied { read } for comm=mailman dev=dm-2 egid=41 euid=8 > exe=/usr/lib/mailman/mail/mailman exit=0 fsgid=41 fsuid=8 gid=12 items=0 > path=/var/spool/mqueue/dfm1K3MwNg031190 pid=31193 > scontext=system_u:system_r:mailman_mail_t:s0 sgid=41 > subj=system_u:system_r:mailman_mail_t:s0 suid=8 tclass=file > tcontext=system_u:object_r:mqueue_spool_t:s0 tty=(none) uid=8 > > > > > Summary > SELinux is preventing /usr/lib/mailman/mail/mailman (mailman_mail_t) > "read" > to /var/spool/mqueue/dfm1K3MwNg031190 (mqueue_spool_t). > > Detailed Description > SELinux denied access requested by /usr/lib/mailman/mail/mailman. It > is not > expected that this access is required > by /usr/lib/mailman/mail/mailman and > this access may signal an intrusion attempt. It is also possible > that the > specific version or configuration of the application is causing it > to > require additional access. > > Allowing Access > Sometimes labeling problems can cause SELinux denials. You could > try to > restore the default system file context for > /var/spool/mqueue/dfm1K3MwNg031190, restorecon -v > /var/spool/mqueue/dfm1K3MwNg031190 If this does not work, there is > currently > no automatic way to allow this access. Instead, you can generate a > local > policy module to allow this access - see > http://fedora.redhat.com/docs > /selinux-faq-fc5/#id2961385 Or you can disable SELinux protection > altogether. Disabling SELinux protection is not recommended. Please > file a > http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this > package. > > Additional Information > > Source Context system_u:system_r:mailman_mail_t:s0 > Target Context system_u:object_r:mqueue_spool_t:s0 > Target Objects /var/spool/mqueue/dfm1K3MwNg031190 > [ file ] > Affected RPM Packages mailman-2.1.9-8.2.fc8 [application] > Policy RPM selinux-policy-3.0.8-84.fc8 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name plugins.catchall_file > Host Name kilroy.chi.il.us > Platform Linux kilroy.chi.il.us 2.6.23.15-137.fc8 > #1 SMP > Sun Feb 10 17:48:34 EST 2008 i686 i686 > Alert Count 1 > First Seen Tue 19 Feb 2008 09:22:58 PM CST > Last Seen Tue 19 Feb 2008 09:22:58 PM CST > Local ID c52fd5cd-781f-4178-ae56-dd979cb54ab6 > Line Numbers > > Raw Audit Messages > > avc: denied { read } for comm=mailman dev=dm-2 egid=41 euid=8 > exe=/usr/lib/mailman/mail/mailman exit=0 fsgid=41 fsuid=8 gid=12 items=0 > path=/var/spool/mqueue/dfm1K3MwNg031190 pid=31193 > scontext=system_u:system_r:mailman_mail_t:s0 sgid=41 > subj=system_u:system_r:mailman_mail_t:s0 suid=8 tclass=file > tcontext=system_u:object_r:mqueue_spool_t:s0 tty=(none) uid=8 > > > If I repeat the procedure from earlier, I get a longer mymailman.te file > that contains the following: > > > module mymailman2 1.0; > > require { > type sendmail_t; > type mailman_mail_t; > type mailman_log_t; > type mailman_data_t; > type mqueue_spool_t; > class unix_stream_socket { read write }; > class dir { write remove_name search add_name }; > class file { write rename getattr read create append }; > } > > #============= mailman_mail_t ============== > allow mailman_mail_t mqueue_spool_t:file { read write }; > allow mailman_mail_t sendmail_t:unix_stream_socket { read write }; > > #============= sendmail_t ============== > allow sendmail_t mailman_data_t:dir { write remove_name add_name }; > allow sendmail_t mailman_data_t:file { write rename getattr create }; > allow sendmail_t mailman_log_t:dir search; > allow sendmail_t mailman_log_t:file { read getattr append }; > > It appears that I don't need all of these rules. Looking at the two > files, I see a *.pp file that appears to be a binary file and a *.te > file that is human readable. But I'm not sure how to create a policy > file that's just the text file. > > I also don't know why mailman wants access to the spool file, but with > the above I get no complaints when I send mail to the list. Without the > above I still get a complaint, although the mail appears to get > delivered OK. > > Eddie > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAke8J60ACgkQrlYvE4MpobORRgCfVr249LQxcjRHyIPwHhmovUV3 cbwAoMIXtY35qkG8qNLzpP8bpYNjfIuI =blTj -----END PGP SIGNATURE----- From dwalsh at redhat.com Wed Feb 20 13:19:29 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 20 Feb 2008 08:19:29 -0500 Subject: Relocate directories (e.g. tmp): how? In-Reply-To: References: <20080219033950.GC1078472@hiwaay.net> Message-ID: <47BC28E1.7020501@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 S P Arif Sahari Wibowo wrote: > On Mon, 18 Feb 2008, Chris Adams wrote: >> I hit this too; my solution was to bind mount /tmp onto /var/tmp. My >> /etc/fstab has: >> /tmp /var/tmp none bind > > Thanks! I was thinking about this before but somehow my fstab > configuration was incorrect. I copy yours and now it works nicely. > > That said, I still interested in "SELinux solution". This one seems to > be a work-around and SELinux may actually block it in the future. > > Furthermore, there is a small inconvenience that if I boot from rescue > CD, the tmp directory probably won't be mounted. > You can set up alternate labeling on directories using semanage fcontext # semanage fcontext -a -t tmp_t '/mytmp(/.*)?' > > ------------------------------------------------------------------------ > > -- > 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 iEYEARECAAYFAke8KOEACgkQrlYvE4MpobP11gCgs7wJUGhsYuZJjJUByQ4MYfaJ dukAmwU9uPq140jWVW/vTe9jBtIxETTc =RWCe -----END PGP SIGNATURE----- From jmorris at namei.org Wed Feb 20 14:09:14 2008 From: jmorris at namei.org (James Morris) Date: Thu, 21 Feb 2008 01:09:14 +1100 (EST) Subject: SELinux smolt stats In-Reply-To: <47BC04DB.6000708@gmail.com> References: <47BC04DB.6000708@gmail.com> Message-ID: On Wed, 20 Feb 2008, Valent Turkovic wrote: > James Morris wrote: > > It seems that the SELinux enablement stats are now online -- thanks! > > > > I have a question about what the numbers mean. The current values are: > > > > SELinux Enabled > > False 185085 53.3 % True 162262 46.7 % > > If this arguments are true for Fedora 8 than it looks like that more people > dislike selinux than like it, right? Why did you delete the rest of the email, which queried these numbers and suggested that the real figure for enablement was much higher? btw, I asked off-list for a raw SQL query for just F8 systems (which have been reporting SELinux stats all along), and the "Enabled=True" value is currently 94%. It's not clear to me what these numbers really mean, and I think it may be some time before we are able to really see what's happening (e.g. between smolt changes, initial reports, re-reporting, different distro versions with different levels of usability, permissive vs. enforcing etc.). - James -- James Morris From jdennis at redhat.com Wed Feb 20 14:29:37 2008 From: jdennis at redhat.com (John Dennis) Date: Wed, 20 Feb 2008 09:29:37 -0500 Subject: SELinux smolt stats In-Reply-To: References: <47BC04DB.6000708@gmail.com> Message-ID: <47BC3951.1010004@redhat.com> James Morris wrote: > On Wed, 20 Feb 2008, Valent Turkovic wrote: >> James Morris wrote: >>> It seems that the SELinux enablement stats are now online -- thanks! >>> >>> I have a question about what the numbers mean. The current values are: >>> >>> SELinux Enabled >>> False 185085 53.3 % True 162262 46.7 % >> If this arguments are true for Fedora 8 than it looks like that more people >> dislike selinux than like it, right? > Why did you delete the rest of the email ... Because Valent has an anti SELinux agenda (refer to previous threads). -- John Dennis From benny+usenet at amorsen.dk Wed Feb 20 19:29:47 2008 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Wed, 20 Feb 2008 20:29:47 +0100 Subject: SELinux smolt stats References: <47BC04DB.6000708@gmail.com> Message-ID: James Morris writes: > btw, I asked off-list for a raw SQL query for just F8 systems (which have > been reporting SELinux stats all along), and the "Enabled=True" value is > currently 94%. Does Enabled=True imply enforcing? /Benny From jmorris at namei.org Wed Feb 20 22:41:11 2008 From: jmorris at namei.org (James Morris) Date: Thu, 21 Feb 2008 09:41:11 +1100 (EST) Subject: SELinux smolt stats In-Reply-To: References: <47BC04DB.6000708@gmail.com> Message-ID: On Wed, 20 Feb 2008, Benny Amorsen wrote: > James Morris writes: > > > btw, I asked off-list for a raw SQL query for just F8 systems (which have > > been reporting SELinux stats all along), and the "Enabled=True" value is > > currently 94%. > > Does Enabled=True imply enforcing? No. I think they are starting to collect that now. What would also be useful would be to compare figures with other security features like iptables. - James -- James Morris From selinux at gmail.com Thu Feb 21 15:59:31 2008 From: selinux at gmail.com (Tom London) Date: Thu, 21 Feb 2008 07:59:31 -0800 Subject: "getcap" AVCs .... Message-ID: <4c4ba1530802210759i1d113b0ocd36fdf482ab3987@mail.gmail.com> Running selinux-policy-targeted-3.2.9-1.fc9.noarch type=AVC msg=audit(1203608392.877:5): avc: denied { getcap } for pid=2231 comm="dbus-daemon" scontext=system_u:system_r:system_dbusd_t:s0 tcontext=system_u:system_r:system_dbusd_t:s0 tclass=process type=SYSCALL msg=audit(1203608392.877:5): arch=40000003 syscall=184 success=no exit=-14 a0=b93db7f4 a1=0 a2=1a20f0 a3=b93db7f0 items=0 ppid=1 pid=2231 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="dbus-daemon" exe="/bin/dbus-daemon" subj=system_u:system_r:system_dbusd_t:s0 key=(null) and type=AVC msg=audit(1203608414.575:14): avc: denied { getcap } for pid=2295 comm="ntpd" scontext=system_u:system_r:ntpd_t:s0 tcontext=system_u:system_r:ntpd_t:s0 tclass=process type=SYSCALL msg=audit(1203608414.575:14): arch=40000003 syscall=184 success=no exit=-14 a0=b8ab14cc a1=0 a2=2ad0f0 a3=b8ab14c8 items=0 ppid=1 pid=2295 auid=4294967295 uid=38 gid=38 euid=38 suid=38 fsuid=38 egid=38 sgid=38 fsgid=38 tty=(none) ses=4294967295 comm="ntpd" exe="/usr/sbin/ntpd" subj=system_u:system_r:ntpd_t:s0 key=(null) tom -- Tom London From dwalsh at redhat.com Thu Feb 21 16:26:26 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 21 Feb 2008 11:26:26 -0500 Subject: "getcap" AVCs .... In-Reply-To: <4c4ba1530802210759i1d113b0ocd36fdf482ab3987@mail.gmail.com> References: <4c4ba1530802210759i1d113b0ocd36fdf482ab3987@mail.gmail.com> Message-ID: <47BDA632.7060109@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom London wrote: > Running selinux-policy-targeted-3.2.9-1.fc9.noarch > > type=AVC msg=audit(1203608392.877:5): avc: denied { getcap } for > pid=2231 comm="dbus-daemon" > scontext=system_u:system_r:system_dbusd_t:s0 > tcontext=system_u:system_r:system_dbusd_t:s0 tclass=process > type=SYSCALL msg=audit(1203608392.877:5): arch=40000003 syscall=184 > success=no exit=-14 a0=b93db7f4 a1=0 a2=1a20f0 a3=b93db7f0 items=0 > ppid=1 pid=2231 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 > egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="dbus-daemon" > exe="/bin/dbus-daemon" subj=system_u:system_r:system_dbusd_t:s0 > key=(null) > > and > > type=AVC msg=audit(1203608414.575:14): avc: denied { getcap } for > pid=2295 comm="ntpd" scontext=system_u:system_r:ntpd_t:s0 > tcontext=system_u:system_r:ntpd_t:s0 tclass=process > type=SYSCALL msg=audit(1203608414.575:14): arch=40000003 syscall=184 > success=no exit=-14 a0=b8ab14cc a1=0 a2=2ad0f0 a3=b8ab14c8 items=0 > ppid=1 pid=2295 auid=4294967295 uid=38 gid=38 euid=38 suid=38 fsuid=38 > egid=38 sgid=38 fsgid=38 tty=(none) ses=4294967295 comm="ntpd" > exe="/usr/sbin/ntpd" subj=system_u:system_r:ntpd_t:s0 key=(null) > > tom I wonder if everyone that now calls setcap now needs getcap? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAke9pjEACgkQrlYvE4MpobNruACgqwsyCF16Um2Olk175kVgev8L jJAAniSkw7os9Z6U34deIhk9rvCeF5N2 =fpr3 -----END PGP SIGNATURE----- From olivares14031 at yahoo.com Thu Feb 21 18:06:38 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Thu, 21 Feb 2008 10:06:38 -0800 (PST) Subject: SELinux is preventing ntpd (ntpd_t) "getcap" to (ntpd_t) Message-ID: <606942.96507.qm@web52607.mail.re2.yahoo.com> Summary: SELinux is preventing ntpd (ntpd_t) "getcap" to (ntpd_t). Detailed Description: SELinux denied access requested by ntpd. It is not expected that this access is required by ntpd and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context unconfined_u:system_r:ntpd_t Target Context unconfined_u:system_r:ntpd_t Target Objects None [ process ] Source ntpdate Source Path /usr/sbin/ntpdate Port Host localhost Source RPM Packages ntp-4.2.4p4-3.fc9 Target RPM Packages Policy RPM selinux-policy-3.2.9-1.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name localhost Platform Linux localhost 2.6.25-0.40.rc1.git2.fc9 #1 SMP Wed Feb 13 17:55:35 EST 2008 i686 athlon Alert Count 2 First Seen Thu 21 Feb 2008 10:58:12 AM CST Last Seen Thu 21 Feb 2008 10:58:20 AM CST Local ID ad5db6a3-d94d-4ee7-87ca-e8ea7b0196ea Line Numbers Raw Audit Messages host=localhost type=AVC msg=audit(1203613100.285:81): avc: denied { getcap } for pid=14697 comm="ntpd" scontext=unconfined_u:system_r:ntpd_t:s0 tcontext=unconfined_u:system_r:ntpd_t:s0 tclass=process host=localhost type=SYSCALL msg=audit(1203613100.285:81): arch=40000003 syscall=184 success=no exit=-13 a0=b8e93444 a1=0 a2=2ad0f0 a3=b8e93440 items=0 ppid=1 pid=14697 auid=500 uid=38 gid=38 euid=38 suid=38 fsuid=38 egid=38 sgid=38 fsgid=38 tty=(none) ses=2 comm="ntpd" exe="/usr/sbin/ntpd" subj=unconfined_u:system_r:ntpd_t:s0 key=(null) ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From notting at redhat.com Thu Feb 21 23:23:21 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 21 Feb 2008 18:23:21 -0500 Subject: excessively verbose policy Message-ID: <20080221232321.GB9069@nostromo.devel.redhat.com> I was writing policy today, and I couldn't help notice a lot of repetitiveness in our policy: libs_use_ld_so(...) libs_use_shared_libs(...) These are needed by, well, everything. Can't they be assumed-unless-denied? Similarly, 99% of confined apps need: miscfiles_read_localization() files_read_etc_files(.) pipes & stream sockets Is there a way to streamline policy so there is a lot less repetition? Bill From notting at redhat.com Thu Feb 21 23:28:06 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 21 Feb 2008 18:28:06 -0500 Subject: periodic policy audits Message-ID: <20080221232806.GC9069@nostromo.devel.redhat.com> Again, looking through the policy I see sections for policy to confine cardmgr, /etc/hotplug scripts, updfstab, etc. Do we do any routine policy updates to purge obsolete policy? If not, should we? Bill From dwalsh at redhat.com Fri Feb 22 13:44:43 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 22 Feb 2008 08:44:43 -0500 Subject: periodic policy audits In-Reply-To: <20080221232806.GC9069@nostromo.devel.redhat.com> References: <20080221232806.GC9069@nostromo.devel.redhat.com> Message-ID: <47BED1CB.5000606@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Nottingham wrote: > Again, looking through the policy I see sections for policy > to confine cardmgr, /etc/hotplug scripts, updfstab, etc. Do > we do any routine policy updates to purge obsolete policy? > > If not, should we? > > Bill > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list The problem is we are using the same upstream policy for RHEL4/RHEL5/Fedora7-9/Debian/Gentoo/Ubunto/... So while one distribution may not use it, others might. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAke+0csACgkQrlYvE4MpobMimgCfQp37B8OwRRn0jLJ7/Vu8//PU 9/gAnj6ZFwSl9JR5V7PiMoWGcMp9c4HN =hBUY -----END PGP SIGNATURE----- From dwalsh at redhat.com Fri Feb 22 13:47:46 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 22 Feb 2008 08:47:46 -0500 Subject: excessively verbose policy In-Reply-To: <20080221232321.GB9069@nostromo.devel.redhat.com> References: <20080221232321.GB9069@nostromo.devel.redhat.com> Message-ID: <47BED282.6040502@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Nottingham wrote: > I was writing policy today, and I couldn't help notice a lot of > repetitiveness in our policy: > > libs_use_ld_so(...) > libs_use_shared_libs(...) > > These are needed by, well, everything. Can't they be assumed-unless-denied? > > Similarly, 99% of confined apps need: > > miscfiles_read_localization() > files_read_etc_files(.) > pipes & stream sockets > > Is there a way to streamline policy so there is a lot less > repetition? > > Bill > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list We have talked about this in the past, and so far it has not gone anywhere. The original goal when refpolicy policy was first written was to allow more fine grained control then the example policy, which grouped large amounts of access rules within a single macro. (can_network) for example. So we wanted to avoid this, and perhaps the pendulum swung too far to the opposite degree. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAke+0oIACgkQrlYvE4MpobPd5gCfYpoWTHLDhsCf1Ae1oTQFv4dA AukAn0voXayQTmjDZm+AvEWoFyU2n/Rz =sl9z -----END PGP SIGNATURE----- From sds at tycho.nsa.gov Fri Feb 22 14:47:41 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 22 Feb 2008 09:47:41 -0500 Subject: periodic policy audits In-Reply-To: <20080221232806.GC9069@nostromo.devel.redhat.com> References: <20080221232806.GC9069@nostromo.devel.redhat.com> Message-ID: <1203691661.2804.40.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2008-02-21 at 18:28 -0500, Bill Nottingham wrote: > Again, looking through the policy I see sections for policy > to confine cardmgr, /etc/hotplug scripts, updfstab, etc. Do > we do any routine policy updates to purge obsolete policy? > > If not, should we? (these questions really belong over on selinux list) I think part of the problem is that upstream policy needs to retain the ability to be used on existing releases, all the way back to RHEL4, although it does have ifdefs for that kind of thing. -- Stephen Smalley National Security Agency From marceklein at gmail.com Fri Feb 22 15:51:09 2008 From: marceklein at gmail.com (Marcelo Klein) Date: Fri, 22 Feb 2008 13:51:09 -0200 Subject: excessively verbose policy In-Reply-To: <47BED282.6040502@redhat.com> References: <20080221232321.GB9069@nostromo.devel.redhat.com> <47BED282.6040502@redhat.com> Message-ID: <13fbbfba0802220751g4cd140f6y83ad6c4f2105535d@mail.gmail.com> Is there any possibility of writing bundles of policies that can be "imported" into other configurations? Such as defining a package for a set of policies like "shared-libs", and then when writing the policy putting "import shared-libs" or something like that? Is this too much complex to do? Marcelo. 2008/2/22, Daniel J Walsh : > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Bill Nottingham wrote: > > I was writing policy today, and I couldn't help notice a lot of > > repetitiveness in our policy: > > > > libs_use_ld_so(...) > > libs_use_shared_libs(...) > > > > These are needed by, well, everything. Can't they be > assumed-unless-denied? > > > > Similarly, 99% of confined apps need: > > > > miscfiles_read_localization() > > files_read_etc_files(.) > > pipes & stream sockets > > > > Is there a way to streamline policy so there is a lot less > > repetition? > > > > Bill > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > We have talked about this in the past, and so far it has not gone > anywhere. The original goal when refpolicy policy was first written was > to allow more fine grained control then the example policy, which > grouped large amounts of access rules within a single macro. > (can_network) for example. So we wanted to avoid this, and perhaps the > pendulum swung too far to the opposite degree. > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAke+0oIACgkQrlYvE4MpobPd5gCfYpoWTHLDhsCf1Ae1oTQFv4dA > AukAn0voXayQTmjDZm+AvEWoFyU2n/Rz > =sl9z > -----END PGP SIGNATURE----- > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwalsh at redhat.com Fri Feb 22 16:57:26 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 22 Feb 2008 11:57:26 -0500 Subject: excessively verbose policy In-Reply-To: <13fbbfba0802220751g4cd140f6y83ad6c4f2105535d@mail.gmail.com> References: <20080221232321.GB9069@nostromo.devel.redhat.com> <47BED282.6040502@redhat.com> <13fbbfba0802220751g4cd140f6y83ad6c4f2105535d@mail.gmail.com> Message-ID: <47BEFEF6.4010202@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marcelo Klein wrote: > Is there any possibility of writing bundles of policies that can be > "imported" into other configurations? > Such as defining a package for a set of policies like "shared-libs", and > then when writing the policy putting "import shared-libs" or something like > that? > Is this too much complex to do? > > Marcelo. > No, this is what interfaces do, although they are more like functions calls. We have two ways of grouping access to a domain, either directory though allow rules, or by adding an attribute. For example type httpd_t, domain; allow domain self:file read; or allow httpd_t self:file read; Both generate the same policy. In refpolicy we have a interface domain_type() which adds the domain attribute. So we could move all libs_use_ld_so(domain) libs_use_shared_libs(domain) And eliminate these rules from all te files. The question is what granularity do you do this at. Almost every confined domain needs to read etc_t so if we added files_read_etc_files(domain) We could remove those, but now if someone wanted to write a confined domain without access to etc_t, his policy is a lot harder to write. > 2008/2/22, Daniel J Walsh : > > Bill Nottingham wrote: >>>> I was writing policy today, and I couldn't help notice a lot of >>>> repetitiveness in our policy: >>>> >>>> libs_use_ld_so(...) >>>> libs_use_shared_libs(...) >>>> >>>> These are needed by, well, everything. Can't they be > assumed-unless-denied? >>>> Similarly, 99% of confined apps need: >>>> >>>> miscfiles_read_localization() >>>> files_read_etc_files(.) >>>> pipes & stream sockets >>>> >>>> Is there a way to streamline policy so there is a lot less >>>> repetition? >>>> >>>> Bill >>>> >>>> -- >>>> fedora-selinux-list mailing list >>>> fedora-selinux-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > We have talked about this in the past, and so far it has not gone > anywhere. The original goal when refpolicy policy was first written was > to allow more fine grained control then the example policy, which > grouped large amounts of access rules within a single macro. > (can_network) for example. So we wanted to avoid this, and perhaps the > pendulum swung too far to the opposite degree. > > >> >> - -- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAke+/vYACgkQrlYvE4MpobODXgCgqIz5SV2TRH9LIt3LFePsQkXa tjsAoNACxe2ftqUHZhxRyDo70/c3Oa4Q =MJG/ -----END PGP SIGNATURE----- From selinux at gmail.com Mon Feb 25 02:28:29 2008 From: selinux at gmail.com (Tom London) Date: Sun, 24 Feb 2008 18:28:29 -0800 Subject: avahi wants getcap Message-ID: <4c4ba1530802241828r1e1b2f2egaa75b19a2239652f@mail.gmail.com> Running rawhide: avahi-0.6.22-7.fc9.i386, selinux-policy-3.3.0-1.fc9.noarch Appears avahi needs getcap: type=AVC msg=audit(1203904427.662:13): avc: denied { getcap } for pid=2255 comm="avahi-daemon" scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:system_r:avahi_t:s0 tclass=process type=SYSCALL msg=audit(1203904427.662:13): arch=40000003 syscall=184 success=no exit=-13 a0=8a1a78c a1=0 a2=4cb0f0 a3=8a1a788 items=0 ppid=1 pid=2255 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="avahi-daemon" exe="/usr/sbin/avahi-daemon" subj=system_u:system_r:avahi_t:s0 key=(null) type=AVC msg=audit(1203904427.665:14): avc: denied { getcap } for pid=2255 comm="avahi-daemon" scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:system_r:avahi_t:s0 tclass=process type=SYSCALL msg=audit(1203904427.665:14): arch=40000003 syscall=184 success=no exit=-13 a0=8a1b454 a1=0 a2=4cb0f0 a3=8a1b450 items=0 ppid=1 pid=2255 auid=4294967295 uid=70 gid=70 euid=70 suid=70 fsuid=70 egid=70 sgid=70 fsgid=70 tty=(none) ses=4294967295 comm="avahi-daemon" exe="/usr/sbin/avahi-daemon" subj=system_u:system_r:avahi_t:s0 key=(null) -- Tom London From dwalsh at redhat.com Mon Feb 25 14:22:56 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 25 Feb 2008 09:22:56 -0500 Subject: avahi wants getcap In-Reply-To: <4c4ba1530802241828r1e1b2f2egaa75b19a2239652f@mail.gmail.com> References: <4c4ba1530802241828r1e1b2f2egaa75b19a2239652f@mail.gmail.com> Message-ID: <47C2CF40.3070904@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom London wrote: > Running rawhide: avahi-0.6.22-7.fc9.i386, selinux-policy-3.3.0-1.fc9.noarch > > Appears avahi needs getcap: > > > type=AVC msg=audit(1203904427.662:13): avc: denied { getcap } for > pid=2255 comm="avahi-daemon" scontext=system_u:system_r:avahi_t:s0 > tcontext=system_u:system_r:avahi_t:s0 tclass=process > type=SYSCALL msg=audit(1203904427.662:13): arch=40000003 syscall=184 > success=no exit=-13 a0=8a1a78c a1=0 a2=4cb0f0 a3=8a1a788 items=0 > ppid=1 pid=2255 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 > egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="avahi-daemon" > exe="/usr/sbin/avahi-daemon" subj=system_u:system_r:avahi_t:s0 > key=(null) > type=AVC msg=audit(1203904427.665:14): avc: denied { getcap } for > pid=2255 comm="avahi-daemon" scontext=system_u:system_r:avahi_t:s0 > tcontext=system_u:system_r:avahi_t:s0 tclass=process > type=SYSCALL msg=audit(1203904427.665:14): arch=40000003 syscall=184 > success=no exit=-13 a0=8a1b454 a1=0 a2=4cb0f0 a3=8a1b450 items=0 > ppid=1 pid=2255 auid=4294967295 uid=70 gid=70 euid=70 suid=70 fsuid=70 > egid=70 sgid=70 fsgid=70 tty=(none) ses=4294967295 comm="avahi-daemon" > exe="/usr/sbin/avahi-daemon" subj=system_u:system_r:avahi_t:s0 > key=(null) > > I am just going to give everydomain that has setcap, getcap. Since these are suddenly popping up all over. I figure if you can setcap, you probably should be allowed to get it as well. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfCzz8ACgkQrlYvE4MpobP/CwCfUB/Vy5MdDBGHlfR+k5QfmmEK fjkAnAygZPAuaiUiXmSmcr68vxX9wNKe =wC5i -----END PGP SIGNATURE----- From olivares14031 at yahoo.com Mon Feb 25 15:26:51 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Mon, 25 Feb 2008 07:26:51 -0800 (PST) Subject: SELinux is preventing avahi-daemon (avahi_t) "getcap" to (avahi_t). Message-ID: <340677.47596.qm@web52607.mail.re2.yahoo.com> Dear all, I am running rawhide. I see the following: Is avahi-deamon doing something that it shouldn't? Thanks, Antonio Summary: SELinux is preventing avahi-daemon (avahi_t) "getcap" to (avahi_t). Detailed Description: SELinux denied access requested by avahi-daemon. It is not expected that this access is required by avahi-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: 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:avahi_t Target Context system_u:system_r:avahi_t Target Objects None [ process ] Source avahi-daemon Source Path /usr/sbin/avahi-daemon Port Host localhost Source RPM Packages avahi-0.6.17-1.fc7 Target RPM Packages Policy RPM selinux-policy-3.3.0-1.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name localhost Platform Linux localhost 2.6.25-0.65.rc2.git7.fc9 #1 SMP Sat Feb 23 23:06:09 EST 2008 i686 athlon Alert Count 12 First Seen Sat 23 Feb 2008 01:04:44 PM CST Last Seen Mon 25 Feb 2008 07:19:57 AM CST Local ID e83550c8-f8d8-4109-9f8f-215e82dbb99c Line Numbers Raw Audit Messages host=localhost type=AVC msg=audit(1203945597.443:10): avc: denied { getcap } for pid=2159 comm="avahi-daemon" scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:system_r:avahi_t:s0 tclass=process host=localhost type=SYSCALL msg=audit(1203945597.443:10): arch=40000003 syscall=184 success=no exit=-13 a0=8c60e3c a1=0 a2=9df0f0 a3=8c60e38 items=0 ppid=1 pid=2159 auid=4294967295 uid=70 gid=70 euid=70 suid=70 fsuid=70 egid=70 sgid=70 fsgid=70 tty=(none) ses=4294967295 comm="avahi-daemon" exe="/usr/sbin/avahi-daemon" subj=system_u:system_r:avahi_t:s0 key=(null) ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From dwalsh at redhat.com Mon Feb 25 17:29:13 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 25 Feb 2008 12:29:13 -0500 Subject: SELinux is preventing avahi-daemon (avahi_t) "getcap" to (avahi_t). In-Reply-To: <340677.47596.qm@web52607.mail.re2.yahoo.com> References: <340677.47596.qm@web52607.mail.re2.yahoo.com> Message-ID: <47C2FAE9.5080603@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Antonio Olivares wrote: > Dear all, > > I am running rawhide. I see the following: > Is avahi-deamon doing something that it shouldn't? > > Thanks, > > Antonio > > Summary: > > SELinux is preventing avahi-daemon (avahi_t) "getcap" > to (avahi_t). > > Detailed Description: > > SELinux denied access requested by avahi-daemon. It is > not expected that this > access is required by avahi-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: > > 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:avahi_t > Target Context > system_u:system_r:avahi_t > Target Objects None [ process ] > Source avahi-daemon > Source Path /usr/sbin/avahi-daemon > Port > Host localhost > Source RPM Packages avahi-0.6.17-1.fc7 > Target RPM Packages > Policy RPM > selinux-policy-3.3.0-1.fc9 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name catchall > Host Name localhost > Platform Linux localhost > 2.6.25-0.65.rc2.git7.fc9 #1 SMP > Sat Feb 23 23:06:09 EST > 2008 i686 athlon > Alert Count 12 > First Seen Sat 23 Feb 2008 01:04:44 > PM CST > Last Seen Mon 25 Feb 2008 07:19:57 > AM CST > Local ID > e83550c8-f8d8-4109-9f8f-215e82dbb99c > Line Numbers > > Raw Audit Messages > > host=localhost type=AVC msg=audit(1203945597.443:10): > avc: denied { getcap } for pid=2159 > comm="avahi-daemon" > scontext=system_u:system_r:avahi_t:s0 > tcontext=system_u:system_r:avahi_t:s0 tclass=process > > host=localhost type=SYSCALL > msg=audit(1203945597.443:10): arch=40000003 > syscall=184 success=no exit=-13 a0=8c60e3c a1=0 > a2=9df0f0 a3=8c60e38 items=0 ppid=1 pid=2159 > auid=4294967295 uid=70 gid=70 euid=70 suid=70 fsuid=70 > egid=70 sgid=70 fsgid=70 tty=(none) ses=4294967295 > comm="avahi-daemon" exe="/usr/sbin/avahi-daemon" > subj=system_u:system_r:avahi_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 No, I am guessing that some library function or kernel change has happened to cause all apps that use setcap to need getcap. So I am making the change in policy. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfC+ukACgkQrlYvE4MpobPQ9ACgzIKefOCCXipfJJgwGs9VUq/l yR0Anj6oX/fqRl9QmdW/lAgOwnsKnnQf =Q/Um -----END PGP SIGNATURE----- From gene.heskett at verizon.net Tue Feb 26 03:56:52 2008 From: gene.heskett at verizon.net (Gene Heskett) Date: Mon, 25 Feb 2008 22:56:52 -0500 Subject: SA problem, selinux seems to be killing spamassassin Message-ID: <200802252256.52859.gene.heskett@verizon.net> Greetings; I get home tonight with the spam going wild, so I restart spamassassin, and get another copy of this: Summary: SELinux is preventing spamd(/usr/bin/perl) (spamd_t) "kill" to (spamd_t). Detailed Description: SELinux denied access requested by spamd(/usr/bin/perl). It is not expected that this access is required by spamd(/usr/bin/perl) and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:spamd_t:s0 Target Context system_u:system_r:spamd_t:s0 Target Objects None [ capability ] Source spamd(/usr/bin/perl) Port Host coyote.coyote.den Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.0.8-84.fc8 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name coyote.coyote.den Platform Linux coyote.coyote.den 2.6.24 #1 SMP PREEMPT Sun Feb 10 20:51:31 EST 2008 i686 athlon Alert Count 10 First Seen Wed 20 Feb 2008 09:36:02 PM EST Last Seen Mon 25 Feb 2008 10:51:32 PM EST Local ID 6d119b1a-2693-43cf-b27b-f4c2d8339623 Line Numbers Raw Audit Messages host=coyote.coyote.den type=AVC msg=audit(1203997892.182:2127): avc: denied { kill } for pid=5699 comm="spamd" capability=5 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:system_r:spamd_t:s0 tclass=capability host=coyote.coyote.den type=SYSCALL msg=audit(1203997892.182:2127): arch=40000003 syscall=37 success=no exit=-1 a0=3f42 a1=2 a2=4af5f5cc a3=80775a8 items=0 ppid=1 pid=5699 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="spamd" exe="/usr/bin/perl" subj=system_u:system_r:spamd_t:s0 key=(null) ===================== So there's the bug report. What can I do? -- 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) "Hi, I'm Professor Alan Ginsburg... But you can call me... Captain Toke." -- John Lovitz, as ex-Supreme Court nominee Alan Ginsburg, on SNL From olivares14031 at yahoo.com Tue Feb 26 13:29:49 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Tue, 26 Feb 2008 05:29:49 -0800 (PST) Subject: SELinux is preventing plugin-config from making the program stack executable/seamonkey Message-ID: <744746.86203.qm@web52608.mail.re2.yahoo.com> Dear all, I have changed the stack to allow firefox to use the stack, then I reverted. I read Jim's exchange with Mr. Dan Walsh and there it was mentioned about nspluginwrapper. I installed it and I see the following every time I start firefox/seamonkey. I have avoided to do anything because I am not sure what to do. One side of me tells me to do what setroubleshoot tells me, the other tells me to ask for advice as to which is the best way to proceed and fix this issue(s) for good. I leave it in the hands of the people that know best and follow your guidance carefully. TIA, Antonio Summary: SELinux is preventing plugin-config from making the program stack executable. Detailed Description: The plugin-config 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 plugin-config 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 plugin-config to run correctly, you can change the context of the executable to unconfined_execmem_exec_t. "chcon -t unconfined_execmem_exec_t '/usr/lib/nspluginwrapper/plugin-config'" 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 '/usr/lib/nspluginwrapper/plugin-config'" Fix Command: chcon -t unconfined_execmem_exec_t '/usr/lib/nspluginwrapper/plugin-config' 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 Source Path /usr/lib/firefox-3.0b3pre/firefox Port Host localhost Source RPM Packages nspluginwrapper-0.9.91.5-22.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.0-1.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.25-0.65.rc2.git7.fc9 #1 SMP Sat Feb 23 23:06:09 EST 2008 i686 athlon Alert Count 133 First Seen Fri 01 Feb 2008 05:08:54 PM CST Last Seen Tue 26 Feb 2008 06:55:45 AM CST Local ID c4806f30-a6dc-43b0-8901-5531075795f7 Line Numbers Raw Audit Messages host=localhost type=AVC msg=audit(1204030545.936:22): avc: denied { execstack } for pid=2959 comm="plugin-config" 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(1204030545.936:22): arch=40000003 syscall=125 success=no exit=-13 a0=bfbc9000 a1=1000 a2=1000007 a3=fffff000 items=0 ppid=2957 pid=2959 auid=500 uid=500 gid=500 euid=0 suid=0 fsuid=0 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="plugin-config" exe="/usr/lib/nspluginwrapper/plugin-config" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) **** end of nspluginwrapper ****** **** start of seamonkey setroubleshoot message *** Summary: SELinux is preventing seamonkey-bin from making the program stack executable. Detailed Description: The seamonkey-bin 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 seamonkey-bin 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 seamonkey-bin to run correctly, you can change the context of the executable to unconfined_execmem_exec_t. "chcon -t unconfined_execmem_exec_t '/usr/lib/seamonkey-1.1.8/seamonkey-bin'" 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 '/usr/lib/seamonkey-1.1.8/seamonkey-bin'" Fix Command: chcon -t unconfined_execmem_exec_t '/usr/lib/seamonkey-1.1.8/seamonkey-bin' 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 Source Path /usr/lib/firefox-3.0b3pre/firefox Port Host localhost Source RPM Packages seamonkey-1.1.8-4.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.0-1.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.25-0.65.rc2.git7.fc9 #1 SMP Sat Feb 23 23:06:09 EST 2008 i686 athlon Alert Count 135 First Seen Fri 01 Feb 2008 05:08:54 PM CST Last Seen Tue 26 Feb 2008 07:24:52 AM CST Local ID c4806f30-a6dc-43b0-8901-5531075795f7 Line Numbers Raw Audit Messages host=localhost type=AVC msg=audit(1204032292.58:34): avc: denied { execstack } for pid=4524 comm="seamonkey-bin" 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(1204032292.58:34): arch=40000003 syscall=125 success=no exit=-13 a0=bfa5e000 a1=1000 a2=1000007 a3=fffff000 items=0 ppid=1 pid=4524 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="seamonkey-bin" exe="/usr/lib/seamonkey-1.1.8/seamonkey-bin" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) ***** end of seamonkey ***** ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From mike.clarkson at baesystems.com Tue Feb 26 17:02:01 2008 From: mike.clarkson at baesystems.com (Clarkson, Mike R (US SSA)) Date: Tue, 26 Feb 2008 09:02:01 -0800 Subject: excessively verbose policy References: <20080221232321.GB9069@nostromo.devel.redhat.com> Message-ID: <0794F277152EF94AA637E3AECF5CB70F111DFC@blums0042.bluelnk.net> You can always create your own interface to eliminate the repetition that you're seeing. That's what I did. I created a basic_app module with a template that takes care of the basic stuff that I found nearly all of my policy modules needed. Here is what my interface looks like: ################################################ ## ## Call this template for basic functionality necessary for most ## application domains ## ## ##

## This template creates derived domains for applications ##

## ## The prefix for domain name. For example: somedomain ## This will result in the creation of the following types: ## somedomain_t ## somedomain_exec_t ## ## The prefix of the user domain (for example, user if the prefix for user_t), ## which will be running the client/server. NOTE: This must be an unprivileged ## user, such as user_t or staff_t. It will NOT work for a privileged user such ## as sysadm_t or secadm_t. ## template(`basic_app_unpriv_template',` ################################ # Declarations type $1_t; domain_type($1_t) ## Access to shared libraries libs_use_ld_so($1_t) libs_use_shared_libs($1_t) miscfiles_read_localization($1_t) ## Type of the exec, which is the entrypoint into the domain type $1_exec_t; files_type($1_exec_t) domain_entry_file($1_t, $1_exec_t) ## allow transitions from unprivileged user to this domain gen_require(` type $2_t; ') userdom_entry_spec_domtrans_unpriv_users($1_t) domain_auto_trans($2_t, $1_exec_t, $1_t) ## allow this domain to use sshd file descriptors ssh_use_fd($1_t) ## Allow this domain to use newrole file descriptors. Needed ## if we newrole to a new shell before running seutil_use_newrole_fds($1_t) ## allow this domain to use the correct devpts_t (tty) type userdom_use_user_terminals($2, $1_t) ## allow this domain to send a SIGCHLD signal back to the shell process ## to notify the shell that the child process has ended allow $1_t $2_t:process sigchld; ## need this to allow ps to see the process running in this domain, ## which is listed in the /proc dir ##allow $2_t $1_t:dir search_dir_perms; ##allow $2_t $1_t:file read_file_perms; allow_unpriv_ps_access($1_t) fs_search_auto_mountpoints($1_t) files_read_etc_files($1_t) files_search_home($1_t) fs_search_nfs($1_t) files_search_usr($1_t) files_list_tmp($1_t) ') > -----Original Message----- > From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux-list- > bounces at redhat.com] On Behalf Of Bill Nottingham > Sent: Thursday, February 21, 2008 3:23 PM > To: fedora-selinux-list at redhat.com > Subject: excessively verbose policy > > I was writing policy today, and I couldn't help notice a lot of > repetitiveness in our policy: > > libs_use_ld_so(...) > libs_use_shared_libs(...) > > These are needed by, well, everything. Can't they be assumed-unless- > denied? > > Similarly, 99% of confined apps need: > > miscfiles_read_localization() > files_read_etc_files(.) > pipes & stream sockets > > Is there a way to streamline policy so there is a lot less > repetition? > > Bill > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From ftaylor at redhat.com Tue Feb 26 20:50:50 2008 From: ftaylor at redhat.com (Forrest Taylor) Date: Tue, 26 Feb 2008 13:50:50 -0700 Subject: Changing policies, using enforcing=0 the first time In-Reply-To: <1202492579.4495.17.camel@localhost.localdomain> References: <1202481771.3889.15.camel@localhost.localdomain> <1202482457.27371.338.camel@moss-spartans.epoch.ncsc.mil> <1202484010.4495.9.camel@localhost.localdomain> <1202485141.27371.375.camel@moss-spartans.epoch.ncsc.mil> <1202492579.4495.17.camel@localhost.localdomain> Message-ID: <1204059050.3827.20.camel@localhost.localdomain> On Fri, 2008-02-08 at 10:42 -0700, Forrest Taylor wrote: > On Fri, 2008-02-08 at 10:39 -0500, Stephen Smalley wrote: > > On Fri, 2008-02-08 at 08:20 -0700, Forrest Taylor wrote: > > > On Fri, 2008-02-08 at 09:54 -0500, Stephen Smalley wrote: > > > > On Fri, 2008-02-08 at 07:42 -0700, Forrest Taylor wrote: > > > > > I am running into a strange occurrence running RHEL5.1 with an updated > > > > > policy (2.4.6-106.el5_1.3). By default, it runs the targeted policy. I > > > > > install the mls and the strict policy and touch /.autorelabel. The > > > > > first time that I boot to one of these other policies, I get a kernel > > > > > panic, and I have to use enforcing=0. The strange thing is that I can > > > > > then go back and forth between any policy without setting permissive > > > > > mode--that is, I only have to set enforcing=0 the first time that I make > > > > > a policy change, but subsequent times it is not required. Does fixfiles > > > > > change something the first time that allows the relabel to work > > > > > subsequent times in enforcing mode? Any thoughts? > > > > > > > > IIRC, RHEL5 still had separate shlib_t vs. lib_t types in the strict/mls > > > > policies, which means that when you first switch from targeted, you > > > > can't execute shared objects in enforcing mode until you've first > > > > relabeled. targeted policy aliases them into a single type, and > > > > upstream policy has done away with the distinction now as well, I > > > > believe. > > > > > > > > So, on the first conversion, the xattrs get reset from lib_t to shlib_t, > > > > then they stay that way because targeted views them as identical. > > > > > > AH! I knew it was something like that. I couldn't find the difference > > > because shlib_t is a typealias to lib_t, so it always shows lib_t. > > > > > > Is there any way in the targeted policy to verify that it actually is > > > shlib_t instead of lib_t? It obviously must have some difference for > > > strict/mls to work. > > > > No, the kernel canonicalizes the context to the policy's native form > > before returning it via getxattr. That was introduced to accomodate the > > transition from non-MCS/MLS to MCS/MLS, so that the kernel could > > auto-magically add the MCS/MLS field for files on filesystems created > > under the older policy (e.g. for going from RHEL4 -> RHEL5). But it > > also means that even if the on-disk xattr has shlib_t, the kernel will > > return lib_t under targeted policy due to the canonicalization. > > Ah, that makes sense. Just for future reference, I can change policies > without setting permissive mode by changing the context to shlib_t on > the following: > > /lib/libblkid.so* > /lib/libc.so* > /lib/libdevmapper.so* > /lib/libdl.so* > /lib/libselinux.so* > /lib/libsepol.so > /lib/libtermcap.so* > /lib/libuuid.so* > > These came from the shared libraries needed for init, mount and sh. > Once those are changed, the system can get far enough through rc.sysinit > to run fixfiles. I hate to reply to my own post, but is there some reason that we do not set the context on these files by default? How do they originally get the context--from the parent directory? Perhaps a %post in the selinux-policy-targeted rpm would fix it? Thanks, Forrest -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwalsh at redhat.com Tue Feb 26 21:04:44 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 26 Feb 2008 16:04:44 -0500 Subject: Changing policies, using enforcing=0 the first time In-Reply-To: <1204059050.3827.20.camel@localhost.localdomain> References: <1202481771.3889.15.camel@localhost.localdomain> <1202482457.27371.338.camel@moss-spartans.epoch.ncsc.mil> <1202484010.4495.9.camel@localhost.localdomain> <1202485141.27371.375.camel@moss-spartans.epoch.ncsc.mil> <1202492579.4495.17.camel@localhost.localdomain> <1204059050.3827.20.camel@localhost.localdomain> Message-ID: <47C47EEC.40400@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Forrest Taylor wrote: > On Fri, 2008-02-08 at 10:42 -0700, Forrest Taylor wrote: >> On Fri, 2008-02-08 at 10:39 -0500, Stephen Smalley wrote: >>> On Fri, 2008-02-08 at 08:20 -0700, Forrest Taylor wrote: >>>> On Fri, 2008-02-08 at 09:54 -0500, Stephen Smalley wrote: >>>>> On Fri, 2008-02-08 at 07:42 -0700, Forrest Taylor wrote: >>>>>> I am running into a strange occurrence running RHEL5.1 with an updated >>>>>> policy (2.4.6-106.el5_1.3). By default, it runs the targeted policy. I >>>>>> install the mls and the strict policy and touch /.autorelabel. The >>>>>> first time that I boot to one of these other policies, I get a kernel >>>>>> panic, and I have to use enforcing=0. The strange thing is that I can >>>>>> then go back and forth between any policy without setting permissive >>>>>> mode--that is, I only have to set enforcing=0 the first time that I make >>>>>> a policy change, but subsequent times it is not required. Does fixfiles >>>>>> change something the first time that allows the relabel to work >>>>>> subsequent times in enforcing mode? Any thoughts? >>>>> IIRC, RHEL5 still had separate shlib_t vs. lib_t types in the strict/mls >>>>> policies, which means that when you first switch from targeted, you >>>>> can't execute shared objects in enforcing mode until you've first >>>>> relabeled. targeted policy aliases them into a single type, and >>>>> upstream policy has done away with the distinction now as well, I >>>>> believe. >>>>> >>>>> So, on the first conversion, the xattrs get reset from lib_t to shlib_t, >>>>> then they stay that way because targeted views them as identical. >>>> AH! I knew it was something like that. I couldn't find the difference >>>> because shlib_t is a typealias to lib_t, so it always shows lib_t. >>>> >>>> Is there any way in the targeted policy to verify that it actually is >>>> shlib_t instead of lib_t? It obviously must have some difference for >>>> strict/mls to work. >>> No, the kernel canonicalizes the context to the policy's native form >>> before returning it via getxattr. That was introduced to accomodate the >>> transition from non-MCS/MLS to MCS/MLS, so that the kernel could >>> auto-magically add the MCS/MLS field for files on filesystems created >>> under the older policy (e.g. for going from RHEL4 -> RHEL5). But it >>> also means that even if the on-disk xattr has shlib_t, the kernel will >>> return lib_t under targeted policy due to the canonicalization. >> Ah, that makes sense. Just for future reference, I can change policies >> without setting permissive mode by changing the context to shlib_t on >> the following: >> >> /lib/libblkid.so* >> /lib/libc.so* >> /lib/libdevmapper.so* >> /lib/libdl.so* >> /lib/libselinux.so* >> /lib/libsepol.so >> /lib/libtermcap.so* >> /lib/libuuid.so* >> >> These came from the shared libraries needed for init, mount and sh. >> Once those are changed, the system can get far enough through rc.sysinit >> to run fixfiles. > > I hate to reply to my own post, but is there some reason that we do not > set the context on these files by default? How do they originally get > the context--from the parent directory? Perhaps a %post in the > selinux-policy-targeted rpm would fix it? > > Thanks, > > Forrest They are set when they are installed by rpm. The problem is that targeted policy labels them lib_t. And in MLS they are labeled shlib_t. mls policy does not allow the execution of lib_t, so when init tries to execute the library code, it gets a denial and blows up. In Fedora 9 and beyond all shared libraries in all policies are labeled lib_t and confined domains are allowed execution, so in the future this should not be a problem. > > > ------------------------------------------------------------------------ > > -- > 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 iEYEARECAAYFAkfEfuwACgkQrlYvE4MpobN/AwCg2GLC43xTjfJ4b4tVCiVzODZI 4xwAnR/nkRdked5hTu1nVNpcAMeKoTB4 =PlRq -----END PGP SIGNATURE----- From olivares14031 at yahoo.com Tue Feb 26 21:22:15 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Tue, 26 Feb 2008 13:22:15 -0800 (PST) Subject: SELinux is preventing seamonkey-bin from making the program stack executable. Message-ID: <789853.42386.qm@web52609.mail.re2.yahoo.com> Dear all, After applying the fix suggested by Mr. Walsh, [root at localhost ~]# setsebool -P allow_unconfined_nsplugin_transition=1 allow_nsplugin_execmem=1 [root at localhost ~]# getsebool -a | grep nsp allow_nsplugin_execmem --> on allow_unconfined_nsplugin_transition --> on Seamonkey is asking permission for the stack. I do not want to allow access if it is not correct for seamonkey to allow stack execution. Please help me nail this one as well and crossing my fingers that firefox/minefield does not ask as well. Summary: SELinux is preventing seamonkey-bin from making the program stack executable. Detailed Description: The seamonkey-bin 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 seamonkey-bin 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 seamonkey-bin to run correctly, you can change the context of the executable to unconfined_execmem_exec_t. "chcon -t unconfined_execmem_exec_t '/usr/lib/seamonkey-1.1.8/seamonkey-bin'" 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 '/usr/lib/seamonkey-1.1.8/seamonkey-bin'" Fix Command: chcon -t unconfined_execmem_exec_t '/usr/lib/seamonkey-1.1.8/seamonkey-bin' 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 Source Path /usr/lib/firefox-3.0b3pre/firefox Port Host localhost Source RPM Packages seamonkey-1.1.8-4.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.0-1.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.25-0.65.rc2.git7.fc9 #1 SMP Sat Feb 23 23:06:09 EST 2008 i686 athlon Alert Count 140 First Seen Fri 01 Feb 2008 05:08:54 PM CST Last Seen Tue 26 Feb 2008 03:17:04 PM CST Local ID c4806f30-a6dc-43b0-8901-5531075795f7 Line Numbers Raw Audit Messages host=localhost type=AVC msg=audit(1204060624.602:108): avc: denied { execstack } for pid=20290 comm="seamonkey-bin" 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(1204060624.602:108): arch=40000003 syscall=125 success=no exit=-13 a0=bfc72000 a1=1000 a2=1000007 a3=fffff000 items=0 ppid=1 pid=20290 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="seamonkey-bin" exe="/usr/lib/seamonkey-1.1.8/seamonkey-bin" 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 Tue Feb 26 21:26:08 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Tue, 26 Feb 2008 13:26:08 -0800 (PST) Subject: SELinux is preventing plugin-config (nsplugin_config_t) "execstack" to (nsplugin_config_t) Message-ID: <952131.26172.qm@web52611.mail.re2.yahoo.com> Ok Seamonkey and selinux, firefox, and nsplugin. Here are the results. Thanks for your suggestions and advice in advance. Antonio Summary: SELinux is preventing plugin-config (nsplugin_config_t) "execstack" to (nsplugin_config_t). Detailed Description: SELinux denied access requested by plugin-config. It is not expected that this access is required by plugin-config and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context unconfined_u:unconfined_r:nsplugin_config_t :SystemLow-SystemHigh Target Context unconfined_u:unconfined_r:nsplugin_config_t :SystemLow-SystemHigh Target Objects None [ process ] Source plugin-config Source Path /usr/lib/nspluginwrapper/plugin-config Port Host localhost Source RPM Packages nspluginwrapper-0.9.91.5-22.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.0-1.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name localhost Platform Linux localhost 2.6.25-0.65.rc2.git7.fc9 #1 SMP Sat Feb 23 23:06:09 EST 2008 i686 athlon Alert Count 2 First Seen Tue 26 Feb 2008 03:17:23 PM CST Last Seen Tue 26 Feb 2008 03:22:56 PM CST Local ID 276820c9-9871-4632-8ec1-c8909c8d7c0b Line Numbers Raw Audit Messages host=localhost type=AVC msg=audit(1204060976.98:110): avc: denied { execstack } for pid=20500 comm="plugin-config" scontext=unconfined_u:unconfined_r:nsplugin_config_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:nsplugin_config_t:s0-s0:c0.c1023 tclass=process host=localhost type=SYSCALL msg=audit(1204060976.98:110): arch=40000003 syscall=125 success=no exit=-13 a0=bf957000 a1=1000 a2=1000007 a3=fffff000 items=0 ppid=20498 pid=20500 auid=500 uid=500 gid=500 euid=0 suid=0 fsuid=0 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="plugin-config" exe="/usr/lib/nspluginwrapper/plugin-config" subj=unconfined_u:unconfined_r:nsplugin_config_t:s0-s0:c0.c1023 key=(null) ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From olivares14031 at yahoo.com Tue Feb 26 21:27:41 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Tue, 26 Feb 2008 13:27:41 -0800 (PST) Subject: SELinux is preventing npviewer.bin (nsplugin_t) "search" to ./pcm (alsa_etc_rw_t) Message-ID: <383003.96152.qm@web52606.mail.re2.yahoo.com> What is npviewr? What does it do? Setroubleshoot reports that it is causing trouble: Summary: SELinux is preventing npviewer.bin (nsplugin_t) "search" to ./pcm (alsa_etc_rw_t). Detailed Description: SELinux denied access requested by npviewer.bin. It is not expected that this access is required by npviewer.bin and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for ./pcm, restorecon -v './pcm' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context unconfined_u:unconfined_r:nsplugin_t:SystemLow- SystemHigh Target Context system_u:object_r:alsa_etc_rw_t Target Objects ./pcm [ dir ] Source npviewer.bin Source Path /usr/lib/nspluginwrapper/npviewer.bin Port Host localhost Source RPM Packages nspluginwrapper-0.9.91.5-22.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.0-1.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name localhost Platform Linux localhost 2.6.25-0.65.rc2.git7.fc9 #1 SMP Sat Feb 23 23:06:09 EST 2008 i686 athlon Alert Count 1 First Seen Tue 26 Feb 2008 03:24:34 PM CST Last Seen Tue 26 Feb 2008 03:24:34 PM CST Local ID 21b2a4d1-ec93-4670-a34e-841d82827177 Line Numbers Raw Audit Messages host=localhost type=AVC msg=audit(1204061074.835:111): avc: denied { search } for pid=20571 comm="npviewer.bin" name="pcm" dev=dm-0 ino=28344759 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=system_u:object_r:alsa_etc_rw_t:s0 tclass=dir host=localhost type=SYSCALL msg=audit(1204061074.835:111): arch=40000003 syscall=5 success=no exit=-13 a0=906d258 a1=0 a2=1b6 a3=0 items=0 ppid=20512 pid=20571 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="npviewer.bin" exe="/usr/lib/nspluginwrapper/npviewer.bin" subj=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 key=(null) Regards, Antonio ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From ftaylor at redhat.com Tue Feb 26 22:15:15 2008 From: ftaylor at redhat.com (Forrest Taylor) Date: Tue, 26 Feb 2008 15:15:15 -0700 Subject: User web pages in the strict policy Message-ID: <1204064115.3827.30.camel@localhost.localdomain> I am using RHEL5.1 with selinux-policy-strict-2.4.6-106.el5_1.3. Users in user_r or staff_r cannot see the public_html directory nor it's content using the strict policy. The public_html directory gets httpd_user_content_t or httpd_staff_content_t. I was expecting to be able to view my own content, but I cannot. `ls -Z` shows that I cannot view the permission or context. Is this expected behavior? If so, what is the logic behind it? Thanks, Forrest 1. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ftaylor at redhat.com Tue Feb 26 22:23:41 2008 From: ftaylor at redhat.com (Forrest Taylor) Date: Tue, 26 Feb 2008 15:23:41 -0700 Subject: Polyinstantiation that allows group access Message-ID: <1204064621.3827.40.camel@localhost.localdomain> Is there any way to allow polyinstantiation to give the same view to a number of users? For example, I want to give users in the adm group access to the same shared /tmp (really /tmp-adm) directory, users in the wheel group access to a different shared /tmp (really /tmp-wheel), and all other users access to their own individual /tmp. Is this possible? Of course, the more I think about this, the more I see reasons not to do it such as conflicts--what if a user were in the adm and wheel groups? For a single group, I can see excluding them from the polyinstantiated directory entirely, but with several groups I cannot think of a way to safely do this. Thoughts? Thanks, Forrest -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tmraz at redhat.com Tue Feb 26 22:37:57 2008 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 26 Feb 2008 23:37:57 +0100 Subject: Polyinstantiation that allows group access In-Reply-To: <1204064621.3827.40.camel@localhost.localdomain> References: <1204064621.3827.40.camel@localhost.localdomain> Message-ID: <1204065477.3056.69.camel@vespa.frost.loc> On Tue, 2008-02-26 at 15:23 -0700, Forrest Taylor wrote: > Is there any way to allow polyinstantiation to give the same view to a > number of users? For example, I want to give users in the adm group > access to the same shared /tmp (really /tmp-adm) directory, users in the > wheel group access to a different shared /tmp (really /tmp-wheel), and > all other users access to their own individual /tmp. Is this possible? > > Of course, the more I think about this, the more I see reasons not to do > it such as conflicts--what if a user were in the adm and wheel groups? > For a single group, I can see excluding them from the polyinstantiated > directory entirely, but with several groups I cannot think of a way to > safely do this. Thoughts? There isn't such method in pam_namespace yet. The question is how would you resolve the conflicts. But in the pam-0.99.10.0 there is already possibility to share a polyinstantiated directory among users (using the shared flag). The directory would be polyinstantiated purely based on the context (or level) so the users with the same context will get the same instance. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From ftaylor at redhat.com Tue Feb 26 23:06:05 2008 From: ftaylor at redhat.com (Forrest Taylor) Date: Tue, 26 Feb 2008 16:06:05 -0700 Subject: Polyinstantiation that allows group access In-Reply-To: <1204065477.3056.69.camel@vespa.frost.loc> References: <1204064621.3827.40.camel@localhost.localdomain> <1204065477.3056.69.camel@vespa.frost.loc> Message-ID: <1204067165.3827.52.camel@localhost.localdomain> On Tue, 2008-02-26 at 23:37 +0100, Tomas Mraz wrote: > On Tue, 2008-02-26 at 15:23 -0700, Forrest Taylor wrote: > > Is there any way to allow polyinstantiation to give the same view to a > > number of users? For example, I want to give users in the adm group > > access to the same shared /tmp (really /tmp-adm) directory, users in the > > wheel group access to a different shared /tmp (really /tmp-wheel), and > > all other users access to their own individual /tmp. Is this possible? > > > > Of course, the more I think about this, the more I see reasons not to do > > it such as conflicts--what if a user were in the adm and wheel groups? > > For a single group, I can see excluding them from the polyinstantiated > > directory entirely, but with several groups I cannot think of a way to > > safely do this. Thoughts? > > There isn't such method in pam_namespace yet. The question is how would > you resolve the conflicts. But in the pam-0.99.10.0 there is already > possibility to share a polyinstantiated directory among users (using the > shared flag). The directory would be polyinstantiated purely based on > the context (or level) so the users with the same context will get the > same instance. Excellent, thanks for the quick reply! I think the shared flag would work just fine. We could change the context of users that were in the groups that needed to be separate and PAM would take care of the rest. Thanks, Forrest -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mcepl at redhat.com Wed Feb 27 10:01:08 2008 From: mcepl at redhat.com (Matej Cepl) Date: Wed, 27 Feb 2008 11:01:08 +0100 Subject: SELinux is preventing npviewer.bin (nsplugin_t) "search" to ./pcm (alsa_etc_rw_t) References: <383003.96152.qm@web52606.mail.re2.yahoo.com> Message-ID: <40pf95xoif.ln2@ppp1053.in.ipex.cz> On 2008-02-26, 21:27 GMT, Antonio Olivares wrote: > What is npviewr? > > What does it do? > > Setroubleshoot reports that it is causing trouble: File the bug to RH BZ. Matej From maximilianbianco at gmail.com Wed Feb 27 18:42:07 2008 From: maximilianbianco at gmail.com (max bianco) Date: Wed, 27 Feb 2008 13:42:07 -0500 Subject: VOIP policy Message-ID: Do current SELinux policies support VoIP (internet telephony)? Thanks, Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwalsh at redhat.com Wed Feb 27 19:39:38 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 27 Feb 2008 14:39:38 -0500 Subject: VOIP policy In-Reply-To: References: Message-ID: <47C5BC7A.20302@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 max bianco wrote: > Do current SELinux policies support VoIP (internet telephony)? > > > Thanks, > > Max > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list We should not block it. But you would have to check whether it is confined by an existing policy. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfFvHoACgkQrlYvE4MpobPgVwCfQp2Z9vMFTbRFhqClSDeGfqCS xpYAn35tboErFWwXKV/AngTnmkKNs58n =r/7g -----END PGP SIGNATURE----- From dwalsh at redhat.com Wed Feb 27 19:42:06 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 27 Feb 2008 14:42:06 -0500 Subject: SELinux is preventing seamonkey-bin from making the program stack executable. In-Reply-To: <789853.42386.qm@web52609.mail.re2.yahoo.com> References: <789853.42386.qm@web52609.mail.re2.yahoo.com> Message-ID: <47C5BD0E.9090601@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Antonio Olivares wrote: > Dear all, > > After applying the fix suggested by Mr. Walsh, > [root at localhost ~]# setsebool -P > allow_unconfined_nsplugin_transition=1 > allow_nsplugin_execmem=1 > [root at localhost ~]# getsebool -a | grep nsp > allow_nsplugin_execmem --> on > allow_unconfined_nsplugin_transition --> on > > Seamonkey is asking permission for the stack. I do > not want to allow access if it is not correct for > seamonkey to allow stack execution. Please help me > nail this one as well and crossing my fingers that > firefox/minefield does not ask as well. > > > Summary: > > SELinux is preventing seamonkey-bin from making the > program stack executable. > > Detailed Description: > > The seamonkey-bin 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 seamonkey-bin 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 > seamonkey-bin to run correctly, you can change the > context of the executable to > unconfined_execmem_exec_t. "chcon -t > unconfined_execmem_exec_t > '/usr/lib/seamonkey-1.1.8/seamonkey-bin'" 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 > '/usr/lib/seamonkey-1.1.8/seamonkey-bin'" > > Fix Command: > > chcon -t unconfined_execmem_exec_t > '/usr/lib/seamonkey-1.1.8/seamonkey-bin' > > 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 > Source Path > /usr/lib/firefox-3.0b3pre/firefox > Port > Host localhost > Source RPM Packages seamonkey-1.1.8-4.fc9 > Target RPM Packages > Policy RPM > selinux-policy-3.3.0-1.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.25-0.65.rc2.git7.fc9 #1 SMP > Sat Feb 23 23:06:09 EST > 2008 i686 athlon > Alert Count 140 > First Seen Fri 01 Feb 2008 05:08:54 > PM CST > Last Seen Tue 26 Feb 2008 03:17:04 > PM CST > Local ID > c4806f30-a6dc-43b0-8901-5531075795f7 > Line Numbers > > Raw Audit Messages > > host=localhost type=AVC msg=audit(1204060624.602:108): > avc: denied { execstack } for pid=20290 > comm="seamonkey-bin" > 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(1204060624.602:108): arch=40000003 > syscall=125 success=no exit=-13 a0=bfc72000 a1=1000 > a2=1000007 a3=fffff000 items=0 ppid=1 pid=20290 > auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 > egid=500 sgid=500 fsgid=500 tty=(none) ses=1 > comm="seamonkey-bin" > exe="/usr/lib/seamonkey-1.1.8/seamonkey-bin" > 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 > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Looks like seamonkey does not use nsplugin. So in order to use this plugin you will need to turn on the allow_execstack boolean. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfFvQ4ACgkQrlYvE4MpobMSpgCfa7gDlSPJtNzzCJIf60idt70T cRYAn2GPuZWZPWTQSNOBjeOuB1sbCVP2 =8sCk -----END PGP SIGNATURE----- From dwalsh at redhat.com Wed Feb 27 19:42:41 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 27 Feb 2008 14:42:41 -0500 Subject: SELinux is preventing plugin-config (nsplugin_config_t) "execstack" to (nsplugin_config_t) In-Reply-To: <952131.26172.qm@web52611.mail.re2.yahoo.com> References: <952131.26172.qm@web52611.mail.re2.yahoo.com> Message-ID: <47C5BD31.6080408@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Antonio Olivares wrote: > Ok Seamonkey and selinux, firefox, and nsplugin. > > Here are the results. Thanks for your suggestions and > advice in advance. > > Antonio > > > > Summary: > > SELinux is preventing plugin-config > (nsplugin_config_t) "execstack" to > (nsplugin_config_t). > > Detailed Description: > > SELinux denied access requested by plugin-config. It > is not expected that this > access is required by plugin-config and this access > may signal an intrusion > attempt. It is also possible that the specific version > or configuration of the > application is causing it to require additional > access. > > Allowing Access: > > You can generate a local policy module to allow this > access - see FAQ > (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) > Or you can disable > SELinux protection altogether. Disabling SELinux > protection is not recommended. > Please file a bug report > (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) > against this package. > > Additional Information: > > Source Context > unconfined_u:unconfined_r:nsplugin_config_t > :SystemLow-SystemHigh > Target Context > unconfined_u:unconfined_r:nsplugin_config_t > :SystemLow-SystemHigh > Target Objects None [ process ] > Source plugin-config > Source Path > /usr/lib/nspluginwrapper/plugin-config > Port > Host localhost > Source RPM Packages > nspluginwrapper-0.9.91.5-22.fc9 > Target RPM Packages > Policy RPM > selinux-policy-3.3.0-1.fc9 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name catchall > Host Name localhost > Platform Linux localhost > 2.6.25-0.65.rc2.git7.fc9 #1 SMP > Sat Feb 23 23:06:09 EST > 2008 i686 athlon > Alert Count 2 > First Seen Tue 26 Feb 2008 03:17:23 > PM CST > Last Seen Tue 26 Feb 2008 03:22:56 > PM CST > Local ID > 276820c9-9871-4632-8ec1-c8909c8d7c0b > Line Numbers > > Raw Audit Messages > > host=localhost type=AVC msg=audit(1204060976.98:110): > avc: denied { execstack } for pid=20500 > comm="plugin-config" > scontext=unconfined_u:unconfined_r:nsplugin_config_t:s0-s0:c0.c1023 > tcontext=unconfined_u:unconfined_r:nsplugin_config_t:s0-s0:c0.c1023 > tclass=process > > host=localhost type=SYSCALL > msg=audit(1204060976.98:110): arch=40000003 > syscall=125 success=no exit=-13 a0=bf957000 a1=1000 > a2=1000007 a3=fffff000 items=0 ppid=20498 pid=20500 > auid=500 uid=500 gid=500 euid=0 suid=0 fsuid=0 > egid=500 sgid=500 fsgid=500 tty=(none) ses=1 > comm="plugin-config" > exe="/usr/lib/nspluginwrapper/plugin-config" > subj=unconfined_u:unconfined_r:nsplugin_config_t:s0-s0:c0.c1023 > key=(null) > > > > Will add to tonights policy update. > > ____________________________________________________________________________________ > 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfFvTEACgkQrlYvE4MpobM7kwCfbudvNu7595pzZpJlFY8bnhZm jVkAnAj0tVLXKeYEC+u47oF20ZhXBTX2 =s/HR -----END PGP SIGNATURE----- From olivares14031 at yahoo.com Wed Feb 27 19:46:20 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Wed, 27 Feb 2008 11:46:20 -0800 (PST) Subject: SELinux prevented dbus-daemon from using the terminal /dev/tty1 Message-ID: <584259.76666.qm@web52603.mail.re2.yahoo.com> Summary: SELinux prevented dbus-daemon from using the terminal /dev/tty1. Detailed Description: SELinux prevented dbus-daemon from using the terminal /dev/tty1. In most cases daemons do not need to interact with the terminal, usually these avc messages can be ignored. All of the confined daemons should have dontaudit rules around using the terminal. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this selinux-policy. If you would like to allow all daemons to interact with the terminal, you can turn on the allow_daemons_use_tty boolean. Allowing Access: Changing the "allow_daemons_use_tty" boolean to true will allow this access: "setsebool -P allow_daemons_use_tty=1." Fix Command: setsebool -P allow_daemons_use_tty=1 Additional Information: Source Context unconfined_u:unconfined_r:unconfined_dbusd_t :SystemLow-SystemHigh Target Context unconfined_u:object_r:unconfined_tty_device_t Target Objects /dev/tty1 [ chr_file ] Source dbus-daemon Source Path /bin/dbus-daemon Port Host localhost Source RPM Packages dbus-1.1.4-6.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-4.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name allow_daemons_use_tty Host Name localhost Platform Linux localhost 2.6.25-0.69.rc3.git1.fc9 #1 SMP Tue Feb 26 16:12:54 EST 2008 i686 athlon Alert Count 6 First Seen Fri 01 Feb 2008 05:06:20 PM CST Last Seen Wed 27 Feb 2008 01:01:38 PM CST Local ID c0a79310-b4d4-41fc-a712-a4db505290d5 Line Numbers Raw Audit Messages host=localhost type=AVC msg=audit(1204138898.740:24): avc: denied { read write } for pid=2845 comm="dbus-daemon" path="/dev/tty1" dev=tmpfs ino=1858 scontext=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:unconfined_tty_device_t:s0 tclass=chr_file host=localhost type=SYSCALL msg=audit(1204138898.740:24): arch=40000003 syscall=11 success=yes exit=0 a0=804c907 a1=bfd1f04c a2=bfd20474 a3=7 items=0 ppid=2844 pid=2845 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="dbus-daemon" exe="/bin/dbus-daemon" subj=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 key=(null) ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From selinux at gmail.com Thu Feb 28 15:41:27 2008 From: selinux at gmail.com (Tom London) Date: Thu, 28 Feb 2008 07:41:27 -0800 Subject: gnome login broken.... "null" avcs... Message-ID: <4c4ba1530802280741hfcfa9b1ve87869d3e4e9b0fd@mail.gmail.com> After applying today's selinux-policy* packages, gnome/gdm login fails: gdmgreeter runs, but X quickly dies after enter password and you're back to the greeter. Booting up in permissive lets me log in. Here are the borkages: #============= mono_t ============== allow mono_t xdm_xserver_t:x_device read; #============= unconfined_execmem_t ============== allow unconfined_execmem_t xdm_xserver_t:x_device read; #============= unconfined_t ============== allow unconfined_t mono_t:x_resource write; allow unconfined_t unconfined_execmem_t:x_resource { write read }; allow unconfined_t unlabeled_t:x_drawable { destroy getattr }; [root at localhost ~]# I attach complete log file. This something to do with new X keyboard confinement stuff? tom -- Tom London -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: log.txt URL: From selinux at gmail.com Thu Feb 28 15:52:31 2008 From: selinux at gmail.com (Tom London) Date: Thu, 28 Feb 2008 07:52:31 -0800 Subject: gnome login broken.... "null" avcs... In-Reply-To: <4c4ba1530802280741hfcfa9b1ve87869d3e4e9b0fd@mail.gmail.com> References: <4c4ba1530802280741hfcfa9b1ve87869d3e4e9b0fd@mail.gmail.com> Message-ID: <4c4ba1530802280752s55fa3e29p22faa966fa4beca3@mail.gmail.com> On Thu, Feb 28, 2008 at 7:41 AM, Tom London wrote: > After applying today's selinux-policy* packages, gnome/gdm login > fails: gdmgreeter runs, but X quickly dies after enter password and > you're back to the greeter. > > Booting up in permissive lets me log in. > > Here are the borkages: > > > #============= mono_t ============== > allow mono_t xdm_xserver_t:x_device read; > > #============= unconfined_execmem_t ============== > allow unconfined_execmem_t xdm_xserver_t:x_device read; > > #============= unconfined_t ============== > allow unconfined_t mono_t:x_resource write; > allow unconfined_t unconfined_execmem_t:x_resource { write read }; > allow unconfined_t unlabeled_t:x_drawable { destroy getattr }; > [root at localhost ~]# > > I attach complete log file. > > This something to do with new X keyboard confinement stuff? > > tom > -- > Tom London > Reverting to selinux-policy-3.3.1-4.fc9.noarch fixes..... tom -- Tom London From ftaylor at redhat.com Thu Feb 28 17:49:56 2008 From: ftaylor at redhat.com (Forrest Taylor) Date: Thu, 28 Feb 2008 10:49:56 -0700 Subject: Problem with audit2allow reference policy involving logs Message-ID: <1204220996.3851.9.camel@localhost.localdomain> Running RHEL5.1 with with selinux-policy-strict-2.4.6-106.el5_1.3. I am building my own policy for FTP and in creating the xferlog, audit2allow -alR gives this macro: logging_search_logs(ftpd_t) The problem is that this macros generates the following type transition: type_transition ftpd_t var_log_t : file sendmail_log_t; This, of course, is not really what I want, so I dropped the -R option to audit2allow and it returns: allow ftpd_t var_log_t:dir search; With the next iteration, audit2allow -alR shows: sendmail_create_log(ftpd_t) and audit2allow -la shows: allow ftpd_t var_log_t:dir write; Someone really liked sendmail_log_t ;o) Forrest -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwalsh at redhat.com Thu Feb 28 18:06:12 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 28 Feb 2008 13:06:12 -0500 Subject: gnome login broken.... "null" avcs... In-Reply-To: <4c4ba1530802280752s55fa3e29p22faa966fa4beca3@mail.gmail.com> References: <4c4ba1530802280741hfcfa9b1ve87869d3e4e9b0fd@mail.gmail.com> <4c4ba1530802280752s55fa3e29p22faa966fa4beca3@mail.gmail.com> Message-ID: <47C6F814.1080601@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom London wrote: > On Thu, Feb 28, 2008 at 7:41 AM, Tom London wrote: >> After applying today's selinux-policy* packages, gnome/gdm login >> fails: gdmgreeter runs, but X quickly dies after enter password and >> you're back to the greeter. >> >> Booting up in permissive lets me log in. >> >> Here are the borkages: >> >> >> #============= mono_t ============== >> allow mono_t xdm_xserver_t:x_device read; >> >> #============= unconfined_execmem_t ============== >> allow unconfined_execmem_t xdm_xserver_t:x_device read; >> >> #============= unconfined_t ============== >> allow unconfined_t mono_t:x_resource write; >> allow unconfined_t unconfined_execmem_t:x_resource { write read }; >> allow unconfined_t unlabeled_t:x_drawable { destroy getattr }; >> [root at localhost ~]# >> >> I attach complete log file. >> >> This something to do with new X keyboard confinement stuff? >> >> tom >> -- >> Tom London >> > > Reverting to selinux-policy-3.3.1-4.fc9.noarch fixes..... > > tom Did you have the xserver_object_manager boolean turned on? This should only have effected those machines, that were dumb^wadventuresome enough to turn this on. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfG+BQACgkQrlYvE4MpobNnRQCfbNeuVabGA9dUfo9X1yBlvGKH 73QAnjcUlJH1Xgabj3Mbopz7rCgMMwxr =+82k -----END PGP SIGNATURE----- From dwalsh at redhat.com Thu Feb 28 18:14:50 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 28 Feb 2008 13:14:50 -0500 Subject: gnome login broken.... "null" avcs... In-Reply-To: <4c4ba1530802280752s55fa3e29p22faa966fa4beca3@mail.gmail.com> References: <4c4ba1530802280741hfcfa9b1ve87869d3e4e9b0fd@mail.gmail.com> <4c4ba1530802280752s55fa3e29p22faa966fa4beca3@mail.gmail.com> Message-ID: <47C6FA1A.3080303@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom London wrote: > On Thu, Feb 28, 2008 at 7:41 AM, Tom London wrote: >> After applying today's selinux-policy* packages, gnome/gdm login >> fails: gdmgreeter runs, but X quickly dies after enter password and >> you're back to the greeter. >> >> Booting up in permissive lets me log in. >> >> Here are the borkages: >> >> >> #============= mono_t ============== >> allow mono_t xdm_xserver_t:x_device read; >> >> #============= unconfined_execmem_t ============== >> allow unconfined_execmem_t xdm_xserver_t:x_device read; >> >> #============= unconfined_t ============== >> allow unconfined_t mono_t:x_resource write; >> allow unconfined_t unconfined_execmem_t:x_resource { write read }; >> allow unconfined_t unlabeled_t:x_drawable { destroy getattr }; >> [root at localhost ~]# >> >> I attach complete log file. >> >> This something to do with new X keyboard confinement stuff? >> >> tom >> -- >> Tom London >> > > Reverting to selinux-policy-3.3.1-4.fc9.noarch fixes..... > > tom What does the unlabeled_t x_drawable avc look like? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfG+hkACgkQrlYvE4MpobMYBQCdE5YwQGLw46SEAcUSzN2SK5L1 jc4An0hyMOX039jru5aKdJGMjiHyesJp =IW9S -----END PGP SIGNATURE----- From dwalsh at redhat.com Thu Feb 28 18:18:26 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 28 Feb 2008 13:18:26 -0500 Subject: Problem with audit2allow reference policy involving logs In-Reply-To: <1204220996.3851.9.camel@localhost.localdomain> References: <1204220996.3851.9.camel@localhost.localdomain> Message-ID: <47C6FAF2.4010700@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Forrest Taylor wrote: > Running RHEL5.1 with with selinux-policy-strict-2.4.6-106.el5_1.3. > > I am building my own policy for FTP and in creating the xferlog, > audit2allow -alR gives this macro: > > logging_search_logs(ftpd_t) > > The problem is that this macros generates the following type transition: > > type_transition ftpd_t var_log_t : file sendmail_log_t; > I think you are wrong here. interface(`logging_search_logs',` gen_require(` type var_log_t; ') files_search_var($1) allow $1 var_log_t:dir search_dir_perms; ') > This, of course, is not really what I want, so I dropped the -R option > to audit2allow and it returns: > > allow ftpd_t var_log_t:dir search; > > With the next iteration, audit2allow -alR shows: > > sendmail_create_log(ftpd_t) > I have no idea where this comes from, I guess I would need to see you log files. > and audit2allow -la shows: > > allow ftpd_t var_log_t:dir write; > > Someone really liked sendmail_log_t ;o) > > Forrest > > > ------------------------------------------------------------------------ > > -- > 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 iEYEARECAAYFAkfG+vEACgkQrlYvE4MpobN1VACffeQUQQxs9LswugYoaVN63JNn ePAAoOsQyxwM431hRZJXxrV285bI3nWI =LNnL -----END PGP SIGNATURE----- From selinux at gmail.com Thu Feb 28 18:45:42 2008 From: selinux at gmail.com (Tom London) Date: Thu, 28 Feb 2008 10:45:42 -0800 Subject: gnome login broken.... "null" avcs... In-Reply-To: <47C6FA1A.3080303@redhat.com> References: <4c4ba1530802280741hfcfa9b1ve87869d3e4e9b0fd@mail.gmail.com> <4c4ba1530802280752s55fa3e29p22faa966fa4beca3@mail.gmail.com> <47C6FA1A.3080303@redhat.com> Message-ID: <4c4ba1530802281045t5052dbf6p568af7c2a852d64f@mail.gmail.com> On Thu, Feb 28, 2008 at 10:14 AM, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Tom London wrote: > > > > On Thu, Feb 28, 2008 at 7:41 AM, Tom London wrote: > >> After applying today's selinux-policy* packages, gnome/gdm login > >> fails: gdmgreeter runs, but X quickly dies after enter password and > >> you're back to the greeter. > >> > >> Booting up in permissive lets me log in. > >> > >> Here are the borkages: > >> > >> > >> #============= mono_t ============== > >> allow mono_t xdm_xserver_t:x_device read; > >> > >> #============= unconfined_execmem_t ============== > >> allow unconfined_execmem_t xdm_xserver_t:x_device read; > >> > >> #============= unconfined_t ============== > >> allow unconfined_t mono_t:x_resource write; > >> allow unconfined_t unconfined_execmem_t:x_resource { write read }; > >> allow unconfined_t unlabeled_t:x_drawable { destroy getattr }; > >> [root at localhost ~]# > >> > >> I attach complete log file. > >> > >> This something to do with new X keyboard confinement stuff? > >> > >> tom > >> -- > >> Tom London > >> > > > > Reverting to selinux-policy-3.3.1-4.fc9.noarch fixes..... > > > > tom > What does the unlabeled_t x_drawable avc look like? > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkfG+hkACgkQrlYvE4MpobMYBQCdE5YwQGLw46SEAcUSzN2SK5L1 > jc4An0hyMOX039jru5aKdJGMjiHyesJp > =IW9S > -----END PGP SIGNATURE----- > I attached the log file with the AVCs in the original message: type=USER_AVC msg=audit(1204212866.270:29): user pid=2907 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc: denied null for request=GLX:MakeCurrent comm=compiz resid=b0 restype=WINDOW scontext=unconfined_u:unconfined_r:unconfined_t:s0 tcontext=system_u:object_r:x_rootwindow_t:s0 tclass=x_drawable : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)' I am running compiz, and it sort of looked like DRM was failing in Xorg.0.log. Could that be an issue? -- Tom London From selinux at gmail.com Thu Feb 28 18:47:39 2008 From: selinux at gmail.com (Tom London) Date: Thu, 28 Feb 2008 10:47:39 -0800 Subject: gnome login broken.... "null" avcs... In-Reply-To: <47C6F814.1080601@redhat.com> References: <4c4ba1530802280741hfcfa9b1ve87869d3e4e9b0fd@mail.gmail.com> <4c4ba1530802280752s55fa3e29p22faa966fa4beca3@mail.gmail.com> <47C6F814.1080601@redhat.com> Message-ID: <4c4ba1530802281047t9326974q55626168b0c6366a@mail.gmail.com> On Thu, Feb 28, 2008 at 10:06 AM, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Tom London wrote: > > On Thu, Feb 28, 2008 at 7:41 AM, Tom London wrote: > >> After applying today's selinux-policy* packages, gnome/gdm login > >> fails: gdmgreeter runs, but X quickly dies after enter password and > >> you're back to the greeter. > >> > >> Booting up in permissive lets me log in. > >> > >> Here are the borkages: > >> > >> > >> #============= mono_t ============== > >> allow mono_t xdm_xserver_t:x_device read; > >> > >> #============= unconfined_execmem_t ============== > >> allow unconfined_execmem_t xdm_xserver_t:x_device read; > >> > >> #============= unconfined_t ============== > >> allow unconfined_t mono_t:x_resource write; > >> allow unconfined_t unconfined_execmem_t:x_resource { write read }; > >> allow unconfined_t unlabeled_t:x_drawable { destroy getattr }; > >> [root at localhost ~]# > >> > >> I attach complete log file. > >> > >> This something to do with new X keyboard confinement stuff? > >> > >> tom > >> -- > >> Tom London > >> > > > > Reverting to selinux-policy-3.3.1-4.fc9.noarch fixes..... > > > > tom > Did you have the xserver_object_manager boolean turned on? This should > only have effected those machines, that were dumb^wadventuresome enough > to turn this on. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkfG+BQACgkQrlYvE4MpobNnRQCfbNeuVabGA9dUfo9X1yBlvGKH > 73QAnjcUlJH1Xgabj3Mbopz7rCgMMwxr > =+82k > -----END PGP SIGNATURE----- > Nope: [root at localhost ~]# getsebool -a | grep xserver allow_xserver_execmem --> on xserver_object_manager --> off [root at localhost ~]# compiz/glx? I get this in Xorg.0.log: Backtrace: 0: /usr/bin/Xorg(xf86SigHandler+0x79) [0x80bc9a9] 1: [0x110400] 2: /usr/lib/xorg/modules/extensions//libglx.so(__glXDeassociateContext+0x19) [0x1d73b9] 3: /usr/lib/xorg/modules/extensions//libglx.so(__glXContextDestroy+0x23) [0x1d35b3] 4: /usr/lib/xorg/modules/extensions//libglx.so [0x20dfe8] 5: /usr/lib/xorg/modules/extensions//libglx.so(__glXFreeContext+0x89) [0x1d5c09] 6: /usr/lib/xorg/modules/extensions//libglx.so [0x1d5c57] 7: /usr/bin/Xorg(FreeClientResources+0xe6) [0x806d4e6] 8: /usr/bin/Xorg(CloseDownClient+0x1ec) [0x807f33c] 9: /usr/bin/Xorg(Dispatch+0x208) [0x8085588] 10: /usr/bin/Xorg(main+0x475) [0x806b1d5] 11: /lib/libc.so.6(__libc_start_main+0xe6) [0x444516] 12: /usr/bin/Xorg(FontFileCompleteXLFD+0x215) [0x806a5c1] tom -- Tom London From ryan.ware at navy.mil Thu Feb 28 14:28:37 2008 From: ryan.ware at navy.mil (Ryan Ware) Date: Thu, 28 Feb 2008 09:28:37 -0500 Subject: MLS Guide Message-ID: <47C6C515.8010304@navy.mil> Does anyone know of a decent guide for setting up an SELinux MLS policy in Fedora 8 with polyinstantiated home directories? Thank you, Ryan W. From ewalsh at tycho.nsa.gov Thu Feb 28 20:21:10 2008 From: ewalsh at tycho.nsa.gov (Eamon Walsh) Date: Thu, 28 Feb 2008 15:21:10 -0500 Subject: gnome login broken.... "null" avcs... In-Reply-To: <4c4ba1530802281047t9326974q55626168b0c6366a@mail.gmail.com> References: <4c4ba1530802280741hfcfa9b1ve87869d3e4e9b0fd@mail.gmail.com> <4c4ba1530802280752s55fa3e29p22faa966fa4beca3@mail.gmail.com> <47C6F814.1080601@redhat.com> <4c4ba1530802281047t9326974q55626168b0c6366a@mail.gmail.com> Message-ID: <47C717B6.4040700@tycho.nsa.gov> Tom London wrote: > On Thu, Feb 28, 2008 at 10:06 AM, Daniel J Walsh wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> >> Tom London wrote: >> > On Thu, Feb 28, 2008 at 7:41 AM, Tom London wrote: >> >> After applying today's selinux-policy* packages, gnome/gdm login >> >> fails: gdmgreeter runs, but X quickly dies after enter password and >> >> you're back to the greeter. >> >> >> >> Booting up in permissive lets me log in. >> >> >> >> Here are the borkages: >> >> >> >> >> >> #============= mono_t ============== >> >> allow mono_t xdm_xserver_t:x_device read; >> >> >> >> #============= unconfined_execmem_t ============== >> >> allow unconfined_execmem_t xdm_xserver_t:x_device read; >> >> >> >> #============= unconfined_t ============== >> >> allow unconfined_t mono_t:x_resource write; >> >> allow unconfined_t unconfined_execmem_t:x_resource { write read }; >> >> allow unconfined_t unlabeled_t:x_drawable { destroy getattr }; >> >> [root at localhost ~]# >> >> The "null" avc's are fixed in the upstream X server. This is a bad security hook call in the GLX code and affects GLX programs such as compiz. The unlabeled AVC is the result of a mislabeled program? -- Eamon Walsh National Security Agency From selinux at gmail.com Thu Feb 28 21:38:27 2008 From: selinux at gmail.com (Tom London) Date: Thu, 28 Feb 2008 13:38:27 -0800 Subject: gnome login broken.... "null" avcs... In-Reply-To: <47C717B6.4040700@tycho.nsa.gov> References: <4c4ba1530802280741hfcfa9b1ve87869d3e4e9b0fd@mail.gmail.com> <4c4ba1530802280752s55fa3e29p22faa966fa4beca3@mail.gmail.com> <47C6F814.1080601@redhat.com> <4c4ba1530802281047t9326974q55626168b0c6366a@mail.gmail.com> <47C717B6.4040700@tycho.nsa.gov> Message-ID: <4c4ba1530802281338web75f0bu6b2d2180a6861620@mail.gmail.com> On Thu, Feb 28, 2008 at 12:21 PM, Eamon Walsh wrote: > Tom London wrote: > > On Thu, Feb 28, 2008 at 10:06 AM, Daniel J Walsh wrote: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> > >> > >> Tom London wrote: > >> > On Thu, Feb 28, 2008 at 7:41 AM, Tom London wrote: > >> >> After applying today's selinux-policy* packages, gnome/gdm login > >> >> fails: gdmgreeter runs, but X quickly dies after enter password and > >> >> you're back to the greeter. > >> >> > >> >> Booting up in permissive lets me log in. > >> >> > >> >> Here are the borkages: > >> >> > >> >> > >> >> #============= mono_t ============== > >> >> allow mono_t xdm_xserver_t:x_device read; > >> >> > >> >> #============= unconfined_execmem_t ============== > >> >> allow unconfined_execmem_t xdm_xserver_t:x_device read; > >> >> > >> >> #============= unconfined_t ============== > >> >> allow unconfined_t mono_t:x_resource write; > >> >> allow unconfined_t unconfined_execmem_t:x_resource { write read }; > >> >> allow unconfined_t unlabeled_t:x_drawable { destroy getattr }; > >> >> [root at localhost ~]# > >> >> > > The "null" avc's are fixed in the upstream X server. This is a bad > security hook call in the GLX code and affects GLX programs such as compiz. > > The unlabeled AVC is the result of a mislabeled program? > > > > -- > Eamon Walsh > National Security Agency > > I've backed up policy to previous version, and checking for unlabeled programs indicates nothing amiss. No programs were relabeled on install of poicy; something else I should check? tom -- Tom London From sds at tycho.nsa.gov Thu Feb 28 21:43:04 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 28 Feb 2008 16:43:04 -0500 Subject: gnome login broken.... "null" avcs... In-Reply-To: <4c4ba1530802281338web75f0bu6b2d2180a6861620@mail.gmail.com> References: <4c4ba1530802280741hfcfa9b1ve87869d3e4e9b0fd@mail.gmail.com> <4c4ba1530802280752s55fa3e29p22faa966fa4beca3@mail.gmail.com> <47C6F814.1080601@redhat.com> <4c4ba1530802281047t9326974q55626168b0c6366a@mail.gmail.com> <47C717B6.4040700@tycho.nsa.gov> <4c4ba1530802281338web75f0bu6b2d2180a6861620@mail.gmail.com> Message-ID: <1204234984.31790.222.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2008-02-28 at 13:38 -0800, Tom London wrote: > On Thu, Feb 28, 2008 at 12:21 PM, Eamon Walsh wrote: > > Tom London wrote: > > > On Thu, Feb 28, 2008 at 10:06 AM, Daniel J Walsh wrote: > > > > > >> -----BEGIN PGP SIGNED MESSAGE----- > > >> Hash: SHA1 > > >> > > >> > > >> > > >> Tom London wrote: > > >> > On Thu, Feb 28, 2008 at 7:41 AM, Tom London wrote: > > >> >> After applying today's selinux-policy* packages, gnome/gdm login > > >> >> fails: gdmgreeter runs, but X quickly dies after enter password and > > >> >> you're back to the greeter. > > >> >> > > >> >> Booting up in permissive lets me log in. > > >> >> > > >> >> Here are the borkages: > > >> >> > > >> >> > > >> >> #============= mono_t ============== > > >> >> allow mono_t xdm_xserver_t:x_device read; > > >> >> > > >> >> #============= unconfined_execmem_t ============== > > >> >> allow unconfined_execmem_t xdm_xserver_t:x_device read; > > >> >> > > >> >> #============= unconfined_t ============== > > >> >> allow unconfined_t mono_t:x_resource write; > > >> >> allow unconfined_t unconfined_execmem_t:x_resource { write read }; > > >> >> allow unconfined_t unlabeled_t:x_drawable { destroy getattr }; > > >> >> [root at localhost ~]# > > >> >> > > > > The "null" avc's are fixed in the upstream X server. This is a bad > > security hook call in the GLX code and affects GLX programs such as compiz. > > > > The unlabeled AVC is the result of a mislabeled program? > > > > > > > > -- > > Eamon Walsh > > National Security Agency > > > > > I've backed up policy to previous version, and checking for unlabeled > programs indicates nothing amiss. > > No programs were relabeled on install of poicy; something else I should check? grep 'invalidating context' /var/log/messages -- Stephen Smalley National Security Agency From selinux at gmail.com Thu Feb 28 21:50:34 2008 From: selinux at gmail.com (Tom London) Date: Thu, 28 Feb 2008 13:50:34 -0800 Subject: gnome login broken.... "null" avcs... In-Reply-To: <1204234984.31790.222.camel@moss-spartans.epoch.ncsc.mil> References: <4c4ba1530802280741hfcfa9b1ve87869d3e4e9b0fd@mail.gmail.com> <4c4ba1530802280752s55fa3e29p22faa966fa4beca3@mail.gmail.com> <47C6F814.1080601@redhat.com> <4c4ba1530802281047t9326974q55626168b0c6366a@mail.gmail.com> <47C717B6.4040700@tycho.nsa.gov> <4c4ba1530802281338web75f0bu6b2d2180a6861620@mail.gmail.com> <1204234984.31790.222.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4c4ba1530802281350m22968fc8g93806538fefed031@mail.gmail.com> On Thu, Feb 28, 2008 at 1:43 PM, Stephen Smalley wrote: > > > On Thu, 2008-02-28 at 13:38 -0800, Tom London wrote: > > On Thu, Feb 28, 2008 at 12:21 PM, Eamon Walsh wrote: > > > Tom London wrote: > > > > On Thu, Feb 28, 2008 at 10:06 AM, Daniel J Walsh wrote: > > > > > > > >> -----BEGIN PGP SIGNED MESSAGE----- > > > >> Hash: SHA1 > > > >> > > > >> > > > >> > > > >> Tom London wrote: > > > >> > On Thu, Feb 28, 2008 at 7:41 AM, Tom London wrote: > > > >> >> After applying today's selinux-policy* packages, gnome/gdm login > > > >> >> fails: gdmgreeter runs, but X quickly dies after enter password and > > > >> >> you're back to the greeter. > > > >> >> > > > >> >> Booting up in permissive lets me log in. > > > >> >> > > > >> >> Here are the borkages: > > > >> >> > > > >> >> > > > >> >> #============= mono_t ============== > > > >> >> allow mono_t xdm_xserver_t:x_device read; > > > >> >> > > > >> >> #============= unconfined_execmem_t ============== > > > >> >> allow unconfined_execmem_t xdm_xserver_t:x_device read; > > > >> >> > > > >> >> #============= unconfined_t ============== > > > >> >> allow unconfined_t mono_t:x_resource write; > > > >> >> allow unconfined_t unconfined_execmem_t:x_resource { write read }; > > > >> >> allow unconfined_t unlabeled_t:x_drawable { destroy getattr }; > > > >> >> [root at localhost ~]# > > > >> >> > > > > > > The "null" avc's are fixed in the upstream X server. This is a bad > > > security hook call in the GLX code and affects GLX programs such as compiz. > > > > > > The unlabeled AVC is the result of a mislabeled program? > > > > > > > > > > > > -- > > > Eamon Walsh > > > National Security Agency > > > > > > > > I've backed up policy to previous version, and checking for unlabeled > > programs indicates nothing amiss. > > > > No programs were relabeled on install of poicy; something else I should check? > > grep 'invalidating context' /var/log/messages > > -- > Stephen Smalley > National Security Agency > > [root at localhost ~]# grep 'invalidating context' /var/log/messages Feb 27 07:13:31 localhost kernel: security: invalidating context unconfined_u:unconfined_r:samba_net_t:s0 Feb 28 06:47:08 localhost kernel: security: invalidating context system_u:system_r:httpd_unconfined_script_t:s0-s0:c0.c1023 Feb 28 06:47:08 localhost kernel: security: invalidating context unconfined_u:system_r:httpd_unconfined_script_t:s0 Feb 28 06:47:08 localhost kernel: security: invalidating context unconfined_u:unconfined_r:httpd_unconfined_script_t:s0 Feb 28 07:46:11 localhost kernel: security: invalidating context unconfined_u:system_r:httpd_user_script_t:s0 Feb 28 07:46:11 localhost kernel: security: invalidating context unconfined_u:system_r:httpd_user_script_t:s0-s0:c0.c255 Feb 28 07:46:11 localhost kernel: security: invalidating context system_u:system_r:httpd_user_script_t:s0-s0:c0.c1023 [root at localhost ~]# -- Tom London From selinux at gmail.com Thu Feb 28 22:46:54 2008 From: selinux at gmail.com (Tom London) Date: Thu, 28 Feb 2008 14:46:54 -0800 Subject: gnome login broken.... "null" avcs... In-Reply-To: <4c4ba1530802281350m22968fc8g93806538fefed031@mail.gmail.com> References: <4c4ba1530802280741hfcfa9b1ve87869d3e4e9b0fd@mail.gmail.com> <4c4ba1530802280752s55fa3e29p22faa966fa4beca3@mail.gmail.com> <47C6F814.1080601@redhat.com> <4c4ba1530802281047t9326974q55626168b0c6366a@mail.gmail.com> <47C717B6.4040700@tycho.nsa.gov> <4c4ba1530802281338web75f0bu6b2d2180a6861620@mail.gmail.com> <1204234984.31790.222.camel@moss-spartans.epoch.ncsc.mil> <4c4ba1530802281350m22968fc8g93806538fefed031@mail.gmail.com> Message-ID: <4c4ba1530802281446h18648abw97eaef0069d94858@mail.gmail.com> On Thu, Feb 28, 2008 at 1:50 PM, Tom London wrote: > > On Thu, Feb 28, 2008 at 1:43 PM, Stephen Smalley wrote: > > > > > > On Thu, 2008-02-28 at 13:38 -0800, Tom London wrote: > > > On Thu, Feb 28, 2008 at 12:21 PM, Eamon Walsh wrote: > > > > Tom London wrote: > > > > > On Thu, Feb 28, 2008 at 10:06 AM, Daniel J Walsh wrote: > > > > > > > > > >> -----BEGIN PGP SIGNED MESSAGE----- > > > > >> Hash: SHA1 > > > > >> > > > > >> > > > > >> > > > > >> Tom London wrote: > > > > >> > On Thu, Feb 28, 2008 at 7:41 AM, Tom London wrote: > > > > >> >> After applying today's selinux-policy* packages, gnome/gdm login > > > > >> >> fails: gdmgreeter runs, but X quickly dies after enter password and > > > > >> >> you're back to the greeter. > > > > >> >> > > > > >> >> Booting up in permissive lets me log in. > > > > >> >> > > > > >> >> Here are the borkages: > > > > >> >> > > > > >> >> > > > > >> >> #============= mono_t ============== > > > > >> >> allow mono_t xdm_xserver_t:x_device read; > > > > >> >> > > > > >> >> #============= unconfined_execmem_t ============== > > > > >> >> allow unconfined_execmem_t xdm_xserver_t:x_device read; > > > > >> >> > > > > >> >> #============= unconfined_t ============== > > > > >> >> allow unconfined_t mono_t:x_resource write; > > > > >> >> allow unconfined_t unconfined_execmem_t:x_resource { write read }; > > > > >> >> allow unconfined_t unlabeled_t:x_drawable { destroy getattr }; > > > > >> >> [root at localhost ~]# > > > > >> >> > > > > > > > > The "null" avc's are fixed in the upstream X server. This is a bad > > > > security hook call in the GLX code and affects GLX programs such as compiz. > > > > > > > > The unlabeled AVC is the result of a mislabeled program? > > > > > > > > > > > > > > > > -- > > > > Eamon Walsh > > > > National Security Agency > > > > > > > > > > > I've backed up policy to previous version, and checking for unlabeled > > > programs indicates nothing amiss. > > > > > > No programs were relabeled on install of poicy; something else I should check? > > > > grep 'invalidating context' /var/log/messages > > > > -- > > Stephen Smalley > > National Security Agency > > > > > [root at localhost ~]# grep 'invalidating context' /var/log/messages > Feb 27 07:13:31 localhost kernel: security: invalidating context > unconfined_u:unconfined_r:samba_net_t:s0 > Feb 28 06:47:08 localhost kernel: security: invalidating context > system_u:system_r:httpd_unconfined_script_t:s0-s0:c0.c1023 > Feb 28 06:47:08 localhost kernel: security: invalidating context > unconfined_u:system_r:httpd_unconfined_script_t:s0 > Feb 28 06:47:08 localhost kernel: security: invalidating context > unconfined_u:unconfined_r:httpd_unconfined_script_t:s0 > Feb 28 07:46:11 localhost kernel: security: invalidating context > unconfined_u:system_r:httpd_user_script_t:s0 > Feb 28 07:46:11 localhost kernel: security: invalidating context > unconfined_u:system_r:httpd_user_script_t:s0-s0:c0.c255 > Feb 28 07:46:11 localhost kernel: security: invalidating context > system_u:system_r:httpd_user_script_t:s0-s0:c0.c1023 > [root at localhost ~]# > > Dowloading latest selinux-policy and xorg-x11-server packages from koji fix this for me: [root at localhost ~]# rpm -qa selinux\* xorg-x11-server\* xorg-x11-server-utils-7.3-3.fc9.i386 selinux-policy-targeted-3.3.1-7.fc9.noarch xorg-x11-server-common-1.4.99.1-0.26.20080227.fc9.i386 selinux-policy-devel-3.3.1-7.fc9.noarch selinux-policy-3.3.1-7.fc9.noarch xorg-x11-server-Xorg-1.4.99.1-0.26.20080227.fc9.i386 [root at localhost ~]# "grep 'invalidating context' /var/log/messages" shows nothing. Thanks for the quick work on this! tom -- Tom London From ewalsh at tycho.nsa.gov Thu Feb 28 23:27:36 2008 From: ewalsh at tycho.nsa.gov (Eamon Walsh) Date: Thu, 28 Feb 2008 18:27:36 -0500 Subject: gnome login broken.... "null" avcs... In-Reply-To: <4c4ba1530802281338web75f0bu6b2d2180a6861620@mail.gmail.com> References: <4c4ba1530802280741hfcfa9b1ve87869d3e4e9b0fd@mail.gmail.com> <4c4ba1530802280752s55fa3e29p22faa966fa4beca3@mail.gmail.com> <47C6F814.1080601@redhat.com> <4c4ba1530802281047t9326974q55626168b0c6366a@mail.gmail.com> <47C717B6.4040700@tycho.nsa.gov> <4c4ba1530802281338web75f0bu6b2d2180a6861620@mail.gmail.com> Message-ID: <47C74368.8020304@tycho.nsa.gov> Tom London wrote: > On Thu, Feb 28, 2008 at 12:21 PM, Eamon Walsh wrote: > >> The unlabeled AVC is the result of a mislabeled program? >> >> >> >> -- >> Eamon Walsh >> National Security Agency >> >> >> > I've backed up policy to previous version, and checking for unlabeled > programs indicates nothing amiss. > > No programs were relabeled on install of poicy; something else I should check? > > tom > I think I found the problem. The pixmaps created by XCompositeNameWindowPixmap were not being labeled. I just pushed a fix upstream. -- Eamon Walsh National Security Agency From ekuns at kilroy.chi.il.us Fri Feb 29 04:31:23 2008 From: ekuns at kilroy.chi.il.us (Edward Kuns) Date: Thu, 28 Feb 2008 22:31:23 -0600 Subject: SELinux interfering with clamav? Message-ID: <1204259483.32130.2120.camel@kilroy.chi.il.us> A couple times a day (23 times in 10 days), I get the following AVC: Summary SELinux is preventing /usr/sbin/clamav-milter (clamd_t) "search" to (bin_t). Detailed Description SELinux denied access requested by /usr/sbin/clamav-milter. It is not expected that this access is required by /usr/sbin/clamav-milter and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for , restorecon -v If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Additional Information Source Context system_u:system_r:clamd_t:s0 Target Context system_u:object_r:bin_t:s0 Target Objects None [ dir ] Affected RPM Packages clamav-milter-0.92.1-1.fc8 [application] Policy RPM selinux-policy-3.0.8-84.fc8 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.catchall_file Host Name kilroy.chi.il.us Platform Linux kilroy.chi.il.us 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:48:34 EST 2008 i686 i686 Alert Count 23 First Seen Wed 20 Feb 2008 12:25:16 PM CST Last Seen Thu 28 Feb 2008 09:11:28 PM CST Local ID 7eb02331-c2e4-4c65-a413-d283fbb7ca6f Line Numbers Raw Audit Messages avc: denied { search } for comm=clamav-milter dev=dm-0 egid=486 euid=492 exe=/usr/sbin/clamav-milter exit=-13 fsgid=486 fsuid=492 gid=486 items=0 name=bin pid=13663 scontext=system_u:system_r:clamd_t:s0 sgid=486 subj=system_u:system_r:clamd_t:s0 suid=492 tclass=dir tcontext=system_u:object_r:bin_t:s0 tty=(none) uid=492 I assume that we want to allow clamav to scan anything on the system, yes? If I follow the advice from an earlier Email and try the following: grep clamav /var/log/audit/audit.log | audit2allow -M clamav I get a file that contains: module clamav 1.0; require { type bin_t; type clamd_t; class dir search; } #============= clamd_t ============== allow clamd_t bin_t:dir search; Is this something that should be part of standard policy? Hmm, I try to install the above policy and get a complaint: # semodule -i clamav.pp libsepol.print_missing_requirements: clamav's global requirements were not met: type/attribute clamd_t libsemanage.semanage_link_sandbox: Link packages failed semodule: Failed! Any thoughts? Thanks Eddie -- Edward Kuns From paul at city-fan.org Fri Feb 29 08:59:26 2008 From: paul at city-fan.org (Paul Howarth) Date: Fri, 29 Feb 2008 08:59:26 +0000 Subject: F8 updates kill setroubleshootd? Message-ID: <47C7C96E.2040004@city-fan.org> Having installed the latest bunch of Fedora 8 updates this morning, which included selinux-policy and setroubleshoot, I'm getting these denials: type=AVC msg=audit(1204275163.032:209): avc: denied { connectto } for pid=26345 comm="setroubleshootd" path="/var/run/audispd_events" scontext=unconfined_u:system_r:setroubleshootd_t:s0 tcontext=system_u:system_r:auditd_t:s0 tclass=unix_stream_socket type=AVC msg=audit(1204275171.133:210): avc: denied { read } for pid=26379 comm="setroubleshootd" name=".rpmmacros" dev=0:15 ino=6331637 scontext=unconfined_u:system_r:setroubleshootd_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=file The first one looks like a policy issue but I can't fathom why setroubleshootd would be trying access ~/.rpmmacros for the second one. Paul. From paul at city-fan.org Fri Feb 29 11:09:33 2008 From: paul at city-fan.org (Paul Howarth) Date: Fri, 29 Feb 2008 11:09:33 +0000 Subject: F8 updates kill setroubleshootd? In-Reply-To: <47C7C96E.2040004@city-fan.org> References: <47C7C96E.2040004@city-fan.org> Message-ID: <47C7E7ED.2090701@city-fan.org> Paul Howarth wrote: > Having installed the latest bunch of Fedora 8 updates this morning, > which included selinux-policy and setroubleshoot, I'm getting these > denials: > > type=AVC msg=audit(1204275163.032:209): avc: denied { connectto } for > pid=26345 comm="setroubleshootd" path="/var/run/audispd_events" > scontext=unconfined_u:system_r:setroubleshootd_t:s0 > tcontext=system_u:system_r:auditd_t:s0 tclass=unix_stream_socket > > type=AVC msg=audit(1204275171.133:210): avc: denied { read } for > pid=26379 comm="setroubleshootd" name=".rpmmacros" dev=0:15 ino=6331637 > scontext=unconfined_u:system_r:setroubleshootd_t:s0 > tcontext=system_u:object_r:nfs_t:s0 tclass=file > > The first one looks like a policy issue but I can't fathom why > setroubleshootd would be trying access ~/.rpmmacros for the second one. Following a reboot, the socket /var/run/audispd_events changed from auditd_t to audisp_var_run_t and there are no more AVCs for this. I tried a restorecon before the reboot but that didn't do anything, which is strange given that policy does indeed specify context: # semanage fcontext -l | grep audisp /sbin/audispd regular file system_u:object_r:audisp_exec_t:s0 /sbin/audisp-prelude regular file system_u:object_r:audisp_prelude_exec_t:s0 /var/run/audispd_events socket system_u:object_r:audisp_var_run_t:s0 Perhaps that was finger trouble? Paul. From dwalsh at redhat.com Fri Feb 29 14:05:39 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 29 Feb 2008 09:05:39 -0500 Subject: F8 updates kill setroubleshootd? In-Reply-To: <47C7E7ED.2090701@city-fan.org> References: <47C7C96E.2040004@city-fan.org> <47C7E7ED.2090701@city-fan.org> Message-ID: <47C81133.4040604@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Howarth wrote: > Paul Howarth wrote: >> Having installed the latest bunch of Fedora 8 updates this morning, >> which included selinux-policy and setroubleshoot, I'm getting these >> denials: >> >> type=AVC msg=audit(1204275163.032:209): avc: denied { connectto } >> for pid=26345 comm="setroubleshootd" path="/var/run/audispd_events" >> scontext=unconfined_u:system_r:setroubleshootd_t:s0 >> tcontext=system_u:system_r:auditd_t:s0 tclass=unix_stream_socket >> >> type=AVC msg=audit(1204275171.133:210): avc: denied { read } for >> pid=26379 comm="setroubleshootd" name=".rpmmacros" dev=0:15 >> ino=6331637 scontext=unconfined_u:system_r:setroubleshootd_t:s0 >> tcontext=system_u:object_r:nfs_t:s0 tclass=file >> >> The first one looks like a policy issue but I can't fathom why >> setroubleshootd would be trying access ~/.rpmmacros for the second one. > > Following a reboot, the socket /var/run/audispd_events changed from > auditd_t to audisp_var_run_t and there are no more AVCs for this. I > tried a restorecon before the reboot but that didn't do anything, which > is strange given that policy does indeed specify context: > > # semanage fcontext -l | grep audisp > /sbin/audispd regular file > system_u:object_r:audisp_exec_t:s0 > /sbin/audisp-prelude regular file > system_u:object_r:audisp_prelude_exec_t:s0 > /var/run/audispd_events socket > system_u:object_r:audisp_var_run_t:s0 > > Perhaps that was finger trouble? You needed to restart the audit daemon to get the proper context. I probably should have left the policy for both. setroubleshoot loads the rpm python bindings, which tries to read the .rpmmacros file in $HOME. So if you do a service setoubleshoot restart after su or sudo then you can see this avc. It is supposed to be dontaudited, but It must be missing the nfs_t one. > > Paul. > > -- > 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 iEYEARECAAYFAkfIETMACgkQrlYvE4MpobNA8QCgj1QDgxtMSRMcKl7QvJIwBIMs /V4AoJpoHeRtUQukFHZ/t0wSdPopfuB8 =ELeU -----END PGP SIGNATURE----- From dwalsh at redhat.com Fri Feb 29 14:16:34 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 29 Feb 2008 09:16:34 -0500 Subject: SELinux interfering with clamav? In-Reply-To: <1204259483.32130.2120.camel@kilroy.chi.il.us> References: <1204259483.32130.2120.camel@kilroy.chi.il.us> Message-ID: <47C813C2.1040405@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Edward Kuns wrote: > A couple times a day (23 times in 10 days), I get the following AVC: > > Summary > SELinux is preventing /usr/sbin/clamav-milter (clamd_t) "search" to > (bin_t). > > Detailed Description > SELinux denied access requested by /usr/sbin/clamav-milter. It is > not > expected that this access is required by /usr/sbin/clamav-milter and > this > access may signal an intrusion attempt. It is also possible that the > specific version or configuration of the application is causing it > to > require additional access. > > Allowing Access > Sometimes labeling problems can cause SELinux denials. You could > try to > restore the default system file context for , restorecon -v > If this does not work, there is currently no automatic way > to > allow this access. Instead, you can generate a local policy module > to allow > this access - see > http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 > Or you can disable SELinux protection altogether. Disabling SELinux > protection is not recommended. Please file a > http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this > package. > > Additional Information > > Source Context system_u:system_r:clamd_t:s0 > Target Context system_u:object_r:bin_t:s0 > Target Objects None [ dir ] > Affected RPM Packages clamav-milter-0.92.1-1.fc8 [application] > Policy RPM selinux-policy-3.0.8-84.fc8 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name plugins.catchall_file > Host Name kilroy.chi.il.us > Platform Linux kilroy.chi.il.us 2.6.23.15-137.fc8 > #1 SMP > Sun Feb 10 17:48:34 EST 2008 i686 i686 > Alert Count 23 > First Seen Wed 20 Feb 2008 12:25:16 PM CST > Last Seen Thu 28 Feb 2008 09:11:28 PM CST > Local ID 7eb02331-c2e4-4c65-a413-d283fbb7ca6f > Line Numbers > > Raw Audit Messages > > avc: denied { search } for comm=clamav-milter dev=dm-0 egid=486 euid=492 > exe=/usr/sbin/clamav-milter exit=-13 fsgid=486 fsuid=492 gid=486 items=0 > name=bin pid=13663 scontext=system_u:system_r:clamd_t:s0 sgid=486 > subj=system_u:system_r:clamd_t:s0 suid=492 tclass=dir > tcontext=system_u:object_r:bin_t:s0 tty=(none) uid=492 > > > > I assume that we want to allow clamav to scan anything on the system, > yes? If I follow the advice from an earlier Email and try the > following: > > grep clamav /var/log/audit/audit.log | audit2allow -M clamav > > I get a file that contains: > > > module clamav 1.0; > > require { > type bin_t; > type clamd_t; > class dir search; > } > > #============= clamd_t ============== > allow clamd_t bin_t:dir search; > > > Is this something that should be part of standard policy? Hmm, I try to > install the above policy and get a complaint: > > # semodule -i clamav.pp > libsepol.print_missing_requirements: clamav's global requirements were > not met: type/attribute clamd_t > libsemanage.semanage_link_sandbox: Link packages failed > semodule: Failed! > > > Any thoughts? > > Thanks > > Eddie > Always add a user specify front end to your policy. grep clamav /var/log/audit/audit.log | audit2allow -M MYclamav semodule -i MYclamav.pp Otherwise you are trying to replace the clamav.pp installed as part of selinux-policy. This policy seems reasonable but most likely clamav-milter is going to /usr/bin to execute something. So you might end up needing either corecmd_exec_bin(clamd_t) Or some transition to another domain. If you have an idea what app it is looking for, we can correct the policy. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfIE8IACgkQrlYvE4MpobPhwgCfcgcKhHGGDf6gg7fmb5dq7cpD 7RoAnRNSgbnK0tU/MCTywypjOmHQQ33b =n80j -----END PGP SIGNATURE----- From dwalsh at redhat.com Fri Feb 29 14:22:41 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 29 Feb 2008 09:22:41 -0500 Subject: gnome login broken.... "null" avcs... In-Reply-To: <4c4ba1530802281350m22968fc8g93806538fefed031@mail.gmail.com> References: <4c4ba1530802280741hfcfa9b1ve87869d3e4e9b0fd@mail.gmail.com> <4c4ba1530802280752s55fa3e29p22faa966fa4beca3@mail.gmail.com> <47C6F814.1080601@redhat.com> <4c4ba1530802281047t9326974q55626168b0c6366a@mail.gmail.com> <47C717B6.4040700@tycho.nsa.gov> <4c4ba1530802281338web75f0bu6b2d2180a6861620@mail.gmail.com> <1204234984.31790.222.camel@moss-spartans.epoch.ncsc.mil> <4c4ba1530802281350m22968fc8g93806538fefed031@mail.gmail.com> Message-ID: <47C81531.2040906@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom London wrote: > On Thu, Feb 28, 2008 at 1:43 PM, Stephen Smalley wrote: >> >> On Thu, 2008-02-28 at 13:38 -0800, Tom London wrote: >> > On Thu, Feb 28, 2008 at 12:21 PM, Eamon Walsh wrote: >> > > Tom London wrote: >> > > > On Thu, Feb 28, 2008 at 10:06 AM, Daniel J Walsh wrote: >> > > > >> > > >> -----BEGIN PGP SIGNED MESSAGE----- >> > > >> Hash: SHA1 >> > > >> >> > > >> >> > > >> >> > > >> Tom London wrote: >> > > >> > On Thu, Feb 28, 2008 at 7:41 AM, Tom London wrote: >> > > >> >> After applying today's selinux-policy* packages, gnome/gdm login >> > > >> >> fails: gdmgreeter runs, but X quickly dies after enter password and >> > > >> >> you're back to the greeter. >> > > >> >> >> > > >> >> Booting up in permissive lets me log in. >> > > >> >> >> > > >> >> Here are the borkages: >> > > >> >> >> > > >> >> >> > > >> >> #============= mono_t ============== >> > > >> >> allow mono_t xdm_xserver_t:x_device read; >> > > >> >> >> > > >> >> #============= unconfined_execmem_t ============== >> > > >> >> allow unconfined_execmem_t xdm_xserver_t:x_device read; >> > > >> >> >> > > >> >> #============= unconfined_t ============== >> > > >> >> allow unconfined_t mono_t:x_resource write; >> > > >> >> allow unconfined_t unconfined_execmem_t:x_resource { write read }; >> > > >> >> allow unconfined_t unlabeled_t:x_drawable { destroy getattr }; >> > > >> >> [root at localhost ~]# >> > > >> >> >> > > >> > > The "null" avc's are fixed in the upstream X server. This is a bad >> > > security hook call in the GLX code and affects GLX programs such as compiz. >> > > >> > > The unlabeled AVC is the result of a mislabeled program? >> > > >> > > >> > > >> > > -- >> > > Eamon Walsh >> > > National Security Agency >> > > >> > > >> > I've backed up policy to previous version, and checking for unlabeled >> > programs indicates nothing amiss. >> > >> > No programs were relabeled on install of poicy; something else I should check? >> >> grep 'invalidating context' /var/log/messages >> >> -- >> Stephen Smalley >> National Security Agency >> >> > [root at localhost ~]# grep 'invalidating context' /var/log/messages > Feb 27 07:13:31 localhost kernel: security: invalidating context > unconfined_u:unconfined_r:samba_net_t:s0 Ok I removed the transition from unconfined_t to samba_net_t, and replaced it with samba_unconfined_net_t. But this removed the unconfined_r designation causing this. > Feb 28 06:47:08 localhost kernel: security: invalidating context > system_u:system_r:httpd_unconfined_script_t:s0-s0:c0.c1023 > Feb 28 06:47:08 localhost kernel: security: invalidating context > unconfined_u:system_r:httpd_unconfined_script_t:s0 > Feb 28 06:47:08 localhost kernel: security: invalidating context > unconfined_u:unconfined_r:httpd_unconfined_script_t:s0 > Feb 28 07:46:11 localhost kernel: security: invalidating context > unconfined_u:system_r:httpd_user_script_t:s0 > Feb 28 07:46:11 localhost kernel: security: invalidating context > unconfined_u:system_r:httpd_user_script_t:s0-s0:c0.c255 > Feb 28 07:46:11 localhost kernel: security: invalidating context > system_u:system_r:httpd_user_script_t:s0-s0:c0.c1023 I have been working on switching apache scripts but not sure why this invalidated. > [root at localhost ~]# > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfIFTEACgkQrlYvE4MpobNOVwCeKSlEX289AIk1iUGb28i2KYII b1cAoLlxZ3XmCj9OgKhRZ1XXMv3PB3HP =gMDs -----END PGP SIGNATURE----- From ekuns at kilroy.chi.il.us Fri Feb 29 14:30:00 2008 From: ekuns at kilroy.chi.il.us (Edward Kuns) Date: Fri, 29 Feb 2008 08:30:00 -0600 Subject: SELinux interfering with clamav? In-Reply-To: <47C813C2.1040405@redhat.com> References: <1204259483.32130.2120.camel@kilroy.chi.il.us> <47C813C2.1040405@redhat.com> Message-ID: <1204295400.32130.2186.camel@kilroy.chi.il.us> On Fri, 2008-02-29 at 09:16 -0500, Daniel J Walsh wrote: > Always add a user specify front end to your policy. D'oh! That fixed it. Thanks. > This policy seems reasonable but most likely clamav-milter is going to > /usr/bin to execute something. So you might end up needing either > > corecmd_exec_bin(clamd_t) > > Or some transition to another domain. > > If you have an idea what app it is looking for, we can correct the policy. How can I find out what it's looking for? As a test, I just added the policy: module myclamav 1.0; require { type bin_t; type clamd_t; class dir search; } #============= clamd_t ============== allow clamd_t bin_t:dir search; so if I understand this, you expect that I should later today get an AVC that clamav is trying to execute something that is bin_t? Assuming that's the case, I'll see what is there when I get home from work later and I'll post that. But if there's something else I can do to find out, let me know. Thanks Eddie From dwalsh at redhat.com Fri Feb 29 14:39:15 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 29 Feb 2008 09:39:15 -0500 Subject: SELinux interfering with clamav? In-Reply-To: <1204295400.32130.2186.camel@kilroy.chi.il.us> References: <1204259483.32130.2120.camel@kilroy.chi.il.us> <47C813C2.1040405@redhat.com> <1204295400.32130.2186.camel@kilroy.chi.il.us> Message-ID: <47C81913.2030902@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Edward Kuns wrote: > On Fri, 2008-02-29 at 09:16 -0500, Daniel J Walsh wrote: >> Always add a user specify front end to your policy. > > D'oh! That fixed it. Thanks. > > >> This policy seems reasonable but most likely clamav-milter is going to >> /usr/bin to execute something. So you might end up needing either >> >> corecmd_exec_bin(clamd_t) >> >> Or some transition to another domain. >> >> If you have an idea what app it is looking for, we can correct the policy. > > How can I find out what it's looking for? As a test, I just added the > policy: > > module myclamav 1.0; > > require { > type bin_t; > type clamd_t; > class dir search; > } > > #============= clamd_t ============== > allow clamd_t bin_t:dir search; > > so if I understand this, you expect that I should later today get an AVC > that clamav is trying to execute something that is bin_t? Assuming > that's the case, I'll see what is there when I get home from work later > and I'll post that. But if there's something else I can do to find out, > let me know. > > Thanks > > Eddie > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Nope, that is the best you can do. You could put your machine in permissive mode to get all of the AVC's but that could be dangerous. We hope to have permissive domains eventually, were we could allow clamd_t only to do it's thing, but we don't have it yet. THanks for your help diagnosing this. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfIGRMACgkQrlYvE4MpobMiBwCePpuERf+k4vRKPlwEMtOgzg0l yB0AoLHFBaLJcEodsF1oYFWjGydP0Mzx =6YRg -----END PGP SIGNATURE-----