From zephod at cfl.rr.com Sat Aug 2 17:58:30 2008 From: zephod at cfl.rr.com (Steve Blackwell) Date: Sat, 2 Aug 2008 13:58:30 -0400 Subject: Can't export samba share In-Reply-To: <4890B750.3020306@redhat.com> References: <20080725192711.09897d64@steve.blackwell> <20080726142507.786093f6@steve.blackwell> <4890B750.3020306@redhat.com> Message-ID: <20080802135830.7447c9bd@steve.blackwell> > Sorry I was away at OLS last week and am just getting back though the > emails. > > What OS are you running? > > samba_share_fusefs is a boolean in Fedora 9 and Rawhide that allows > the > sharing of fusefs file systems in samba with selinux. > > setsebool -P samba_share_fusefs 1 Dan, I just noticed your e-mail from Wednesday. Sorry for the delay in answering. I'm running F8. Steve From olivares14031 at yahoo.com Sun Aug 3 04:02:13 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Sat, 2 Aug 2008 21:02:13 -0700 (PDT) Subject: fedora-selinux-list Digest, Vol 54, Issue 1 In-Reply-To: <20080801160019.7A9A861AF53@hormel.redhat.com> Message-ID: <685328.36949.qm@web52602.mail.re2.yahoo.com> > Easiest is: > > touch /.autorelabel; reboot > > You also might fix all/most of these with > > restorecon -R -v /home /root > > -Eric > ------------------------------ Eric, I tried the restorecon command first, but it failed, I still got flood of selinux denials. The first one, I did and it appears to have cured the mess :) touch /.autorelabel; reboot Regards, Antonio From olivares14031 at yahoo.com Sun Aug 3 17:59:34 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Sun, 3 Aug 2008 10:59:34 -0700 (PDT) Subject: SELinux is preventing nspluginviewer .... Message-ID: <535695.23541.qm@web52602.mail.re2.yahoo.com> Dear all, Now I know why playing Penalty_Fever caused a problem. The following is clear evidence :( Summary: SELinux is preventing nspluginviewer from changing a writable memory segment executable. Detailed Description: The nspluginviewer application attempted to change the access protection of memory (e.g., allocated using malloc). This is a potential security problem. Applications should not be doing this. Applications are sometimes coded incorrectly and request this permission. The SELinux Memory Protection Tests (http://people.redhat.com/drepper/selinux-mem.html) web page explains how to remove this requirement. If nspluginviewer 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: If you trust nspluginviewer to run correctly, you can change the context of the executable to unconfined_execmem_exec_t. "chcon -t unconfined_execmem_exec_t '/usr/bin/nspluginviewer'". 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/nspluginviewer'" Fix Command: chcon -t unconfined_execmem_exec_t '/usr/bin/nspluginviewer' 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 nspluginviewer Source Path /usr/bin/nspluginviewer Port Host localhost.localdomain Source RPM Packages kdebase-4.1.0-1.fc10 Target RPM Packages Policy RPM selinux-policy-3.5.1-4.fc10 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name allow_execmem Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.26.1 #1 SMP Sat Aug 2 21:36:01 CDT 2008 i686 i686 Alert Count 29 First Seen Sun 03 Aug 2008 12:55:21 PM CDT Last Seen Sun 03 Aug 2008 12:55:21 PM CDT Local ID 865503d3-baab-4dcd-adc0-47f8fff6ade6 Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1217786121.365:53): avc: denied { execmem } for pid=3262 comm="nspluginviewer" 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(1217786121.365:53): arch=40000003 syscall=125 success=no exit=-13 a0=b1aaa000 a1=1000 a2=5 a3=bfa32acc items=0 ppid=3222 pid=3262 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="nspluginviewer" exe="/usr/bin/nspluginviewer" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) This was an old bug and it returns to bite back :( Is anybody else also encountering this problem? Regards, Antonio From olivares14031 at yahoo.com Sun Aug 3 18:35:24 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Sun, 3 Aug 2008 11:35:24 -0700 (PDT) Subject: SELinux is preventing nspluginviewer .... In-Reply-To: <535695.23541.qm@web52602.mail.re2.yahoo.com> Message-ID: <645769.57484.qm@web52601.mail.re2.yahoo.com> > Dear all, > > Now I know why playing Penalty_Fever caused a problem. The > following is clear evidence :( > > > Summary: > > SELinux is preventing nspluginviewer from changing a > writable memory segment > executable. > > Detailed Description: > > The nspluginviewer application attempted to change the > access protection of > memory (e.g., allocated using malloc). This is a potential > security problem. > Applications should not be doing this. Applications are > sometimes coded > incorrectly and request this permission. The SELinux Memory > Protection Tests > (http://people.redhat.com/drepper/selinux-mem.html) web > page explains how to > remove this requirement. If nspluginviewer 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: > > If you trust nspluginviewer to run correctly, you can > change the context of the > executable to unconfined_execmem_exec_t. "chcon -t > unconfined_execmem_exec_t > '/usr/bin/nspluginviewer'". 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/nspluginviewer'" > > Fix Command: > > chcon -t unconfined_execmem_exec_t > '/usr/bin/nspluginviewer' > > 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 nspluginviewer > Source Path /usr/bin/nspluginviewer > Port > Host localhost.localdomain > Source RPM Packages kdebase-4.1.0-1.fc10 > Target RPM Packages > Policy RPM selinux-policy-3.5.1-4.fc10 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name allow_execmem > Host Name localhost.localdomain > Platform Linux localhost.localdomain > 2.6.26.1 #1 SMP Sat > Aug 2 21:36:01 CDT 2008 i686 > i686 > Alert Count 29 > First Seen Sun 03 Aug 2008 12:55:21 PM > CDT > Last Seen Sun 03 Aug 2008 12:55:21 PM > CDT > Local ID > 865503d3-baab-4dcd-adc0-47f8fff6ade6 > Line Numbers > > Raw Audit Messages > > host=localhost.localdomain type=AVC > msg=audit(1217786121.365:53): avc: denied { execmem } for > pid=3262 comm="nspluginviewer" > 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(1217786121.365:53): arch=40000003 syscall=125 > success=no exit=-13 a0=b1aaa000 a1=1000 a2=5 a3=bfa32acc > items=0 ppid=3222 pid=3262 auid=500 uid=500 gid=500 euid=500 > suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) > ses=1 comm="nspluginviewer" > exe="/usr/bin/nspluginviewer" > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > key=(null) > > > This was an old bug and it returns to bite back :( > Is anybody else also encountering this problem? > > Regards, > > Antonio > > > > > -- BTW, the old bug with nspluginwrapper was here: https://bugzilla.redhat.com/show_bug.cgi?id=431708 It was closed. It looks a little bit different, now I am not sure if it is related? Thanks, Antonio From dwalsh at redhat.com Mon Aug 4 18:25:25 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 04 Aug 2008 14:25:25 -0400 Subject: selinux and denied gconf errors In-Reply-To: <1217539433.2902.128.camel@localhost.localdomain> References: <844219.47264.qm@web52607.mail.re2.yahoo.com> <1217539433.2902.128.camel@localhost.localdomain> Message-ID: <48974995.5000403@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Paris wrote: > On Thu, 2008-07-31 at 12:17 -0700, Antonio Olivares wrote: > > All labeling issues, either things on disk have no label (they were > created on a machine not running SELinux), they have an old label (I > don't remember us changing .gconfd anytime recently) or any number of > other things. > > Easiest is: > > touch /.autorelabel; reboot > Easiest and the biggest pain in the butt. Please do this as a last resort to fix labeling. Easiest is restorecon -R -v PATHTOOFFENDINGFILE, Next restorecon -R -v /TOPDIROFPATHTOOFFENDINGFILE Unlabled_t files are caused by me, trying to clean up file context and making a mistake. I updated the policy fairly quickly to try to eliminate this problem. But I am sorry it bit some of you. > You also might fix all/most of these with > > restorecon -R -v /home /root > > -Eric > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiXSZUACgkQrlYvE4MpobNhCgCfY/fW5FyY8+fVnqlB18h1tt+p GyoAoOq2RHXZ8X4V2n5uhGfvq3KdWsrD =ruFn -----END PGP SIGNATURE----- From dwalsh at redhat.com Mon Aug 4 18:32:54 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 04 Aug 2008 14:32:54 -0400 Subject: SELinux is preventing nspluginviewer .... In-Reply-To: <645769.57484.qm@web52601.mail.re2.yahoo.com> References: <645769.57484.qm@web52601.mail.re2.yahoo.com> Message-ID: <48974B56.9080001@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Antonio Olivares wrote: >> Dear all, >> >> Now I know why playing Penalty_Fever caused a problem. The >> following is clear evidence :( >> >> >> Summary: >> >> SELinux is preventing nspluginviewer from changing a >> writable memory segment >> executable. >> >> Detailed Description: >> >> The nspluginviewer application attempted to change the >> access protection of >> memory (e.g., allocated using malloc). This is a potential >> security problem. >> Applications should not be doing this. Applications are >> sometimes coded >> incorrectly and request this permission. The SELinux Memory >> Protection Tests >> (http://people.redhat.com/drepper/selinux-mem.html) web >> page explains how to >> remove this requirement. If nspluginviewer 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: >> >> If you trust nspluginviewer to run correctly, you can >> change the context of the >> executable to unconfined_execmem_exec_t. "chcon -t >> unconfined_execmem_exec_t >> '/usr/bin/nspluginviewer'". 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/nspluginviewer'" >> >> Fix Command: >> >> chcon -t unconfined_execmem_exec_t >> '/usr/bin/nspluginviewer' >> >> 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 nspluginviewer >> Source Path /usr/bin/nspluginviewer >> Port >> Host localhost.localdomain >> Source RPM Packages kdebase-4.1.0-1.fc10 >> Target RPM Packages >> Policy RPM selinux-policy-3.5.1-4.fc10 >> Selinux Enabled True >> Policy Type targeted >> MLS Enabled True >> Enforcing Mode Enforcing >> Plugin Name allow_execmem >> Host Name localhost.localdomain >> Platform Linux localhost.localdomain >> 2.6.26.1 #1 SMP Sat >> Aug 2 21:36:01 CDT 2008 i686 >> i686 >> Alert Count 29 >> First Seen Sun 03 Aug 2008 12:55:21 PM >> CDT >> Last Seen Sun 03 Aug 2008 12:55:21 PM >> CDT >> Local ID >> 865503d3-baab-4dcd-adc0-47f8fff6ade6 >> Line Numbers >> >> Raw Audit Messages >> >> host=localhost.localdomain type=AVC >> msg=audit(1217786121.365:53): avc: denied { execmem } for >> pid=3262 comm="nspluginviewer" >> 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(1217786121.365:53): arch=40000003 syscall=125 >> success=no exit=-13 a0=b1aaa000 a1=1000 a2=5 a3=bfa32acc >> items=0 ppid=3222 pid=3262 auid=500 uid=500 gid=500 euid=500 >> suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) >> ses=1 comm="nspluginviewer" >> exe="/usr/bin/nspluginviewer" >> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 >> key=(null) >> >> >> This was an old bug and it returns to bite back :( >> Is anybody else also encountering this problem? >> >> Regards, >> >> Antonio >> >> >> >> >> -- > > BTW, > > the old bug with nspluginwrapper was here: > > https://bugzilla.redhat.com/show_bug.cgi?id=431708 > > It was closed. It looks a little bit different, now I am not sure if it is related? > > Thanks, > > Antonio > > > > Most likely caused by one of the plugins you are using. You have multiple choices to fix this, one you could turn on nsplugin confinement # getsebool -a | grep nsplugin allow_nsplugin_execmem --> on allow_unconfined_nsplugin_transition --> on You should relabel your homedir if you do. restorecon -R -v ~ Then restart firefox. This would allow a confined nsplugin to execmem but not all apps run from unconfined_t. I have been running like this for a long time and have had few problems, although the more people who run with this mode the better so we can figure out what firefox plugins want to do. You can not run the offending plugin. You can ignore the error if it does not seem to cause the problem. You can turn on allow_execmem boolean. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiXS1YACgkQrlYvE4MpobPgsgCgtS04Z/kSzNfsa6MILORC1ZxU QJEAn1v2xRLEMv3r5rmVQlE0xfpAnicO =1PTR -----END PGP SIGNATURE----- From olivares14031 at yahoo.com Mon Aug 4 18:33:38 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Mon, 4 Aug 2008 11:33:38 -0700 (PDT) Subject: selinux and denied gconf errors In-Reply-To: <48974995.5000403@redhat.com> Message-ID: <261018.31298.qm@web52606.mail.re2.yahoo.com> > > All labeling issues, either things on disk have no > label (they were > > created on a machine not running SELinux), they have > an old label (I > > don't remember us changing .gconfd anytime > recently) or any number of > > other things. > > > > Easiest is: > > > > touch /.autorelabel; reboot > > > Easiest and the biggest pain in the butt. Please do this > as a last > resort to fix labeling. Easiest is restorecon -R -v > PATHTOOFFENDINGFILE, Next restorecon -R -v > /TOPDIROFPATHTOOFFENDINGFILE I tried the restorecon for all of them, they were like 20 or more warnings and it failed :(, it was more of a pain to go through those 20 or so each one individually and still have to see them :( I applied the magic touch /.autorelabel; reboot and it fixed those. > > Unlabled_t files are caused by me, trying to clean up file > context and > making a mistake. I updated the policy fairly quickly to > try to > eliminate this problem. But I am sorry it bit some of you. No problem, I applied a brute force removal of all files in /tmp/ I did a # rm -rf /tmp/* and checked back if there were files and I removed those by brute force. and all appears well :) I have been through this before and with your guidance and help, I overcame these :) > > > You also might fix all/most of these with > > > > restorecon -R -v /home /root > > > > -Eric > > > > -- Thanks for checking back. Now its nsplugin and selinux, but will get to that one later. Regards, Antonio From olivares14031 at yahoo.com Mon Aug 4 18:39:02 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Mon, 4 Aug 2008 11:39:02 -0700 (PDT) Subject: SELinux is preventing nspluginviewer .... In-Reply-To: <48974B56.9080001@redhat.com> Message-ID: <452886.33308.qm@web52608.mail.re2.yahoo.com> > >> Dear all, > >> > >> Now I know why playing Penalty_Fever caused a > problem. The > >> following is clear evidence :( > >> > >> > >> Summary: > >> > >> SELinux is preventing nspluginviewer from changing > a > >> writable memory segment > >> executable. > >> > >> Detailed Description: > >> > >> The nspluginviewer application attempted to change > the > >> access protection of > >> memory (e.g., allocated using malloc). This is a > potential > >> security problem. > >> Applications should not be doing this. > Applications are > >> sometimes coded > >> incorrectly and request this permission. The > SELinux Memory > >> Protection Tests > >> > (http://people.redhat.com/drepper/selinux-mem.html) web > >> page explains how to > >> remove this requirement. If nspluginviewer 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: > >> > >> If you trust nspluginviewer to run correctly, you > can > >> change the context of the > >> executable to unconfined_execmem_exec_t. > "chcon -t > >> unconfined_execmem_exec_t > >> '/usr/bin/nspluginviewer'". 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/nspluginviewer'" > >> > >> Fix Command: > >> > >> chcon -t unconfined_execmem_exec_t > >> '/usr/bin/nspluginviewer' > >> > >> 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 nspluginviewer > >> Source Path > /usr/bin/nspluginviewer > >> Port > >> Host > localhost.localdomain > >> Source RPM Packages kdebase-4.1.0-1.fc10 > >> Target RPM Packages > >> Policy RPM > selinux-policy-3.5.1-4.fc10 > >> Selinux Enabled True > >> Policy Type targeted > >> MLS Enabled True > >> Enforcing Mode Enforcing > >> Plugin Name allow_execmem > >> Host Name > localhost.localdomain > >> Platform Linux > localhost.localdomain > >> 2.6.26.1 #1 SMP Sat > >> Aug 2 21:36:01 CDT > 2008 i686 > >> i686 > >> Alert Count 29 > >> First Seen Sun 03 Aug 2008 > 12:55:21 PM > >> CDT > >> Last Seen Sun 03 Aug 2008 > 12:55:21 PM > >> CDT > >> Local ID > >> 865503d3-baab-4dcd-adc0-47f8fff6ade6 > >> Line Numbers > >> > >> Raw Audit Messages > >> > >> host=localhost.localdomain type=AVC > >> msg=audit(1217786121.365:53): avc: denied { > execmem } for > >> pid=3262 comm="nspluginviewer" > >> > 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(1217786121.365:53): arch=40000003 > syscall=125 > >> success=no exit=-13 a0=b1aaa000 a1=1000 a2=5 > a3=bfa32acc > >> items=0 ppid=3222 pid=3262 auid=500 uid=500 > gid=500 euid=500 > >> suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 > tty=(none) > >> ses=1 comm="nspluginviewer" > >> exe="/usr/bin/nspluginviewer" > >> > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > >> key=(null) > >> > >> > >> This was an old bug and it returns to bite back :( > >> Is anybody else also encountering this problem? > >> > >> Regards, > >> > >> Antonio > >> > >> > >> > >> > >> -- > > > > BTW, > > > > the old bug with nspluginwrapper was here: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=431708 > > > > It was closed. It looks a little bit different, now I > am not sure if it is related? > > > > Thanks, > > > > Antonio > > > > > > > > > Most likely caused by one of the plugins you are using. > You have > multiple choices to fix this, one you could turn on > nsplugin confinement > > # getsebool -a | grep nsplugin > allow_nsplugin_execmem --> on > allow_unconfined_nsplugin_transition --> on > > You should relabel your homedir if you do. > > restorecon -R -v ~ > > Then restart firefox. This would allow a confined nsplugin > to execmem > but not all apps run from unconfined_t. I have been > running like this > for a long time and have had few problems, although the > more people who > run with this mode the better so we can figure out what > firefox plugins > want to do. I am running konqueror on KDE 4.1 Rawhide. Firefox and Seamonkey are not reliable and I yum removed 'em. I was playing a flash game and it was working nicely, but then I got to the next level and CPU went up to 100% and crashed. I can try the suggestions, but I am not sure that konqueror behaves like firefox with the plugins. > > You can not run the offending plugin. > > You can ignore the error if it does not seem to cause the > problem. > > You can turn on allow_execmem boolean. I'll take a look into that. Regards, Antonio From fdsubs at t-online.hu Mon Aug 4 21:08:13 2008 From: fdsubs at t-online.hu (Daniel Fazekas) Date: Mon, 4 Aug 2008 23:08:13 +0200 Subject: linux-igd blocked by SELinux Message-ID: The linux-igd package in Fedora 9 doesn't seem to function at all in its default configuration with SELinux enabled. It's a UPnP IGD implementation which calls iptables to automatically add requested port forwarding DNAT entries to the nat table's PREROUTING chain, and the filter table's FORWARD chain. Two runs through audit2allow made me a module which allows it to function, however, I'm worried whether the automatically generated rules are sensible, or if it's even normal that a Fedora 9 package by default just wouldn't work at all with SELinux enforcing on. Thanks for any insight. The upnpd runs as root. The package versions: linux-igd-1.0-5.fc9.i386 selinux-policy-targeted-3.3.1-79.fc9.noarch Audit messages: type=1400 audit(1217802519.747:3819): avc: denied { read write } for pid=7890 comm="iptables" path="socket:[133770]" dev=sockfs ino=133770 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=udp_socket type=1400 audit(1217804575.392:3820): avc: denied { read write } for pid=8058 comm="iptables" path="socket:[133769]" dev=sockfs ino=133769 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket type=1401 audit(1217811758.594:3828): security_compute_sid: invalid context unconfined_u:unconfined_r:insmod_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:iptables_t:s0-s0:c0.c1023 tcontext=system_u:object_r:insmod_exec_t:s0 tclass=process The auto-generated module which allows it to function: module myupnpd 1.0.1; require { type iptables_t; type initrc_t; type insmod_t; role unconfined_r; class tcp_socket { read write }; class udp_socket { read write }; } #============= ROLES ============== role unconfined_r types insmod_t; #============= iptables_t ============== allow iptables_t initrc_t:tcp_socket { read write }; allow iptables_t initrc_t:udp_socket { read write }; From dwalsh at redhat.com Tue Aug 5 13:22:25 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 05 Aug 2008 09:22:25 -0400 Subject: linux-igd blocked by SELinux In-Reply-To: References: Message-ID: <48985411.50600@redhat.com> Daniel Fazekas wrote: > The linux-igd package in Fedora 9 doesn't seem to function at all in its > default configuration with SELinux enabled. > > It's a UPnP IGD implementation which calls iptables to automatically add > requested port forwarding DNAT entries to the nat table's PREROUTING > chain, and the filter table's FORWARD chain. > > Two runs through audit2allow made me a module which allows it to > function, however, I'm worried whether the automatically generated rules > are sensible, or if it's even normal that a Fedora 9 package by default > just wouldn't work at all with SELinux enforcing on. Thanks for any > insight. > The upnpd runs as root. > > The package versions: > linux-igd-1.0-5.fc9.i386 > selinux-policy-targeted-3.3.1-79.fc9.noarch > > Audit messages: > type=1400 audit(1217802519.747:3819): avc: denied { read write } for > pid=7890 comm="iptables" path="socket:[133770]" dev=sockfs ino=133770 > scontext=unconfined_u:system_r:iptables_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=udp_socket > type=1400 audit(1217804575.392:3820): avc: denied { read write } for > pid=8058 comm="iptables" path="socket:[133769]" dev=sockfs ino=133769 > scontext=unconfined_u:system_r:iptables_t:s0 > tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket > type=1401 audit(1217811758.594:3828): security_compute_sid: invalid > context unconfined_u:unconfined_r:insmod_t:s0-s0:c0.c1023 for > scontext=unconfined_u:unconfined_r:iptables_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:insmod_exec_t:s0 tclass=process > > The auto-generated module which allows it to function: > module myupnpd 1.0.1; > > require { > type iptables_t; > type initrc_t; > type insmod_t; > role unconfined_r; > class tcp_socket { read write }; > class udp_socket { read write }; > } > > #============= ROLES ============== > role unconfined_r types insmod_t; > > #============= iptables_t ============== > allow iptables_t initrc_t:tcp_socket { read write }; > allow iptables_t initrc_t:udp_socket { read write }; These two are a leaked file descriptor from the daemon running as initrc_t. These should be reported as a bug in this tool. All open file descriptors should be closed before execing an application fcntl(fd, F_SETFD, FD_CLOSEXEC) The role commands should be added, and I will fix F9 and Rawhide policy. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list The From selinux.list at troodos.demon.co.uk Wed Aug 6 09:48:28 2008 From: selinux.list at troodos.demon.co.uk (Arthur Dent) Date: Wed, 6 Aug 2008 10:48:28 +0100 Subject: Clamd getting out of hand... In-Reply-To: <4890C1FA.3030804@redhat.com> References: <20080727192458.GA7621@localhost.localdomain> <489087BF.2060708@redhat.com> <20080730172923.GA4400@localhost.localdomain> <4890C1FA.3030804@redhat.com> Message-ID: <20080806094828.GA3857@localhost.localdomain> On Wed, Jul 30, 2008 at 03:33:14PM -0400, Daniel J Walsh wrote: > But do you have the original avc messages used to generate the policy. > I want to see if we are missing transitions? What port is it > communicating with etc. Apologies for the slow response. RL gets in the way sometimes... To recap: My mail chain is as follows: fetchmail -> procmail | -> clamassassin -> spamassassin -> dovecot -> MUA | -> clamdscan | -> clamd I had made several home-made policies to allow clamd to work under F8. Following an upgrade to F9 I get a whole load more avc denials and have had to add a bunch of policies to get it to work. With SEL in enforcing mode (I know I should have set it to permissive until I had sorted this out but I though each problem would be the last..) the recent denials fell into 3 types: sending denials receiving denial write to pipe denials I got several hundred sending denials until I wrote a policy with audit2allow then I got sever hundred receiving denials until I fixed that and finally a ton of write-to pipe. If you look at the collection of raw audit messages (just a sample) that I posted here http://pastebin.com/m7b60d46a you will see that almost every part of the mail chain seems to be affected. Finding the original avc messages from my F8 install would be hard work, but I have included 3 (one of each type) from the F9 upgrade. You can see them here: http://pastebin.com/m1fc5a466 If you want others (as referred to in the raw avcs) just let me know. So, clamd settings can be seen here (entire clamd.conf file) : http://pastebin.com/m72927397 A selection of raw avc messages can be seen here: http://pastebin.com/m7b60d46a And 3 of the entire avc messages here: http://pastebin.com/m1fc5a466 I really do thank you for your help... AD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From dwalsh at redhat.com Wed Aug 6 13:34:03 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 06 Aug 2008 09:34:03 -0400 Subject: Clamd getting out of hand... In-Reply-To: <20080806094828.GA3857@localhost.localdomain> References: <20080727192458.GA7621@localhost.localdomain> <489087BF.2060708@redhat.com> <20080730172923.GA4400@localhost.localdomain> <4890C1FA.3030804@redhat.com> <20080806094828.GA3857@localhost.localdomain> Message-ID: <4899A84B.60208@redhat.com> Arthur Dent wrote: > On Wed, Jul 30, 2008 at 03:33:14PM -0400, Daniel J Walsh wrote: > > >> But do you have the original avc messages used to generate the policy. >> I want to see if we are missing transitions? What port is it >> communicating with etc. > > Apologies for the slow response. RL gets in the way sometimes... > > To recap: > > My mail chain is as follows: > > fetchmail -> procmail > | > -> clamassassin -> spamassassin -> dovecot -> MUA > | > -> clamdscan > | > -> clamd > > I had made several home-made policies to allow clamd to work under F8. > Following an upgrade to F9 I get a whole load more avc denials and have > had to add a bunch of policies to get it to work. > > With SEL in enforcing mode (I know I should have set it to permissive > until I had sorted this out but I though each problem would be the > last..) the recent denials fell into 3 types: > > sending denials > receiving denial > write to pipe denials > > I got several hundred sending denials until I wrote a policy with > audit2allow then I got sever hundred receiving denials until I fixed > that and finally a ton of write-to pipe. If you look at the collection > of raw audit messages (just a sample) that I posted here > > http://pastebin.com/m7b60d46a > > you will see that almost every part of the mail chain seems to be > affected. > > Finding the original avc messages from my F8 install would be hard work, > but I have included 3 (one of each type) from the F9 upgrade. You can > see them here: > > http://pastebin.com/m1fc5a466 > > If you want others (as referred to in the raw avcs) just let me know. > > So, clamd settings can be seen here (entire clamd.conf file) : > http://pastebin.com/m72927397 > A selection of raw avc messages can be seen here: > http://pastebin.com/m7b60d46a > And 3 of the entire avc messages here: > http://pastebin.com/m1fc5a466 > > > I really do thank you for your help... > > AD > > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Adding the following policy to clamscan mta_send_mail(clamscan_t) corenet_all_recvfrom_unlabeled(clamscan_t) corenet_all_recvfrom_netlabel(clamscan_t) corenet_tcp_sendrecv_all_if(clamscan_t) corenet_tcp_sendrecv_all_nodes(clamscan_t) corenet_tcp_sendrecv_all_ports(clamscan_t) corenet_tcp_sendrecv_clamd_port(clamscan_t) corenet_tcp_connect_clamd_port(clamscan_t) Shoudl fix. Updated in selinux-policy-3.3.1-85.fc9 From sundaram at fedoraproject.org Wed Aug 6 22:49:33 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 07 Aug 2008 04:19:33 +0530 Subject: system-config-services issue Message-ID: <489A2A7D.1080200@fedoraproject.org> Hi, In rawhide, I am running across this issue: -- Summary: SELinux is preventing the dbus-daemon-lau (system_dbusd_t) from executing ./system-config-services-mechanism.py. Detailed Description: SELinux has denied the dbus-daemon-lau from executing ./system-config-services-mechanism.py. If dbus-daemon-lau is supposed to be able to execute ./system-config-services-mechanism.py, this could be a labeling problem. Most confined domains are allowed to execute files labeled bin_t. So you could change the labeling on this file to bin_t and retry the application. If this dbus-daemon-lau is not supposed to execute ./system-config-services-mechanism.py, this could signal a intrusion attempt. Allowing Access: If you want to allow dbus-daemon-lau to execute ./system-config-services-mechanism.py: chcon -t bin_t './system-config-services-mechanism.py' If this fix works, please update the file context on disk, with the following command: semanage fcontext -a -t bin_t './system-config-services-mechanism.py' Please specify the full path to the executable, Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this selinux-policy to make sure this becomes the default labeling. Additional Information: Source Context system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 Target Context system_u:object_r:usr_t:s0 Target Objects ./system-config-services-mechanism.py [ file ] Source dbus-daemon-lau Source Path /lib/dbus-1/dbus-daemon-launch-helper Port Host localhost.localdomain Source RPM Packages dbus-1.2.1-7.fc10 Target RPM Packages Policy RPM selinux-policy-3.5.1-4.fc10 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name execute Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.27-0.166.rc0.git8.fc10.i686 #1 SMP Mon Jul 21 20:51:26 EDT 2008 i686 i686 Alert Count 2 First Seen Thu 07 Aug 2008 02:21:12 AM IST Last Seen Thu 07 Aug 2008 04:01:06 AM IST Local ID 8473c2be-dcfe-4f50-9db3-6f3dbd1d6025 Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1218061866.291:173): avc: denied { execute } for pid=26453 comm="dbus-daemon-lau" name="system-config-services-mechanism.py" dev=dm-1 ino=1474565 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:usr_t:s0 tclass=file host=localhost.localdomain type=SYSCALL msg=audit(1218061866.291:173): arch=40000003 syscall=11 success=no exit=-13 a0=8816018 a1=8815d60 a2=8815008 a3=6c99bc items=0 ppid=26452 pid=26453 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="dbus-daemon-lau" exe="/lib/dbus-1/dbus-daemon-launch-helper" subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null) --- Rahul From sundaram at fedoraproject.org Wed Aug 6 23:00:38 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 07 Aug 2008 04:30:38 +0530 Subject: system-config-selinux in rawhide Message-ID: <489A2D16.8060502@fedoraproject.org> Hi, For some reason, system-config-selinux is taking a really long time just to open up in rawhide. # rpm -qf /usr/bin/system-config-selinux policycoreutils-gui-2.0.53-1.fc10.i386 Rahul From dwalsh at redhat.com Thu Aug 7 12:25:10 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 07 Aug 2008 08:25:10 -0400 Subject: system-config-services issue In-Reply-To: <489A2A7D.1080200@fedoraproject.org> References: <489A2A7D.1080200@fedoraproject.org> Message-ID: <489AE9A6.6030007@redhat.com> Rahul Sundaram wrote: > Hi, > > In rawhide, I am running across this issue: > > -- > > Summary: > > SELinux is preventing the dbus-daemon-lau (system_dbusd_t) from executing > ./system-config-services-mechanism.py. > > Detailed Description: > > SELinux has denied the dbus-daemon-lau from executing > ./system-config-services-mechanism.py. If dbus-daemon-lau is supposed to > be able > to execute ./system-config-services-mechanism.py, this could be a labeling > problem. Most confined domains are allowed to execute files labeled > bin_t. So > you could change the labeling on this file to bin_t and retry the > application. > If this dbus-daemon-lau is not supposed to execute > ./system-config-services-mechanism.py, this could signal a intrusion > attempt. > > Allowing Access: > > If you want to allow dbus-daemon-lau to execute > ./system-config-services-mechanism.py: chcon -t bin_t > './system-config-services-mechanism.py' If this fix works, please update > the > file context on disk, with the following command: semanage fcontext -a > -t bin_t > './system-config-services-mechanism.py' Please specify the full path to the > executable, Please file a bug report > (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this > selinux-policy > to make sure this becomes the default labeling. > > Additional Information: > > Source Context system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 > Target Context system_u:object_r:usr_t:s0 > Target Objects ./system-config-services-mechanism.py [ > file ] > Source dbus-daemon-lau > Source Path /lib/dbus-1/dbus-daemon-launch-helper > Port > Host localhost.localdomain > Source RPM Packages dbus-1.2.1-7.fc10 > Target RPM Packages > Policy RPM selinux-policy-3.5.1-4.fc10 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name execute > Host Name localhost.localdomain > Platform Linux localhost.localdomain > 2.6.27-0.166.rc0.git8.fc10.i686 #1 SMP Mon > Jul 21 > 20:51:26 EDT 2008 i686 i686 > Alert Count 2 > First Seen Thu 07 Aug 2008 02:21:12 AM IST > Last Seen Thu 07 Aug 2008 04:01:06 AM IST > Local ID 8473c2be-dcfe-4f50-9db3-6f3dbd1d6025 > Line Numbers > > Raw Audit Messages > > host=localhost.localdomain type=AVC msg=audit(1218061866.291:173): avc: > denied { execute } for pid=26453 comm="dbus-daemon-lau" > name="system-config-services-mechanism.py" dev=dm-1 ino=1474565 > scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:usr_t:s0 tclass=file > > host=localhost.localdomain type=SYSCALL msg=audit(1218061866.291:173): > arch=40000003 syscall=11 success=no exit=-13 a0=8816018 a1=8815d60 > a2=8815008 a3=6c99bc items=0 ppid=26452 pid=26453 auid=4294967295 uid=0 > gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) > ses=4294967295 comm="dbus-daemon-lau" > exe="/lib/dbus-1/dbus-daemon-launch-helper" > subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null) > > --- > > Rahul > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Fixed in selinux-policy-3.5.2-2.fc10 Should be in tonights rawhide. From sundaram at fedoraproject.org Thu Aug 7 16:24:11 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 07 Aug 2008 21:54:11 +0530 Subject: system-config-selinux in rawhide In-Reply-To: <489AEA23.9070108@redhat.com> References: <489A2D16.8060502@fedoraproject.org> <489AEA23.9070108@redhat.com> Message-ID: <489B21AB.7010905@fedoraproject.org> Daniel J Walsh wrote: > Rahul Sundaram wrote: > >> Hi, >> >> For some reason, system-config-selinux is taking a really long time just >> to open up in rawhide. >> >> > Seems to be working well for me? > I saw someone else complaining in the forum. So it's not just me. How do i help you debug this issue? Rahul From dwalsh at redhat.com Thu Aug 7 16:44:38 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 07 Aug 2008 12:44:38 -0400 Subject: system-config-selinux in rawhide In-Reply-To: <489B21AB.7010905@fedoraproject.org> References: <489A2D16.8060502@fedoraproject.org> <489AEA23.9070108@redhat.com> <489B21AB.7010905@fedoraproject.org> Message-ID: <489B2676.9060405@redhat.com> Rahul Sundaram wrote: > Daniel J Walsh wrote: >> Rahul Sundaram wrote: >> >>> Hi, >>> >>> For some reason, system-config-selinux is taking a really long time just >>> to open up in rawhide. >>> >>> >> Seems to be working well for me? >> > > I saw someone else complaining in the forum. So it's not just me. How do > i help you debug this issue? > > Rahul How long is it taking to load? From sundaram at fedoraproject.org Thu Aug 7 16:57:21 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 07 Aug 2008 22:27:21 +0530 Subject: system-config-selinux in rawhide In-Reply-To: <489B2676.9060405@redhat.com> References: <489A2D16.8060502@fedoraproject.org> <489AEA23.9070108@redhat.com> <489B21AB.7010905@fedoraproject.org> <489B2676.9060405@redhat.com> Message-ID: <489B2971.3030705@fedoraproject.org> Daniel J Walsh wrote: > Rahul Sundaram wrote: > >> Daniel J Walsh wrote: >> >>> Rahul Sundaram wrote: >>> >>> >>>> Hi, >>>> >>>> For some reason, system-config-selinux is taking a really long time just >>>> to open up in rawhide. >>>> >>>> >>>> >>> Seems to be working well for me? >>> >>> >> I saw someone else complaining in the forum. So it's not just me. How do >> i help you debug this issue? >> >> Rahul >> > How long is it taking to load? > The password dialog is immediate. The application itself takes more than 10 seconds. It used to be immediate in Fedora 9 IIRC. Rahul From dwalsh at redhat.com Fri Aug 8 15:51:24 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 08 Aug 2008 11:51:24 -0400 Subject: system-config-selinux in rawhide In-Reply-To: <489B2971.3030705@fedoraproject.org> References: <489A2D16.8060502@fedoraproject.org> <489AEA23.9070108@redhat.com> <489B21AB.7010905@fedoraproject.org> <489B2676.9060405@redhat.com> <489B2971.3030705@fedoraproject.org> Message-ID: <489C6B7C.6050808@redhat.com> Rahul Sundaram wrote: > Daniel J Walsh wrote: >> Rahul Sundaram wrote: >> >>> Daniel J Walsh wrote: >>> >>>> Rahul Sundaram wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> For some reason, system-config-selinux is taking a really long time >>>>> just >>>>> to open up in rawhide. >>>>> >>>>> >>>> Seems to be working well for me? >>>> >>> I saw someone else complaining in the forum. So it's not just me. How do >>> i help you debug this issue? >>> >>> Rahul >>> >> How long is it taking to load? >> > > The password dialog is immediate. The application itself takes more than > 10 seconds. It used to be immediate in Fedora 9 IIRC. > > Rahul > I am running it on both Fedora 9 and Rawhide and they both take around 10 seconds. I think this is caused by some of the loading of screens in the background. IE It is reading lots of data and executing commands like semodule -l, getsebool -a. reading policy. From aleksander.adamowski.fedora at altkom.pl Mon Aug 11 10:32:28 2008 From: aleksander.adamowski.fedora at altkom.pl (Aleksander Adamowski) Date: Mon, 11 Aug 2008 12:32:28 +0200 Subject: Running a script from Samba In-Reply-To: <4880D832.3070406@redhat.com> References: <200807181836.14111.tony.molloy@ul.ie> <4880D832.3070406@redhat.com> Message-ID: <48A0153C.5090008@altkom.pl> Daniel J Walsh wrote: > Tony Molloy wrote: > >> This is on Centos not Fedora but that shouldn't matter. >> >> If I want Samba to run a script ( logon logout scripts ) what context should I >> set the scripts to. >> >> Thanks,, >> >> Tony >> > /var/lib/samba/scripts(/.*)? > system_u:object_r:samba_unconfined_script_exec_t:s0 > Hi! I have a problem with this type on Fedora 9 (upgraded from Fedora 8). I'm trying to rebuild the policy and recompile my custom modules for policy version 3.3, but when I try to replace the base policy I get the error that this type is not defined: # semodule -b /usr/share/selinux/targeted/base.pp libsepol.context_from_record: type samba_unconfined_script_exec_t is not defined libsepol.context_from_record: could not create context structure libsepol.context_from_string: could not create context structure libsepol.sepol_context_to_sid: could not convert system_u:object_r:samba_unconfined_script_exec_t:s0 to sid invalid context system_u:object_r:samba_unconfined_script_exec_t:s0 libsemanage.semanage_install_active: setfiles returned error code 1. semodule: Failed! I've removed all my custom modules; my file_contexts.local contains only one entry that concerns stunnel: /usr/bin/stunnel -- system_u:object_r:stunnel_exec_t:s0 I also have the unconfined.pp module unloaded (when it was Fedora 8). But when I try to load it back on Fedora 9, I get this error: # semodule -i /usr/share/selinux/targeted/unconfined.pp libsepol.permission_copy_callback: Module unconfined depends on permission forward_out in class packet, not satisfied libsemanage.semanage_link_sandbox: Link packages failed semodule: Failed! Which is probably (I think) due to the old base.pp being still used because I cannot install the new one because of this problem with Samba script type. Could you suggest a path for getting out of this situation? -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.org.pl From aleksander.adamowski.fedora at altkom.pl Mon Aug 11 11:58:40 2008 From: aleksander.adamowski.fedora at altkom.pl (Aleksander Adamowski) Date: Mon, 11 Aug 2008 13:58:40 +0200 Subject: Running a script from Samba In-Reply-To: <48A0153C.5090008@altkom.pl> References: <200807181836.14111.tony.molloy@ul.ie> <4880D832.3070406@redhat.com> <48A0153C.5090008@altkom.pl> Message-ID: <48A02970.8000304@altkom.pl> Aleksander Adamowski wrote: > > Hi! > > I have a problem with this type on Fedora 9 (upgraded from Fedora 8). > > I'm trying to rebuild the policy and recompile my custom modules for > policy version 3.3, but when I try to replace the base policy I get > the error that this type is not defined: > > # semodule -b /usr/share/selinux/targeted/base.pp > libsepol.context_from_record: type samba_unconfined_script_exec_t is > not defined > libsepol.context_from_record: could not create context structure > libsepol.context_from_string: could not create context structure > libsepol.sepol_context_to_sid: could not convert > system_u:object_r:samba_unconfined_script_exec_t:s0 to sid > invalid context system_u:object_r:samba_unconfined_script_exec_t:s0 > libsemanage.semanage_install_active: setfiles returned error code 1. > semodule: Failed! > > I've removed all my custom modules; my file_contexts.local contains > only one entry that concerns stunnel: > /usr/bin/stunnel -- system_u:object_r:stunnel_exec_t:s0 > > I also have the unconfined.pp module unloaded (when it was Fedora 8). > But when I try to load it back on Fedora 9, I get this error: > > # semodule -i /usr/share/selinux/targeted/unconfined.pp > libsepol.permission_copy_callback: Module unconfined depends on > permission forward_out in class packet, not satisfied > libsemanage.semanage_link_sandbox: Link packages failed > semodule: Failed! > > Which is probably (I think) due to the old base.pp being still used > because I cannot install the new one because of this problem with > Samba script type. > > Could you suggest a path for getting out of this situation? > I've figured out that indeed my unloading of unconfined.pp was causing the problem with loading the base policy. However, copying /usr/share/selinux/targeted/unconfined.pp manually to /etc/selinux/targeted/modules/active/modules has allowed me to load the new base.pp. -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.org.pl From aleksander.adamowski.fedora at altkom.pl Mon Aug 11 14:46:06 2008 From: aleksander.adamowski.fedora at altkom.pl (Aleksander Adamowski) Date: Mon, 11 Aug 2008 16:46:06 +0200 Subject: Running a script from Samba In-Reply-To: <48A02970.8000304@altkom.pl> References: <200807181836.14111.tony.molloy@ul.ie> <4880D832.3070406@redhat.com> <48A0153C.5090008@altkom.pl> <48A02970.8000304@altkom.pl> Message-ID: <48A050AE.5040506@altkom.pl> Aleksander Adamowski wrote: > > I've figured out that indeed my unloading of unconfined.pp was causing > the problem with loading the base policy. However, copying > /usr/share/selinux/targeted/unconfined.pp manually to > /etc/selinux/targeted/modules/active/modules has allowed me to load > the new base.pp. The problem with the solution is that now I cannot "semodule -r unconfined" like Dan has advised for Fedora 8. On Fedora 9 this results in this error: # semodule -r unconfined libsepol.context_from_record: type samba_unconfined_script_exec_t is not defined libsepol.context_from_record: could not create context structure libsepol.context_from_string: could not create context structure libsepol.sepol_context_to_sid: could not convert system_u:object_r:samba_unconfined_script_exec_t:s0 to sid invalid context system_u:object_r:samba_unconfined_script_exec_t:s0 Has the procedure of removing the "unconfined" module been superseded by something else in Fedora 9? BTW, this is probably a question to Dan: is there any single place with documentation about all the changes in the SELinux policy and procedures relating to its customisation between Fedora releases? There is no such information in Fedora's release notes (where any sane being would look for them first). Currently with each Fedora Release there are numerous changes that break backward compatibility and significantly change the customisation procedures. However, I were able to find information about them only by scraping them from all around the web - from interviews with Dan Walsh, his LiveJournal blog, some random mailing list discussions, half-finished Fedora Wiki pages and so on. Am I missing something? Is there a place where comprehensive documentation for all this lies? -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.org.pl From selinux.list at troodos.demon.co.uk Tue Aug 12 16:47:19 2008 From: selinux.list at troodos.demon.co.uk (Arthur Dent) Date: Tue, 12 Aug 2008 17:47:19 +0100 Subject: Clamd getting out of hand... In-Reply-To: <4899A84B.60208@redhat.com> References: <20080727192458.GA7621@localhost.localdomain> <489087BF.2060708@redhat.com> <20080730172923.GA4400@localhost.localdomain> <4890C1FA.3030804@redhat.com> <20080806094828.GA3857@localhost.localdomain> <4899A84B.60208@redhat.com> Message-ID: <20080812164719.GA2043@localhost.localdomain> On Wed, Aug 06, 2008 at 09:34:03AM -0400, Daniel J Walsh wrote: > Arthur Dent wrote: > > On Wed, Jul 30, 2008 at 03:33:14PM -0400, Daniel J Walsh wrote: > Adding the following policy to clamscan > > mta_send_mail(clamscan_t) > corenet_all_recvfrom_unlabeled(clamscan_t) > corenet_all_recvfrom_netlabel(clamscan_t) > corenet_tcp_sendrecv_all_if(clamscan_t) > corenet_tcp_sendrecv_all_nodes(clamscan_t) > corenet_tcp_sendrecv_all_ports(clamscan_t) > corenet_tcp_sendrecv_clamd_port(clamscan_t) > corenet_tcp_connect_clamd_port(clamscan_t) > > Shoudl fix. > > Updated in selinux-policy-3.3.1-85.fc9 Hi Daniel, Thank you very much for taking the time to help me on this. This is the first chance I've had to test your policy. With setenforce set to 0 and just the above lines in my clamd policy I got 11 (eleven) AVC denials for the first inbound email. I have put all 11 AVCs (full) here: http://pastebin.com/m3126be9d Running audit2allow on those says I should also have the following policies: require { type clamscan_t; type procmail_log_t; type clamd_t; class tcp_socket { write create connect }; class file append; } require { type clamscan_t; type procmail_log_t; type clamd_t; class tcp_socket { write create connect }; class file append; } #============= clamd_t ============== corenet_tcp_bind_generic_port(clamd_t) #============= clamscan_t ============== allow clamscan_t procmail_log_t:file append; allow clamscan_t self:tcp_socket { write create connect }; corenet_tcp_connect_generic_port(clamscan_t) mta_read_queue(clamscan_t) procmail_rw_tmp_files(clamscan_t) What do you think? Thanks again... AD p.s. On Fri Aug 08 yum updated my system with selinux-policy-3.3.1-82.fc9.noarch. You say that much of the above is in 3.3.1-85. Typically how long is the gap between you releasing the policy and it getting into the repos for we mortals? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From dwalsh at redhat.com Tue Aug 12 19:31:59 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 12 Aug 2008 15:31:59 -0400 Subject: Clamd getting out of hand... In-Reply-To: <20080812164719.GA2043@localhost.localdomain> References: <20080727192458.GA7621@localhost.localdomain> <489087BF.2060708@redhat.com> <20080730172923.GA4400@localhost.localdomain> <4890C1FA.3030804@redhat.com> <20080806094828.GA3857@localhost.localdomain> <4899A84B.60208@redhat.com> <20080812164719.GA2043@localhost.localdomain> Message-ID: <48A1E52F.2050209@redhat.com> Arthur Dent wrote: > On Wed, Aug 06, 2008 at 09:34:03AM -0400, Daniel J Walsh wrote: >> Arthur Dent wrote: >>> On Wed, Jul 30, 2008 at 03:33:14PM -0400, Daniel J Walsh wrote: > > >> Adding the following policy to clamscan >> >> mta_send_mail(clamscan_t) >> corenet_all_recvfrom_unlabeled(clamscan_t) >> corenet_all_recvfrom_netlabel(clamscan_t) >> corenet_tcp_sendrecv_all_if(clamscan_t) >> corenet_tcp_sendrecv_all_nodes(clamscan_t) >> corenet_tcp_sendrecv_all_ports(clamscan_t) >> corenet_tcp_sendrecv_clamd_port(clamscan_t) >> corenet_tcp_connect_clamd_port(clamscan_t) >> >> Shoudl fix. >> >> Updated in selinux-policy-3.3.1-85.fc9 > > Hi Daniel, > > Thank you very much for taking the time to help me on this. > > This is the first chance I've had to test your policy. With setenforce > set to 0 and just the above lines in my clamd policy I got 11 (eleven) > AVC denials for the first inbound email. > > I have put all 11 AVCs (full) here: > > http://pastebin.com/m3126be9d > > > Running audit2allow on those says I should also have the following > policies: > > require { > type clamscan_t; > type procmail_log_t; > type clamd_t; > class tcp_socket { write create connect }; > class file append; > } > require { > type clamscan_t; > type procmail_log_t; > type clamd_t; > class tcp_socket { write create connect }; > class file append; > } > > #============= clamd_t ============== > corenet_tcp_bind_generic_port(clamd_t) > What port is it binding do? > #============= clamscan_t ============== > allow clamscan_t procmail_log_t:file append; Sounds ok > allow clamscan_t self:tcp_socket { write create connect }; allow clamscan_t self:tcp_socket create_stream_socket_perms; > corenet_tcp_connect_generic_port(clamscan_t) What port is it connecting to? > mta_read_queue(clamscan_t) > procmail_rw_tmp_files(clamscan_t) Ok > > What do you think? > > Thanks again... > > AD > > p.s. > > On Fri Aug 08 yum updated my system with selinux-policy-3.3.1-82.fc9.noarch. > You say that much of the above is in 3.3.1-85. Typically how long is the > gap between you releasing the policy and it getting into the repos for > we mortals? > > > > > ------------------------------------------------------------------------ > > -- > 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 Aug 12 20:23:43 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 12 Aug 2008 16:23:43 -0400 Subject: Clamd getting out of hand... In-Reply-To: <20080812164719.GA2043@localhost.localdomain> References: <20080727192458.GA7621@localhost.localdomain> <489087BF.2060708@redhat.com> <20080730172923.GA4400@localhost.localdomain> <4890C1FA.3030804@redhat.com> <20080806094828.GA3857@localhost.localdomain> <4899A84B.60208@redhat.com> <20080812164719.GA2043@localhost.localdomain> Message-ID: <48A1F14F.9000601@redhat.com> Arthur Dent wrote: > On Wed, Aug 06, 2008 at 09:34:03AM -0400, Daniel J Walsh wrote: >> Arthur Dent wrote: >>> On Wed, Jul 30, 2008 at 03:33:14PM -0400, Daniel J Walsh wrote: > > >> Adding the following policy to clamscan >> >> mta_send_mail(clamscan_t) >> corenet_all_recvfrom_unlabeled(clamscan_t) >> corenet_all_recvfrom_netlabel(clamscan_t) >> corenet_tcp_sendrecv_all_if(clamscan_t) >> corenet_tcp_sendrecv_all_nodes(clamscan_t) >> corenet_tcp_sendrecv_all_ports(clamscan_t) >> corenet_tcp_sendrecv_clamd_port(clamscan_t) >> corenet_tcp_connect_clamd_port(clamscan_t) >> >> Shoudl fix. >> >> Updated in selinux-policy-3.3.1-85.fc9 > > Hi Daniel, > > Thank you very much for taking the time to help me on this. > > This is the first chance I've had to test your policy. With setenforce > set to 0 and just the above lines in my clamd policy I got 11 (eleven) > AVC denials for the first inbound email. > > I have put all 11 AVCs (full) here: > > http://pastebin.com/m3126be9d > > > Running audit2allow on those says I should also have the following > policies: > > require { > type clamscan_t; > type procmail_log_t; > type clamd_t; > class tcp_socket { write create connect }; > class file append; > } > require { > type clamscan_t; > type procmail_log_t; > type clamd_t; > class tcp_socket { write create connect }; > class file append; > } > > #============= clamd_t ============== > corenet_tcp_bind_generic_port(clamd_t) > > #============= clamscan_t ============== > allow clamscan_t procmail_log_t:file append; > allow clamscan_t self:tcp_socket { write create connect }; > corenet_tcp_connect_generic_port(clamscan_t) > mta_read_queue(clamscan_t) > procmail_rw_tmp_files(clamscan_t) > > What do you think? > > Thanks again... > > AD > > p.s. > > On Fri Aug 08 yum updated my system with selinux-policy-3.3.1-82.fc9.noarch. > You say that much of the above is in 3.3.1-85. Typically how long is the > gap between you releasing the policy and it getting into the repos for > we mortals? > > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Usually I release about once per week. 85 should be in testing tonight. From selinux.list at troodos.demon.co.uk Tue Aug 12 21:15:50 2008 From: selinux.list at troodos.demon.co.uk (Arthur Dent) Date: Tue, 12 Aug 2008 22:15:50 +0100 Subject: Clamd getting out of hand... In-Reply-To: <48A1E52F.2050209@redhat.com> References: <20080727192458.GA7621@localhost.localdomain> <489087BF.2060708@redhat.com> <20080730172923.GA4400@localhost.localdomain> <4890C1FA.3030804@redhat.com> <20080806094828.GA3857@localhost.localdomain> <4899A84B.60208@redhat.com> <20080812164719.GA2043@localhost.localdomain> <48A1E52F.2050209@redhat.com> Message-ID: <20080812211549.GA2703@localhost.localdomain> On Tue, Aug 12, 2008 at 03:31:59PM -0400, Daniel J Walsh wrote: > Arthur Dent wrote: > > On Wed, Aug 06, 2008 at 09:34:03AM -0400, Daniel J Walsh wrote: > >> Arthur Dent wrote: > >>> On Wed, Jul 30, 2008 at 03:33:14PM -0400, Daniel J Walsh wrote: > > > > > >> Adding the following policy to clamscan > >> > >> mta_send_mail(clamscan_t) > >> corenet_all_recvfrom_unlabeled(clamscan_t) > >> corenet_all_recvfrom_netlabel(clamscan_t) > >> corenet_tcp_sendrecv_all_if(clamscan_t) > >> corenet_tcp_sendrecv_all_nodes(clamscan_t) > >> corenet_tcp_sendrecv_all_ports(clamscan_t) > >> corenet_tcp_sendrecv_clamd_port(clamscan_t) > >> corenet_tcp_connect_clamd_port(clamscan_t) > >> > >> Shoudl fix. > >> > >> Updated in selinux-policy-3.3.1-85.fc9 > > > > Hi Daniel, > > > > Thank you very much for taking the time to help me on this. > > > > This is the first chance I've had to test your policy. With setenforce > > set to 0 and just the above lines in my clamd policy I got 11 (eleven) > > AVC denials for the first inbound email. > > > > I have put all 11 AVCs (full) here: > > > > http://pastebin.com/m3126be9d > > > > > > Running audit2allow on those says I should also have the following > > policies: > > > > require { > > type clamscan_t; > > type procmail_log_t; > > type clamd_t; > > class tcp_socket { write create connect }; > > class file append; > > } > > require { > > type clamscan_t; > > type procmail_log_t; > > type clamd_t; > > class tcp_socket { write create connect }; > > class file append; > > } > > > > #============= clamd_t ============== > > corenet_tcp_bind_generic_port(clamd_t) > > > What port is it binding do? > > #============= clamscan_t ============== > > allow clamscan_t procmail_log_t:file append; > Sounds ok > > allow clamscan_t self:tcp_socket { write create connect }; > allow clamscan_t self:tcp_socket create_stream_socket_perms; > > corenet_tcp_connect_generic_port(clamscan_t) > What port is it connecting to? > > mta_read_queue(clamscan_t) > > procmail_rw_tmp_files(clamscan_t) > Ok > > > > What do you think? Daniel, thanks for your input. Much appreciated. I'm not sure I understand the inner workings of clamd, nor do I really know the difference between binding to a port and connecting to a port. I therefore list the only entries I can see in clamd.conf that relate vaguely to "ports": # # TCP port address. # Default: no TCPSocket 3310 # # TCP address. # By default we bind to INADDR_ANY, probably not wise. # Enable the following to provide some degree of protection # from the outside world. # Default: no TCPAddr 127.0.0.1 # and # # Limit port range. # Default: 1024 StreamMinPort 30000 # Default: 2048 StreamMaxPort 32000 # If you think I should change these clamd settings or modify by clamd selinux policy please let me know. Thanks again... AD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From sundaram at fedoraproject.org Wed Aug 13 03:14:03 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 13 Aug 2008 08:44:03 +0530 Subject: nspluginwrapper policy issue Message-ID: <48A2517B.3020400@fedoraproject.org> Hi, Summary: SELinux is preventing npviewer.bin (nsplugin_t) "getattr" to /dev/dri/card0 (dri_device_t). Detailed Description: SELinux denied access requested by npviewer.bin. It is not expected that this access is required by npviewer.bin and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /dev/dri/card0, restorecon -v '/dev/dri/card0' 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:s0-s0:c0.c102 3 Target Context system_u:object_r:dri_device_t:s0 Target Objects /dev/dri/card0 [ chr_file ] Source npviewer.bin Source Path /usr/lib/nspluginwrapper/npviewer.bin Port Host localhost.localdomain Source RPM Packages nspluginwrapper-1.1.0-5.fc10 Target RPM Packages Policy RPM selinux-policy-3.5.1-4.fc10 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.27-0.244.rc2.git1.fc10.i686 #1 SMP Fri Aug 8 13:26:20 EDT 2008 i686 i686 Alert Count 200 First Seen Wed 13 Aug 2008 12:46:15 AM IST Last Seen Wed 13 Aug 2008 02:22:02 AM IST Local ID de968e68-bfda-46a2-b7bb-624dd3967d16 Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1218574322.776:773): avc: denied { getattr } for pid=12887 comm="npviewer.bin" path="/dev/dri/card0" dev=tmpfs ino=9434 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dri_device_t:s0 tclass=chr_file host=localhost.localdomain type=SYSCALL msg=audit(1218574322.776:773): arch=40000003 syscall=195 success=no exit=-13 a0=bfccaed4 a1=bfccae60 a2=6c7ff4 a3=32 items=0 ppid=14557 pid=12887 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) Rahul From sundaram at fedoraproject.org Wed Aug 13 03:14:30 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 13 Aug 2008 08:44:30 +0530 Subject: Exim policy issue Message-ID: <48A25196.6040706@fedoraproject.org> Hi Summary: SELinux is preventing exim (exim_t) "read" to inotify (inotifyfs_t). Detailed Description: SELinux denied access requested by exim. It is not expected that this access is required by exim and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for inotify, restorecon -v 'inotify' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:exim_t:s0-s0:c0.c1023 Target Context system_u:object_r:inotifyfs_t:s0 Target Objects inotify [ dir ] Source exim Source Path /usr/sbin/exim Port Host localhost.localdomain Source RPM Packages exim-4.69-5.fc10 Target RPM Packages Policy RPM selinux-policy-3.5.1-4.fc10 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.27-0.244.rc2.git1.fc10.i686 #1 SMP Fri Aug 8 13:26:20 EDT 2008 i686 i686 Alert Count 3 First Seen Mon 11 Aug 2008 04:02:14 AM IST Last Seen Wed 13 Aug 2008 04:02:11 AM IST Local ID 746dedc0-e321-48a0-8649-29a02d459530 Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1218580331.174:832): avc: denied { read } for pid=17565 comm="exim" path="inotify" dev=inotifyfs ino=1 scontext=system_u:system_r:exim_t:s0-s0:c0.c1023 tcontext=system_u:object_r:inotifyfs_t:s0 tclass=dir host=localhost.localdomain type=SYSCALL msg=audit(1218580331.174:832): arch=40000003 syscall=11 success=yes exit=0 a0=b80d5424 a1=b9a93548 a2=bfbf5330 a3=1 items=0 ppid=1 pid=17565 auid=0 uid=93 gid=93 euid=0 suid=0 fsuid=0 egid=93 sgid=93 fsgid=93 tty=(none) ses=37 comm="exim" exe="/usr/sbin/exim" subj=system_u:system_r:exim_t:s0-s0:c0.c1023 key=(null) Rahul From sundaram at fedoraproject.org Wed Aug 13 03:15:04 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 13 Aug 2008 08:45:04 +0530 Subject: Realplayer problem Message-ID: <48A251B8.5080906@fedoraproject.org> Hi Summary: SELinux is preventing the plugin-config (nsplugin_config_t) from executing /opt/real/RealPlayer/mozilla/nphelix.so. Detailed Description: SELinux has denied the plugin-config from executing /opt/real/RealPlayer/mozilla/nphelix.so. If plugin-config is supposed to be able to execute /opt/real/RealPlayer/mozilla/nphelix.so, 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 plugin-config is not supposed to execute /opt/real/RealPlayer/mozilla/nphelix.so, this could signal a intrusion attempt. Allowing Access: If you want to allow plugin-config to execute /opt/real/RealPlayer/mozilla/nphelix.so: chcon -t bin_t '/opt/real/RealPlayer/mozilla/nphelix.so' If this fix works, please update the file context on disk, with the following command: semanage fcontext -a -t bin_t '/opt/real/RealPlayer/mozilla/nphelix.so' 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 unconfined_u:unconfined_r:nsplugin_config_t:s0-s0: c0.c1023 Target Context system_u:object_r:usr_t:s0 Target Objects /opt/real/RealPlayer/mozilla/nphelix.so [ file ] Source plugin-config Source Path /usr/lib/nspluginwrapper/plugin-config Port Host localhost.localdomain Source RPM Packages nspluginwrapper-1.1.0-5.fc10 Target RPM Packages RealPlayer-11.0.0.4028-20080225 Policy RPM selinux-policy-3.5.1-4.fc10 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name execute Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.27-0.244.rc2.git1.fc10.i686 #1 SMP Fri Aug 8 13:26:20 EDT 2008 i686 i686 Alert Count 104 First Seen Sat 09 Aug 2008 06:54:03 PM IST Last Seen Wed 13 Aug 2008 07:51:33 AM IST Local ID c324c12a-83ab-424c-bf42-85849f4f3fba Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1218594093.968:857): avc: denied { execute } for pid=28902 comm="plugin-config" path="/opt/real/RealPlayer/mozilla/nphelix.so" dev=dm-1 ino=1785954 scontext=unconfined_u:unconfined_r:nsplugin_config_t:s0-s0:c0.c1023 tcontext=system_u:object_r:usr_t:s0 tclass=file host=localhost.localdomain type=SYSCALL msg=audit(1218594093.968:857): arch=40000003 syscall=192 success=no exit=-13 a0=0 a1=9eec a2=5 a3=802 items=0 ppid=28900 pid=28902 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) Rahul From kaigai at ak.jp.nec.com Wed Aug 13 08:33:52 2008 From: kaigai at ak.jp.nec.com (KaiGai Kohei) Date: Wed, 13 Aug 2008 17:33:52 +0900 Subject: [BUG] legacy typenames of se-postgresql still remain Message-ID: <48A29C70.6040107@ak.jp.nec.com> I got the following access denied logs, when I tries to connect SE-PostgreSQL (postgresql_t) from PHP script (httpd_t) via unix domain socket (/tmp/.s.PGSQL.5432). type=AVC msg=audit(1218613044.484:10388): avc: denied { write } for pid=4805 comm="httpd" name=".s.PGSQL.5432" dev=sda6 ino=1079246 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:postgresql_tmp_t:s0 tclass=sock_file type=AVC msg=audit(1218613044.484:10388): avc: denied { connectto } for pid=4805 comm="httpd" path="/tmp/.s.PGSQL.5432" scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:system_r:postgresql_t:s0 tclass=unix_stream_socket However, both permissions are allowed via postgresql_stream_connect() independent from any booleans, if required types are provided by postgresql.te. postgresql_stream_connect() and postgresql_unpriv_client() are put within same optional_policy section at apache.te. postgresql_unpriv_client() requires trusted procedure related types, but postgresql.te declares them in legacy names. old: sepgsql_trusted_domain_t --> new: sepgsql_trusted_proc_t old: sepgsql_trusted_proc_t --> new: sepgsql_trusted_proc_exec_t Could you apply the attached patch? It fixes them as upstream doing. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei -------------- next part -------------- A non-text attachment was scrubbed... Name: selinux-policy-3.5.1-sepgsql-fixes.patch Type: text/x-patch Size: 1049 bytes Desc: not available URL: From kaigai at ak.jp.nec.com Wed Aug 13 09:25:32 2008 From: kaigai at ak.jp.nec.com (KaiGai Kohei) Date: Wed, 13 Aug 2008 18:25:32 +0900 Subject: [BUG] legacy typenames of se-postgresql still remain In-Reply-To: <48A29C70.6040107@ak.jp.nec.com> References: <48A29C70.6040107@ak.jp.nec.com> Message-ID: <48A2A88C.70006@ak.jp.nec.com> Sorry, the previous patch was imcomplete one. We allows sepgsql_client_type and sepgsql_unconfined_type to invoke sepgsql_trusted_proc_t, but it should be sepgsql_trusted_proc_exec_t, because sepgsql_trusted_proc_t is a domain. This matter also exists at upstreamed policy now. The attached "refpolicy-sepgsql-trusted-proc-fixes.patch" can be applied to upstreamed reference policy. Thanks, KaiGai Kohei wrote: > I got the following access denied logs, when I tries to connect > SE-PostgreSQL (postgresql_t) from PHP script (httpd_t) via unix > domain socket (/tmp/.s.PGSQL.5432). > > type=AVC msg=audit(1218613044.484:10388): avc: denied { write } > for pid=4805 comm="httpd" name=".s.PGSQL.5432" dev=sda6 ino=1079246 > scontext=unconfined_u:system_r:httpd_t:s0 > tcontext=unconfined_u:object_r:postgresql_tmp_t:s0 > tclass=sock_file > type=AVC msg=audit(1218613044.484:10388): avc: denied { connectto } > for pid=4805 comm="httpd" path="/tmp/.s.PGSQL.5432" > scontext=unconfined_u:system_r:httpd_t:s0 > tcontext=unconfined_u:system_r:postgresql_t:s0 > tclass=unix_stream_socket > > However, both permissions are allowed via postgresql_stream_connect() > independent from any booleans, if required types are provided by > postgresql.te. > > postgresql_stream_connect() and postgresql_unpriv_client() are put > within same optional_policy section at apache.te. > postgresql_unpriv_client() requires trusted procedure related types, > but postgresql.te declares them in legacy names. > > old: sepgsql_trusted_domain_t --> new: sepgsql_trusted_proc_t > old: sepgsql_trusted_proc_t --> new: sepgsql_trusted_proc_exec_t > > Could you apply the attached patch? > It fixes them as upstream doing. > > Thanks, > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -- OSS Platform Development Division, NEC KaiGai Kohei -------------- next part -------------- A non-text attachment was scrubbed... Name: selinux-policy-3.5.1-sepgsql-fixes.2.patch Type: text/x-patch Size: 2177 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: refpolicy-sepgsql-trusted-proc-fixes.patch Type: text/x-patch Size: 1304 bytes Desc: not available URL: From dwalsh at redhat.com Wed Aug 13 16:35:55 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 13 Aug 2008 12:35:55 -0400 Subject: [BUG] legacy typenames of se-postgresql still remain In-Reply-To: <48A2A88C.70006@ak.jp.nec.com> References: <48A29C70.6040107@ak.jp.nec.com> <48A2A88C.70006@ak.jp.nec.com> Message-ID: <48A30D6B.6010609@redhat.com> KaiGai Kohei wrote: > Sorry, the previous patch was imcomplete one. > > We allows sepgsql_client_type and sepgsql_unconfined_type to invoke > sepgsql_trusted_proc_t, but it should be sepgsql_trusted_proc_exec_t, > because sepgsql_trusted_proc_t is a domain. > > This matter also exists at upstreamed policy now. > The attached "refpolicy-sepgsql-trusted-proc-fixes.patch" can be applied > to upstreamed reference policy. > > Thanks, > > KaiGai Kohei wrote: >> I got the following access denied logs, when I tries to connect >> SE-PostgreSQL (postgresql_t) from PHP script (httpd_t) via unix >> domain socket (/tmp/.s.PGSQL.5432). >> >> type=AVC msg=audit(1218613044.484:10388): avc: denied { write } >> for pid=4805 comm="httpd" name=".s.PGSQL.5432" dev=sda6 ino=1079246 >> scontext=unconfined_u:system_r:httpd_t:s0 >> tcontext=unconfined_u:object_r:postgresql_tmp_t:s0 >> tclass=sock_file >> type=AVC msg=audit(1218613044.484:10388): avc: denied { connectto } >> for pid=4805 comm="httpd" path="/tmp/.s.PGSQL.5432" >> scontext=unconfined_u:system_r:httpd_t:s0 >> tcontext=unconfined_u:system_r:postgresql_t:s0 >> tclass=unix_stream_socket >> >> However, both permissions are allowed via postgresql_stream_connect() >> independent from any booleans, if required types are provided by >> postgresql.te. >> >> postgresql_stream_connect() and postgresql_unpriv_client() are put >> within same optional_policy section at apache.te. >> postgresql_unpriv_client() requires trusted procedure related types, >> but postgresql.te declares them in legacy names. >> >> old: sepgsql_trusted_domain_t --> new: sepgsql_trusted_proc_t >> old: sepgsql_trusted_proc_t --> new: sepgsql_trusted_proc_exec_t >> >> Could you apply the attached patch? >> It fixes them as upstream doing. >> >> Thanks, >> >> >> ------------------------------------------------------------------------ >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Fedora 9? Rawhide? From dwalsh at redhat.com Wed Aug 13 17:27:06 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 13 Aug 2008 13:27:06 -0400 Subject: nspluginwrapper policy issue In-Reply-To: <48A2517B.3020400@fedoraproject.org> References: <48A2517B.3020400@fedoraproject.org> Message-ID: <48A3196A.9060902@redhat.com> Rahul Sundaram wrote: > Hi, > > > Summary: > > SELinux is preventing npviewer.bin (nsplugin_t) "getattr" to /dev/dri/card0 > (dri_device_t). > > Detailed Description: > > SELinux denied access requested by npviewer.bin. It is not expected that > this > access is required by npviewer.bin and this access may signal an intrusion > attempt. It is also possible that the specific version or configuration > of the > application is causing it to require additional access. > > Allowing Access: > > Sometimes labeling problems can cause SELinux denials. You could try to > restore > the default system file context for /dev/dri/card0, > > restorecon -v '/dev/dri/card0' > > 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:s0-s0:c0.c102 > 3 > Target Context system_u:object_r:dri_device_t:s0 > Target Objects /dev/dri/card0 [ chr_file ] > Source npviewer.bin > Source Path /usr/lib/nspluginwrapper/npviewer.bin > Port > Host localhost.localdomain > Source RPM Packages nspluginwrapper-1.1.0-5.fc10 > Target RPM Packages > Policy RPM selinux-policy-3.5.1-4.fc10 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name catchall_file > Host Name localhost.localdomain > Platform Linux localhost.localdomain > 2.6.27-0.244.rc2.git1.fc10.i686 #1 SMP Fri > Aug 8 > 13:26:20 EDT 2008 i686 i686 > Alert Count 200 > First Seen Wed 13 Aug 2008 12:46:15 AM IST > Last Seen Wed 13 Aug 2008 02:22:02 AM IST > Local ID de968e68-bfda-46a2-b7bb-624dd3967d16 > Line Numbers > > Raw Audit Messages > > host=localhost.localdomain type=AVC msg=audit(1218574322.776:773): avc: > denied { getattr } for pid=12887 comm="npviewer.bin" > path="/dev/dri/card0" dev=tmpfs ino=9434 > scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:dri_device_t:s0 tclass=chr_file > > host=localhost.localdomain type=SYSCALL msg=audit(1218574322.776:773): > arch=40000003 syscall=195 success=no exit=-13 a0=bfccaed4 a1=bfccae60 > a2=6c7ff4 a3=32 items=0 ppid=14557 pid=12887 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) > > Rahul > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Do you think it will need to read/write this device? From sundaram at fedoraproject.org Wed Aug 13 17:29:11 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 13 Aug 2008 22:59:11 +0530 Subject: nspluginwrapper policy issue In-Reply-To: <48A3196A.9060902@redhat.com> References: <48A2517B.3020400@fedoraproject.org> <48A3196A.9060902@redhat.com> Message-ID: <48A319E7.70600@fedoraproject.org> Daniel J Walsh wrote: > Rahul Sundaram wrote: >> Hi, >> >> >> Summary: >> >> SELinux is preventing npviewer.bin (nsplugin_t) "getattr" to /dev/dri/card0 >> (dri_device_t). >> > Do you think it will need to read/write this device? Sorry. I have no idea why it would and if that is a valid thing to do or not. Rahul From ivazqueznet at gmail.com Wed Aug 13 18:42:57 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Wed, 13 Aug 2008 14:42:57 -0400 Subject: nspluginwrapper policy issue In-Reply-To: <48A319E7.70600@fedoraproject.org> References: <48A2517B.3020400@fedoraproject.org> <48A3196A.9060902@redhat.com> <48A319E7.70600@fedoraproject.org> Message-ID: <1218652977.11246.15.camel@ignacio.lan> On Wed, 2008-08-13 at 22:59 +0530, Rahul Sundaram wrote: > Daniel J Walsh wrote: > > Rahul Sundaram wrote: > >> Hi, > >> > >> > >> Summary: > >> > >> SELinux is preventing npviewer.bin (nsplugin_t) "getattr" to /dev/dri/card0 > >> (dri_device_t). > >> > > Do you think it will need to read/write this device? > > Sorry. I have no idea why it would and if that is a valid thing to do or > not. It just might... http://labs.adobe.com/technologies/flashplayer10/ -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- 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 Wed Aug 13 18:48:01 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 13 Aug 2008 14:48:01 -0400 Subject: Clamd getting out of hand... In-Reply-To: <20080812211549.GA2703@localhost.localdomain> References: <20080727192458.GA7621@localhost.localdomain> <489087BF.2060708@redhat.com> <20080730172923.GA4400@localhost.localdomain> <4890C1FA.3030804@redhat.com> <20080806094828.GA3857@localhost.localdomain> <4899A84B.60208@redhat.com> <20080812164719.GA2043@localhost.localdomain> <48A1E52F.2050209@redhat.com> <20080812211549.GA2703@localhost.localdomain> Message-ID: <48A32C61.8080604@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Arthur Dent wrote: > On Tue, Aug 12, 2008 at 03:31:59PM -0400, Daniel J Walsh wrote: >> Arthur Dent wrote: >>> On Wed, Aug 06, 2008 at 09:34:03AM -0400, Daniel J Walsh wrote: >>>> Arthur Dent wrote: >>>>> On Wed, Jul 30, 2008 at 03:33:14PM -0400, Daniel J Walsh wrote: >>> >>>> Adding the following policy to clamscan >>>> >>>> mta_send_mail(clamscan_t) >>>> corenet_all_recvfrom_unlabeled(clamscan_t) >>>> corenet_all_recvfrom_netlabel(clamscan_t) >>>> corenet_tcp_sendrecv_all_if(clamscan_t) >>>> corenet_tcp_sendrecv_all_nodes(clamscan_t) >>>> corenet_tcp_sendrecv_all_ports(clamscan_t) >>>> corenet_tcp_sendrecv_clamd_port(clamscan_t) >>>> corenet_tcp_connect_clamd_port(clamscan_t) >>>> >>>> Shoudl fix. >>>> >>>> Updated in selinux-policy-3.3.1-85.fc9 >>> Hi Daniel, >>> >>> Thank you very much for taking the time to help me on this. >>> >>> This is the first chance I've had to test your policy. With setenforce >>> set to 0 and just the above lines in my clamd policy I got 11 (eleven) >>> AVC denials for the first inbound email. >>> >>> I have put all 11 AVCs (full) here: >>> >>> http://pastebin.com/m3126be9d >>> >>> >>> Running audit2allow on those says I should also have the following >>> policies: >>> >>> require { >>> type clamscan_t; >>> type procmail_log_t; >>> type clamd_t; >>> class tcp_socket { write create connect }; >>> class file append; >>> } >>> require { >>> type clamscan_t; >>> type procmail_log_t; >>> type clamd_t; >>> class tcp_socket { write create connect }; >>> class file append; >>> } >>> >>> #============= clamd_t ============== >>> corenet_tcp_bind_generic_port(clamd_t) >>> >> What port is it binding do? >>> #============= clamscan_t ============== >>> allow clamscan_t procmail_log_t:file append; >> Sounds ok >>> allow clamscan_t self:tcp_socket { write create connect }; >> allow clamscan_t self:tcp_socket create_stream_socket_perms; >>> corenet_tcp_connect_generic_port(clamscan_t) >> What port is it connecting to? >>> mta_read_queue(clamscan_t) >>> procmail_rw_tmp_files(clamscan_t) >> Ok >>> What do you think? > > Daniel, thanks for your input. Much appreciated. > > I'm not sure I understand the inner workings of clamd, nor do I really > know the difference between binding to a port and connecting to a port. > I therefore list the only entries I can see in clamd.conf that relate > vaguely to "ports": > > # > # TCP port address. > # Default: no > TCPSocket 3310 > # > # TCP address. > # By default we bind to INADDR_ANY, probably not wise. > # Enable the following to provide some degree of protection > # from the outside world. > # Default: no > TCPAddr 127.0.0.1 > # > > and > > # > # Limit port range. > # Default: 1024 > StreamMinPort 30000 > # Default: 2048 > StreamMaxPort 32000 > # > > If you think I should change these clamd settings or modify by clamd > selinux policy please let me know. > > Thanks again... > > AD > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list No if you look at the avc message that referred to port_t there is a src or dest field. This is the number of the port that clamd tried to connect listened for incoming connections on. network_port(clamd, tcp,3310,s0) Is already in policy so it must be another port. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkijLGEACgkQrlYvE4MpobM/TgCgpu/XiHVkvdz0nKIY20wOfXYg ojkAoM63/HUYya2L5M3DlN0Yjf5f/cT3 =3Y5G -----END PGP SIGNATURE----- From Richard.Johnson at stratus.com Wed Aug 13 19:06:20 2008 From: Richard.Johnson at stratus.com (Johnson, Richard) Date: Wed, 13 Aug 2008 15:06:20 -0400 Subject: file contexts change on reboot Message-ID: I'm not sure, but I think I'm hitting a precedence issue which is causing files to be relabeled on boot. The symptom is: root at lstlinux57 13:32:21 ~> restorecon -R /var/opt/ft/log root at lstlinux57 13:32:28 ~> ls -lZ /var/opt/ft/log/libft_sra_alarm_server.log -rw------- root root system_u:object_r:lsb-ft-asn_rw_t /var/opt/ft/log/libft_sra_alarm_server.log root at lstlinux57 13:32:36 ~> init 6 root at lstlinux57 13:32:40 ~> logout Connection to 134.111.82.122 closed. bash-3.1$ ssh 134.111.82.122 -l root root at 134.111.82.122's password: Last login: Wed Aug 13 13:08:02 2008 from rjlinux2.mno.stratus.com root at lstlinux57 13:39:22 ~> ls -lZ /var/opt/ft/log/libft_sra_alarm_server.log -rw------- root root system_u:object_r:var_log_t /var/opt/ft/log/libft_sra_alarm_server.log root at lstlinux57 13:39:24 ~> restorecon -R /var/opt/ft/log root at lstlinux57 13:39:45 ~> ls -lZ /var/opt/ft/log/libft_sra_alarm_server.log -rw------- root root system_u:object_r:lsb-ft-asn_rw_t /var/opt/ft/log/libft_sra_alarm_server.log The situation is a standard RHEL5.2 with all errata applied; plus the following modifications I have a local policy modification introduced by one rpm: /usr/sbin/semanage fcontext -a -t var_log_t -s system_u '/var/opt/ft/log' And a separate policy module containing: /var/opt/ft/log/libft_.* -- gen_context(system_u:object_r:lsb-ft-asn_rw_t,s0) The net result is: root at lstlinux57 14:56:56 ~> semanage fcontext -l | grep '/opt/ft' /var/opt/ft/asn(/.*)? all files system_u:object_r:lsb-ft-asn_rw_t:s0 /var/opt/ft/log/libft_.* regular file system_u:object_r:lsb-ft-asn_rw_t:s0 /opt/ft/sbin/sra_alarm regular file system_u:object_r:lsb-ft-asn_exec_t:s0 /etc/opt/ft/asn/sra_ppp/ASN_CallHome regular file system_u:object_r:lsb-ft-asn_script_t:s0 /etc/opt/ft/asn/sra_ppp/SetUPCallHome regular file system_u:object_r:lsb-ft-asn_script_t:s0 /var/opt/ft/log all files system_u:object_r:var_log_t:s0 /var/opt/ft/log/snmpd\.log all files system_u:object_r:snmpd_log_t:s0 I suspect that the problem lies with the ordering of those '/var/opt/ft/log' lines. Am I on the right track? How can I sort things out? Thx, --rich From dwalsh at redhat.com Wed Aug 13 19:15:41 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 13 Aug 2008 15:15:41 -0400 Subject: file contexts change on reboot In-Reply-To: References: Message-ID: <48A332DD.3010709@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johnson, Richard wrote: > I'm not sure, but I think I'm hitting a precedence issue which is > causing files to be relabeled on boot. The symptom is: > > root at lstlinux57 13:32:21 ~> restorecon -R /var/opt/ft/log > root at lstlinux57 13:32:28 ~> ls -lZ > /var/opt/ft/log/libft_sra_alarm_server.log > -rw------- root root system_u:object_r:lsb-ft-asn_rw_t > /var/opt/ft/log/libft_sra_alarm_server.log > root at lstlinux57 13:32:36 ~> init 6 > root at lstlinux57 13:32:40 ~> logout > > Connection to 134.111.82.122 closed. > bash-3.1$ ssh 134.111.82.122 -l root > root at 134.111.82.122's password: > Last login: Wed Aug 13 13:08:02 2008 from rjlinux2.mno.stratus.com > root at lstlinux57 13:39:22 ~> ls -lZ > /var/opt/ft/log/libft_sra_alarm_server.log > -rw------- root root system_u:object_r:var_log_t > /var/opt/ft/log/libft_sra_alarm_server.log > root at lstlinux57 13:39:24 ~> restorecon -R /var/opt/ft/log > root at lstlinux57 13:39:45 ~> ls -lZ > /var/opt/ft/log/libft_sra_alarm_server.log > -rw------- root root system_u:object_r:lsb-ft-asn_rw_t > /var/opt/ft/log/libft_sra_alarm_server.log > > > The situation is a standard RHEL5.2 with all errata applied; plus the > following modifications > > I have a local policy modification introduced by one rpm: > > /usr/sbin/semanage fcontext -a -t var_log_t -s system_u > '/var/opt/ft/log' > > And a separate policy module containing: > > /var/opt/ft/log/libft_.* -- > gen_context(system_u:object_r:lsb-ft-asn_rw_t,s0) > > The net result is: > > root at lstlinux57 14:56:56 ~> semanage fcontext -l | grep '/opt/ft' > > /var/opt/ft/asn(/.*)? all files > system_u:object_r:lsb-ft-asn_rw_t:s0 > /var/opt/ft/log/libft_.* regular file > system_u:object_r:lsb-ft-asn_rw_t:s0 > /opt/ft/sbin/sra_alarm regular file > system_u:object_r:lsb-ft-asn_exec_t:s0 > /etc/opt/ft/asn/sra_ppp/ASN_CallHome regular file > system_u:object_r:lsb-ft-asn_script_t:s0 > /etc/opt/ft/asn/sra_ppp/SetUPCallHome regular file > system_u:object_r:lsb-ft-asn_script_t:s0 > /var/opt/ft/log all files > system_u:object_r:var_log_t:s0 > /var/opt/ft/log/snmpd\.log all files > system_u:object_r:snmpd_log_t:s0 > > I suspect that the problem lies with the ordering of those > '/var/opt/ft/log' lines. Am I on the right track? How can I sort > things out? > > Thx, > --rich > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list The file libft_sra_alarm_server.log is being created on boot probably by an init script or by the executable. Since the parent directory is labeled var_log_t it gets that context. If you run restorecon the context will get set correctly. If all the files in this directory are supposed to be system_u:object_r:lsb-ft-asn_rw_t:s0 Then you should label /usr/sbin/semanage fcontext -a -t lsb-ft-asn_rw_t -s system_u '/var/opt/ft/log(/.*)' If you need other files in that directory labeled differently you might want to move your log files to a subdir and label that one. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkijMt0ACgkQrlYvE4MpobMcywCcCoNfb+yGutLnFOdB697NfK2q gMwAn1AudcCj4ORA8acEa3NsM0Yj4KHd =+wXT -----END PGP SIGNATURE----- From dwalsh at redhat.com Wed Aug 13 19:16:17 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 13 Aug 2008 15:16:17 -0400 Subject: Running a script from Samba In-Reply-To: <48A050AE.5040506@altkom.pl> References: <200807181836.14111.tony.molloy@ul.ie> <4880D832.3070406@redhat.com> <48A0153C.5090008@altkom.pl> <48A02970.8000304@altkom.pl> <48A050AE.5040506@altkom.pl> Message-ID: <48A33301.7020003@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aleksander Adamowski wrote: > Aleksander Adamowski wrote: >> >> I've figured out that indeed my unloading of unconfined.pp was causing >> the problem with loading the base policy. However, copying >> /usr/share/selinux/targeted/unconfined.pp manually to >> /etc/selinux/targeted/modules/active/modules has allowed me to load >> the new base.pp. > The problem with the solution is that now I cannot "semodule -r > unconfined" like Dan has advised for Fedora 8. > On Fedora 9 this results in this error: > > # semodule -r unconfined > libsepol.context_from_record: type samba_unconfined_script_exec_t is not > defined > libsepol.context_from_record: could not create context structure > libsepol.context_from_string: could not create context structure > libsepol.sepol_context_to_sid: could not convert > system_u:object_r:samba_unconfined_script_exec_t:s0 to sid > invalid context system_u:object_r:samba_unconfined_script_exec_t:s0 > > Has the procedure of removing the "unconfined" module been superseded by > something else in Fedora 9? > > BTW, this is probably a question to Dan: is there any single place with > documentation about all the changes in the SELinux policy and procedures > relating to its customisation between Fedora releases? There is no such > information in Fedora's release notes (where any sane being would look > for them first). > > Currently with each Fedora Release there are numerous changes that break > backward compatibility and significantly change the customisation > procedures. However, I were able to find information about them only by > scraping them from all around the web - from interviews with Dan Walsh, > his LiveJournal blog, some random mailing list discussions, > half-finished Fedora Wiki pages and so on. Am I missing something? > Is there a place where comprehensive documentation for all this lies? > > I am fixing this in policy so you can remove the unconfined_domain. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkijMwEACgkQrlYvE4MpobNNGACfUJzZWk6p8yNz7FmoJX48fWOa DK4AoIO3MV4oZUjiCgAV8P17DqKOjuzh =22eQ -----END PGP SIGNATURE----- From dwalsh at redhat.com Wed Aug 13 19:17:09 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 13 Aug 2008 15:17:09 -0400 Subject: Clamd getting out of hand... In-Reply-To: <20080812211549.GA2703@localhost.localdomain> References: <20080727192458.GA7621@localhost.localdomain> <489087BF.2060708@redhat.com> <20080730172923.GA4400@localhost.localdomain> <4890C1FA.3030804@redhat.com> <20080806094828.GA3857@localhost.localdomain> <4899A84B.60208@redhat.com> <20080812164719.GA2043@localhost.localdomain> <48A1E52F.2050209@redhat.com> <20080812211549.GA2703@localhost.localdomain> Message-ID: <48A33335.90601@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Arthur Dent wrote: > On Tue, Aug 12, 2008 at 03:31:59PM -0400, Daniel J Walsh wrote: >> Arthur Dent wrote: >>> On Wed, Aug 06, 2008 at 09:34:03AM -0400, Daniel J Walsh wrote: >>>> Arthur Dent wrote: >>>>> On Wed, Jul 30, 2008 at 03:33:14PM -0400, Daniel J Walsh wrote: >>> >>>> Adding the following policy to clamscan >>>> >>>> mta_send_mail(clamscan_t) >>>> corenet_all_recvfrom_unlabeled(clamscan_t) >>>> corenet_all_recvfrom_netlabel(clamscan_t) >>>> corenet_tcp_sendrecv_all_if(clamscan_t) >>>> corenet_tcp_sendrecv_all_nodes(clamscan_t) >>>> corenet_tcp_sendrecv_all_ports(clamscan_t) >>>> corenet_tcp_sendrecv_clamd_port(clamscan_t) >>>> corenet_tcp_connect_clamd_port(clamscan_t) >>>> >>>> Shoudl fix. >>>> >>>> Updated in selinux-policy-3.3.1-85.fc9 >>> Hi Daniel, >>> >>> Thank you very much for taking the time to help me on this. >>> >>> This is the first chance I've had to test your policy. With setenforce >>> set to 0 and just the above lines in my clamd policy I got 11 (eleven) >>> AVC denials for the first inbound email. >>> >>> I have put all 11 AVCs (full) here: >>> >>> http://pastebin.com/m3126be9d >>> >>> >>> Running audit2allow on those says I should also have the following >>> policies: >>> >>> require { >>> type clamscan_t; >>> type procmail_log_t; >>> type clamd_t; >>> class tcp_socket { write create connect }; >>> class file append; >>> } >>> require { >>> type clamscan_t; >>> type procmail_log_t; >>> type clamd_t; >>> class tcp_socket { write create connect }; >>> class file append; >>> } >>> >>> #============= clamd_t ============== >>> corenet_tcp_bind_generic_port(clamd_t) >>> >> What port is it binding do? >>> #============= clamscan_t ============== >>> allow clamscan_t procmail_log_t:file append; >> Sounds ok >>> allow clamscan_t self:tcp_socket { write create connect }; >> allow clamscan_t self:tcp_socket create_stream_socket_perms; >>> corenet_tcp_connect_generic_port(clamscan_t) >> What port is it connecting to? >>> mta_read_queue(clamscan_t) >>> procmail_rw_tmp_files(clamscan_t) >> Ok >>> What do you think? > > Daniel, thanks for your input. Much appreciated. > > I'm not sure I understand the inner workings of clamd, nor do I really > know the difference between binding to a port and connecting to a port. > I therefore list the only entries I can see in clamd.conf that relate > vaguely to "ports": > > # > # TCP port address. > # Default: no > TCPSocket 3310 > # > # TCP address. > # By default we bind to INADDR_ANY, probably not wise. > # Enable the following to provide some degree of protection > # from the outside world. > # Default: no > TCPAddr 127.0.0.1 > # > > and > > # > # Limit port range. > # Default: 1024 > StreamMinPort 30000 > # Default: 2048 > StreamMaxPort 32000 > # > > If you think I should change these clamd settings or modify by clamd > selinux policy please let me know. > > Thanks again... > > AD > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list After a little more investigation, I will allow clamd to bind and connect to unreserved_ports which should fix the problem. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkijMzQACgkQrlYvE4MpobOmUgCgtyPGApKW1HFUxI6qW3uZf88p KKYAoM5CMpBMHkpmawMPDP/5+AHjmJ5h =J5jZ -----END PGP SIGNATURE----- From Richard.Johnson at stratus.com Wed Aug 13 19:53:22 2008 From: Richard.Johnson at stratus.com (Johnson, Richard) Date: Wed, 13 Aug 2008 15:53:22 -0400 Subject: file contexts change on reboot In-Reply-To: 48A332DD.3010709@redhat.com References: 48A332DD.3010709@redhat.com Message-ID: Daniel J Walsh wrote: >Johnson, Richard wrote: >> I'm not sure, but I think I'm hitting a precedence issue which is >> causing files to be relabeled on boot. The symptom is: >> >> root at lstlinux57 13:32:21 ~> restorecon -R /var/opt/ft/log >> root at lstlinux57 13:32:28 ~> ls -lZ >> /var/opt/ft/log/libft_sra_alarm_server.log >> -rw------- root root system_u:object_r:lsb-ft-asn_rw_t >> /var/opt/ft/log/libft_sra_alarm_server.log >> root at lstlinux57 13:32:36 ~> init 6 >> root at lstlinux57 13:32:40 ~> logout >> >> Connection to 134.111.82.122 closed. >> bash-3.1$ ssh 134.111.82.122 -l root >> root at 134.111.82.122's password: >> Last login: Wed Aug 13 13:08:02 2008 from rjlinux2.mno.stratus.com >> root at lstlinux57 13:39:22 ~> ls -l >>/var/opt/ft/log/libft_sra_alarm_server.log >> -rw------- root root system_u:object_r:var_log_t >> /var/opt/ft/log/libft_sra_alarm_server.log >> root at lstlinux57 13:39:24 ~> restorecon -R /var/opt/ft/log >> root at lstlinux57 13:39:45 ~> ls -lZ >> /var/opt/ft/log/libft_sra_alarm_server.log >> -rw------- root root system_u:object_r:lsb-ft-asn_rw_t >> /var/opt/ft/log/libft_sra_alarm_server.log >> >> >> The situation is a standard RHEL5.2 with all errata applied; plus the [...snip for brevity...] > >The file libft_sra_alarm_server.log is being created on boot probably by >an init script or by the executable. Since the parent directory is >labeled var_log_t it gets that context. If you run restorecon the >context will get set correctly. > >If all the files in this directory are supposed to be >system_u:object_r:lsb-ft-asn_rw_t:s0 > >Then you should label > > /usr/sbin/semanage fcontext -a -t lsb-ft-asn_rw_t -s system_u >'/var/opt/ft/log(/.*)' > >If you need other files in that directory labeled differently you might >want to move your log files to a subdir and label that one. Yes this log (among others) is created by a daemon started from an init script. I will investigate moving the logs to a sub-dir. But for historical and support reasons I'd prefer to leave them where they are. Is there a way for the daemon to create the files with the appropriate label from the get-go? --rich From dwalsh at redhat.com Wed Aug 13 20:11:11 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 13 Aug 2008 16:11:11 -0400 Subject: file contexts change on reboot In-Reply-To: References: 48A332DD.3010709@redhat.com Message-ID: <48A33FDF.60005@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johnson, Richard wrote: > > Daniel J Walsh wrote: >> Johnson, Richard wrote: >>> I'm not sure, but I think I'm hitting a precedence issue which is >>> causing files to be relabeled on boot. The symptom is: >>> >>> root at lstlinux57 13:32:21 ~> restorecon -R /var/opt/ft/log >>> root at lstlinux57 13:32:28 ~> ls -lZ >>> /var/opt/ft/log/libft_sra_alarm_server.log >>> -rw------- root root system_u:object_r:lsb-ft-asn_rw_t >>> /var/opt/ft/log/libft_sra_alarm_server.log >>> root at lstlinux57 13:32:36 ~> init 6 >>> root at lstlinux57 13:32:40 ~> logout >>> >>> Connection to 134.111.82.122 closed. >>> bash-3.1$ ssh 134.111.82.122 -l root >>> root at 134.111.82.122's password: >>> Last login: Wed Aug 13 13:08:02 2008 from rjlinux2.mno.stratus.com >>> root at lstlinux57 13:39:22 ~> ls -l >>> /var/opt/ft/log/libft_sra_alarm_server.log >>> -rw------- root root system_u:object_r:var_log_t >>> /var/opt/ft/log/libft_sra_alarm_server.log >>> root at lstlinux57 13:39:24 ~> restorecon -R /var/opt/ft/log >>> root at lstlinux57 13:39:45 ~> ls -lZ >>> /var/opt/ft/log/libft_sra_alarm_server.log >>> -rw------- root root system_u:object_r:lsb-ft-asn_rw_t >>> /var/opt/ft/log/libft_sra_alarm_server.log >>> >>> >>> The situation is a standard RHEL5.2 with all errata applied; plus the > [...snip for brevity...] >> The file libft_sra_alarm_server.log is being created on boot probably > by >> an init script or by the executable. Since the parent directory is >> labeled var_log_t it gets that context. If you run restorecon the >> context will get set correctly. >> >> If all the files in this directory are supposed to be >> system_u:object_r:lsb-ft-asn_rw_t:s0 >> >> Then you should label >> >> /usr/sbin/semanage fcontext -a -t lsb-ft-asn_rw_t -s system_u >> '/var/opt/ft/log(/.*)' >> >> If you need other files in that directory labeled differently you might >> want to move your log files to a subdir and label that one. > > > Yes this log (among others) is created by a daemon started from an init > script. I will investigate moving the logs to a sub-dir. But for > historical and support reasons I'd prefer to leave them where they are. > Is there a way for the daemon to create the files with the appropriate > label from the get-go? > > --rich Yes, you have three choices. 1. Write a policy for this daemon so that when it created files in directories labeled var_log_t, it transitions to the correct context 2. You could have the script create the log file and run restorecon on it and then have your program open and write to it. 3. You could make your application SELinux aware and ask the system how the log file should be labeled and then call the selinux api to tell the kernel to label it correctly. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkijP98ACgkQrlYvE4MpobNrTwCgmczJF2zoLn8GsvV0/2CUld67 GyEAmgPcBAXVKaKJcO4+zU6yodH5V9A6 =4BN7 -----END PGP SIGNATURE----- From Richard.Johnson at stratus.com Wed Aug 13 20:35:28 2008 From: Richard.Johnson at stratus.com (Johnson, Richard) Date: Wed, 13 Aug 2008 16:35:28 -0400 Subject: file contexts change on reboot In-Reply-To: 48A33FDF.60005@redhat.com References: 48A332DD.3010709@redhat.com 48A33FDF.60005@redhat.com Message-ID: Daniel J Walsh wrote: > Johnson, Richard wrote: >> Daniel J Walsh wrote: >>> The file libft_sra_alarm_server.log is being created on boot probably > by >>> an init script or by the executable. Since the parent directory is >>> labeled var_log_t it gets that context. If you run restorecon the >> context will get set correctly. >>> >>> If all the files in this directory are supposed to be >>> system_u:object_r:lsb-ft-asn_rw_t:s0 >>> >>> Then you should label >>> >>> /usr/sbin/semanage fcontext -a -t lsb-ft-asn_rw_t -s system_u >>> '/var/opt/ft/log(/.*)' >>> >>> If you need other files in that directory labeled differently you might >>> want to move your log files to a subdir and label that one. >> >> >> Yes this log (among others) is created by a daemon started from an init >> script. I will investigate moving the logs to a sub-dir. But for >> historical and support reasons I'd prefer to leave them where they are. >> Is there a way for the daemon to create the files with the appropriate >> label from the get-go? >> >>1. Write a policy for this daemon so that when it created files in >>directories labeled var_log_t, it transitions to the correct context Ah. I'm halfway down this road with a a candidate policy--which might be how I got into this mess. But being new at it, I guess it's par for the course. Back to the books and other docs...this time focusing on transitions. >>2. You could have the script create the log file and run restorecon on >>it and then have your program open and write to it. >> >>3. You could make your application SELinux aware and ask the system how >>the log file should be labeled and then call the selinux api to tell the >>kernel to label it correctly. From kaigai at kaigai.gr.jp Wed Aug 13 22:32:13 2008 From: kaigai at kaigai.gr.jp (KaiGai Kohei) Date: Thu, 14 Aug 2008 07:32:13 +0900 Subject: [BUG] legacy typenames of se-postgresql still remain In-Reply-To: <48A30D6B.6010609@redhat.com> References: <48A29C70.6040107@ak.jp.nec.com> <48A2A88C.70006@ak.jp.nec.com> <48A30D6B.6010609@redhat.com> Message-ID: <48A360ED.2030104@kaigai.gr.jp> Daniel J Walsh wrote: > KaiGai Kohei wrote: >> Sorry, the previous patch was imcomplete one. >> >> We allows sepgsql_client_type and sepgsql_unconfined_type to invoke >> sepgsql_trusted_proc_t, but it should be sepgsql_trusted_proc_exec_t, >> because sepgsql_trusted_proc_t is a domain. >> >> This matter also exists at upstreamed policy now. >> The attached "refpolicy-sepgsql-trusted-proc-fixes.patch" can be applied >> to upstreamed reference policy. >> >> Thanks, >> >> KaiGai Kohei wrote: >>> I got the following access denied logs, when I tries to connect >>> SE-PostgreSQL (postgresql_t) from PHP script (httpd_t) via unix >>> domain socket (/tmp/.s.PGSQL.5432). >>> >>> type=AVC msg=audit(1218613044.484:10388): avc: denied { write } >>> for pid=4805 comm="httpd" name=".s.PGSQL.5432" dev=sda6 ino=1079246 >>> scontext=unconfined_u:system_r:httpd_t:s0 >>> tcontext=unconfined_u:object_r:postgresql_tmp_t:s0 >>> tclass=sock_file >>> type=AVC msg=audit(1218613044.484:10388): avc: denied { connectto } >>> for pid=4805 comm="httpd" path="/tmp/.s.PGSQL.5432" >>> scontext=unconfined_u:system_r:httpd_t:s0 >>> tcontext=unconfined_u:system_r:postgresql_t:s0 >>> tclass=unix_stream_socket >>> >>> However, both permissions are allowed via postgresql_stream_connect() >>> independent from any booleans, if required types are provided by >>> postgresql.te. >>> >>> postgresql_stream_connect() and postgresql_unpriv_client() are put >>> within same optional_policy section at apache.te. >>> postgresql_unpriv_client() requires trusted procedure related types, >>> but postgresql.te declares them in legacy names. >>> >>> old: sepgsql_trusted_domain_t --> new: sepgsql_trusted_proc_t >>> old: sepgsql_trusted_proc_t --> new: sepgsql_trusted_proc_exec_t >>> >>> Could you apply the attached patch? >>> It fixes them as upstream doing. >>> >>> Thanks, >>> >>> >>> ------------------------------------------------------------------------ >>> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> > Fedora 9? Rawhide? Sorry, I missed the version. It is in Rawhide. (selinux-policy-3.5.1-4.fc10) Thanks, -- KaiGai Kohei From dwalsh at redhat.com Thu Aug 14 12:47:43 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 14 Aug 2008 08:47:43 -0400 Subject: [BUG] legacy typenames of se-postgresql still remain In-Reply-To: <48A360ED.2030104@kaigai.gr.jp> References: <48A29C70.6040107@ak.jp.nec.com> <48A2A88C.70006@ak.jp.nec.com> <48A30D6B.6010609@redhat.com> <48A360ED.2030104@kaigai.gr.jp> Message-ID: <48A4296F.7080608@redhat.com> KaiGai Kohei wrote: > Daniel J Walsh wrote: >> KaiGai Kohei wrote: >>> Sorry, the previous patch was imcomplete one. >>> >>> We allows sepgsql_client_type and sepgsql_unconfined_type to invoke >>> sepgsql_trusted_proc_t, but it should be sepgsql_trusted_proc_exec_t, >>> because sepgsql_trusted_proc_t is a domain. >>> >>> This matter also exists at upstreamed policy now. >>> The attached "refpolicy-sepgsql-trusted-proc-fixes.patch" can be applied >>> to upstreamed reference policy. >>> >>> Thanks, >>> >>> KaiGai Kohei wrote: >>>> I got the following access denied logs, when I tries to connect >>>> SE-PostgreSQL (postgresql_t) from PHP script (httpd_t) via unix >>>> domain socket (/tmp/.s.PGSQL.5432). >>>> >>>> type=AVC msg=audit(1218613044.484:10388): avc: denied { write } >>>> for pid=4805 comm="httpd" name=".s.PGSQL.5432" dev=sda6 ino=1079246 >>>> scontext=unconfined_u:system_r:httpd_t:s0 >>>> tcontext=unconfined_u:object_r:postgresql_tmp_t:s0 >>>> tclass=sock_file >>>> type=AVC msg=audit(1218613044.484:10388): avc: denied { connectto } >>>> for pid=4805 comm="httpd" path="/tmp/.s.PGSQL.5432" >>>> scontext=unconfined_u:system_r:httpd_t:s0 >>>> tcontext=unconfined_u:system_r:postgresql_t:s0 >>>> tclass=unix_stream_socket >>>> >>>> However, both permissions are allowed via postgresql_stream_connect() >>>> independent from any booleans, if required types are provided by >>>> postgresql.te. >>>> >>>> postgresql_stream_connect() and postgresql_unpriv_client() are put >>>> within same optional_policy section at apache.te. >>>> postgresql_unpriv_client() requires trusted procedure related types, >>>> but postgresql.te declares them in legacy names. >>>> >>>> old: sepgsql_trusted_domain_t --> new: sepgsql_trusted_proc_t >>>> old: sepgsql_trusted_proc_t --> new: sepgsql_trusted_proc_exec_t >>>> >>>> Could you apply the attached patch? >>>> It fixes them as upstream doing. >>>> >>>> Thanks, >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> -- >>>> fedora-selinux-list mailing list >>>> fedora-selinux-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> Fedora 9? Rawhide? > > Sorry, I missed the version. > It is in Rawhide. (selinux-policy-3.5.1-4.fc10) > > Thanks, Current Rawhide is pretty much the same as upstream. Here is the only patch I have on postgresql as of today's rawhide. Fedora 9 next update should match this policy in the next update also. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: services_postgresql.patch URL: From kaigai at ak.jp.nec.com Fri Aug 15 01:47:24 2008 From: kaigai at ak.jp.nec.com (KaiGai Kohei) Date: Fri, 15 Aug 2008 10:47:24 +0900 Subject: [BUG] legacy typenames of se-postgresql still remain In-Reply-To: <48A4296F.7080608@redhat.com> References: <48A29C70.6040107@ak.jp.nec.com> <48A2A88C.70006@ak.jp.nec.com> <48A30D6B.6010609@redhat.com> <48A360ED.2030104@kaigai.gr.jp> <48A4296F.7080608@redhat.com> Message-ID: <48A4E02C.9020506@ak.jp.nec.com> Daniel J Walsh wrote: > KaiGai Kohei wrote: >> Daniel J Walsh wrote: >>> KaiGai Kohei wrote: >>>> Sorry, the previous patch was imcomplete one. >>>> >>>> We allows sepgsql_client_type and sepgsql_unconfined_type to invoke >>>> sepgsql_trusted_proc_t, but it should be sepgsql_trusted_proc_exec_t, >>>> because sepgsql_trusted_proc_t is a domain. >>>> >>>> This matter also exists at upstreamed policy now. >>>> The attached "refpolicy-sepgsql-trusted-proc-fixes.patch" can be applied >>>> to upstreamed reference policy. >>>> >>>> Thanks, >>>> >>>> KaiGai Kohei wrote: >>>>> I got the following access denied logs, when I tries to connect >>>>> SE-PostgreSQL (postgresql_t) from PHP script (httpd_t) via unix >>>>> domain socket (/tmp/.s.PGSQL.5432). >>>>> >>>>> type=AVC msg=audit(1218613044.484:10388): avc: denied { write } >>>>> for pid=4805 comm="httpd" name=".s.PGSQL.5432" dev=sda6 ino=1079246 >>>>> scontext=unconfined_u:system_r:httpd_t:s0 >>>>> tcontext=unconfined_u:object_r:postgresql_tmp_t:s0 >>>>> tclass=sock_file >>>>> type=AVC msg=audit(1218613044.484:10388): avc: denied { connectto } >>>>> for pid=4805 comm="httpd" path="/tmp/.s.PGSQL.5432" >>>>> scontext=unconfined_u:system_r:httpd_t:s0 >>>>> tcontext=unconfined_u:system_r:postgresql_t:s0 >>>>> tclass=unix_stream_socket >>>>> >>>>> However, both permissions are allowed via postgresql_stream_connect() >>>>> independent from any booleans, if required types are provided by >>>>> postgresql.te. >>>>> >>>>> postgresql_stream_connect() and postgresql_unpriv_client() are put >>>>> within same optional_policy section at apache.te. >>>>> postgresql_unpriv_client() requires trusted procedure related types, >>>>> but postgresql.te declares them in legacy names. >>>>> >>>>> old: sepgsql_trusted_domain_t --> new: sepgsql_trusted_proc_t >>>>> old: sepgsql_trusted_proc_t --> new: sepgsql_trusted_proc_exec_t >>>>> >>>>> Could you apply the attached patch? >>>>> It fixes them as upstream doing. >>>>> >>>>> Thanks, >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> -- >>>>> fedora-selinux-list mailing list >>>>> fedora-selinux-list at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>> Fedora 9? Rawhide? >> Sorry, I missed the version. >> It is in Rawhide. (selinux-policy-3.5.1-4.fc10) >> >> Thanks, > > Current Rawhide is pretty much the same as upstream. Here is the only > patch I have on postgresql as of today's rawhide. Fedora 9 next update > should match this policy in the next update also. > OK, I confirmed the first matter is fixed at selinux-policy-3.5.4-2 in rawhide. (Sorry, I saw a bit older version.) However, the second matter still remains at upstream and rawhide. Chris, could you apply the attached patch which fixes lagacy naming matter. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei -------------- next part -------------- A non-text attachment was scrubbed... Name: refpolicy-sepgsql-trusted-proc-fixes.patch Type: text/x-patch Size: 1304 bytes Desc: not available URL: From dclinuxlist at gmail.com Mon Aug 18 22:18:45 2008 From: dclinuxlist at gmail.com (dbcooper) Date: Mon, 18 Aug 2008 18:18:45 -0400 Subject: SELinux and Nagios (Fedora 9 + Nagios) Message-ID: <858214240808181518n6a737beete1b969207004eb17@mail.gmail.com> Hello, I've setup (via default yum repos) Nagios (nagios-2.11-3.fc9.i386 and all the needed plugs). I'm getting the following messages when using SELinux in Target/Enabled mode. My knowledge is very limited with SELinux and I'm trying to learn the proper way to troubleshoot/resolve issues on my own, and hopefully I can use this as my firts learning curve with it. Thanks for any suggestions. --------------------------------------------------------------------------------------------------------------- Summary: SELinux is preventing ping (ping_t) "read" to /var/spool/nagios/cmd/nagios.cmd (nagios_spool_t). Detailed Description: SELinux denied access requested by ping. It is not expected that this access is required by ping 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:ping_t:s0 Target Context unconfined_u:object_r:nagios_spool_t:s0 Target Objects /var/spool/nagios/cmd/nagios.cmd [ fifo_file ] Source ping Source Path /bin/ping Port Host xxxxxxxxxx Source RPM Packages iputils-20071127-2.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-84.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name xxxxxxxxxxxxxx Platform Linux xxxxxxxxxxxxx 2.6.25.14-108.fc9.i686 #1 SMP Mon Aug 4 14:08:11 EDT 2008 i686 i686 Alert Count 23 First Seen Sun 17 Aug 2008 02:06:45 AM EDT Last Seen Mon 18 Aug 2008 06:11:31 PM EDT Local ID 67986880-653f-455c-88bb-5598d451bb14 Line Numbers Raw Audit Messages host=xxxxxxxxxxx type=AVC msg=audit(1219097491.87:211): avc: denied { read } for pid=6420 comm="ping" path="/var/spool/nagios/cmd/nagios.cmd" dev=dm-0 ino=728571 scontext=system_u:system_r:ping_t:s0 tcontext=unconfined_u:object_r:nagios_spool_t:s0 tclass=fifo_file host=xxxxxxxxxxxxx type=SYSCALL msg=audit(1219097491.87:211): arch=40000003 syscall=11 success=yes exit=0 a0=96dda38 a1=96ddb18 a2=bfec6ae4 a3=0 items=0 ppid=6419 pid=6420 auid=4294967295 uid=493 gid=489 euid=0 suid=0 fsuid=0 egid=489 sgid=489 fsgid=489 tty=(none) ses=4294967295 comm="ping" exe="/bin/ping" subj=system_u:system_r:ping_t:s0 key=(null) --------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From init at kth.se Tue Aug 19 08:31:32 2008 From: init at kth.se (Ingemar Nilsson) Date: Tue, 19 Aug 2008 10:31:32 +0200 Subject: SELinux and Nagios (Fedora 9 + Nagios) In-Reply-To: <858214240808181518n6a737beete1b969207004eb17@mail.gmail.com> References: <858214240808181518n6a737beete1b969207004eb17@mail.gmail.com> Message-ID: <48AA84E4.9070306@kth.se> dbcooper wrote: > I've setup (via default yum repos) Nagios (nagios-2.11-3.fc9.i386 and > all the needed plugs). > > I'm getting the following messages when using SELinux in Target/Enabled > mode. > > My knowledge is very limited with SELinux and I'm trying to learn the > proper way to troubleshoot/resolve issues on my own, and hopefully I can use > this as my firts learning curve with it. > > Thanks for any suggestions. > > --------------------------------------------------------------------------------------------------------------- > Summary: > > SELinux is preventing ping (ping_t) "read" to > /var/spool/nagios/cmd/nagios.cmd > (nagios_spool_t). I got that one too (on CentOS 5.1 and Nagios 2.12), but since I couldn't fathom why ping should be able to read the nagios.cmd file, and ping seemed to work anyway, I created an SELinux policy module that skipped writing those messages to the audit log. In other words, I piped the audit log message through "audit2allow -M nagiosping", which creates two files, nagiosping.te and nagiosping.pp. The .te file is the policy module source file, and the .pp file is the binary package generated by compiling the source file. I edited the source file and changed the "allow" to "dontaudit", with everything else kept as it was. Then I compiled the module: checkmodule -M -m -o nagiosping.mod nagiosping.te semodule_package -m nagiosping.mod -o nagiosping.pp rm nagiosping.mod You need the checkpolicy package for the checkmodule command, and the policycoreutils package for the semodule and semodule_package commands. The .mod file is a temporary file, that's why I removed it. Then I inserted it into the kernel: semodule -i nagiosping.pp And tada, no more "ping can't read from nagios.cmd" messages in the audit log. Regards Ingemar From olivares14031 at yahoo.com Tue Aug 19 13:06:07 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Tue, 19 Aug 2008 06:06:07 -0700 (PDT) Subject: selinux - nspluginscan, and xine denials Message-ID: <899265.52010.qm@web52612.mail.re2.yahoo.com> Two alerts from selinux Summary: SELinux is preventing nspluginviewer from changing a writable memory segment executable. Detailed Description: The nspluginviewer application attempted to change the access protection of memory (e.g., allocated using malloc). This is a potential security problem. Applications should not be doing this. Applications are sometimes coded incorrectly and request this permission. The SELinux Memory Protection Tests (http://people.redhat.com/drepper/selinux-mem.html) web page explains how to remove this requirement. If nspluginviewer 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: If you trust nspluginviewer to run correctly, you can change the context of the executable to unconfined_execmem_exec_t. "chcon -t unconfined_execmem_exec_t '/usr/bin/nspluginviewer'". 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/nspluginviewer'" Fix Command: chcon -t unconfined_execmem_exec_t '/usr/bin/nspluginviewer' 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 nspluginviewer Source Path /usr/bin/nspluginviewer Port Host localhost.localdomain Source RPM Packages kdebase-4.1.0-1.fc10 Target RPM Packages Policy RPM selinux-policy-3.5.1-4.fc10 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name allow_execmem Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.26.1 #1 SMP Sat Aug 2 21:36:01 CDT 2008 i686 i686 Alert Count 29 First Seen Sun 03 Aug 2008 12:55:21 PM CDT Last Seen Sun 03 Aug 2008 12:55:21 PM CDT Local ID 865503d3-baab-4dcd-adc0-47f8fff6ade6 Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1217786121.365:53): avc: denied { execmem } for pid=3262 comm="nspluginviewer" 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(1217786121.365:53): arch=40000003 syscall=125 success=no exit=-13 a0=b1aaa000 a1=1000 a2=5 a3=bfa32acc items=0 ppid=3222 pid=3262 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="nspluginviewer" exe="/usr/bin/nspluginviewer" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) I have recently installed xine(xine-lib-1.1.15 and xine-ui from source) and I got this one immediately following: What should I do? Should I just apply the fix and move on? Summary: SELinux is preventing xine from making the program stack executable. Detailed Description: The xine 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 xine 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 xine to run correctly, you can change the context of the executable to unconfined_execmem_exec_t. "chcon -t unconfined_execmem_exec_t '/usr/bin/xine'" 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/xine'" Fix Command: chcon -t unconfined_execmem_exec_t '/usr/bin/xine' 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 xine-0.99.5-1.lvn8 Target RPM Packages Policy RPM selinux-policy-3.5.1-4.fc10 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name allow_execstack Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.27-0.244.rc2.git1.fc10.i686 #1 SMP Fri Aug 8 13:26:20 EDT 2008 i686 i686 Alert Count 4 First Seen Mon 28 Jul 2008 10:50:50 PM CDT Last Seen Tue 19 Aug 2008 08:01:26 AM CDT Local ID d1193200-ba21-44ee-bdf0-5b24a80cdb04 Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1219150886.174:61): avc: denied { execstack } for pid=18915 comm="xine" 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(1219150886.174:61): arch=40000003 syscall=125 success=no exit=-13 a0=bfaed000 a1=1000 a2=1000007 a3=fffff000 items=0 ppid=4154 pid=18915 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts4 ses=1 comm="xine" exe="/usr/bin/xine" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) Thanks, Antonio From eparis at redhat.com Tue Aug 19 15:16:14 2008 From: eparis at redhat.com (Eric Paris) Date: Tue, 19 Aug 2008 11:16:14 -0400 Subject: selinux - nspluginscan, and xine denials In-Reply-To: <899265.52010.qm@web52612.mail.re2.yahoo.com> References: <899265.52010.qm@web52612.mail.re2.yahoo.com> Message-ID: <1219158974.15566.158.camel@localhost.localdomain> On Tue, 2008-08-19 at 06:06 -0700, Antonio Olivares wrote: > Two alerts from selinux [snip] > host=localhost.localdomain type=AVC msg=audit(1217786121.365:53): avc: denied { execmem } for pid=3262 comm="nspluginviewer" 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(1217786121.365:53): arch=40000003 syscall=125 success=no exit=-13 a0=b1aaa000 a1=1000 a2=5 a3=bfa32acc items=0 ppid=3222 pid=3262 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="nspluginviewer" exe="/usr/bin/nspluginviewer" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) [snip] > host=localhost.localdomain type=AVC msg=audit(1219150886.174:61): avc: denied { execstack } for pid=18915 comm="xine" 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(1219150886.174:61): arch=40000003 syscall=125 success=no exit=-13 a0=bfaed000 a1=1000 a2=1000007 a3=fffff000 items=0 ppid=4154 pid=18915 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts4 ses=1 comm="xine" exe="/usr/bin/xine" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) [snip] I'm guessing these are one in the same? Did it install xine as a plugin to firefox? This is a xine bug. execstack is never right. Did you try following the suggestion and run execstack -c LIBRARY_PATH on all of the libraries installed by xine-libs? -Eric From dwalsh at redhat.com Wed Aug 20 10:52:57 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 20 Aug 2008 06:52:57 -0400 Subject: SELinux and Nagios (Fedora 9 + Nagios) In-Reply-To: <858214240808181518n6a737beete1b969207004eb17@mail.gmail.com> References: <858214240808181518n6a737beete1b969207004eb17@mail.gmail.com> Message-ID: <48ABF789.1010005@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 dbcooper wrote: > Hello, > > I've setup (via default yum repos) Nagios (nagios-2.11-3.fc9.i386 and all > the needed plugs). > > I'm getting the following messages when using SELinux in Target/Enabled > mode. > > My knowledge is very limited with SELinux and I'm trying to learn the proper > way to troubleshoot/resolve issues on my own, and hopefully I can use > this as my firts learning curve with it. > > Thanks for any suggestions. > > --------------------------------------------------------------------------------------------------------------- > Summary: > > SELinux is preventing ping (ping_t) "read" to > /var/spool/nagios/cmd/nagios.cmd > (nagios_spool_t). > > Detailed Description: > > SELinux denied access requested by ping. It is not expected that this access > is > required by ping 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:ping_t:s0 > Target Context unconfined_u:object_r:nagios_spool_t:s0 > Target Objects /var/spool/nagios/cmd/nagios.cmd [ fifo_file ] > Source ping > Source Path /bin/ping > Port > Host xxxxxxxxxx > Source RPM Packages iputils-20071127-2.fc9 > Target RPM Packages > Policy RPM selinux-policy-3.3.1-84.fc9 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name catchall > Host Name xxxxxxxxxxxxxx > Platform Linux xxxxxxxxxxxxx 2.6.25.14-108.fc9.i686 #1 > SMP Mon Aug 4 14:08:11 EDT 2008 i686 i686 > Alert Count 23 > First Seen Sun 17 Aug 2008 02:06:45 AM EDT > Last Seen Mon 18 Aug 2008 06:11:31 PM EDT > Local ID 67986880-653f-455c-88bb-5598d451bb14 > Line Numbers > > Raw Audit Messages > > host=xxxxxxxxxxx type=AVC msg=audit(1219097491.87:211): avc: denied { read > } for pid=6420 comm="ping" path="/var/spool/nagios/cmd/nagios.cmd" dev=dm-0 > ino=728571 scontext=system_u:system_r:ping_t:s0 > tcontext=unconfined_u:object_r:nagios_spool_t:s0 tclass=fifo_file > > host=xxxxxxxxxxxxx type=SYSCALL msg=audit(1219097491.87:211): arch=40000003 > syscall=11 success=yes exit=0 a0=96dda38 a1=96ddb18 a2=bfec6ae4 a3=0 items=0 > ppid=6419 pid=6420 auid=4294967295 uid=493 gid=489 euid=0 suid=0 fsuid=0 > egid=489 sgid=489 fsgid=489 tty=(none) ses=4294967295 comm="ping" > exe="/bin/ping" subj=system_u:system_r:ping_t:s0 key=(null) > > --------------------------------------------------------------------------------------------------------- > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list This is a classic leaked file descriptor. Obviously ping has no business reading the nagios spool file, it would know nothing about this file, but nagios has a open file descriptor to the fifo_file when it execs ping. ping inherits the open file descriptor. The kernel checks the ping policy to see if ping can read the fifo file, when it finds it can not, it reports a violation, closes the file desctriptor for ping and reopens it with /dev/null. It then completes the startup of ping. You should report this as a bug to nagios. They should execute fcntl(fd, F_SETFD, FD_CLOEXEC) on all open file descriptors before fork/exec of any subprocess. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkir94kACgkQrlYvE4MpobP7pQCfblWcSW3EIrq2eSIMSPYdXE2h qscAoMsUbUVRp5rs2wOYNp9zsQ0AaaQz =IyRr -----END PGP SIGNATURE----- From prakashkhallalli at gmail.com Thu Aug 21 13:11:57 2008 From: prakashkhallalli at gmail.com (prakash hallalli) Date: Thu, 21 Aug 2008 18:41:57 +0530 Subject: Samba Policy - Type Enforcement File Message-ID: <994219730808210611o588df335td0ce3cd4e6a937a5@mail.gmail.com> Hi All I have installed selinux on fedora 8, I was using targeted policy which is the default policy in fedora. I have searched the policy module file ( File Context (FC) Type Enforcement (TE) and an Interface file (IF) ) Because i have configured samba server, so i need to change some permissions in samba.te file, but i couldn't find these file. Please help me where can i get these file and which package i have to install. Thanks praksh,h,k -------------- next part -------------- An HTML attachment was scrubbed... URL: From artur.szymczak at altkom.pl Thu Aug 21 13:44:17 2008 From: artur.szymczak at altkom.pl (Artur Szymczak) Date: Thu, 21 Aug 2008 15:44:17 +0200 Subject: Samba Policy - Type Enforcement File In-Reply-To: <994219730808210611o588df335td0ce3cd4e6a937a5@mail.gmail.com> References: <994219730808210611o588df335td0ce3cd4e6a937a5@mail.gmail.com> Message-ID: <48AD7131.40703@altkom.pl> selinux-policy-VERSION.fc8.src.rpm prakash hallalli wrote: > Hi All > I have installed selinux on fedora 8, I was using targeted policy > which is the default policy in fedora. > I have searched the policy module file ( File Context (FC) Type Enforcement > (TE) and an Interface file (IF) ) Because i have configured samba server, > so i need to change some permissions in samba.te file, but i couldn't find > these file. Please help me where can i get these file and which package i > have to install. > > > Thanks > praksh,h,k > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -- Artur Szymczak GPG-Fingerprint: C03A 385E 5C10 82C5 6564 C1E9 3D6A 616E B15D 122D Altkom Akademia S.A. 00-867 Warszawa ul. Ch?odna 51 S?d Rejonowy dla m.st. Warszawy w Warszawie, XII Wydzia? Gospodarczy Krajowego Rejestru S?dowego, KRS: 0000120139, NIP 118-00-08-391, Kapita? zak?adowy: 1 000 000 PLN. Adres rejestrowy Firmy - ul. Stawki 2, 00-193 Warszawa. Niniejsza wiadomo?? zawiera informacje zastrze?one i stanowi?ce tajemnic? przedsi?biorstwa firmy Altkom Akademia S.A. Ujawnianie tych informacji osobom trzecim lub nieuprawnione wykorzystanie ich do w?asnych cel?w jest zabronione. Je?eli otrzymali?cie Pa?stwo niniejsz? wiadomo?? omy?kowo, prosimy o niezw?oczne skontaktowanie si? z nadawc? oraz usuni?cie wszelkich kopii niniejszej wiadomo?ci. This message contains proprietary information and trade secrets of Altkom Akademia S.A. company. Unauthorized use or disclosure of this information to any third party is prohibited. If you received this message by mistake, please contact the sender immediately and delete all copies of this message. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From olivares14031 at yahoo.com Thu Aug 21 16:50:48 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Thu, 21 Aug 2008 09:50:48 -0700 (PDT) Subject: selinux and readahead Message-ID: <14264.81745.qm@web52612.mail.re2.yahoo.com> Dear all, I have encountered the following setroubleshoot warning: Summary: SELinux is preventing readahead (readahead_t) "read" to inotify (inotifyfs_t). Detailed Description: SELinux denied access requested by readahead. It is not expected that this access is required by readahead and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for inotify, restorecon -v 'inotify' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:readahead_t:SystemLow-SystemHigh Target Context system_u:object_r:inotifyfs_t Target Objects inotify [ dir ] Source readahead Source Path /usr/sbin/readahead Port Host localhost.localdomain Source RPM Packages readahead-1.4.4-1.fc10 Target RPM Packages Policy RPM selinux-policy-3.5.1-4.fc10 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.27-0.244.rc2.git1.fc10.i686 #1 SMP Fri Aug 8 13:26:20 EDT 2008 i686 i686 Alert Count 2 First Seen Thu 21 Aug 2008 04:04:26 AM CDT Last Seen Thu 21 Aug 2008 04:04:28 AM CDT Local ID c67dc8d2-0096-4510-9075-cbea7074ffa2 Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1219309468.106:155): avc: denied { read } for pid=7574 comm="readahead" path="inotify" dev=inotifyfs ino=1 scontext=system_u:system_r:readahead_t:s0-s0:c0.c1023 tcontext=system_u:object_r:inotifyfs_t:s0 tclass=dir host=localhost.localdomain type=SYSCALL msg=audit(1219309468.106:155): arch=40000003 syscall=11 success=yes exit=0 a0=9f292d0 a1=9f29368 a2=9f295c0 a3=0 items=0 ppid=7564 pid=7574 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=24 comm="readahead" exe="/usr/sbin/readahead" subj=system_u:system_r:readahead_t:s0-s0:c0.c1023 key=(null) I do not know if readahead should be denied or not? What do you recommend that I do? Regards, Antonio From rstory at sparta.com Fri Aug 22 16:51:02 2008 From: rstory at sparta.com (Robert Story) Date: Fri, 22 Aug 2008 12:51:02 -0400 Subject: MLS enforcing and kerberos Message-ID: <20080822125102.447ca489@sparta.com> I'm trying to switch a working kerberos server from targeted/enforcing to mls/enforcing. The krb5kdc daemon start fine, but kadmin does not. There is a single avc in the audit log: type=AVC msg=audit(1219421464.372:719): avc: denied { getattr } for pid=2436 comm="kadmind" path="/var/tmp/kadmin_0" dev=dm-5 ino=82064 scontext=system_u:system_r:kadmind_t:s0-s15:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s15:c0.c1023 tclass=file I ran this through audit2allow and loaded the module, with no luck. I ran 'semodule -DB' to see what else was being hit and not audited, and get quite a few more: type=AVC msg=audit(1219421462.655:714): avc: denied { siginh } for pid=2436 comm="kadmind" scontext=system_u:system_r:initrc_t:s0-s15:c0.c1023 tcontext=system_u:system_r:kadmind_t:s0-s15:c0.c1023 tclass=process type=AVC msg=audit(1219421462.655:714): avc: denied { rlimitinh } for pid=2436 comm="kadmind" scontext=system_u:system_r:initrc_t:s0-s15:c0.c1023 tcontext=system_u:system_r:kadmind_t:s0-s15:c0.c1023 tclass=process type=AVC msg=audit(1219421462.655:714): avc: denied { noatsecure } for pid=2436 comm="kadmind" scontext=system_u:system_r:initrc_t:s0-s15:c0.c1023 tcontext=system_u:system_r:kadmind_t:s0-s15:c0.c1023 tclass=process type=SYSCALL msg=audit(1219421462.655:714): arch=14 syscall=11 success=yes exit=0 a0=100f1600 a1=100f13b0 a2=100f03d8 a3=0 items=0 ppid=2435 pid=2436 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts6 ses=5 comm="kadmind" exe="/usr/kerberos/sbin/kadmind" subj=system_u:system_r:kadmind_t:s0-s15:c0.c1023 key=(null) type=AVC msg=audit(1219421462.668:715): avc: denied { read } for pid=2436 comm="kadmind" name="config" dev=dm-5 ino=57734 scontext=system_u:system_r:kadmind_t:s0-s15:c0.c1023 tcontext=system_u:object_r:selinux_config_t:s0 tclass=file type=SYSCALL msg=audit(1219421462.668:715): arch=14 syscall=5 success=no exit=-13 a0=1fcdc380 a1=10000 a2=1b6 a3=0 items=0 ppid=2435 pid=2436 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts6 ses=5 comm="kadmind" exe="/usr/kerberos/sbin/kadmind" subj=system_u:system_r:kadmind_t:s0-s15:c0.c1023 key=(null) type=AVC msg=audit(1219421462.670:716): avc: denied { write } for pid=2436 comm="kadmind" name="kdc.conf" dev=dm-5 ino=82034 scontext=system_u:system_r:kadmind_t:s0-s15:c0.c1023 tcontext=system_u:object_r:krb5kdc_conf_t:s0 tclass=file type=SYSCALL msg=audit(1219421462.670:716): arch=14 syscall=33 success=no exit=-13 a0=20020c30 a1=2 a2=1b6 a3=0 items=0 ppid=2435 pid=2436 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts6 ses=5 comm="kadmind" exe="/usr/kerberos/sbin/kadmind" subj=system_u:system_r:kadmind_t:s0-s15:c0.c1023 key=(null) type=AVC msg=audit(1219421462.671:717): avc: denied { write } for pid=2436 comm="kadmind" name="krb5.conf" dev=dm-5 ino=378227 scontext=system_u:system_r:kadmind_t:s0-s15:c0.c1023 tcontext=system_u:object_r:krb5_conf_t:s0 tclass=file type=SYSCALL msg=audit(1219421462.671:717): arch=14 syscall=33 success=no exit=-13 a0=20020d20 a1=2 a2=1b6 a3=0 items=0 ppid=2435 pid=2436 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts6 ses=5 comm="kadmind" exe="/usr/kerberos/sbin/kadmind" subj=system_u:system_r:kadmind_t:s0-s15:c0.c1023 key=(null) type=AVC msg=audit(1219421464.369:718): avc: denied { name_bind } for pid=2436 comm="kadmind" src=916 scontext=system_u:system_r:kadmind_t:s0-s15:c0.c1023 tcontext=system_u:object_r:hi_reserved_port_t:s0 tclass=tcp_socket type=SYSCALL msg=audit(1219421464.369:718): arch=14 syscall=102 success=no exit=-13 a0=2 a1=bfb6c484 a2=10 a3=bfb6c5dc items=0 ppid=2435 pid=2436 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts6 ses=5 comm="kadmind" exe="/usr/kerberos/sbin/kadmind" subj=system_u:system_r:kadmind_t:s0-s15:c0.c1023 key=(null) type=AVC msg=audit(1219421464.372:719): avc: denied { getattr } for pid=2436 comm="kadmind" path="/var/tmp/kadmin_0" dev=dm-5 ino=82064 scontext=system_u:system_r:kadmind_t:s0-s15:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s15:c0.c1023 tclass=file type=SYSCALL msg=audit(1219421464.372:719): arch=14 syscall=195 success=no exit=-13 a0=203136c0 a1=bfb6c120 a2=bfb6c120 a3=0 items=0 ppid=2435 pid=2436 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts6 ses=5 comm="kadmind" exe="/usr/kerberos/sbin/kadmind" subj=system_u:system_r:kadmind_t:s0-s15:c0.c1023 key=(null) type=AVC msg=audit(1219421464.405:720): avc: denied { getattr } for pid=2436 comm="kadmind" path="/var/tmp/kadmin_0" dev=dm-5 ino=82064 scontext=system_u:system_r:kadmind_t:s0-s15:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s15:c0.c1023 tclass=file type=SYSCALL msg=audit(1219421464.405:720): arch=14 syscall=195 success=no exit=-13 a0=20409ad8 a1=bfb6c120 a2=bfb6c120 a3=0 items=0 ppid=2435 pid=2436 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts6 ses=5 comm="kadmind" exe="/usr/kerberos/sbin/kadmind" subj=system_u:system_r:kadmind_t:s0-s15:c0.c1023 key=(null) running this through audit2allow and loading the module doesn't help either... What can I try next? -- Robert Story SPARTA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sds at tycho.nsa.gov Fri Aug 22 17:07:48 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 22 Aug 2008 13:07:48 -0400 Subject: MLS enforcing and kerberos In-Reply-To: <20080822125102.447ca489@sparta.com> References: <20080822125102.447ca489@sparta.com> Message-ID: <1219424868.18600.97.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2008-08-22 at 12:51 -0400, Robert Story wrote: > I'm trying to switch a working kerberos server from targeted/enforcing > to mls/enforcing. The krb5kdc daemon start fine, but kadmin does not. > There is a single avc in the audit log: > > type=AVC msg=audit(1219421464.372:719): avc: denied { getattr } for > pid=2436 comm="kadmind" path="/var/tmp/kadmin_0" dev=dm-5 ino=82064 > scontext=system_u:system_r:kadmind_t:s0-s15:c0.c1023 > tcontext=system_u:object_r:unlabeled_t:s15:c0.c1023 tclass=file The real question there is why is that file labeled unlabeled_t? That usually indicates that its context was invalidated, e.g. you removed the type from the policy? -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Fri Aug 22 17:12:18 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 22 Aug 2008 13:12:18 -0400 Subject: MLS enforcing and kerberos In-Reply-To: <20080822125102.447ca489@sparta.com> References: <20080822125102.447ca489@sparta.com> Message-ID: <1219425138.18600.100.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2008-08-22 at 12:51 -0400, Robert Story wrote: > I'm trying to switch a working kerberos server from targeted/enforcing > to mls/enforcing. The krb5kdc daemon start fine, but kadmin does not. > There is a single avc in the audit log: > > type=AVC msg=audit(1219421464.372:719): avc: denied { getattr } for pid=2436 comm="kadmind" path="/var/tmp/kadmin_0" dev=dm-5 ino=82064 scontext=system_u:system_r:kadmind_t:s0-s15:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s15:c0.c1023 tclass=file BTW, aside from the wrong type on the file, the denial is clearly a MLS denial - look at the levels on the two contexts. You have a process whose current/low level is s0 (aka SystemLow) trying to getattr (read flow) a file at s15:c0.c1023 (aka SystemHigh). No surprises there. The high level of the process is only used as a ceiling for newrole -l or if the process' domain has certain MLS privileges allowing it to act up to its ceiling. -- Stephen Smalley National Security Agency From rstory at sparta.com Fri Aug 22 19:21:49 2008 From: rstory at sparta.com (Robert Story) Date: Fri, 22 Aug 2008 15:21:49 -0400 Subject: MLS enforcing and kerberos In-Reply-To: <1219424868.18600.97.camel@moss-spartans.epoch.ncsc.mil> References: <20080822125102.447ca489@sparta.com> <1219424868.18600.97.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20080822152149.0f5e7905@sparta.com> On Fri, 22 Aug 2008 13:07:48 -0400 Stephen wrote: SS> > type=AVC msg=audit(1219421464.372:719): avc: denied { getattr } for SS> > pid=2436 comm="kadmind" path="/var/tmp/kadmin_0" dev=dm-5 ino=82064 SS> > scontext=system_u:system_r:kadmind_t:s0-s15:c0.c1023 SS> > tcontext=system_u:object_r:unlabeled_t:s15:c0.c1023 tclass=file SS> SS> The real question there is why is that file labeled unlabeled_t? That SS> usually indicates that its context was invalidated, e.g. you removed the SS> type from the policy? I haven't touched policy... The file must be left over from when the box was running in targeted mode... I did relabel, but then there's this: /etc/selinux/mls/contexts/files/file_contexts:/var/tmp/.* <> SS> BTW, aside from the wrong type on the file, the denial is clearly a MLS SS> denial - look at the levels on the two contexts. You have a process SS> whose current/low level is s0 (aka SystemLow) trying to getattr (read SS> flow) a file at s15:c0.c1023 (aka SystemHigh). No surprises there. SS> The high level of the process is only used as a ceiling for newrole -l SS> or if the process' domain has certain MLS privileges allowing it to act SS> up to its ceiling. I couldn't delete the file in enforcing mode, even after 'newrole -l SystemHigh'. So I dropped to permissive and deleted the file. After that, kadmin started fine and the file was recreated with SystemLow. -- Robert Story SPARTA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From brianchad at westnet.com.au Sun Aug 24 03:13:11 2008 From: brianchad at westnet.com.au (Brian Chadwick) Date: Sun, 24 Aug 2008 13:13:11 +1000 Subject: Postfix, /root/.forward, SELinux, F9, Strange AVC Message-ID: <48B0D1C7.9010204@westnet.com.au> Hi All. Well, I have scoured the docs and cant find anything that looks like the problem I am having here. I have a .forward file in /root .. Mail to root should divert to my user account, but SELinux stops Postfix from doing so. If I set SELinux to permissive, then it works, but of course logs the same AVC. SETroubleshooter says to restorecon -R './root' ... ./root is a relative path ... so what does this mean? It doesnt work. [root at admin ~]# restorecon -R -v './root' restorecon: stat error on ./root: No such file or directory [root at admin ~]# .forward File Context: [root at admin ~]# ls -Z /root/.forward -rw-r--r-- root root unconfined_u:object_r:admin_home_t:s0 /root/.forward [root at admin ~]# Postix Booleans: getsebool -a | grep post allow_postfix_local_write_mail_spool --> on allow_user_postgresql_connect --> off [root at admin ~]# Raw Audit Messages : host=admin.brianac.com.au type=AVC msg=audit(1219546087.579:2125): avc: denied { search } for pid=26716 comm="local" name="root" dev=dm-7 ino=63489 scontext=system_u:system_r:postfix_local_t:s0 tcontext=system_u:object_r:admin_home_t:s0 tclass=dir host=admin.brianac.com.au type=SYSCALL msg=audit(1219546087.579:2125): arch=40000003 syscall=196 success=no exit=-13 a0=b8079568 a1=bfe2b844 a2=7dfff4 a3=0 items=0 ppid=3274 pid=26716 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="local" exe="/usr/libexec/postfix/local" subj=system_u:system_r:postfix_local_t:s0 key=(null) Output from Troubleshooter: Summary SELinux is preventing the local from using potentially mislabeled files (./root). Detailed Description SELinux has denied local access to potentially mislabeled file(s) (./root). This means that SELinux will not allow local 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 local to access this files, you need to relabel them using restorecon -v './root'. You might want to relabel the entire directory using restorecon -R -v './root'. Additional Information Source Context: system_u:system_r:postfix_local_t:s0 Target Context: system_u:object_r:admin_home_t:s0 Target Objects: ./root [ dir ]Source: local Source Path: /usr/libexec/postfix/local Port: Host: admin.brianac.com.au Source RPM Packages: postfix-2.5.1-2.fc9 Target RPM Packages: filesystem-2.4.13-1.fc9 Policy RPM: selinux-policy-3.3.1-84.fc9 Selinux Enabled: True Policy Type: targeted MLS Enabled: True Enforcing Mode: Enforcing Plugin Name: home_tmp_bad_labels Host Name: admin.brianac.com.au Platform: Linux admin.brianac.com.au 2.6.25.14-108.fc9.i686 #1 SMP Mon Aug Troubleshooter says to restorecon for ./root. What is this? .. That is a relative path, not a full path. Can anyone help decipher this AVC and provide a fix? Cheers and Beers Brian -- Political Correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. From niftyfedora at niftyegg.com Sun Aug 24 06:55:42 2008 From: niftyfedora at niftyegg.com (Nifty Fedora Mitch) Date: Sat, 23 Aug 2008 23:55:42 -0700 Subject: Postfix, /root/.forward, SELinux, F9, Strange AVC In-Reply-To: <48B0D1C7.9010204@westnet.com.au> References: <48B0D1C7.9010204@westnet.com.au> Message-ID: <20080824065542.GA9765@hpegg.wr.niftyegg.com> On Sun, Aug 24, 2008 at 01:13:11PM +1000, Brian Chadwick wrote: > > Well, I have scoured the docs and cant find anything that looks like the > problem I am having here. > > I have a .forward file in /root .. Mail to root should divert to my user > account, but SELinux stops Postfix from doing so. If I set SELinux to > permissive, then it works, but of course logs the same AVC. > SETroubleshooter says to restorecon -R './root' ... ./root is a relative > path ... so what does this mean? It doesnt work. > Since this is root just fix the aliase for root. Look for the two lines in /etc/aliases that looks like these then add a third that looks like the third. # Person who should get root's mail #root: marc root: brianchad at westnet.com.au The .forward thing has been a thorn to a lot of systems so expect to have to read the documentation and more.... -- T o m M i t c h e l l Got a great hat... now what. From selinux at gmail.com Sun Aug 24 21:20:37 2008 From: selinux at gmail.com (Tom London) Date: Sun, 24 Aug 2008 14:20:37 -0700 Subject: rsync, xattrs, ntfs-3g and "selinux.selinux" Message-ID: <4c4ba1530808241420x70b65aafr9c206d8412fe4e97@mail.gmail.com> Running rawhide. I use "rsync" to backup my system to a USB hard drive. I also ntfs-3g mount a WinXP partition to '/mnt/windows' on boot, and I use the above rsync to back that up as well. Adding '-xattrs' to the argument list for rsync seems to produce scads of the following (I'm guessing one for each file in the ntfs-3g file system ): rsync: rsync_xal_clear: lremovexattr("mnt/windows/WINDOWS/twain_32/wiatwain.ds","security.selinux") failed: Permission denied (13) rsync: rsync_xal_clear: lremovexattr("mnt/windows/temp","security.selinux") failed: Permission denied (13) rsync: rsync_xal_clear: lremovexattr("mnt/windows/temp/setup.log","security.selinux") failed: Permission denied (13) Destination fs i ext4dev. When mounted, all the files in /mnt/windows have type: fusefs_t. When rsych'ed, the type on the ext4 fs is file_t. Running 'getfatttr -d' on the source files produces, for example: [root at localhost temp]# getfattr -d * getfattr: setup.log: Operation not supported [root at localhost temp]# On the destination fs, result is [root at localhost temp]# getfattr -d * [root at localhost temp]# This something due to the way I mounted the ntfs-3g fs? The way I run rsync? Other? thanks, tom -- Tom London From mmcallis at redhat.com Sun Aug 24 22:16:42 2008 From: mmcallis at redhat.com (Murray McAllister) Date: Mon, 25 Aug 2008 08:16:42 +1000 Subject: rsync, xattrs, ntfs-3g and "selinux.selinux" In-Reply-To: <4c4ba1530808241420x70b65aafr9c206d8412fe4e97@mail.gmail.com> References: <4c4ba1530808241420x70b65aafr9c206d8412fe4e97@mail.gmail.com> Message-ID: <48B1DDCA.4020801@redhat.com> Tom London wrote: > Running rawhide. > > I use "rsync" to backup my system to a USB hard drive. > > I also ntfs-3g mount a WinXP partition to '/mnt/windows' on boot, and > I use the above rsync to back that up as well. > > Adding '-xattrs' to the argument list for rsync seems to produce scads > of the following (I'm guessing one for each file in the ntfs-3g file > system ): > > rsync: rsync_xal_clear: > lremovexattr("mnt/windows/WINDOWS/twain_32/wiatwain.ds","security.selinux") > failed: Permission denied (13) > rsync: rsync_xal_clear: > lremovexattr("mnt/windows/temp","security.selinux") failed: Permission > denied (13) > rsync: rsync_xal_clear: > lremovexattr("mnt/windows/temp/setup.log","security.selinux") failed: > Permission denied (13) > > Destination fs i ext4dev. > > When mounted, all the files in /mnt/windows have type: fusefs_t. When > rsych'ed, the type on the ext4 fs is file_t. > > Running 'getfatttr -d' on the source files produces, for example: > [root at localhost temp]# getfattr -d * > getfattr: setup.log: Operation not supported > [root at localhost temp]# > > On the destination fs, result is > [root at localhost temp]# getfattr -d * > [root at localhost temp]# > > This something due to the way I mounted the ntfs-3g fs? The way I run > rsync? Other? > > thanks, > tom This might be off topic, but I am unable to get rsync -X to preserve the SELinux context: . Cheers. From selinux at gmail.com Mon Aug 25 13:32:40 2008 From: selinux at gmail.com (Tom London) Date: Mon, 25 Aug 2008 06:32:40 -0700 Subject: rsync, xattrs, ntfs-3g and "selinux.selinux" In-Reply-To: <48B1DDCA.4020801@redhat.com> References: <4c4ba1530808241420x70b65aafr9c206d8412fe4e97@mail.gmail.com> <48B1DDCA.4020801@redhat.com> Message-ID: <4c4ba1530808250632g31fcc740vdbc3a16d4c0d7d75@mail.gmail.com> On Sun, Aug 24, 2008 at 3:16 PM, Murray McAllister wrote: > Tom London wrote: >> >> Running rawhide. >> >> I use "rsync" to backup my system to a USB hard drive. >> >> I also ntfs-3g mount a WinXP partition to '/mnt/windows' on boot, and >> I use the above rsync to back that up as well. >> >> Adding '-xattrs' to the argument list for rsync seems to produce scads >> of the following (I'm guessing one for each file in the ntfs-3g file >> system ): >> >> rsync: rsync_xal_clear: >> >> lremovexattr("mnt/windows/WINDOWS/twain_32/wiatwain.ds","security.selinux") >> failed: Permission denied (13) >> rsync: rsync_xal_clear: >> lremovexattr("mnt/windows/temp","security.selinux") failed: Permission >> denied (13) >> rsync: rsync_xal_clear: >> lremovexattr("mnt/windows/temp/setup.log","security.selinux") failed: >> Permission denied (13) >> >> Destination fs i ext4dev. >> >> When mounted, all the files in /mnt/windows have type: fusefs_t. When >> rsych'ed, the type on the ext4 fs is file_t. >> >> Running 'getfatttr -d' on the source files produces, for example: >> [root at localhost temp]# getfattr -d * >> getfattr: setup.log: Operation not supported >> [root at localhost temp]# >> >> On the destination fs, result is >> [root at localhost temp]# getfattr -d * >> [root at localhost temp]# >> >> This something due to the way I mounted the ntfs-3g fs? The way I run >> rsync? Other? >> >> thanks, >> tom > > This might be off topic, but I am unable to get rsync -X to preserve the > SELinux context: . > > Cheers. > Appears that your issue is different: I'm running source and destination on the same rawhide server. Apparently, no problem with preserving contexts, just the above issue with "mounted ntfs-3g" files. tom -- Tom London From Richard.Johnson at stratus.com Tue Aug 26 20:02:15 2008 From: Richard.Johnson at stratus.com (Johnson, Richard) Date: Tue, 26 Aug 2008 16:02:15 -0400 Subject: policy rpm %post script encounters avc violations Message-ID: When installing a policy rpm, one cannot log the install activity w/o generating avc errors. For example: rpm -i lsb-ft-asn-selinux > /var/log/rpm-update.log produces the following violation: type=SYSCALL msg=audit(1219774608.030:789): arch=c000003e syscall=59 success=yes exit=0 a0=be952e0 a1=be93390 a2=be958f0 a3=8 items=0 ppid=2848 pid=2875 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS1 ses=2 comm="restorecon" exe="/sbin/restorecon" subj=root:system_r:restorecon_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1219774608.030:789): avc: denied { write } for pid=2875 comm="restorecon" path="/var/log/rpm-update.log" dev=md2 ino=2694055 scontext=root:system_r:restorecon_t:s0-s0:c0.c1023 tcontext=root:object_r:var_log_t:s0 tclass=file The problems seems to stem from recording the %post script's attempts to relabel files affected by the policy, specifically: /sbin/restorecon -F -R -v /opt/ft/sbin/sra_alarm; /sbin/restorecon -F -R -v /etc/opt/ft/asn; /sbin/restorecon -F -R -v /var/opt/ft/asn; /sbin/restorecon -F -R -v /var/opt/ft/log; Is there any way to preserve the logging w/o disabling selinux for the duration of the install? FWIW, the rpm commands are executed from a bash script. From paul at city-fan.org Wed Aug 27 00:04:32 2008 From: paul at city-fan.org (Paul Howarth) Date: Wed, 27 Aug 2008 01:04:32 +0100 Subject: policy rpm %post script encounters avc violations In-Reply-To: References: Message-ID: <20080827010432.2d2c696b@metropolis.intra.city-fan.org> On Tue, 26 Aug 2008 16:02:15 -0400 "Johnson, Richard" wrote: > When installing a policy rpm, one cannot log the install activity w/o > generating avc errors. For example: > > rpm -i lsb-ft-asn-selinux > /var/log/rpm-update.log > > produces the following violation: > > type=SYSCALL msg=audit(1219774608.030:789): arch=c000003e syscall=59 > success=yes exit=0 a0=be952e0 a1=be93390 a2=be958f0 a3=8 items=0 > ppid=2848 pid=2875 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=ttyS1 ses=2 comm="restorecon" > exe="/sbin/restorecon" subj=root:system_r:restorecon_t:s0-s0:c0.c1023 > key=(null) type=AVC msg=audit(1219774608.030:789): avc: denied > { write } for pid=2875 comm="restorecon" > path="/var/log/rpm-update.log" dev=md2 ino=2694055 > scontext=root:system_r:restorecon_t:s0-s0:c0.c1023 > tcontext=root:object_r:var_log_t:s0 tclass=file > > The problems seems to stem from recording the %post script's attempts > to relabel files affected by the policy, specifically: > > /sbin/restorecon -F -R -v /opt/ft/sbin/sra_alarm; > /sbin/restorecon -F -R -v /etc/opt/ft/asn; > /sbin/restorecon -F -R -v /var/opt/ft/asn; > /sbin/restorecon -F -R -v /var/opt/ft/log; > > Is there any way to preserve the logging w/o disabling selinux for the > duration of the install? > > FWIW, the rpm commands are executed from a bash script. You could try logging to a file with a different context type, e.g. rpm -i lsb-ft-asn-selinux > /tmp/rpm-update.log and then move the resulting file to /var/log if you need it to be there. I'm not sure if restorecon_t can write to temp files but it's probably more likely that writing to var_log_t, which is currently what's being denied. Paul. From nick at austin.rr.com Wed Aug 27 01:29:28 2008 From: nick at austin.rr.com (Nickolas Gray) Date: Tue, 26 Aug 2008 20:29:28 -0500 Subject: Bootable copy of an FC9 system. Message-ID: <8E00922D-4154-4451-BC37-33D29C6CE656@austin.rr.com> I am attempting to create a bootable copy of a running SELinux box on FC9. I think I am close but I am coming up with a kernel panic (text at end) Here are the steps and a brief reason. If anyone has any suggestions where I might have made a mistake or left something out a comment would be appreciated. The only requirement so far is that it has to be a disk to disk copy with no CD/DVD rescue involved. The original looks like mbr on boot sector /dev/sda1 ext3 /boot /dev/sda2 LVM VolGroup00/LogVol00 is root VolGroup00/LogVol01 is swap This is what I am doing. ? This seemed like an efficient way to dup the filesystems of the source to the target. sfdisk -d /dev/sda | sfdisk /dev/sdb ?Duplicate the MBR dd if=/dev/sda1 of=/dev/sdb1 bs=512k ?Copy the entire /boot from a to b dd if=/dev/sda of=/dev/sdb bs=664 count=1 ?Add the /dev/sdb2 to LVM pvcreate /dev/sdb2 create the VolGroup for / vgcreate -s 32m VolGroup01 /dev/sdb2 Create the logical volume for / and swap lvcreate -l 1562 -n LogVol00 VolGroup01 lvcreate -l 62 -n LogVol01 VolGroup01 Create the swap area mkswap /dev/VolGroup01/LogVol01 Format the / filesystem mkfs -t ext3 /dev/VolGroup01/LogVol00 Create the snapshot lvcreate -L 20g -s -n snap /dev/VolGroup00/LogVol00 Mount the snapshot mount /dev/VolGroup00/snap /snapshot Mount the target mount /dev/VolGroup01/LogVol00 /target Rsync over the snapshot rsync -vXxpr /snapshot/* /target Unmount the snapshot umount /snapshot lvremove -f VolGroup00/snap At this point I fixed the initrd, the fstab and grub.conf on the target to point to VolGroup01 instead of VolGroup00. I would think this should be it. What I get is. root (hd0,0) Filesystem type is ..... kerne /vmlinuz ...... Linux bzimage..... initrd / initrd .... Linux initrd Decompresing Linux ... Done Booting the kernel Red Hat nash version 6,0,52 starting Reading all physical volumes this make take awhile .... Found volume group VolGroup01 now active ERROR: exec of init (/sbin/init) failed failed!!!! No such file or directory ERROR: failed in exec of /bin/echo: No such file or directory a couple messages about not finding /bin/sleep Kernel Panic I am not really sure where this is getting to. I thought it was getting to the initrd but now I am not sure. Thanks Nick From Richard.Johnson at stratus.com Wed Aug 27 02:01:59 2008 From: Richard.Johnson at stratus.com (Johnson, Richard) Date: Tue, 26 Aug 2008 22:01:59 -0400 Subject: policy rpm %post script encounters avc violations In-Reply-To: <20080827010432.2d2c696b@metropolis.intra.city-fan.org> References: <20080827010432.2d2c696b@metropolis.intra.city-fan.org> Message-ID: On Tue, 26 Aug 2008 8:05 PM "Paul Howarth" wrote: > On Tue, 26 Aug 2008 16:02:15 -0400 > "Johnson, Richard" wrote: > > > When installing a policy rpm, one cannot log the install activity w/o > > generating avc errors. For example: > > > > rpm -i lsb-ft-asn-selinux > /var/log/rpm-update.log > > > > produces the following violation: > > > > type=SYSCALL msg=audit(1219774608.030:789): arch=c000003e syscall=59 > > success=yes exit=0 a0=be952e0 a1=be93390 a2=be958f0 a3=8 items=0 > > ppid=2848 pid=2875 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > > sgid=0 fsgid=0 tty=ttyS1 ses=2 comm="restorecon" > > exe="/sbin/restorecon" subj=root:system_r:restorecon_t:s0-s0:c0.c1023 > > key=(null) type=AVC msg=audit(1219774608.030:789): avc: denied > > { write } for pid=2875 comm="restorecon" > > path="/var/log/rpm-update.log" dev=md2 ino=2694055 > > scontext=root:system_r:restorecon_t:s0-s0:c0.c1023 > > tcontext=root:object_r:var_log_t:s0 tclass=file > > > > The problems seems to stem from recording the %post script's attempts > > to relabel files affected by the policy, specifically: > > > > /sbin/restorecon -F -R -v /opt/ft/sbin/sra_alarm; > > /sbin/restorecon -F -R -v /etc/opt/ft/asn; > > /sbin/restorecon -F -R -v /var/opt/ft/asn; > > /sbin/restorecon -F -R -v /var/opt/ft/log; > > > > Is there any way to preserve the logging w/o disabling selinux for the > > duration of the install? > > > > FWIW, the rpm commands are executed from a bash script. > > You could try logging to a file with a different context type, e.g. > > rpm -i lsb-ft-asn-selinux > /tmp/rpm-update.log > > and then move the resulting file to /var/log if you need it to be > there. I'm not sure if restorecon_t can write to temp files but it's > probably more likely that writing to var_log_t, which is currently > what's being denied. I wish it were as simple as using a tmp_t:file. I tried that, and the answer's no. I suppose the general process would be a script that: - creates a temporary file - label it--silently, to avoid an avc logging the activity - do the restorecon. - cat the temporary file to stdout. - and the various complications of cleanup should an error occur - and replicating the encapsulation in both %post and %postun scripts. For my understanding: If it were to work, what's gained by restricting restorecon from logging directly? --rich From sean at bruenor.org Thu Aug 28 22:05:24 2008 From: sean at bruenor.org (Sean E. Millichamp) Date: Thu, 28 Aug 2008 18:05:24 -0400 Subject: AVC denials when using RH Cluster Suite's qdiskd and ping heuristic Message-ID: <1219961124.3284.36.camel@sewt> I have been experimenting with using a quorum disk with the RH cluster suite product (qdiskd in the cman RPM). One of the requirements of using qdiskd is that you must specify at least one command that can be run to test the health of the node. A typical command to use for this heuristic is ping, although any command that returns a 0/non-0 exit status is acceptable. When I configure a simple ping test with qdisk I get: type=AVC msg=audit(1219960233.627:4561): avc: denied { read write } for pid=23174 comm="ping" path="/dev/sda4" dev=tmpfs ino=1051 scontext=root:system_r:ping_t:s0 tcontext=system_u:object_ r:fixed_disk_device_t:s0 tclass=blk_file type=AVC msg=audit(1219960233.627:4561): avc: denied { read write } for pid=23174 comm="ping" path="/dev/sdb4" dev=tmpfs ino=985 scontext=root:system_r:ping_t:s0 tcontext=system_u:object_r :fixed_disk_device_t:s0 tclass=blk_file type=SYSCALL msg=audit(1219960233.627:4561): arch=c000003e syscall=59 success=yes exit=0 a0=1f3575a0 a1=1f357610 a2=1f356150 a3=3 items=0 ppid=23163 pid=23174 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=189 comm="ping" exe="/bin/ping" subj=root:system_r:ping_t:s0 key=(null) The test is: "/bin/ping -c1 -t1 x.x.x.x" where x.x.x.x is a known-reachable IP. This works without AVC denials from the command line. Interestingly, the ping command seems to complete and return an exit code properly to qdisk as the log message shows that it is up. I have used audit2allow which told me I could do: allow ping_t fixed_disk_device_t:blk_file { read write }; and silence the message, but somehow giving ping access to fixed_disk_device_t to quiet a log message seems like it defeats the spirit of limited access :) I have no idea why ping (I am assuming that I am reading it correctly and it is ping) would be trying to access /dev/sda4 or /dev/sdb4. Those partitions are the extended partition container on my software RAID-1 boot drives. I've poked briefly at the qdiskd code and it seems to do a normal fork/exec to invoke the ping. Has anyone seen anything like this or have any ideas on where I should look next? I've spent a while on it so far and I don't have a lot more time to spend on it, but I'd like to solve it if possible and (if needed) get a fix out somewhere. I have been doing my testing with the RHEL versions of these tools as I don't have a cluster of Fedora machines handy, but I couldn't find a RHEL SELinux list and this looked like the best bet. selinux-policy-targeted-2.4.6-137.1.el5 cman-2.0.84-2.el5 I'm still pretty new to trying to sift through SELinux policy/messages so please be patient with me. :) Thanks! Sean From sean at bruenor.org Fri Aug 29 03:58:53 2008 From: sean at bruenor.org (Sean E. Millichamp) Date: Thu, 28 Aug 2008 23:58:53 -0400 Subject: AVC denials when using RH Cluster Suite's qdiskd and ping heuristic In-Reply-To: <1219961124.3284.36.camel@sewt> References: <1219961124.3284.36.camel@sewt> Message-ID: <1219982333.3117.3.camel@sewt> On Thu, 2008-08-28 at 18:05 -0400, Sean E. Millichamp wrote: > When I configure a simple ping test with qdisk I get: > > type=AVC msg=audit(1219960233.627:4561): avc: denied { read write } for pid=23174 comm="ping" path="/dev/sda4" dev=tmpfs ino=1051 scontext=root:system_r:ping_t:s0 tcontext=system_u:object_ > r:fixed_disk_device_t:s0 tclass=blk_file > > type=AVC msg=audit(1219960233.627:4561): avc: denied { read write } for pid=23174 comm="ping" path="/dev/sdb4" dev=tmpfs ino=985 scontext=root:system_r:ping_t:s0 tcontext=system_u:object_r > :fixed_disk_device_t:s0 tclass=blk_file > > type=SYSCALL msg=audit(1219960233.627:4561): arch=c000003e syscall=59 success=yes exit=0 a0=1f3575a0 a1=1f357610 a2=1f356150 a3=3 items=0 ppid=23163 pid=23174 auid=0 uid=0 gid=0 euid=0 suid=0 > fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=189 comm="ping" exe="/bin/ping" subj=root:system_r:ping_t:s0 key=(null) These messages are because qdiskd doesn't properly clean up its file descriptors before forking and execing ping. I will clean up my findings and submit a patch/open a bug report against qdisk. Thanks, Sean From olivares14031 at yahoo.com Fri Aug 29 22:41:56 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Fri, 29 Aug 2008 15:41:56 -0700 (PDT) Subject: avcs for readahead :( Message-ID: <249564.86604.qm@web52610.mail.re2.yahoo.com> Dear fellow testers and Selinux experts, Upon applying the most recent updates, I am encountering some denied avcs for readahead. I previously posted about readahead, but i got no response, maybe implying that they are not important or that it is okay for selinux to step in and stop readhead from creating trouble. SELinux: initialized (dev binfmt_misc, type binfmt_misc), uses genfs_contexts type=1400 audit(1220049017.315:7): avc: denied { fowner } for pid=653 comm="readahead" capability=3 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:system_r:readahead_t:s0 tclass=capability type=1400 audit(1220049017.685:8): avc: denied { fowner } for pid=653 comm="readahead" capability=3 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:system_r:readahead_t:s0 tclass=capability type=1400 audit(1220049017.685:9): avc: denied { fowner } for pid=653 comm="readahead" capability=3 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:system_r:readahead_t:s0 tclass=capability type=1400 audit(1220049017.685:10): avc: denied { fowner } for pid=653 comm="readahead" capability=3 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:system_r:readahead_t:s0 tclass=capability IA-32 Microcode Update Driver: v1.14a Thanks in Advance, Antonio From frankly3d at gmail.com Sat Aug 30 07:35:23 2008 From: frankly3d at gmail.com (Frank Murphy) Date: Sat, 30 Aug 2008 08:35:23 +0100 Subject: AVC Denial "services" Message-ID: su - root chcon -t bin_t './system-config-services-mechanism.py' chcon: cannot access `./system-config-services-mechanism.py': No such file or directory Summary: SELinux is preventing the dbus-daemon-lau (system_dbusd_t) from executing ./system-config-services-mechanism.py. Detailed Description: SELinux has denied the dbus-daemon-lau from executing ./system-config-services-mechanism.py. If dbus-daemon-lau is supposed to be able to execute ./system-config-services-mechanism.py, this could be a labeling problem. Most confined domains are allowed to execute files labeled bin_t. So you could change the labeling on this file to bin_t and retry the application. If this dbus-daemon-lau is not supposed to execute ./system-config-services-mechanism.py, this could signal a intrusion attempt. Allowing Access: If you want to allow dbus-daemon-lau to execute ./system-config-services-mechanism.py: chcon -t bin_t './system-config-services-mechanism.py' If this fix works, please update the file context on disk, with the following command: semanage fcontext -a -t bin_t './system-config-services-mechanism.py' Please specify the full path to the executable, Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this selinux-policy to make sure this becomes the default labeling. Additional Information: Source Context system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 Target Context system_u:object_r:usr_t:s0 Target Objects ./system-config-services-mechanism.py [ file ] Source dbus-daemon-lau Source Path /lib/dbus-1/dbus-daemon-launch-helper Port Host rawhide-02 Source RPM Packages dbus-1.2.3-1.fc10 Target RPM Packages Policy RPM selinux-policy-3.5.1-4.fc10 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name execute Host Name rawhide-02 Platform Linux rawhide-02 2.6.27-0.238.rc2.fc10.i686 #1 SMP Thu Aug 7 08:00:04 EDT 2008 i686 i686 Alert Count 1 First Seen Sat 30 Aug 2008 08:22:57 IST Last Seen Sat 30 Aug 2008 08:22:57 IST Local ID ffddfd97-63b1-4809-aee4-c10e29d86722 Line Numbers Raw Audit Messages host=rawhide-02 type=AVC msg=audit(1220080977.294:17): avc: denied { execute } for pid=3564 comm="dbus-daemon-lau" name="system-config-services-mechanism.py" dev=dm-0 ino=2605067 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:usr_t:s0 tclass=file host=rawhide-02 type=SYSCALL msg=audit(1220080977.294:17): arch=40000003 syscall=11 success=no exit=-13 a0=9774018 a1=9773d60 a2=9773008 a3=b8d9bc items=0 ppid=3563 pid=3564 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="dbus-daemon-lau" exe="/lib/dbus-1/dbus-daemon-launch-helper" subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null)