From dwalsh at redhat.com Mon May 1 21:03:25 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 01 May 2006 17:03:25 -0400 Subject: update changes to disabled In-Reply-To: <444B948E.2050806@mindspring.com> References: <444B948E.2050806@mindspring.com> Message-ID: <4456779D.1020603@redhat.com> Richard Hally wrote: > Updating from selinux-policy-targeted-2.2.34-2 to the latest 2.2.34-3 > changes the /etc/selinux/config from SELINUX=enforcing to disabled. Is > this intentional? No this was a bug in the update script. > > Richard Hally > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From dwalsh at redhat.com Mon May 1 21:15:27 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 01 May 2006 17:15:27 -0400 Subject: enforcing reset to disabled on update In-Reply-To: <4c4ba1530604270657h46ebfeb3pe984586ea0878708@mail.gmail.com> References: <44501B11.50707@mindspring.com> <4c4ba1530604270644s6f7f2f72s2abc94c282cc63b9@mail.gmail.com> <4c4ba1530604270657h46ebfeb3pe984586ea0878708@mail.gmail.com> Message-ID: <44567A6F.7090001@redhat.com> Tom London wrote: > On 4/27/06, Tom London wrote: >> I can verify this. I separately updated to today's 'selinux-policy*' >> packages, and check /etc/selinux/config before and afterwards. >> Before: >> SELINUX=enforcing >> Afterwards >> SELINUX=disabled >> >> tom > Could the offending script be the postuninstall script of selinux-policy: > The problem was in the preceding policy package that did not have the if [ $1 = 0]; then Call so when it got updated this code executed. IE the spec file thought it was being updated. The newer policy packages should handle this correctly. > postuninstall scriptlet (using /bin/sh): > if [ $1 = 0 ]; then > setenforce 0 2> /dev/null > if [ ! -s /etc/selinux/config ]; then > echo "SELINUX=disabled" > /etc/selinux/config > else > sed -i 's/^SELINUX=.*/SELINUX=disabled/g' > /etc/selinux/config > fi > fi > > I also noticed that after the 'yum update', my system was in > permissive mode.... > > tom > -- > Tom London > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From dwalsh at redhat.com Mon May 1 21:21:50 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 01 May 2006 17:21:50 -0400 Subject: fedora-selinux-list Digest, Vol 26, Issue 32 In-Reply-To: <4450F588.4070701@grifent.com> References: <20060427095825.413A07309E@hormel.redhat.com> <4450F588.4070701@grifent.com> Message-ID: <44567BEE.8060506@redhat.com> John Griffiths wrote: > > > fedora-selinux-list-request at redhat.com wrote: >> >> Subject: >> Error running ffmpeg due to permission denied on library >> From: >> "Robert Foster" >> Date: >> Thu, 27 Apr 2006 12:41:09 +1000 >> To: >> >> >> To: >> >> >> >> Hi, >> I'm trying to get ffmpeg working for Gallery2 on FC5, and getting the >> following error (from the debug message via Gallery): >> >> Executing: ( "/usr/bin/ffmpeg" "-h" ) >> 2>/MV/webs/Repository/gallery/tmp/g2dbgitTQYC >> file_exists(/MV/webs/Repository/gallery/tmp/g2dbgitTQYC) >> filesize(/MV/webs/Repository/gallery/tmp/g2dbgitTQYC) >> fopen(/MV/webs/Repository/gallery/tmp/g2dbgitTQYC, r, 0) >> feof(Resource id #108) >> fgets(Resource id #108, 4096) >> feof(Resource id #108) >> fgets(Resource id #108, 4096) >> feof(Resource id #108) >> fclose(Resource id #108) >> unlink(/MV/webs/Repository/gallery/tmp/g2dbgitTQYC) >> Regular Output: >> Error Output: >> /usr/bin/ffmpeg: error while loading shared libraries: libavcodec.so.51: >> cannot enable executable stack as shared object requires: Permission >> denied >> Status: 127 (expected 0) >> A quick look in /usr/lib reveals: >> >> -rwxr-xr-x root root system_u:object_r:textrel_shlib_t >> /usr/lib/libavcodec-CVS.so >> lrwxrwxrwx root root system_u:object_r:lib_t >> /usr/lib/libavcodec.so -> libavcodec-CVS.so >> lrwxrwxrwx root root system_u:object_r:lib_t >> /usr/lib/libavcodec.so.51 -> libavcodec-CVS.so >> >> >> /var/log/audit/audit.log shows: >> >> type=SYSCALL msg=audit(1146010953.133:45163): arch=40000003 >> syscall=125 success=no exit=-13 a0=bfc5b000 a1=1000 a2=1000007 >> a3=fffff000 items=0 pid=25005 auid=1000 uid=48 gid=48 euid=48 suid=48 >> fsuid=48 egid=48 sgid=48 fsgid=48 comm="ffmpeg" exe="/usr/bin/ffmpeg" >> type=AVC msg=audit(1146010953.141:45164): avc: denied { execstack } >> for pid=25007 comm="ffmpeg" >> scontext=user_u:system_r:httpd_sys_script_t:s0 >> tcontext=user_u:system_r:httpd_sys_script_t:s0 tclass=process >> type=SYSCALL msg=audit(1146010953.141:45164): arch=40000003 >> syscall=125 success=no exit=-13 a0=bf9e8000 a1=1000 a2=1000007 >> a3=fffff000 items=0 pid=25007 auid=1000 uid=48 gid=48 euid=48 suid=48 >> fsuid=48 egid=48 sgid=48 fsgid=48 comm="ffmpeg" exe="/usr/bin/ffmpeg" >> type=AVC msg=audit(1146010953.213:45165): avc: denied { execstack } >> for pid=25009 comm="ffmpeg" >> scontext=user_u:system_r:httpd_sys_script_t:s0 >> tcontext=user_u:system_r:httpd_sys_script_t:s0 tclass=process >> type=SYSCALL msg=audit(1146010953.213:45165): arch=40000003 >> syscall=125 success=no exit=-13 a0=bfbe6000 a1=1000 a2=1000007 >> a3=fffff000 items=0 pid=25009 auid=1000 uid=48 gid=48 euid=48 suid=48 >> fsuid=48 egid=48 sgid=48 fsgid=48 comm="ffmpeg" exe="/usr/bin/ffmpeg" >> type=AVC msg=audit(1146010953.221:45166): avc: denied { execstack } >> for pid=25011 comm="ffmpeg" >> scontext=user_u:system_r:httpd_sys_script_t:s0 >> tcontext=user_u:system_r:httpd_sys_script_t:s0 tclass=process >> type=SYSCALL msg=audit(1146010953.221:45166): arch=40000003 >> syscall=125 success=no exit=-13 a0=bf89b000 a1=1000 a2=1000007 >> a3=fffff000 items=0 pid=25011 auid=1000 uid=48 gid=48 euid=48 suid=48 >> fsuid=48 egid=48 sgid=48 fsgid=48 comm="ffmpeg" exe="/usr/bin/ffmpeg" >> when I run the page producing the error output. >> >> I tried to set the allow_execstack boolean but it didn't make any >> difference. >> >> I'm out of ideas on this one - any help appreciated :) >> >> Robert Foster >> General Manager >> Mountain Visions P/L http://mountainvisions.com.au >> >> Mobile: 0418 131 065 >> > I had the same problem when using Kino which also uses ffmpeg. Here is > what I did and it works. > > execstack -c /usr/lib/libmp3lame.so.0 > execstack -c /usr/lib/libxvidcore.so.4 Please submit bugs on these to Kino and ffmpeg. > chcon -t textrel_shlib_t /usr/lib/libavformat.so.50 > > chcon -t textrel_shlib_t /usr/lib/libavutil.so.49 > chcon -t textrel_shlib_t /usr/lib/libavcodec.so.51 > > This also takes care of the problem with lame-3.96.1-10.rhfc5.at, > libxvidcore4-1.1.0-8.rhfc5.at, > libavformat50-0.4.9-14_cvs20060301.rhfc5.at, > libavutil49-0.4.9-14_cvs20060301.rhfc5.at, and > libavcodec51-0.4.9-14_cvs20060301.rhfc5.at. > > Regards, > John > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From fedora at grifent.com Tue May 2 18:07:37 2006 From: fedora at grifent.com (John Griffiths) Date: Tue, 02 May 2006 14:07:37 -0400 Subject: fedora-selinux-list Digest, Vol 26, Issue 32 In-Reply-To: <44567BEE.8060506@redhat.com> References: <20060427095825.413A07309E@hormel.redhat.com> <4450F588.4070701@grifent.com> <44567BEE.8060506@redhat.com> Message-ID: <44579FE9.2060600@grifent.com> Daniel J Walsh wrote: > John Griffiths wrote: >> >> >> fedora-selinux-list-request at redhat.com wrote: >>> >>> Subject: >>> Error running ffmpeg due to permission denied on library >>> From: >>> "Robert Foster" >>> Date: >>> Thu, 27 Apr 2006 12:41:09 +1000 >>> To: >>> >>> >>> To: >>> >>> >>> >>> Hi, >>> I'm trying to get ffmpeg working for Gallery2 on FC5, and getting >>> the following error (from the debug message via Gallery): >>> >>> snip >> I had the same problem when using Kino which also uses ffmpeg. Here >> is what I did and it works. >> >> execstack -c /usr/lib/libmp3lame.so.0 >> execstack -c /usr/lib/libxvidcore.so.4 > Please submit bugs on these to Kino and ffmpeg. Actually /usr/lib/libmp3lame.so.0 is part of lame-3.96.1-10.rhfc5.at and libxvidcore4-1.1.0-8.rhfc5.at both from ATRpms.net. I'll let the people at ATRpm know. OT: Wish I had changed the subject of the reply in my original. Sorry. Regards, John From Axel.Thimm at ATrpms.net Tue May 2 18:18:32 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 2 May 2006 20:18:32 +0200 Subject: lame/libxvidcore & execstack (was: fedora-selinux-list Digest, Vol 26, Issue 32) In-Reply-To: <44579FE9.2060600@grifent.com> References: <20060427095825.413A07309E@hormel.redhat.com> <4450F588.4070701@grifent.com> <44567BEE.8060506@redhat.com> <44579FE9.2060600@grifent.com> Message-ID: <20060502181832.GA15337@neu.nirvana> On Tue, May 02, 2006 at 02:07:37PM -0400, John Griffiths wrote: > Daniel J Walsh wrote: > >John Griffiths wrote: > >>fedora-selinux-list-request at redhat.com wrote: > >>>Subject: > >>>Error running ffmpeg due to permission denied on library > >>>From: > >>>"Robert Foster" > >>>Date: > >>>Thu, 27 Apr 2006 12:41:09 +1000 > >>>To: > >>> > >>> > >>>To: > >>> > >>> > >>> > >>>Hi, > >>>I'm trying to get ffmpeg working for Gallery2 on FC5, and getting > >>>the following error (from the debug message via Gallery): > >>> > >>>snip > >>I had the same problem when using Kino which also uses ffmpeg. Here > >>is what I did and it works. > >> > >> execstack -c /usr/lib/libmp3lame.so.0 > >> execstack -c /usr/lib/libxvidcore.so.4 > >Please submit bugs on these to Kino and ffmpeg. > Actually /usr/lib/libmp3lame.so.0 is part of lame-3.96.1-10.rhfc5.at and > libxvidcore4-1.1.0-8.rhfc5.at both from ATRpms.net. > > I'll let the people at ATRpm know. Is this considered a packaging or upstream issue? If packaging: What is the recommended way to fix it specfile-wise? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at grifent.com Tue May 2 18:27:24 2006 From: fedora at grifent.com (John Griffiths) Date: Tue, 02 May 2006 14:27:24 -0400 Subject: lame/libxvidcore & execstack In-Reply-To: <20060502181832.GA15337@neu.nirvana> References: <20060427095825.413A07309E@hormel.redhat.com> <4450F588.4070701@grifent.com> <44567BEE.8060506@redhat.com> <44579FE9.2060600@grifent.com> <20060502181832.GA15337@neu.nirvana> Message-ID: <4457A48C.8050709@grifent.com> Axel Thimm wrote: > On Tue, May 02, 2006 at 02:07:37PM -0400, John Griffiths wrote: > >> Daniel J Walsh wrote: >> >>> John Griffiths wrote: >>> >>>> fedora-selinux-list-request at redhat.com wrote: >>>> >>>>> Subject: >>>>> Error running ffmpeg due to permission denied on library >>>>> From: >>>>> "Robert Foster" >>>>> Date: >>>>> Thu, 27 Apr 2006 12:41:09 +1000 >>>>> To: >>>>> >>>>> >>>>> To: >>>>> >>>>> >>>>> >>>>> Hi, >>>>> I'm trying to get ffmpeg working for Gallery2 on FC5, and getting >>>>> the following error (from the debug message via Gallery): >>>>> >>>>> snip >>>>> >>>> I had the same problem when using Kino which also uses ffmpeg. Here >>>> is what I did and it works. >>>> >>>> execstack -c /usr/lib/libmp3lame.so.0 >>>> execstack -c /usr/lib/libxvidcore.so.4 >>>> >>> Please submit bugs on these to Kino and ffmpeg. >>> >> Actually /usr/lib/libmp3lame.so.0 is part of lame-3.96.1-10.rhfc5.at and >> libxvidcore4-1.1.0-8.rhfc5.at both from ATRpms.net. >> >> I'll let the people at ATRpm know. >> > > Is this considered a packaging or upstream issue? > > If packaging: What is the recommended way to fix it specfile-wise? > From this, I find the folks at ATRpms know. From Axel.Thimm at ATrpms.net Tue May 2 18:34:34 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 2 May 2006 20:34:34 +0200 Subject: lame/libxvidcore & execstack In-Reply-To: <4457A48C.8050709@grifent.com> References: <20060427095825.413A07309E@hormel.redhat.com> <4450F588.4070701@grifent.com> <44567BEE.8060506@redhat.com> <44579FE9.2060600@grifent.com> <20060502181832.GA15337@neu.nirvana> <4457A48C.8050709@grifent.com> Message-ID: <20060502183434.GB15337@neu.nirvana> On Tue, May 02, 2006 at 02:27:24PM -0400, John Griffiths wrote: > Axel Thimm wrote: > >On Tue, May 02, 2006 at 02:07:37PM -0400, John Griffiths wrote: > >>Daniel J Walsh wrote: > >>>John Griffiths wrote: > >>>>fedora-selinux-list-request at redhat.com wrote: > >>>>>Subject: > >>>>>Error running ffmpeg due to permission denied on library > >>>>>From: > >>>>>"Robert Foster" > >>>>>Date: > >>>>>Thu, 27 Apr 2006 12:41:09 +1000 > >>>>>To: > >>>>> > >>>>> > >>>>>To: > >>>>> > >>>>>I'm trying to get ffmpeg working for Gallery2 on FC5, and getting > >>>>>the following error (from the debug message via Gallery): > >>>>I had the same problem when using Kino which also uses ffmpeg. Here > >>>>is what I did and it works. > >>>> > >>>> execstack -c /usr/lib/libmp3lame.so.0 > >>>> execstack -c /usr/lib/libxvidcore.so.4 > >>>> > >>>Please submit bugs on these to Kino and ffmpeg. > >>> > >>Actually /usr/lib/libmp3lame.so.0 is part of lame-3.96.1-10.rhfc5.at and > >>libxvidcore4-1.1.0-8.rhfc5.at both from ATRpms.net. > >> > >>I'll let the people at ATRpm know. > > > >Is this considered a packaging or upstream issue? > > > >If packaging: What is the recommended way to fix it specfile-wise? > > > From this, I find the folks at ATRpms know. I'm very sure they'll be just as confused as I am ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwalsh at redhat.com Tue May 2 19:09:03 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 02 May 2006 15:09:03 -0400 Subject: lame/libxvidcore & execstack In-Reply-To: <20060502183434.GB15337@neu.nirvana> References: <20060427095825.413A07309E@hormel.redhat.com> <4450F588.4070701@grifent.com> <44567BEE.8060506@redhat.com> <44579FE9.2060600@grifent.com> <20060502181832.GA15337@neu.nirvana> <4457A48C.8050709@grifent.com> <20060502183434.GB15337@neu.nirvana> Message-ID: <4457AE4F.6010008@redhat.com> Axel Thimm wrote: > On Tue, May 02, 2006 at 02:27:24PM -0400, John Griffiths wrote: > >> Axel Thimm wrote: >> >>> On Tue, May 02, 2006 at 02:07:37PM -0400, John Griffiths wrote: >>> >>>> Daniel J Walsh wrote: >>>> >>>>> John Griffiths wrote: >>>>> >>>>>> fedora-selinux-list-request at redhat.com wrote: >>>>>> >>>>>>> Subject: >>>>>>> Error running ffmpeg due to permission denied on library >>>>>>> From: >>>>>>> "Robert Foster" >>>>>>> Date: >>>>>>> Thu, 27 Apr 2006 12:41:09 +1000 >>>>>>> To: >>>>>>> >>>>>>> >>>>>>> To: >>>>>>> >>>>>>> I'm trying to get ffmpeg working for Gallery2 on FC5, and getting >>>>>>> the following error (from the debug message via Gallery): >>>>>>> > > >>>>>> I had the same problem when using Kino which also uses ffmpeg. Here >>>>>> is what I did and it works. >>>>>> >>>>>> execstack -c /usr/lib/libmp3lame.so.0 >>>>>> execstack -c /usr/lib/libxvidcore.so.4 >>>>>> >>>>>> >>>>> Please submit bugs on these to Kino and ffmpeg. >>>>> >>>>> >>>> Actually /usr/lib/libmp3lame.so.0 is part of lame-3.96.1-10.rhfc5.at and >>>> libxvidcore4-1.1.0-8.rhfc5.at both from ATRpms.net. >>>> >>>> I'll let the people at ATRpm know. >>>> >>> Is this considered a packaging or upstream issue? >>> >>> If packaging: What is the recommended way to fix it specfile-wise? >>> >>> >> From this, I find the folks at ATRpms know. >> > > I'm very sure they'll be just as confused as I am ;) > Point them at http://people.redhat.com/~drepper/selinux-mem.html and http://people.redhat.com/drepper/nonselsec.pdf > ------------------------------------------------------------------------ > > -- > 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 May 2 19:16:01 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 02 May 2006 15:16:01 -0400 Subject: Add SELinux protection to Pure-FTPd In-Reply-To: <44523AB3.2050507@city-fan.org> References: <1145023318.17185.12.camel@moss-spartans.epoch.ncsc.mil> <44523AB3.2050507@city-fan.org> Message-ID: <4457AFF1.7020104@redhat.com> Paul Howarth wrote: > Aurelien Bompard wrote: >> Stephen Smalley wrote: >>> policy_module(pureftpd, 1.0) is preferred syntax going forward. >>> If you use policy_module() macro, you'll get the kernel class and >>> permission requires as part of it, so you won't need to explicitly >>> specify them each time. >> >> Yay ! Done that. >> >>> Does it truly need write access? The library always tries to open rw >>> first, then falls back to read-only if it cannot open rw, so even just >>> reading utmp will show up in avc messages as a rw attempt. Try just >>> allowing read, and dontaudit'ing the write permission. >> >> That's right, it only needs read access. I've added: >> init_read_utmp(ftpd_t) >> init_dontaudit_write_utmp(ftpd_t) >> to the module (picked from the policy sources) >> >>> Macros aka interfaces are preferred, as they preserve >>> modularity/encapsulation and thus make your module more portable to >>> other base policies. >> >> OK. I'll use sysnet_use_ldap to allow LDAP access then. >> >>> I don't think you want to put it in /usr/share/selinux/targeted (as >>> that >>> could conflict in the future with the policy package), but I would >>> suggest putting it under /usr/share/selinux/ or similar to >>> keep all policy modules under that selinux tree, unless that also >>> presents some kind of conflict problem? >> >> Looks good to me, except I've placed it >> in /usr/share/selinux/packages/ to avoid the base and >> targeted >> dirs being buried under a ton of packages dirs in the future. > > I've been trying to take this sort of approach with a package I'm > developing. Two issues concern me at the moment: > > 1. I build the policy module from te/fc/if files during the package's > "build" script. I get output like this: > > + /usr/bin/make -C SELinux -f /usr/share/selinux/devel/Makefile > make: Entering directory > `/nis-home/phowarth/BUILD/BUILD/contagged-0.3/SELinux' > Compiling targeted contagged module > /usr/bin/checkmodule: loading policy configuration from > tmp/contagged.tmp > /usr/bin/checkmodule: policy configuration loaded > /usr/bin/checkmodule: writing binary representation (version 5) to > tmp/contagged.mod > Creating targeted contagged.pp policy package > make: Leaving directory > `/nis-home/phowarth/BUILD/BUILD/contagged-0.3/SELinux' > > This suggests to me that the resulting contagged.pp module is specific > to the targeted policy (which I'm running on the host system), so it > would presumably not work with other policies. Is that right? So would > it be better to build and install the policy at package install time > rather than package build time? Or could there be separate modules for > each policy? If so, how would they be built? You can probably build policy agnostic at this time. Your gen_requires should suck in all of the required types and the code should pretty much work the same on strict/targeted or mls machines. Problems could arise in the future and on certain machines the semodule will fail. We do not intend to build specific loadable policy for different policy types at this time. So when/if we ship an apache.pp file it should work on targeted, strict, mls ... policies. > > 2. A mock build fails, presumably because mock does not mount /selinux? > > + /usr/bin/make -C SELinux -f /usr/share/selinux/devel/Makefile > cat: /selinux/mls: No such file or directory > make: Entering directory `/builddir/build/BUILD/contagged-0.3/SELinux' > /usr/share/selinux/devel/Makefile:14: > /usr/share/selinux/targeted/include/Makefile: No such file or directory > make: *** No rule to make target > `/usr/share/selinux/targeted/include/Makefile'. Stop. > make: Leaving directory `/builddir/build/BUILD/contagged-0.3/SELinux' > error: Bad exit status from /var/tmp/rpm-tmp.42152 (%build) > > This also suggests that install-time module building is needed, at > least for anything intending to go into Fedora Extras, where mock is > used for the buildsystem. I guess that would present a problem if the > admin of the system wanted to change to a different policy - the > module would have to be rebuilt somehow. > We build policy all of the time on machines with out policy. This is a bug in the Makefile, it should take a sensible default if /selinux/mnt does not exist. Please bugzilla. > Paul. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From kcarr at tresys.com Tue May 2 19:28:04 2006 From: kcarr at tresys.com (Kevin Carr) Date: Tue, 2 May 2006 15:28:04 -0400 Subject: [ANN] Setools-2.4 Message-ID: <6FE441CD9F0C0C479F2D88F959B0158816FEE5@exchange.columbia.tresys.com> A new version of setools is available on the Tresys website. http://www.tresys.com/selinux/ Change-Log ========== apol: File contexts tab now allows for MLS range searching if the loaded database is from a MLS filesystem. Policy statistics dialog now shows MLS and ocontexts summaries. libapol: Added support for loading base policies containing optionals. Added support for searching range transitions containing attributes. libseaudit: Bugfix to support parsing FC5-style audit logs. seaudit: Added date filters. secmds: Added support to indexcon and searchcon for MLS filesytems. Added support to findcon and replcon for MLS filesystems. sechecker: Added incomplete network access (inc_net_access) module. Added unreachable domains (unreachable_doms) module. Added impossible range transitions (imp_range_trans) module. sesearch: Allow user to search range transitions by attributes and indirect matching. Added RBAC searching. Kevin Carr Tresys Technology 410.290.1411 x137 From Axel.Thimm at ATrpms.net Tue May 2 19:19:43 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 2 May 2006 21:19:43 +0200 Subject: lame/libxvidcore & execstack In-Reply-To: <4457AE4F.6010008@redhat.com> References: <20060427095825.413A07309E@hormel.redhat.com> <4450F588.4070701@grifent.com> <44567BEE.8060506@redhat.com> <44579FE9.2060600@grifent.com> <20060502181832.GA15337@neu.nirvana> <4457A48C.8050709@grifent.com> <20060502183434.GB15337@neu.nirvana> <4457AE4F.6010008@redhat.com> Message-ID: <20060502191943.GA18631@neu.nirvana> On Tue, May 02, 2006 at 03:09:03PM -0400, Daniel J Walsh wrote: > Axel Thimm wrote: > >On Tue, May 02, 2006 at 02:27:24PM -0400, John Griffiths wrote: > > > >>Axel Thimm wrote: > >> > >>>On Tue, May 02, 2006 at 02:07:37PM -0400, John Griffiths wrote: > >>> > >>>>Daniel J Walsh wrote: > >>>> > >>>>>John Griffiths wrote: > >>>>> > >>>>>>fedora-selinux-list-request at redhat.com wrote: > >>>>>> > >>>>>>>Subject: > >>>>>>>Error running ffmpeg due to permission denied on library > >>>>>>>From: > >>>>>>>"Robert Foster" > >>>>>>>Date: > >>>>>>>Thu, 27 Apr 2006 12:41:09 +1000 > >>>>>>>To: > >>>>>>> > >>>>>>> > >>>>>>>To: > >>>>>>> > >>>>>>>I'm trying to get ffmpeg working for Gallery2 on FC5, and getting > >>>>>>>the following error (from the debug message via Gallery): > >>>>>>> > > > > > >>>>>>I had the same problem when using Kino which also uses ffmpeg. Here > >>>>>>is what I did and it works. > >>>>>> > >>>>>> execstack -c /usr/lib/libmp3lame.so.0 > >>>>>> execstack -c /usr/lib/libxvidcore.so.4 > >>>>>> > >>>>>> > >>>>>Please submit bugs on these to Kino and ffmpeg. > >>>>> > >>>>> > >>>>Actually /usr/lib/libmp3lame.so.0 is part of lame-3.96.1-10.rhfc5.at > >>>>and libxvidcore4-1.1.0-8.rhfc5.at both from ATRpms.net. > >>>> > >>>>I'll let the people at ATRpm know. > >>>> > >>>Is this considered a packaging or upstream issue? > >>> > >>>If packaging: What is the recommended way to fix it specfile-wise? > >>> > >>> > >>From this, I find the folks at ATRpms know. > >> > > > >I'm very sure they'll be just as confused as I am ;) > > > > Point them at ^^^^ Them is largely myself, that's why I can tell how confused "they" will be. ;) > http://people.redhat.com/~drepper/selinux-mem.html > > and > > http://people.redhat.com/drepper/nonselsec.pdf But these reference upstream fixing, not packaging ones. Do idioms exist to cirumvent this at the packaging level (other than fixing the source and Patch0: the fix), or is the recommendation to report to upstream and wait for a fix while disabling selinux at the mean time? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwalsh at redhat.com Tue May 2 20:57:31 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 02 May 2006 16:57:31 -0400 Subject: Firefox/Flash printing In-Reply-To: <1145787895.4308.25.camel@topaz.bugfinder.co.uk> References: <1145787895.4308.25.camel@topaz.bugfinder.co.uk> Message-ID: <4457C7BB.2060700@redhat.com> Ted Rule wrote: > On my - admittedly FC4 - system, I've had a problem recently printing > from various Flash pages on certain websites. This is with the > combination of: > > Flash 7.0.63 > Firefox 1.0.8 > selinux-policy-strict-1.27.1-2.27 > > An example of the problem is to be found here ( build the jigsaw an > print it out): > > http://www.bbc.co.uk/cbeebies/funandgames/jigsaw.shtml > > ( Yes, fixing the problem was prompted by my desire not to let 4-year > olds have to know how to temporarily set SELinux to permissive just so > as to print out their games results! ) > > After some burrowing around with policy tweaks and enableaudit, the > minimum extra policy I had to allow was this: > > allow user_mozilla_t cupsd_t:dir { getattr search }; > allow user_mozilla_t cupsd_t:file { read }; > Mozilla is checking if cups is running? > ( i.e. let mozilla plugins read /proc/xxx for the cups daemon process ) > > With enableaudit in place, it seems that the Flash plugin seems to > invoke a very verbose call to "ps". This, in turn, leads to lots of > denial messages as SELinux stops the plugin from seeing /proc/xxx for > all the system processes. The fixup seems to be to allow Flash to read > status and cmdline for the cupsd process itself; once it has found that > process, the existing print/lpr permissions for user_mozilla_t seem to > be enough to allow it to proceed. This still leaves a flood of denial > messages, but at least the printer works. > > My suspicion is that the plugin decodes the output of something like "ps > axww" to determine the flavour of the local print server. Since the > plugin is probably designed to run on a number of platforms, it > presumably has to dynamically probe for the print processor type. > > Given what I see, it would not surprise me that this behaviour exists in > some sort of generic print-API within Flash, and hence the problem may > be reasonably widespread on "Flashy" websites. > > Can anyone confirm/deny whether this permission exists in the FC5 strict > and/or targeted policies? > All of the messages below will be dontaudited, I believe. We can add the allow mozilla to read cups /proc entry. One strange thing I see is why is firefox trying to connect to port 5000? > > Sample enableaudit trace of a print Job invocation - with my patch set > to auditallow: > > Apr 23 10:57:26 workstation kernel: audit(1145786246.469:2567): avc: > denied { getattr } for pid=4883 comm="ps" name="1" dev=proc ino=65538 > scontext=user_u:user_r:user_mozilla_t tcontext=system_u:system_r:init_t > tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.469:2568): avc: > denied { getattr } for pid=4883 comm="ps" name="2" dev=proc ino=131074 > scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:kernel_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.469:2569): avc: > denied { getattr } for pid=4883 comm="ps" name="3" dev=proc ino=196610 > scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:kernel_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.469:2570): avc: > denied { getattr } for pid=4883 comm="ps" name="4" dev=proc ino=262146 > scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:kernel_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.469:2571): avc: > denied { getattr } for pid=4883 comm="ps" name="5" dev=proc ino=327682 > scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:kernel_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.469:2572): avc: > denied { getattr } for pid=4883 comm="ps" name="9" dev=proc ino=589826 > scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:kernel_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.469:2573): avc: > denied { getattr } for pid=4883 comm="ps" name="10" dev=proc > ino=655362 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:kernel_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.469:2574): avc: > denied { getattr } for pid=4883 comm="ps" name="242" dev=proc > ino=15859714 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:kernel_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.469:2575): avc: > denied { getattr } for pid=4883 comm="ps" name="296" dev=proc > ino=19398658 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:kernel_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.469:2576): avc: > denied { getattr } for pid=4883 comm="ps" name="297" dev=proc > ino=19464194 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:kernel_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.469:2577): avc: > denied { getattr } for pid=4883 comm="ps" name="299" dev=proc > ino=19595266 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:kernel_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.469:2578): avc: > denied { getattr } for pid=4883 comm="ps" name="298" dev=proc > ino=19529730 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:kernel_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.469:2579): avc: > denied { getattr } for pid=4883 comm="ps" name="386" dev=proc > ino=25296898 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:kernel_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.473:2580): avc: > denied { getattr } for pid=4883 comm="ps" name="466" dev=proc > ino=30539778 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:kernel_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.473:2581): avc: > denied { getattr } for pid=4883 comm="ps" name="485" dev=proc > ino=31784962 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:kernel_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.473:2582): avc: > denied { getattr } for pid=4883 comm="ps" name="539" dev=proc > ino=35323906 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:kernel_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.473:2583): avc: > denied { getattr } for pid=4883 comm="ps" name="681" dev=proc > ino=44630018 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:udev_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.473:2584): avc: > denied { getattr } for pid=4883 comm="ps" name="1212" dev=proc > ino=79429634 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:kernel_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.473:2585): avc: > denied { getattr } for pid=4883 comm="ps" name="1213" dev=proc > ino=79495170 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:kernel_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.473:2586): avc: > denied { getattr } for pid=4883 comm="ps" name="1655" dev=proc > ino=108462082 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:kernel_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.473:2587): avc: > denied { getattr } for pid=4883 comm="ps" name="1658" dev=proc > ino=108658690 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:kernel_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.473:2588): avc: > denied { getattr } for pid=4883 comm="ps" name="1661" dev=proc > ino=108855298 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:kernel_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.473:2589): avc: > denied { getattr } for pid=4883 comm="ps" name="1664" dev=proc > ino=109051906 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:kernel_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.473:2590): avc: > denied { getattr } for pid=4883 comm="ps" name="1667" dev=proc > ino=109248514 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:kernel_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.473:2591): avc: > denied { getattr } for pid=4883 comm="ps" name="2103" dev=proc > ino=137822210 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:syslogd_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.473:2592): avc: > denied { getattr } for pid=4883 comm="ps" name="2239" dev=proc > ino=146735106 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:automount_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.473:2593): avc: > denied { getattr } for pid=4883 comm="ps" name="2253" dev=proc > ino=147652610 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:fsdaemon_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.473:2594): avc: > denied { getattr } for pid=4883 comm="ps" name="2261" dev=proc > ino=148176898 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:apmd_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.473:2595): avc: > denied { getattr } for pid=4883 comm="ps" name="2269" dev=proc > ino=148701186 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:hplip_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.473:2596): avc: > denied { getattr } for pid=4883 comm="ps" name="2273" dev=proc > ino=148963330 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:hplip_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.473:2597): avc: > granted { getattr } for pid=4883 comm="ps" name="2284" dev=proc > ino=149684226 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:cupsd_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.473:2598): avc: > granted { search } for pid=4883 comm="ps" name="2284" dev=proc > ino=149684226 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:cupsd_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.473:2599): avc: > granted { read } for pid=4883 comm="ps" name="stat" dev=proc > ino=149684237 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:cupsd_t tclass=file > Apr 23 10:57:26 workstation kernel: audit(1145786246.473:2600): avc: > granted { read } for pid=4883 comm="ps" name="stat" dev=proc > ino=149684237 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:cupsd_t tclass=file > Apr 23 10:57:26 workstation kernel: audit(1145786246.477:2601): avc: > granted { search } for pid=4883 comm="ps" name="2284" dev=proc > ino=149684226 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:cupsd_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.477:2602): avc: > granted { read } for pid=4883 comm="ps" name="status" dev=proc > ino=149684228 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:cupsd_t tclass=file > Apr 23 10:57:26 workstation kernel: audit(1145786246.477:2603): avc: > granted { read } for pid=4883 comm="ps" name="status" dev=proc > ino=149684228 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:cupsd_t tclass=file > Apr 23 10:57:26 workstation kernel: audit(1145786246.477:2604): avc: > granted { search } for pid=4883 comm="ps" name="2284" dev=proc > ino=149684226 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:cupsd_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.477:2605): avc: > granted { read } for pid=4883 comm="ps" name="cmdline" dev=proc > ino=149684236 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:cupsd_t tclass=file > Apr 23 10:57:26 workstation kernel: audit(1145786246.477:2606): avc: > granted { read } for pid=4883 comm="ps" name="cmdline" dev=proc > ino=149684236 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:cupsd_t tclass=file > Apr 23 10:57:26 workstation kernel: audit(1145786246.477:2607): avc: > denied { getattr } for pid=4883 comm="ps" name="2341" dev=proc > ino=153419778 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:ntpd_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.477:2608): avc: > denied { getattr } for pid=4883 comm="ps" name="2363" dev=proc > ino=154861570 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:sendmail_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.477:2609): avc: > denied { getattr } for pid=4883 comm="ps" name="2369" dev=proc > ino=155254786 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:sendmail_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.477:2610): avc: > denied { getattr } for pid=4883 comm="ps" name="2379" dev=proc > ino=155910146 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:sendmail_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.477:2611): avc: > denied { getattr } for pid=4883 comm="ps" name="2390" dev=proc > ino=156631042 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:spamd_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.477:2612): avc: > denied { getattr } for pid=4883 comm="ps" name="2399" dev=proc > ino=157220866 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:gpm_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.477:2613): avc: > denied { getattr } for pid=4883 comm="ps" name="2407" dev=proc > ino=157745154 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.477:2614): avc: > denied { getattr } for pid=4883 comm="ps" name="2419" dev=proc > ino=158531586 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:spamd_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.477:2615): avc: > denied { getattr } for pid=4883 comm="ps" name="2420" dev=proc > ino=158597122 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:spamd_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.477:2616): avc: > denied { getattr } for pid=4883 comm="ps" name="2421" dev=proc > ino=158662658 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:spamd_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.477:2617): avc: > denied { getattr } for pid=4883 comm="ps" name="2422" dev=proc > ino=158728194 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:spamd_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.481:2618): avc: > denied { getattr } for pid=4883 comm="ps" name="2423" dev=proc > ino=158793730 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:spamd_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.481:2619): avc: > denied { getattr } for pid=4883 comm="ps" name="2441" dev=proc > ino=159973378 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:xfs_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.481:2620): avc: > denied { getattr } for pid=4883 comm="ps" name="2449" dev=proc > ino=160497666 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:smbd_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.481:2621): avc: > denied { getattr } for pid=4883 comm="ps" name="2451" dev=proc > ino=160628738 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:smbd_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.481:2622): avc: > denied { getattr } for pid=4883 comm="ps" name="2452" dev=proc > ino=160694274 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:nmbd_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.481:2623): avc: > denied { getattr } for pid=4883 comm="ps" name="2468" dev=proc > ino=161742850 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.481:2624): avc: > denied { getattr } for pid=4883 comm="ps" name="2484" dev=proc > ino=162791426 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:system_dbusd_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.481:2625): avc: > denied { getattr } for pid=4883 comm="ps" name="2496" dev=proc > ino=163577858 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:cupsd_config_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.481:2626): avc: > denied { getattr } for pid=4883 comm="ps" name="2505" dev=proc > ino=164167682 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:hald_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.481:2627): avc: > denied { getattr } for pid=4883 comm="ps" name="2510" dev=proc > ino=164495362 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:hald_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.481:2628): avc: > denied { getattr } for pid=4883 comm="ps" name="2518" dev=proc > ino=165019650 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:hald_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.481:2629): avc: > denied { getattr } for pid=4883 comm="ps" name="2520" dev=proc > ino=165150722 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:hald_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.481:2630): avc: > denied { getattr } for pid=4883 comm="ps" name="2526" dev=proc > ino=165543938 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:hald_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.481:2631): avc: > denied { getattr } for pid=4883 comm="ps" name="2538" dev=proc > ino=166330370 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:kernel_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.481:2632): avc: > denied { getattr } for pid=4883 comm="ps" name="2542" dev=proc > ino=166592514 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:hald_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.481:2633): avc: > denied { getattr } for pid=4883 comm="ps" name="2581" dev=proc > ino=169148418 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:mdadm_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.481:2634): avc: > denied { getattr } for pid=4883 comm="ps" name="2588" dev=proc > ino=169607170 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:getty_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.481:2635): avc: > denied { getattr } for pid=4883 comm="ps" name="2589" dev=proc > ino=169672706 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:getty_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.481:2636): avc: > denied { getattr } for pid=4883 comm="ps" name="2590" dev=proc > ino=169738242 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:getty_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.481:2637): avc: > denied { getattr } for pid=4883 comm="ps" name="2591" dev=proc > ino=169803778 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:getty_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.481:2638): avc: > denied { getattr } for pid=4883 comm="ps" name="2592" dev=proc > ino=169869314 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:getty_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.485:2639): avc: > denied { getattr } for pid=4883 comm="ps" name="2593" dev=proc > ino=169934850 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:getty_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.485:2640): avc: > denied { getattr } for pid=4883 comm="ps" name="2594" dev=proc > ino=170000386 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:initrc_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.485:2641): avc: > denied { getattr } for pid=4883 comm="ps" name="2798" dev=proc > ino=183369730 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:xdm_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.485:2642): avc: > denied { getattr } for pid=4883 comm="ps" name="2855" dev=proc > ino=187105282 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:xdm_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.485:2643): avc: > denied { getattr } for pid=4883 comm="ps" name="2865" dev=proc > ino=187760642 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:xdm_xserver_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.485:2644): avc: > denied { getattr } for pid=4883 comm="ps" name="3721" dev=proc > ino=243859458 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.485:2645): avc: > denied { getattr } for pid=4883 comm="ps" name="3723" dev=proc > ino=243990530 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.485:2646): avc: > denied { getattr } for pid=4883 comm="ps" name="3724" dev=proc > ino=244056066 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.485:2647): avc: > denied { getattr } for pid=4883 comm="ps" name="3726" dev=proc > ino=244187138 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.485:2648): avc: > denied { getattr } for pid=4883 comm="ps" name="3727" dev=proc > ino=244252674 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.485:2649): avc: > denied { getattr } for pid=4883 comm="ps" name="3728" dev=proc > ino=244318210 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.485:2650): avc: > denied { getattr } for pid=4883 comm="ps" name="3729" dev=proc > ino=244383746 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.485:2651): avc: > denied { getattr } for pid=4883 comm="ps" name="3730" dev=proc > ino=244449282 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.485:2652): avc: > denied { getattr } for pid=4883 comm="ps" name="3731" dev=proc > ino=244514818 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.485:2653): avc: > denied { getattr } for pid=4883 comm="ps" name="3754" dev=proc > ino=246022146 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.485:2654): avc: > denied { getattr } for pid=4883 comm="ps" name="3756" dev=proc > ino=246153218 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.485:2655): avc: > denied { getattr } for pid=4883 comm="ps" name="3760" dev=proc > ino=246415362 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.485:2656): avc: > denied { getattr } for pid=4883 comm="ps" name="3761" dev=proc > ino=246480898 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.485:2657): avc: > denied { getattr } for pid=4883 comm="ps" name="3763" dev=proc > ino=246611970 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.485:2658): avc: > denied { getattr } for pid=4883 comm="ps" name="3764" dev=proc > ino=246677506 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.485:2659): avc: > denied { getattr } for pid=4883 comm="ps" name="3765" dev=proc > ino=246743042 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.485:2660): avc: > denied { getattr } for pid=4883 comm="ps" name="3767" dev=proc > ino=246874114 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.489:2661): avc: > denied { getattr } for pid=4883 comm="ps" name="3768" dev=proc > ino=246939650 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.489:2662): avc: > denied { getattr } for pid=4883 comm="ps" name="3769" dev=proc > ino=247005186 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.489:2663): avc: > denied { getattr } for pid=4883 comm="ps" name="3770" dev=proc > ino=247070722 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.489:2664): avc: > denied { getattr } for pid=4883 comm="ps" name="3772" dev=proc > ino=247201794 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.489:2665): avc: > denied { getattr } for pid=4883 comm="ps" name="3773" dev=proc > ino=247267330 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.489:2666): avc: > denied { getattr } for pid=4883 comm="ps" name="3797" dev=proc > ino=248840194 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.489:2667): avc: > denied { getattr } for pid=4883 comm="ps" name="3799" dev=proc > ino=248971266 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.489:2668): avc: > denied { getattr } for pid=4883 comm="ps" name="3800" dev=proc > ino=249036802 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.489:2669): avc: > denied { getattr } for pid=4883 comm="ps" name="3802" dev=proc > ino=249167874 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.489:2670): avc: > denied { getattr } for pid=4883 comm="ps" name="3803" dev=proc > ino=249233410 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.489:2671): avc: > denied { getattr } for pid=4883 comm="ps" name="3804" dev=proc > ino=249298946 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.489:2672): avc: > denied { getattr } for pid=4883 comm="ps" name="3805" dev=proc > ino=249364482 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.489:2673): avc: > denied { getattr } for pid=4883 comm="ps" name="3806" dev=proc > ino=249430018 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.489:2674): avc: > denied { getattr } for pid=4883 comm="ps" name="3807" dev=proc > ino=249495554 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.489:2675): avc: > denied { getattr } for pid=4883 comm="ps" name="3833" dev=proc > ino=251199490 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.489:2676): avc: > denied { getattr } for pid=4883 comm="ps" name="3835" dev=proc > ino=251330562 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.489:2677): avc: > denied { getattr } for pid=4883 comm="ps" name="3836" dev=proc > ino=251396098 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.489:2678): avc: > denied { getattr } for pid=4883 comm="ps" name="3838" dev=proc > ino=251527170 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.489:2679): avc: > denied { getattr } for pid=4883 comm="ps" name="3839" dev=proc > ino=251592706 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.493:2680): avc: > denied { getattr } for pid=4883 comm="ps" name="3840" dev=proc > ino=251658242 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.493:2681): avc: > denied { getattr } for pid=4883 comm="ps" name="3841" dev=proc > ino=251723778 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.493:2682): avc: > denied { getattr } for pid=4883 comm="ps" name="3842" dev=proc > ino=251789314 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.493:2683): avc: > denied { getattr } for pid=4883 comm="ps" name="3843" dev=proc > ino=251854850 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.493:2684): avc: > denied { getattr } for pid=4883 comm="ps" name="3866" dev=proc > ino=253362178 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.493:2685): avc: > denied { getattr } for pid=4883 comm="ps" name="3868" dev=proc > ino=253493250 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.493:2686): avc: > denied { getattr } for pid=4883 comm="ps" name="3869" dev=proc > ino=253558786 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.493:2687): avc: > denied { getattr } for pid=4883 comm="ps" name="3871" dev=proc > ino=253689858 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.493:2688): avc: > denied { getattr } for pid=4883 comm="ps" name="3872" dev=proc > ino=253755394 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.493:2689): avc: > denied { getattr } for pid=4883 comm="ps" name="3873" dev=proc > ino=253820930 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.493:2690): avc: > denied { getattr } for pid=4883 comm="ps" name="3874" dev=proc > ino=253886466 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.493:2691): avc: > denied { getattr } for pid=4883 comm="ps" name="3875" dev=proc > ino=253952002 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.493:2692): avc: > denied { getattr } for pid=4883 comm="ps" name="3876" dev=proc > ino=254017538 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.493:2693): avc: > denied { getattr } for pid=4883 comm="ps" name="3900" dev=proc > ino=255590402 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.493:2694): avc: > denied { getattr } for pid=4883 comm="ps" name="3902" dev=proc > ino=255721474 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.493:2695): avc: > denied { getattr } for pid=4883 comm="ps" name="3903" dev=proc > ino=255787010 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.493:2696): avc: > denied { getattr } for pid=4883 comm="ps" name="3905" dev=proc > ino=255918082 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.493:2697): avc: > denied { getattr } for pid=4883 comm="ps" name="3906" dev=proc > ino=255983618 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.493:2698): avc: > denied { getattr } for pid=4883 comm="ps" name="3907" dev=proc > ino=256049154 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.493:2699): avc: > denied { getattr } for pid=4883 comm="ps" name="3908" dev=proc > ino=256114690 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.493:2700): avc: > denied { getattr } for pid=4883 comm="ps" name="3911" dev=proc > ino=256311298 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.497:2701): avc: > denied { getattr } for pid=4883 comm="ps" name="3912" dev=proc > ino=256376834 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.497:2702): avc: > denied { getattr } for pid=4883 comm="ps" name="3934" dev=proc > ino=257818626 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.497:2703): avc: > denied { getattr } for pid=4883 comm="ps" name="3936" dev=proc > ino=257949698 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.497:2704): avc: > denied { getattr } for pid=4883 comm="ps" name="3937" dev=proc > ino=258015234 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.497:2705): avc: > denied { getattr } for pid=4883 comm="ps" name="3939" dev=proc > ino=258146306 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.497:2706): avc: > denied { getattr } for pid=4883 comm="ps" name="3940" dev=proc > ino=258211842 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.497:2707): avc: > denied { getattr } for pid=4883 comm="ps" name="3941" dev=proc > ino=258277378 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.497:2708): avc: > denied { getattr } for pid=4883 comm="ps" name="3942" dev=proc > ino=258342914 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.497:2709): avc: > denied { getattr } for pid=4883 comm="ps" name="3943" dev=proc > ino=258408450 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.497:2710): avc: > denied { getattr } for pid=4883 comm="ps" name="3944" dev=proc > ino=258473986 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.497:2711): avc: > denied { getattr } for pid=4883 comm="ps" name="3958" dev=proc > ino=259391490 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.497:2712): avc: > denied { getattr } for pid=4883 comm="ps" name="4028" dev=proc > ino=263979010 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_ssh_agent_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.497:2713): avc: > denied { getattr } for pid=4883 comm="ps" name="4031" dev=proc > ino=264175618 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_dbusd_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.497:2714): avc: > denied { getattr } for pid=4883 comm="ps" name="4032" dev=proc > ino=264241154 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.497:2715): avc: > denied { getattr } for pid=4883 comm="ps" name="4039" dev=proc > ino=264699906 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_gconfd_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.497:2716): avc: > denied { getattr } for pid=4883 comm="ps" name="4044" dev=proc > ino=265027586 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.497:2717): avc: > denied { getattr } for pid=4883 comm="ps" name="4046" dev=proc > ino=265158658 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_bonobo_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.497:2718): avc: > denied { getattr } for pid=4883 comm="ps" name="4048" dev=proc > ino=265289730 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.497:2719): avc: > denied { getattr } for pid=4883 comm="ps" name="4050" dev=proc > ino=265420802 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.497:2720): avc: > denied { getattr } for pid=4883 comm="ps" name="4052" dev=proc > ino=265551874 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.497:2721): avc: > denied { getattr } for pid=4883 comm="ps" name="4054" dev=proc > ino=265682946 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.497:2722): avc: > denied { getattr } for pid=4883 comm="ps" name="4056" dev=proc > ino=265814018 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.501:2723): avc: > denied { getattr } for pid=4883 comm="ps" name="4072" dev=proc > ino=266862594 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.501:2724): avc: > denied { getattr } for pid=4883 comm="ps" name="4080" dev=proc > ino=267386882 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.501:2725): avc: > denied { getattr } for pid=4883 comm="ps" name="4086" dev=proc > ino=267780098 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.501:2726): avc: > denied { getattr } for pid=4883 comm="ps" name="4090" dev=proc > ino=268042242 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.501:2727): avc: > denied { getattr } for pid=4883 comm="ps" name="4092" dev=proc > ino=268173314 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.501:2728): avc: > denied { getattr } for pid=4883 comm="ps" name="4094" dev=proc > ino=268304386 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.501:2729): avc: > denied { getattr } for pid=4883 comm="ps" name="4098" dev=proc > ino=268566530 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.501:2730): avc: > denied { getattr } for pid=4883 comm="ps" name="4100" dev=proc > ino=268697602 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_evolution_alarm_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.501:2731): avc: > denied { getattr } for pid=4883 comm="ps" name="4103" dev=proc > ino=268894210 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_gnome_vfs_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.501:2732): avc: > denied { getattr } for pid=4883 comm="ps" name="4115" dev=proc > ino=269680642 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.501:2733): avc: > denied { getattr } for pid=4883 comm="ps" name="4121" dev=proc > ino=270073858 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.501:2734): avc: > denied { getattr } for pid=4883 comm="ps" name="4124" dev=proc > ino=270270466 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.501:2735): avc: > denied { getattr } for pid=4883 comm="ps" name="4130" dev=proc > ino=270663682 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:pam_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.501:2736): avc: > denied { getattr } for pid=4883 comm="ps" name="4147" dev=proc > ino=271777794 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_evolution_server_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.501:2737): avc: > denied { getattr } for pid=4883 comm="ps" name="4178" dev=proc > ino=273809410 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_gph_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.501:2738): avc: > denied { getattr } for pid=4883 comm="ps" name="4179" dev=proc > ino=273874946 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.505:2739): avc: > denied { getattr } for pid=4883 comm="ps" name="4195" dev=proc > ino=274923522 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.505:2740): avc: > denied { getattr } for pid=4883 comm="ps" name="4308" dev=proc > ino=282329090 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_evolution_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.505:2741): avc: > denied { getattr } for pid=4883 comm="ps" name="4341" dev=proc > ino=284491778 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.505:2742): avc: > denied { getattr } for pid=4883 comm="ps" name="4342" dev=proc > ino=284557314 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.505:2743): avc: > denied { getattr } for pid=4883 comm="ps" name="4345" dev=proc > ino=284753922 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.505:2744): avc: > denied { getattr } for pid=4883 comm="ps" name="4346" dev=proc > ino=284819458 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.505:2745): avc: > denied { getattr } for pid=4883 comm="ps" name="4347" dev=proc > ino=284884994 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.505:2746): avc: > denied { getattr } for pid=4883 comm="ps" name="4348" dev=proc > ino=284950530 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.505:2747): avc: > denied { getattr } for pid=4883 comm="ps" name="4350" dev=proc > ino=285081602 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.505:2748): avc: > denied { getattr } for pid=4883 comm="ps" name="4351" dev=proc > ino=285147138 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.505:2749): avc: > denied { getattr } for pid=4883 comm="ps" name="4352" dev=proc > ino=285212674 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.505:2750): avc: > denied { getattr } for pid=4883 comm="ps" name="4353" dev=proc > ino=285278210 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.505:2751): avc: > denied { getattr } for pid=4883 comm="ps" name="4354" dev=proc > ino=285343746 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.505:2752): avc: > denied { getattr } for pid=4883 comm="ps" name="4355" dev=proc > ino=285409282 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.505:2753): avc: > denied { getattr } for pid=4883 comm="ps" name="4357" dev=proc > ino=285540354 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.505:2754): avc: > denied { getattr } for pid=4883 comm="ps" name="4414" dev=proc > ino=289275906 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_ssh_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.509:2755): avc: > denied { getattr } for pid=4883 comm="ps" name="4426" dev=proc > ino=290062338 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.509:2756): avc: > denied { getattr } for pid=4883 comm="ps" name="4428" dev=proc > ino=290193410 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.509:2757): avc: > denied { getattr } for pid=4883 comm="ps" name="4429" dev=proc > ino=290258946 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.509:2758): avc: > denied { getattr } for pid=4883 comm="ps" name="4431" dev=proc > ino=290390018 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.509:2759): avc: > denied { getattr } for pid=4883 comm="ps" name="4432" dev=proc > ino=290455554 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.509:2760): avc: > denied { getattr } for pid=4883 comm="ps" name="4433" dev=proc > ino=290521090 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.509:2761): avc: > denied { getattr } for pid=4883 comm="ps" name="4434" dev=proc > ino=290586626 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.509:2762): avc: > denied { getattr } for pid=4883 comm="ps" name="4435" dev=proc > ino=290652162 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.509:2763): avc: > denied { getattr } for pid=4883 comm="ps" name="4436" dev=proc > ino=290717698 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.509:2764): avc: > denied { getattr } for pid=4883 comm="ps" name="4532" dev=proc > ino=297009154 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.509:2765): avc: > denied { getattr } for pid=4883 comm="ps" name="4534" dev=proc > ino=297140226 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.509:2766): avc: > denied { getattr } for pid=4883 comm="ps" name="4535" dev=proc > ino=297205762 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.509:2767): avc: > denied { getattr } for pid=4883 comm="ps" name="4537" dev=proc > ino=297336834 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.509:2768): avc: > denied { getattr } for pid=4883 comm="ps" name="4538" dev=proc > ino=297402370 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.509:2769): avc: > denied { getattr } for pid=4883 comm="ps" name="4539" dev=proc > ino=297467906 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.509:2770): avc: > denied { getattr } for pid=4883 comm="ps" name="4540" dev=proc > ino=297533442 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.509:2771): avc: > denied { getattr } for pid=4883 comm="ps" name="4543" dev=proc > ino=297730050 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.509:2772): avc: > denied { getattr } for pid=4883 comm="ps" name="4544" dev=proc > ino=297795586 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.509:2773): avc: > denied { getattr } for pid=4883 comm="ps" name="4591" dev=proc > ino=300875778 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.509:2774): avc: > denied { getattr } for pid=4883 comm="ps" name="4593" dev=proc > ino=301006850 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.509:2775): avc: > denied { getattr } for pid=4883 comm="ps" name="4594" dev=proc > ino=301072386 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.509:2776): avc: > denied { getattr } for pid=4883 comm="ps" name="4596" dev=proc > ino=301203458 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.513:2777): avc: > denied { getattr } for pid=4883 comm="ps" name="4597" dev=proc > ino=301268994 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.513:2778): avc: > denied { getattr } for pid=4883 comm="ps" name="4598" dev=proc > ino=301334530 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.513:2779): avc: > denied { getattr } for pid=4883 comm="ps" name="4599" dev=proc > ino=301400066 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.513:2780): avc: > denied { getattr } for pid=4883 comm="ps" name="4600" dev=proc > ino=301465602 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.513:2781): avc: > denied { getattr } for pid=4883 comm="ps" name="4601" dev=proc > ino=301531138 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.513:2782): avc: > denied { getattr } for pid=4883 comm="ps" name="4641" dev=proc > ino=304152578 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.513:2783): avc: > denied { getattr } for pid=4883 comm="ps" name="4645" dev=proc > ino=304414722 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.513:2784): avc: > denied { getattr } for pid=4883 comm="ps" name="4646" dev=proc > ino=304480258 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.513:2785): avc: > denied { getattr } for pid=4883 comm="ps" name="4648" dev=proc > ino=304611330 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.513:2786): avc: > denied { getattr } for pid=4883 comm="ps" name="4649" dev=proc > ino=304676866 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.513:2787): avc: > denied { getattr } for pid=4883 comm="ps" name="4650" dev=proc > ino=304742402 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.513:2788): avc: > denied { getattr } for pid=4883 comm="ps" name="4651" dev=proc > ino=304807938 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.513:2789): avc: > denied { getattr } for pid=4883 comm="ps" name="4653" dev=proc > ino=304939010 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.513:2790): avc: > denied { getattr } for pid=4883 comm="ps" name="4654" dev=proc > ino=305004546 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.513:2791): avc: > denied { getattr } for pid=4883 comm="ps" name="4682" dev=proc > ino=306839554 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_su_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.513:2792): avc: > denied { getattr } for pid=4883 comm="ps" name="4687" dev=proc > ino=307167234 scontext=user_u:user_r:user_mozilla_t > tcontext=root:sysadm_r:sysadm_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.513:2793): avc: > denied { getattr } for pid=4883 comm="ps" name="4733" dev=proc > ino=310181890 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.513:2794): avc: > denied { getattr } for pid=4883 comm="ps" name="4786" dev=proc > ino=313655298 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:system_r:crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.513:2795): avc: > denied { getattr } for pid=4883 comm="ps" name="4788" dev=proc > ino=313786370 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.513:2796): avc: > denied { getattr } for pid=4883 comm="ps" name="4789" dev=proc > ino=313851906 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.517:2797): avc: > denied { getattr } for pid=4883 comm="ps" name="4791" dev=proc > ino=313982978 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.517:2798): avc: > denied { getattr } for pid=4883 comm="ps" name="4792" dev=proc > ino=314048514 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.517:2799): avc: > denied { getattr } for pid=4883 comm="ps" name="4793" dev=proc > ino=314114050 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.517:2800): avc: > denied { getattr } for pid=4883 comm="ps" name="4794" dev=proc > ino=314179586 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.517:2801): avc: > denied { getattr } for pid=4883 comm="ps" name="4795" dev=proc > ino=314245122 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.517:2802): avc: > denied { getattr } for pid=4883 comm="ps" name="4796" dev=proc > ino=314310658 scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_crond_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.517:2803): avc: > denied { getattr } for pid=4883 comm="ps" name="4800" dev=proc > ino=314572802 scontext=user_u:user_r:user_mozilla_t > tcontext=root:sysadm_r:sysadm_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.517:2804): avc: > denied { getattr } for pid=4883 comm="ps" name="4801" dev=proc > ino=314638338 scontext=user_u:user_r:user_mozilla_t > tcontext=root:sysadm_r:sysadm_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.549:2807): avc: > denied { read write } for pid=4881 comm="lpr" name="_CACHE_MAP_" > dev=hda8 ino=727273 scontext=user_u:user_r:user_lpr_t > tcontext=user_u:object_r:user_mozilla_home_t tclass=file > Apr 23 10:57:26 workstation kernel: audit(1145786246.549:2808): avc: > denied { read write } for pid=4881 comm="lpr" name="history.dat" > dev=hda8 ino=323465 scontext=user_u:user_r:user_lpr_t > tcontext=user_u:object_r:user_mozilla_home_t tclass=file > Apr 23 10:57:26 workstation kernel: audit(1145786246.549:2809): avc: > denied { read write } for pid=4881 comm="lpr" name="_CACHE_001_" > dev=hda8 ino=727274 scontext=user_u:user_r:user_lpr_t > tcontext=user_u:object_r:user_mozilla_home_t tclass=file > Apr 23 10:57:26 workstation kernel: audit(1145786246.549:2810): avc: > denied { read write } for pid=4881 comm="lpr" name="_CACHE_002_" > dev=hda8 ino=727275 scontext=user_u:user_r:user_lpr_t > tcontext=user_u:object_r:user_mozilla_home_t tclass=file > Apr 23 10:57:26 workstation kernel: audit(1145786246.549:2811): avc: > denied { read write } for pid=4881 comm="lpr" name="_CACHE_003_" > dev=hda8 ino=727276 scontext=user_u:user_r:user_lpr_t > tcontext=user_u:object_r:user_mozilla_home_t tclass=file > Apr 23 10:57:26 workstation kernel: audit(1145786246.549:2812): avc: > denied { read write } for pid=4881 comm="lpr" name="mixer" dev=tmpfs > ino=4206 scontext=user_u:user_r:user_lpr_t > tcontext=system_u:object_r:sound_device_t tclass=chr_file > Apr 23 10:57:26 workstation kernel: audit(1145786246.549:2813): avc: > denied { read } for pid=4881 comm="lpr" name="XUL.mfasl" dev=hda8 > ino=323401 scontext=user_u:user_r:user_lpr_t > tcontext=user_u:object_r:user_mozilla_home_t tclass=file > Apr 23 10:57:26 workstation kernel: audit(1145786246.549:2814): avc: > denied { read write } for pid=4881 comm="lpr" name="7A1B3157d01" > dev=hda8 ino=727747 scontext=user_u:user_r:user_lpr_t > tcontext=user_u:object_r:user_mozilla_home_t tclass=file > Apr 23 10:57:26 workstation kernel: audit(1145786246.549:2815): avc: > denied { read write } for pid=4881 comm="lpr" name="[14195]" > dev=sockfs ino=14195 scontext=user_u:user_r:user_lpr_t > tcontext=user_u:user_r:user_mozilla_t tclass=unix_stream_socket > Apr 23 10:57:26 workstation kernel: audit(1145786246.549:2816): avc: > denied { read write } for pid=4881 comm="lpr" name="[14197]" > dev=sockfs ino=14197 scontext=user_u:user_r:user_lpr_t > tcontext=user_u:user_r:user_mozilla_t tclass=unix_stream_socket > Apr 23 10:57:26 workstation kernel: audit(1145786246.549:2817): avc: > denied { siginh } for pid=4881 comm="lpr" > scontext=user_u:user_r:user_mozilla_t tcontext=user_u:user_r:user_lpr_t > tclass=process > Apr 23 10:57:26 workstation kernel: audit(1145786246.549:2818): avc: > denied { rlimitinh } for pid=4881 comm="lpr" > scontext=user_u:user_r:user_mozilla_t tcontext=user_u:user_r:user_lpr_t > tclass=process > Apr 23 10:57:26 workstation kernel: audit(1145786246.549:2819): avc: > denied { noatsecure } for pid=4881 comm="lpr" > scontext=user_u:user_r:user_mozilla_t tcontext=user_u:user_r:user_lpr_t > tclass=process > Apr 23 10:57:26 workstation kernel: audit(1145786246.557:2820): avc: > denied { search } for pid=4881 comm="lpr" name="nscd" dev=hda7 > ino=258574 scontext=user_u:user_r:user_lpr_t > tcontext=system_u:object_r:nscd_var_run_t tclass=dir > Apr 23 10:57:26 workstation kernel: audit(1145786246.561:2821): avc: > denied { search } for pid=4881 comm="lpr" name="nscd" dev=hda7 > ino=258574 scontext=user_u:user_r:user_lpr_t > tcontext=system_u:object_r:nscd_var_run_t tclass=dir > Apr 23 10:57:28 workstation kernel: audit(1145786247.997:2822): avc: > denied { search } for pid=4881 comm="lpr" name="nscd" dev=hda7 > ino=258574 scontext=user_u:user_r:user_lpr_t > tcontext=system_u:object_r:nscd_var_run_t tclass=dir > Apr 23 10:57:28 workstation kernel: audit(1145786247.997:2823): avc: > denied { search } for pid=4881 comm="lpr" name="nscd" dev=hda7 > ino=258574 scontext=user_u:user_r:user_lpr_t > tcontext=system_u:object_r:nscd_var_run_t tclass=dir > Apr 23 10:57:32 workstation kernel: audit(1145786252.002:2824): avc: > denied { search } for pid=4893 comm="sh" name="nscd" dev=hda7 > ino=258574 scontext=system_u:system_r:cupsd_t > tcontext=system_u:object_r:nscd_var_run_t tclass=dir > Apr 23 10:57:32 workstation kernel: audit(1145786252.006:2825): avc: > denied { search } for pid=4893 comm="sh" name="nscd" dev=hda7 > ino=258574 scontext=system_u:system_r:cupsd_t > tcontext=system_u:object_r:nscd_var_run_t tclass=dir > Apr 23 10:57:32 workstation kernel: audit(1145786252.070:2826): avc: > denied { search } for pid=4893 comm="sh" name="nscd" dev=hda7 > ino=258574 scontext=system_u:system_r:cupsd_t > tcontext=system_u:object_r:nscd_var_run_t tclass=dir > Apr 23 10:57:32 workstation kernel: audit(1145786252.070:2827): avc: > denied { search } for pid=4893 comm="sh" name="nscd" dev=hda7 > ino=258574 scontext=system_u:system_r:cupsd_t > tcontext=system_u:object_r:nscd_var_run_t tclass=dir > Apr 23 10:57:34 workstation kernel: audit(1145786254.714:2828): avc: > denied { search } for pid=4896 comm="sh" name="nscd" dev=hda7 > ino=258574 scontext=system_u:system_r:cupsd_t > tcontext=system_u:object_r:nscd_var_run_t tclass=dir > Apr 23 10:57:34 workstation kernel: audit(1145786254.714:2829): avc: > denied { search } for pid=4896 comm="sh" name="nscd" dev=hda7 > ino=258574 scontext=system_u:system_r:cupsd_t > tcontext=system_u:object_r:nscd_var_run_t tclass=dir > Apr 23 10:57:34 workstation kernel: audit(1145786254.730:2830): avc: > denied { search } for pid=4898 comm="sh" name="nscd" dev=hda7 > ino=258574 scontext=system_u:system_r:cupsd_t > tcontext=system_u:object_r:nscd_var_run_t tclass=dir > Apr 23 10:57:34 workstation kernel: audit(1145786254.730:2831): avc: > denied { search } for pid=4898 comm="sh" name="nscd" dev=hda7 > ino=258574 scontext=system_u:system_r:cupsd_t > tcontext=system_u:object_r:nscd_var_run_t tclass=dir > Apr 23 10:57:42 workstation kernel: audit(1145786262.103:2832): avc: > denied { name_connect } for pid=4199 comm="firefox-bin" dest=5000 > scontext=user_u:user_r:user_mozilla_t tcontext=system_u:object_r:port_t > tclass=tcp_socket > > > > > > > From sundaram at fedoraproject.org Wed May 3 01:39:42 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 03 May 2006 07:09:42 +0530 Subject: [ANN] Setools-2.4 In-Reply-To: <6FE441CD9F0C0C479F2D88F959B0158816FEE5@exchange.columbia.tresys.com> References: <6FE441CD9F0C0C479F2D88F959B0158816FEE5@exchange.columbia.tresys.com> Message-ID: <1146620382.3802.146.camel@sundaram.pnq.redhat.com> On Tue, 2006-05-02 at 15:28 -0400, Kevin Carr wrote: > A new version of setools is available on the Tresys website. > http://www.tresys.com/selinux/ > > Change-Log > ========== > apol: File contexts tab now allows for MLS range searching if the loaded > database is from a MLS filesystem. Policy statistics dialog now > shows MLS and ocontexts summaries. > > libapol: Added support for loading base policies containing optionals. > Added support for searching range transitions containing attributes. > > libseaudit: Bugfix to support parsing FC5-style audit logs. Curious: Is FC5 style different from a standard one? Rahul From ce at ruault.com Wed May 3 05:55:38 2006 From: ce at ruault.com (Charles-Edouard Ruault) Date: Wed, 03 May 2006 07:55:38 +0200 Subject: HOWTO: kdebluetooth with SELinux on FC5 In-Reply-To: References: <4451C950.5080108@ruault.com> Message-ID: <445845DA.1010700@ruault.com> Rex Dieter wrote: > Charles-Edouard Ruault wrote: >> Hi all, >> for those who are interested, after struggling to get kdebluetooth to >> work on my FC5 with SELinux targetted policy i've published a HOWTO at >> the following address: http://www.ruault.com/kdebluetooth/ >> Feel free to let me know if i've missed something or if it can be >> improved. >> Regards. > > Is this something that could be added to the kdebluetooth FE > submission rpm? (http://bugzilla.redhat.com/bugzilla/186452) > > -- Rex > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Yes, that would be a good idea to use those SELinux settings in the rpm. Let me know if i can be of any help. Regards. -- Charles-Edouard Ruault PGP Key ID E4D2B80C From rfoster at mountainvisions.com.au Wed May 3 13:03:06 2006 From: rfoster at mountainvisions.com.au (Robert Foster) Date: Wed, 3 May 2006 23:03:06 +1000 Subject: Problems with clamav and httpd Message-ID: <002201c66eb1$eb744450$5e00a8c0@RoverXP> Hi all, Been playing with docmgr (http://docmgr.sourceforge.net) and discovered that when uploading a file, it fails because clamav can't scan the uploaded content. Audit log contains the following relevant lines: type=AVC msg=audit(1146659861.108:221013): avc: denied { read } for pid=15887 comm="clamscan" name="clamav" dev=dm-3 ino=2593916 scontext=user_u:system_r:httpd_sys_script_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=dir type=SYSCALL msg=audit(1146659861.108:221013): arch=40000003 syscall=5 success=no exit=-13 a0=9de85b8 a1=18800 a2=26f120 a3=9de8008 items=1 pid=15887 auid=1000 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 comm="clamscan" exe="/usr/bin/clamscan" type=CWD msg=audit(1146659861.108:221013): cwd="/MV/webs/project/html/doc" type=PATH msg=audit(1146659861.108:221013): item=0 name="/var/lib/clamav" flags=103 inode=2593916 dev=fd:03 mode=040755 ouid=100 ogid=101 rdev=00:00 I've also setsebool -P on allow_execstack and allow_httpd_anon_write amongst others, and the relevant directories have the following context to allow httpd and samba to play nice together: user_u:object_r:public_content_rw_t Anyone able to shed some light on this? Other (maybe) relevant info: # ls -alZ /var/lib/clamav/ drwxr-xr-x clamav clamav system_u:object_r:var_lib_t . drwxr-xr-x root root system_u:object_r:var_lib_t .. -rw-r--r-- clamav clamav user_u:object_r:var_lib_t daily.cvd -rw-r--r-- clamav clamav user_u:object_r:var_lib_t daily.cvd.rpmsave drwx------ clamav clamav system_u:object_r:var_lib_t Maildir -rw-r--r-- clamav clamav system_u:object_r:var_lib_t main.cvd -rw-r--r-- clamav clamav user_u:object_r:var_lib_t main.cvd.rpmsave # ls -alZ /MV/webs/project/html/doc drwsrws--x apache apache user_u:object_r:public_content_rw_t . drwsrws--x apache apache system_u:object_r:public_content_rw_t .. drwsrws--x apache apache user_u:object_r:public_content_rw_t app drwsrws--x apache apache user_u:object_r:public_content_rw_t auth drwsrws--x apache apache user_u:object_r:public_content_rw_t bin drwsrws--x apache apache user_u:object_r:public_content_rw_t config drwsrws--x apache apache user_u:object_r:public_content_rw_t DOCS drwsrws--x apache apache user_u:object_r:public_content_rw_t fckeditor drwsrws--x apache apache user_u:object_r:public_content_rw_t files drwsrws--x apache apache user_u:object_r:public_content_rw_t header drwsrws--x apache apache user_u:object_r:public_content_rw_t include -rwxrwx--x apache apache user_u:object_r:public_content_rw_t index.php drwsrws--x apache apache user_u:object_r:public_content_rw_t javascript drwsrws--x apache apache user_u:object_r:public_content_rw_t lang drwsrws--x apache apache user_u:object_r:public_content_rw_t modules drwsrws--x apache apache user_u:object_r:public_content_rw_t scripts drwsrws--x apache apache user_u:object_r:public_content_rw_t themes drwsrws--x apache apache user_u:object_r:public_content_rw_t webdav It also seems that docmgr is calling clamscan on a temp file found in /tmp. But I haven't been able to confirm the context of the target file as yet. Thanks, Robert Foster -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcarr at tresys.com Wed May 3 13:27:08 2006 From: kcarr at tresys.com (Kevin Carr) Date: Wed, 3 May 2006 09:27:08 -0400 Subject: [ANN] Setools-2.4 Message-ID: <6FE441CD9F0C0C479F2D88F959B0158816FF33@exchange.columbia.tresys.com> > On Tue, 2006-05-02 at 15:28 -0400, Kevin Carr wrote: > > A new version of setools is available on the Tresys website. > > http://www.tresys.com/selinux/ > > > > Change-Log > > ========== > > apol: File contexts tab now allows for MLS range searching if the loaded > > database is from a MLS filesystem. Policy statistics dialog now > > shows MLS and ocontexts summaries. > > > > libapol: Added support for loading base policies containing optionals. > > Added support for searching range transitions containing attributes. > > > > libseaudit: Bugfix to support parsing FC5-style audit logs. > > Curious: Is FC5 style different from a standard one? This was nothing substantial, just a bug that showed up in the parser. Kevin Carr Tresys Technology 410.290.1411 x137 From florin at andrei.myip.org Wed May 3 16:53:38 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Wed, 03 May 2006 09:53:38 -0700 Subject: failed to customize policy, SELinux won't let me Message-ID: <1146675218.4365.6.camel@stantz.corp.sgi.com> Fresh FC5 install (not an update) on an Intel 32bit CPU. Applied all updates, reboot, let anacron do its job, reboot. Installed Postfix and Cyrus-IMAPd While testing Postfix with Cyrus I got this: May 3 09:38:25 stantz kernel: audit(1146674305.211:305): avc: denied { search } for pid=3441 comm="lmtp" name="lib" dev=hda2 ino=2293761 scontext=user_u:system_r:postfix_master_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=dir OK, fine, I go here and follow the steps (all the time working in the /root/selinux directory): http://fedora.redhat.com/docs/selinux-faq-fc5/#faq-entry-local.te However, I can't seem to load the local module: # /usr/sbin/semodule -i local.pp /usr/sbin/semodule: Could not read file 'local.pp': # ls local.fc local.if local.pp local.te tmp # cat local.te policy_module(local, 1.0) require { type postfix_master_t; type var_lib_t; } allow postfix_master_t var_lib_t:dir search; In the logs I get this: audit(1146674668.001:307): avc: denied { search } for pid=3569 comm="semodule" name="selinux" dev=hda4 ino=6501763 scontext=user_u:system_r:semanage_t:s0 tcontext=user_u:object_r:user_home_t:s0 tclass=dir What is going on? -- Florin Andrei http://florin.myip.org/ From florin at andrei.myip.org Wed May 3 16:55:38 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Wed, 03 May 2006 09:55:38 -0700 Subject: failed to customize policy, SELinux won't let me In-Reply-To: <1146675218.4365.6.camel@stantz.corp.sgi.com> References: <1146675218.4365.6.camel@stantz.corp.sgi.com> Message-ID: <1146675338.4365.7.camel@stantz.corp.sgi.com> On Wed, 2006-05-03 at 09:53 -0700, Florin Andrei wrote: > # /usr/sbin/semodule -i local.pp > /usr/sbin/semodule: Could not read file 'local.pp': > # ls > local.fc local.if local.pp local.te tmp # ls -Z -rw-r--r-- root root user_u:object_r:user_home_t local.fc -rw-r--r-- root root user_u:object_r:user_home_t local.if -rw-r--r-- root root user_u:object_r:user_home_t local.pp -rw-r--r-- root root user_u:object_r:user_home_t local.te drwxr-xr-x root root user_u:object_r:user_home_t tmp -- Florin Andrei http://florin.myip.org/ From sds at tycho.nsa.gov Wed May 3 17:04:06 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 03 May 2006 13:04:06 -0400 Subject: failed to customize policy, SELinux won't let me In-Reply-To: <1146675218.4365.6.camel@stantz.corp.sgi.com> References: <1146675218.4365.6.camel@stantz.corp.sgi.com> Message-ID: <1146675846.27735.107.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-05-03 at 09:53 -0700, Florin Andrei wrote: > Fresh FC5 install (not an update) on an Intel 32bit CPU. > Applied all updates, reboot, let anacron do its job, reboot. > > Installed Postfix and Cyrus-IMAPd > While testing Postfix with Cyrus I got this: > > May 3 09:38:25 stantz kernel: audit(1146674305.211:305): avc: denied > { search } for pid=3441 comm="lmtp" name="lib" dev=hda2 ino=2293761 > scontext=user_u:system_r:postfix_master_t:s0 > tcontext=system_u:object_r:var_lib_t:s0 tclass=dir > > OK, fine, I go here and follow the steps (all the time working in > the /root/selinux directory): > > http://fedora.redhat.com/docs/selinux-faq-fc5/#faq-entry-local.te > > However, I can't seem to load the local module: > > # /usr/sbin/semodule -i local.pp > /usr/sbin/semodule: Could not read file 'local.pp': > # ls > local.fc local.if local.pp local.te tmp > # cat local.te > policy_module(local, 1.0) > > require { > type postfix_master_t; > type var_lib_t; > } > > allow postfix_master_t var_lib_t:dir search; > > In the logs I get this: > > audit(1146674668.001:307): avc: denied { search } for pid=3569 > comm="semodule" name="selinux" dev=hda4 ino=6501763 > scontext=user_u:system_r:semanage_t:s0 > tcontext=user_u:object_r:user_home_t:s0 tclass=dir > > What is going on? Yes, I noticed this as well - semanage/semodule policy doesn't appear to allow it to take input from user home directories presently. Nice from an integrity point of view (don't take untrustworthy inputs), but likely not workable for every day usage. -- Stephen Smalley National Security Agency From florin at andrei.myip.org Wed May 3 17:05:53 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Wed, 03 May 2006 10:05:53 -0700 Subject: failed to customize policy, SELinux won't let me In-Reply-To: <1146675846.27735.107.camel@moss-spartans.epoch.ncsc.mil> References: <1146675218.4365.6.camel@stantz.corp.sgi.com> <1146675846.27735.107.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1146675953.4365.10.camel@stantz.corp.sgi.com> On Wed, 2006-05-03 at 13:04 -0400, Stephen Smalley wrote: > Yes, I noticed this as well - semanage/semodule policy doesn't appear to > allow it to take input from user home directories presently. Nice from > an integrity point of view (don't take untrustworthy inputs), but likely > not workable for every day usage. Still not working: [root at stantz custom]# pwd /etc/selinux/custom [root at stantz custom]# ls -Z -rw-r--r-- root root user_u:object_r:selinux_config_t local.fc -rw-r--r-- root root user_u:object_r:selinux_config_t local.if -rw-r--r-- root root user_u:object_r:selinux_config_t local.pp -rw-r--r-- root root user_u:object_r:selinux_config_t local.te drwxr-xr-x root root user_u:object_r:selinux_config_t tmp [root at stantz custom]# semodule -i local.pp libsemanage.semanage_commit_sandbox: Error while renaming /etc/selinux/targeted/modules/active to /etc/selinux/targeted/modules/previous. semodule: Failed! [root at stantz custom]# tail -n 1 /var/log/messages May 3 10:02:51 stantz kernel: audit(1146675771.487:308): avc: denied { rename } for pid=3845 comm="semodule" name="active" dev=hda4 ino=2319743 scontext=user_u:system_r:semanage_t:s0 tcontext=user_u:object_r:selinux_config_t:s0 tclass=dir :-( -- Florin Andrei http://florin.myip.org/ From sds at tycho.nsa.gov Wed May 3 17:19:51 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 03 May 2006 13:19:51 -0400 Subject: failed to customize policy, SELinux won't let me In-Reply-To: <1146675953.4365.10.camel@stantz.corp.sgi.com> References: <1146675218.4365.6.camel@stantz.corp.sgi.com> <1146675846.27735.107.camel@moss-spartans.epoch.ncsc.mil> <1146675953.4365.10.camel@stantz.corp.sgi.com> Message-ID: <1146676791.27735.119.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-05-03 at 10:05 -0700, Florin Andrei wrote: > On Wed, 2006-05-03 at 13:04 -0400, Stephen Smalley wrote: > > > Yes, I noticed this as well - semanage/semodule policy doesn't appear to > > allow it to take input from user home directories presently. Nice from > > an integrity point of view (don't take untrustworthy inputs), but likely > > not workable for every day usage. > > Still not working: > > [root at stantz custom]# pwd > /etc/selinux/custom > [root at stantz custom]# ls -Z > -rw-r--r-- root root user_u:object_r:selinux_config_t local.fc > -rw-r--r-- root root user_u:object_r:selinux_config_t local.if > -rw-r--r-- root root user_u:object_r:selinux_config_t local.pp > -rw-r--r-- root root user_u:object_r:selinux_config_t local.te > drwxr-xr-x root root user_u:object_r:selinux_config_t tmp Actually, /usr/share/selinux is the standard location for modules to be placed before running semodule on them, but that isn't directly relevant to the denial you see below. > [root at stantz custom]# semodule -i local.pp > libsemanage.semanage_commit_sandbox: Error while > renaming /etc/selinux/targeted/modules/active > to /etc/selinux/targeted/modules/previous. > semodule: Failed! > [root at stantz custom]# tail -n 1 /var/log/messages > May 3 10:02:51 stantz kernel: audit(1146675771.487:308): avc: denied > { rename } for pid=3845 comm="semodule" name="active" dev=hda4 > ino=2319743 scontext=user_u:system_r:semanage_t:s0 > tcontext=user_u:object_r:selinux_config_t:s0 tclass=dir Yes, this has shown up before - it indicates that your /etc/selinux/targeted/modules tree has become mislabeled. Run restorecon -R on it. I think that this has been corrected already in updates? -- Stephen Smalley National Security Agency From dwalsh at redhat.com Wed May 3 17:23:32 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 03 May 2006 13:23:32 -0400 Subject: Another mount issue In-Reply-To: <1145605949.27071.16.camel@laurel.intra.city-fan.org> References: <1145605949.27071.16.camel@laurel.intra.city-fan.org> Message-ID: <4458E714.5010701@redhat.com> Paul Howarth wrote: > On my file/web/samba/nfs server I have a software archive, which I serve > out using both samba and httpd. So the whole thing as > public_content_rw_t, and the appropriate boolean set so that samba can > write to it. > > On the software archive I have DVD ISO images of FC4 and FC5. I have > fstab entries for these to loopback mount them as follows: > > /srv/softlib/fedora/stentz/FC4-i386-DVD.iso /srv/softlib/fedora/stentz/dvd iso9660 ro,loop,fscontext=system_u:object_r:public_content_t 0 0 > > /srv/softlib/fedora/bordeaux/FC-5-i386-DVD.iso /srv/softlib/fedora/bordeaux/dvd iso9660 ro,loop,fscontext=system_u:object_r:public_content_t 0 0 > > Unfortunately the mount won't work at boot time because mount is > confined to the mount_t domain, which can't read public_content_rw_t: > > Apr 21 08:40:21 badby kernel: audit(1145605218.512:331): avc: denied > { read } for pid=1469 comm="mount" name="FC4-i386-DVD.iso" dev=dm-5 > ino=1032205 scontext=system_u:system_r:mount_t:s0 > tcontext=system_u:object_r:public_content_rw_t:s0 tclass=file > > Apr 21 08:40:21 badby kernel: audit(1145605218.564:332): avc: denied > { read } for pid=1469 comm="mount" name="FC-5-i386-DVD.iso" dev=dm-5 > ino=606259 scontext=system_u:system_r:mount_t:s0 > tcontext=root:object_r:public_content_rw_t:s0 tclass=file > > A "mount -a" after booting works fine as it then runs unconfined. > > Is this something that should be generally allowed or should I just > write local policy to fix this? > > Paul. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Adding boolean allow_mount_anyfile, to handle these situations. From dwalsh at redhat.com Wed May 3 17:27:01 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 03 May 2006 13:27:01 -0400 Subject: Problem with SELinux and Postfix (sending from Python scripts) In-Reply-To: <1145987798.3453.TMDA@kidsrock.taltos.com> References: <1145915781.30207.TMDA@kidsrock.taltos.com> <444E56D7.5060304@redhat.com> <1145987798.3453.TMDA@kidsrock.taltos.com> Message-ID: <4458E7E5.3090601@redhat.com> Jeff Coffler wrote: >>> Is this an SELinux policy problem? How can I go about fixing this? >>> I'd prefer to run with SELinux enabled ... >>> >> # grep postfix_spool /var/log/message | audit2allow -M postfixpickup >> # semodule -i postfixpickup.pp >> >> Will fix it for now. >> >> I will update policy to allow searching of this directory > > Hmm, this didn't work ... > > [root jeff]# grep postfix_spool /var/log/messages | audit2allow -M > postfixpickup > Generating type enforcment file: postfixpickup.te > Compiling policy > checkmodule -M -m -o postfixpickup.mod postfixpickup.te > semodule_package -o postfixpickup.pp -m postfixpickup.mod > > ******************** IMPORTANT *********************** > > In order to load this newly created policy package into the kernel, > you are required to execute > > semodule -i postfixpickup.pp > > > [root jeff]# semodule -i postfixpickup.pp > slimserver homedir /usr/local/slimserver or its parent directory > conflicts with a > defined context in /etc/selinux/targeted/contexts/files/file_contexts, > /usr/sbin/genhomedircon will not create a new context. > [root jeff]# grep -i slim > /etc/selinux/targeted/contexts/files/file_contexts > [root jeff]# > > I'm not sure why it's complaining about slimserver since there's no > "slim" in that file. I could deinstall that to do the semodule > command, then reinstall. Or I could wait until you guys push out the > next SELinux policy, then enable SELinux. > > Suggestions? > > Thanks! > > -- Jeff Is there a password entry for slimserver? If yes make sure it has a shell of /sbin/nologin or /bin/false. Then you can run genhomedircon From dwalsh at redhat.com Wed May 3 17:32:31 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 03 May 2006 13:32:31 -0400 Subject: samba selinux adding new PC to domain In-Reply-To: References: <444F82D8.1040003@city-fan.org> <1365.24.2.210.202.1146072841.squirrel@mail.eastgranby.k12.ct.us> Message-ID: <4458E92F.6010702@redhat.com> Scott Tsai wrote: > On Wed, 26 Apr 2006 13:34:01 -0400, mroselinux wrote: > >> How can I always leave enforcing on? >> > > You could create a local policy module to grant useradd the additional > permisions. > > 1. Create a file t.log with the relevant avc messages. > cat <<-EOF > t.log > audit(1145984005.084:160): avc: denied { append } for pid=24952 > comm="useradd" name="log.mslib2k10w" dev=dm-0 ino=8674237 > scontext=root:system_r:useradd_t:s0 tcontext=root:object_r:samba_log_t:s0 > tclass=file > audit(1145984005.088:162): avc: denied { read write } for pid=24952 > comm="useradd" name="passwd" dev=dm-0 ino=1964129 scontext=root:system_r:useradd_t:s0 tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file > EOF > Why is useradd appending to samba_log? This might be a bug in samba is leaking > 2. Build a selinux policy module with audit2allow > audit2allow -M local_samba_useradd -i t.log > > 3. Load the policy module into the kernel > semodule -i local_samba_useradd.pp > > 4. If you want to keep this setting across reboot, > I guess you'll have to put the "semodule -i" line into /etc/rc.d/rc.local ? > > semodule changes are permanant. No need to semodule -i in /etc/rc.d/rc.local. > I'm a bit suspicious about why the "passwd" file was labeled > "etc_runtime_t" in the first place. > > See Also: > http://fedoraproject.org/wiki/SELinux/LoadableModules/Audit2allow > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From dwalsh at redhat.com Wed May 3 18:10:27 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 03 May 2006 14:10:27 -0400 Subject: lame/libxvidcore & execstack In-Reply-To: <20060502191943.GA18631@neu.nirvana> References: <20060427095825.413A07309E@hormel.redhat.com> <4450F588.4070701@grifent.com> <44567BEE.8060506@redhat.com> <44579FE9.2060600@grifent.com> <20060502181832.GA15337@neu.nirvana> <4457A48C.8050709@grifent.com> <20060502183434.GB15337@neu.nirvana> <4457AE4F.6010008@redhat.com> <20060502191943.GA18631@neu.nirvana> Message-ID: <4458F213.4040505@redhat.com> Axel Thimm wrote: > On Tue, May 02, 2006 at 03:09:03PM -0400, Daniel J Walsh wrote: > >> Axel Thimm wrote: >> >>> On Tue, May 02, 2006 at 02:27:24PM -0400, John Griffiths wrote: >>> >>> >>>> Axel Thimm wrote: >>>> >>>> >>>>> On Tue, May 02, 2006 at 02:07:37PM -0400, John Griffiths wrote: >>>>> >>>>> >>>>>> Daniel J Walsh wrote: >>>>>> >>>>>> >>>>>>> John Griffiths wrote: >>>>>>> >>>>>>> >>>>>>>> fedora-selinux-list-request at redhat.com wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Subject: >>>>>>>>> Error running ffmpeg due to permission denied on library >>>>>>>>> From: >>>>>>>>> "Robert Foster" >>>>>>>>> Date: >>>>>>>>> Thu, 27 Apr 2006 12:41:09 +1000 >>>>>>>>> To: >>>>>>>>> >>>>>>>>> >>>>>>>>> To: >>>>>>>>> >>>>>>>>> I'm trying to get ffmpeg working for Gallery2 on FC5, and getting >>>>>>>>> the following error (from the debug message via Gallery): >>>>>>>>> >>>>>>>>> >>> >>> >>>>>>>> I had the same problem when using Kino which also uses ffmpeg. Here >>>>>>>> is what I did and it works. >>>>>>>> >>>>>>>> execstack -c /usr/lib/libmp3lame.so.0 >>>>>>>> execstack -c /usr/lib/libxvidcore.so.4 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Please submit bugs on these to Kino and ffmpeg. >>>>>>> >>>>>>> >>>>>>> >>>>>> Actually /usr/lib/libmp3lame.so.0 is part of lame-3.96.1-10.rhfc5.at >>>>>> and libxvidcore4-1.1.0-8.rhfc5.at both from ATRpms.net. >>>>>> >>>>>> I'll let the people at ATRpm know. >>>>>> >>>>>> >>>>> Is this considered a packaging or upstream issue? >>>>> >>>>> If packaging: What is the recommended way to fix it specfile-wise? >>>>> >>>>> >>>>> >>> >From this, I find the folks at ATRpms know. >>> >>>> >>>> >>> I'm very sure they'll be just as confused as I am ;) >>> >>> >> Point them at >> > > ^^^^ > > Them is largely myself, that's why I can tell how confused "they" will > be. ;) > > >> http://people.redhat.com/~drepper/selinux-mem.html >> >> and >> >> http://people.redhat.com/drepper/nonselsec.pdf >> > > But these reference upstream fixing, not packaging ones. Do idioms > exist to cirumvent this at the packaging level (other than fixing the > source and Patch0: the fix), or is the recommendation to report to > upstream and wait for a fix while disabling selinux at the mean time? How about executing execstack -c /usr/lib/libmp3lame.so.0 execstack -c /usr/lib/libxvidcore.so.4 In the postinstall? If it does not break anything. From florin at andrei.myip.org Wed May 3 21:30:04 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Wed, 03 May 2006 14:30:04 -0700 Subject: failed to customize policy, SELinux won't let me In-Reply-To: <1146676791.27735.119.camel@moss-spartans.epoch.ncsc.mil> References: <1146675218.4365.6.camel@stantz.corp.sgi.com> <1146675846.27735.107.camel@moss-spartans.epoch.ncsc.mil> <1146675953.4365.10.camel@stantz.corp.sgi.com> <1146676791.27735.119.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1146691804.4365.18.camel@stantz.corp.sgi.com> On Wed, 2006-05-03 at 13:19 -0400, Stephen Smalley wrote: > On Wed, 2006-05-03 at 10:05 -0700, Florin Andrei wrote: > > [root at stantz custom]# pwd > > /etc/selinux/custom > Actually, /usr/share/selinux is the standard location for modules to be > placed before running semodule on them, but that isn't directly relevant > to the denial you see below. Not mentioned in the FAQ. ;-) > > [root at stantz custom]# tail -n 1 /var/log/messages > > May 3 10:02:51 stantz kernel: audit(1146675771.487:308): avc: denied > > { rename } for pid=3845 comm="semodule" name="active" dev=hda4 > > ino=2319743 scontext=user_u:system_r:semanage_t:s0 > > tcontext=user_u:object_r:selinux_config_t:s0 tclass=dir > > Yes, this has shown up before - it indicates that > your /etc/selinux/targeted/modules tree has become mislabeled. Run > restorecon -R on it. I think that this has been corrected already in > updates? Hmmm... This is a fresh install, I applied all updates, rebooted, let anacron do all the jobs, did "touch /.autorelabel", rebooted again. Anyway, I did a restorecon, then some more policy tweaks (Postfix was still hitting various snags), and it worked. Thanks! -- Florin Andrei http://florin.myip.org/ From florin at andrei.myip.org Thu May 4 02:25:26 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Wed, 03 May 2006 19:25:26 -0700 Subject: failed to customize policy, SELinux won't let me In-Reply-To: <1146676791.27735.119.camel@moss-spartans.epoch.ncsc.mil> References: <1146675218.4365.6.camel@stantz.corp.sgi.com> <1146675846.27735.107.camel@moss-spartans.epoch.ncsc.mil> <1146675953.4365.10.camel@stantz.corp.sgi.com> <1146676791.27735.119.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1146709526.4294.2.camel@rivendell.home.local> On Wed, 2006-05-03 at 13:19 -0400, Stephen Smalley wrote: > On Wed, 2006-05-03 at 10:05 -0700, Florin Andrei wrote: > > [root at stantz custom]# semodule -i local.pp > > libsemanage.semanage_commit_sandbox: Error while > > renaming /etc/selinux/targeted/modules/active > > to /etc/selinux/targeted/modules/previous. > > semodule: Failed! > > [root at stantz custom]# tail -n 1 /var/log/messages > > May 3 10:02:51 stantz kernel: audit(1146675771.487:308): avc: denied > > { rename } for pid=3845 comm="semodule" name="active" dev=hda4 > > ino=2319743 scontext=user_u:system_r:semanage_t:s0 > > tcontext=user_u:object_r:selinux_config_t:s0 tclass=dir > > Yes, this has shown up before - it indicates that > your /etc/selinux/targeted/modules tree has become mislabeled. Run > restorecon -R on it. I think that this has been corrected already in > updates? I rebooted the system and this happened again. :-( I did a restorecon again and now it's working fine. This is not right. -- Florin Andrei http://florin.myip.org/ From sds at tycho.nsa.gov Thu May 4 11:52:54 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 04 May 2006 07:52:54 -0400 Subject: failed to customize policy, SELinux won't let me In-Reply-To: <1146709526.4294.2.camel@rivendell.home.local> References: <1146675218.4365.6.camel@stantz.corp.sgi.com> <1146675846.27735.107.camel@moss-spartans.epoch.ncsc.mil> <1146675953.4365.10.camel@stantz.corp.sgi.com> <1146676791.27735.119.camel@moss-spartans.epoch.ncsc.mil> <1146709526.4294.2.camel@rivendell.home.local> Message-ID: <1146743574.15669.38.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-05-03 at 19:25 -0700, Florin Andrei wrote: > On Wed, 2006-05-03 at 13:19 -0400, Stephen Smalley wrote: > > On Wed, 2006-05-03 at 10:05 -0700, Florin Andrei wrote: > > > [root at stantz custom]# semodule -i local.pp > > > libsemanage.semanage_commit_sandbox: Error while > > > renaming /etc/selinux/targeted/modules/active > > > to /etc/selinux/targeted/modules/previous. > > > semodule: Failed! > > > [root at stantz custom]# tail -n 1 /var/log/messages > > > May 3 10:02:51 stantz kernel: audit(1146675771.487:308): avc: denied > > > { rename } for pid=3845 comm="semodule" name="active" dev=hda4 > > > ino=2319743 scontext=user_u:system_r:semanage_t:s0 > > > tcontext=user_u:object_r:selinux_config_t:s0 tclass=dir > > > > Yes, this has shown up before - it indicates that > > your /etc/selinux/targeted/modules tree has become mislabeled. Run > > restorecon -R on it. I think that this has been corrected already in > > updates? > > I rebooted the system and this happened again. :-( > I did a restorecon again and now it's working fine. > > This is not right. Indeed. Can you provide more details about your system (e.g. filesystem type) and about the precise steps you use to reproduce the bug? -- Stephen Smalley National Security Agency From ejtr at layer3.co.uk Thu May 4 17:45:04 2006 From: ejtr at layer3.co.uk (Ted Rule) Date: Thu, 04 May 2006 18:45:04 +0100 Subject: lame/libxvidcore & execstack Message-ID: <1146764704.3318.27.camel@topaz.bugfinder.co.uk> Erm. Doesn't that break "rpm -V" file consistency checking? Shouldn't it rather be done at the end of the rpm SPEC %install phase during the RPM build rather than during RPM install itself? Daniel J Walsh wrote: > Date: Wed, 03 May 2006 14:10:27 -0400 > From: Daniel J Walsh > Subject: Re: lame/libxvidcore & execstack > To: fedora-selinux-list at redhat.com > Message-ID: <4458F213.4040505 at redhat.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Axel Thimm wrote: > > On Tue, May 02, 2006 at 03:09:03PM -0400, Daniel J Walsh wrote: > > > >> Axel Thimm wrote: > >> > >>> On Tue, May 02, 2006 at 02:27:24PM -0400, John Griffiths wrote: > >>> > >>> > >>>> Axel Thimm wrote: > >>>> > >>>> > >>>>> On Tue, May 02, 2006 at 02:07:37PM -0400, John Griffiths wrote: > >>>>> > >>>>> > >>>>>> Daniel J Walsh wrote: > >>>>>> > >>>>>> > >>>>>>> John Griffiths wrote: > >>>>>>> > >>>>>>> > >>>>>>>> fedora-selinux-list-request at redhat.com wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>>> Subject: > >>>>>>>>> Error running ffmpeg due to permission denied on library > >>>>>>>>> From: > >>>>>>>>> "Robert Foster" > >>>>>>>>> Date: > >>>>>>>>> Thu, 27 Apr 2006 12:41:09 +1000 > >>>>>>>>> To: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> To: > >>>>>>>>> > >>>>>>>>> I'm trying to get ffmpeg working for Gallery2 on FC5, and > getting > >>>>>>>>> the following error (from the debug message via Gallery): > >>>>>>>>> > >>>>>>>>> > >>> > >>> > >>>>>>>> I had the same problem when using Kino which also uses > ffmpeg. Here > >>>>>>>> is what I did and it works. > >>>>>>>> > >>>>>>>> execstack -c /usr/lib/libmp3lame.so.0 > >>>>>>>> execstack -c /usr/lib/libxvidcore.so.4 > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> Please submit bugs on these to Kino and ffmpeg. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> Actually /usr/lib/libmp3lame.so.0 is part of > lame-3.96.1-10.rhfc5.at > >>>>>> and libxvidcore4-1.1.0-8.rhfc5.at both from ATRpms.net. > >>>>>> > >>>>>> I'll let the people at ATRpm know. > >>>>>> > >>>>>> > >>>>> Is this considered a packaging or upstream issue? > >>>>> > >>>>> If packaging: What is the recommended way to fix it > specfile-wise? > >>>>> > >>>>> > >>>>> > >>> >From this, I find the folks at ATRpms know. > >>> > >>>> > >>>> > >>> I'm very sure they'll be just as confused as I am ;) > >>> > >>> > >> Point them at > >> > > > > ^^^^ > > > > Them is largely myself, that's why I can tell how confused "they" > will > > be. ;) > > > > > >> http://people.redhat.com/~drepper/selinux-mem.html > >> > >> and > >> > >> http://people.redhat.com/drepper/nonselsec.pdf > >> > > > > But these reference upstream fixing, not packaging ones. Do idioms > > exist to cirumvent this at the packaging level (other than fixing > the > > source and Patch0: the fix), or is the recommendation to report to > > upstream and wait for a fix while disabling selinux at the mean > time? > > How about executing > > execstack -c /usr/lib/libmp3lame.so.0 > > execstack -c /usr/lib/libxvidcore.so.4 > > > In the postinstall? If it does not break anything. > Erm. Doesn't that break "rpm -V" file checking? Shouldn't it be done at the end of the rpm SPEC %install phase during the build? -- Ted Rule Director, Layer3 Systems Ltd W: http://www.layer3.co.uk/ From frharris27 at yahoo.com Fri May 5 01:44:20 2006 From: frharris27 at yahoo.com (Fred Harris) Date: Thu, 4 May 2006 18:44:20 -0700 (PDT) Subject: Disable for java? Message-ID: <20060505014420.11632.qmail@web38510.mail.mud.yahoo.com> Is there any way to disable selinux for java? I tried chcon -t java_exec_t /opt/java which I found searching around, and that didn't work. The problem I'm having is that I'm getting a million messages complaining about "execmem", I guess having something to do with accessing shared memory. I'm trying to run Tomcat and get about 100 messages per minute, so I'm faced with either turning off selinux completely, turning off the error logging on selinux, or turning off selinux for java specifically. I'm running the latest Sun Java version. Thanks. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruno at wolff.to Fri May 5 02:54:53 2006 From: bruno at wolff.to (Bruno Wolff III) Date: Thu, 4 May 2006 21:54:53 -0500 Subject: Disable for java? In-Reply-To: <20060505014420.11632.qmail@web38510.mail.mud.yahoo.com> References: <20060505014420.11632.qmail@web38510.mail.mud.yahoo.com> Message-ID: <20060505025453.GA13990@wolff.to> On Thu, May 04, 2006 at 18:44:20 -0700, Fred Harris wrote: > > The problem I'm having is that I'm getting a million messages > complaining about "execmem", I guess having something to > do with accessing shared memory. I'm trying to run Tomcat > and get about 100 messages per minute, so I'm faced > with either turning off selinux completely, turning off > the error logging on selinux, or turning off selinux > for java specifically. One option would be to turn off execmem for everything until you get a chance to figure out how to do something more limited. You can do this in the security settings or use 'setsebool -P allow_execmem on'. From paul at city-fan.org Fri May 5 06:11:43 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 05 May 2006 07:11:43 +0100 Subject: Disable for java? In-Reply-To: <20060505014420.11632.qmail@web38510.mail.mud.yahoo.com> References: <20060505014420.11632.qmail@web38510.mail.mud.yahoo.com> Message-ID: <1146809503.19738.3.camel@laurel.intra.city-fan.org> On Thu, 2006-05-04 at 18:44 -0700, Fred Harris wrote: > Is there any way to disable selinux for java? I tried > chcon -t java_exec_t /opt/java > > which I found searching around, and that didn't work. > > The problem I'm having is that I'm getting a million messages > complaining about "execmem", I guess having something to > do with accessing shared memory. I'm trying to run Tomcat > and get about 100 messages per minute, so I'm faced > with either turning off selinux completely, turning off > the error logging on selinux, or turning off selinux > for java specifically. Are these "denial" or "granted" messages? I believe the "granted" messages were turned off in an FC5 policy update - is your system up to date regarding the SELinux packages? > I'm running the latest Sun Java version. You might also try installing Sun Java using the "JPackage method", which doesn't install the files under /opt: http://www.city-fan.org/tips/JpackageJava Paul. From fedora at grifent.com Fri May 5 12:07:32 2006 From: fedora at grifent.com (John Griffiths) Date: Fri, 05 May 2006 08:07:32 -0400 Subject: targeted policy will not let hostname write to pgstartup.log In-Reply-To: <20060504160015.87E8473C34@hormel.redhat.com> References: <20060504160015.87E8473C34@hormel.redhat.com> Message-ID: <445B4004.6080305@grifent.com> When postgreSQL starts, hostname is denied write to the pgstartup.log. May 4 23:13:12 gei kernel: audit(1146798787.850:59): avc: denied { append } for pid=2479 comm="hostname" name="pgstartup.log" dev=dm-0 ino=1333032 scontext=system_u:system_r:hostname_t:s0 tcontext=system_u:object_r:postgresql_log_t:s0 tclass=file Using selinux-policy-targeted-2.2.34-3.fc5 Regards, John From frharris27 at yahoo.com Fri May 5 15:31:26 2006 From: frharris27 at yahoo.com (Fred Harris) Date: Fri, 5 May 2006 08:31:26 -0700 (PDT) Subject: Disable for java? Message-ID: <20060505153126.23433.qmail@web38510.mail.mud.yahoo.com> Thanks for replying. Bruno, I tried doing what you said, but had to use setsebool -P allow_execmem true ('true' instead of 'on') is that the same thing? I think it was already enabled anyway. The problem I'm getting is with message logging, not with enabling. Paul, the messages I'm getting are the following. >>> May 4 16:50:32 bd1 kernel: audit(1146786631.723:22): avc: granted { execmem } for pid=2159 comm="java" scontext=root:system_r:initrc_t:s0 tcontext=root:system_r:initrc_t:s0 tclass=process <<< Why would installing in other than /opt make a difference? I used to install in /usr/java, but Fedora says that /opt is where you should install a comprehensive package like the JDK. I purposely don't install the GNU JDK because there are lots of bugs in it I've found. How do you update to the latest policy for SELinux? I yumed to the latest Kernel. I can't find a package for SELinux, though. I think I'm not getting some very basic stuff about working with SELinux. It's pretty confusing to me. I've searched most of the FAQs and explanations I can find on Google. Is there a simple, good link that explains it all? For instance I have this basic question about whether or not you can turn off monitoring for a specific application like java_home/bin/java. It seems to me that something like that would be absolutely necessary while apps get up to speed with SELinux. Thanks. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From green at redhat.com Fri May 5 16:03:41 2006 From: green at redhat.com (Anthony Green) Date: Fri, 05 May 2006 09:03:41 -0700 Subject: Disable for java? In-Reply-To: <20060505153126.23433.qmail@web38510.mail.mud.yahoo.com> References: <20060505153126.23433.qmail@web38510.mail.mud.yahoo.com> Message-ID: <1146845021.2910.20.camel@localhost.localdomain> On Fri, 2006-05-05 at 08:31 -0700, Fred Harris wrote: > Why would installing in other than /opt make a difference? I used to > install in > /usr/java, but Fedora says that /opt is where you should install a > comprehensive > package like the JDK. The Fedora wiki actually refers you to the instructions here: http://www.city-fan.org/tips/JpackageJava If there's something else that conflicts this message, please point it out and we can correct it. > I purposely don't install the GNU JDK because there > are lots of bugs in it I've found. Did you report any of them? http://bugzilla.redhat.com Thanks! AG From Valdis.Kletnieks at vt.edu Fri May 5 16:12:50 2006 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 05 May 2006 12:12:50 -0400 Subject: Disable for java? In-Reply-To: Your message of "Fri, 05 May 2006 08:31:26 PDT." <20060505153126.23433.qmail@web38510.mail.mud.yahoo.com> References: <20060505153126.23433.qmail@web38510.mail.mud.yahoo.com> Message-ID: <200605051612.k45GCoQ7004501@turing-police.cc.vt.edu> On Fri, 05 May 2006 08:31:26 PDT, Fred Harris said: Probably not *directly* related to your problem, but.... > May 4 16:50:32 bd1 kernel: audit(1146786631.723:22): avc: granted { execmem } for pid=2159 comm="java" scontext=root:system_r:initrc_t:s0 tcontext=root:system_r:initrc_t:s0 tclass=process OOK. Gaak. and other choking noises. ;) Is it just me, or does the fact that this is being tripped in *initrc_t* saying that we're missing a domain transition someplace? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From gauret at free.fr Fri May 5 16:14:24 2006 From: gauret at free.fr (Aurelien Bompard) Date: Fri, 05 May 2006 18:14:24 +0200 Subject: NFS sharing is blocked Message-ID: Hi all, Since the last policy upgrade, I can't share my NFS dir. Since this directory is also available through apache, I had to set its type to httpd_sys_content_t. I'm getting this type of message : type=AVC msg=audit(1146845517.056:16545): avc: denied { getattr } for pid=8729 comm="rpc.mountd" name="musique" dev=md0 ino=17039419 scontext=user_u:system_r:nfsd_t:s0 tcontext=user_u:object_r:httpd_sys_content_t:s0 tclass=dir Which type should it be labeled to to be seen from NFS and from Apache (and from FTP by the way) ? Which leads me to another question: is there a tool to view which file_contexts a program is allowed to access ? If there isn't, do you think it wouldn't be hard to write one (can the python bindings do that) ? Thanks Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "Millions long for immortality who do not know what to do with themselves on a rainy Sunday afternoon." -- Susan Ertz From frharris27 at yahoo.com Fri May 5 15:34:59 2006 From: frharris27 at yahoo.com (Fred Harris) Date: Fri, 5 May 2006 08:34:59 -0700 (PDT) Subject: Disable for java? Message-ID: <20060505153459.95990.qmail@web38514.mail.mud.yahoo.com> BTW, sorry, I'm not sure if I made this clear. The reason execmem message logging is a problem is that they're flooding my logs and are making log reading very difficult. It seems to be about a couple of hundred messages at Tomcat startup and another couple hundred every hour, so it's a big pain to deal with them. Thanks __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at city-fan.org Fri May 5 17:06:46 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 05 May 2006 18:06:46 +0100 Subject: Disable for java? In-Reply-To: <20060505153126.23433.qmail@web38510.mail.mud.yahoo.com> References: <20060505153126.23433.qmail@web38510.mail.mud.yahoo.com> Message-ID: <1146848806.19738.76.camel@laurel.intra.city-fan.org> On Fri, 2006-05-05 at 08:31 -0700, Fred Harris wrote: > Thanks for replying. > > Bruno, I tried doing what you said, but had to use > setsebool -P allow_execmem true ('true' instead of 'on') > > is that the same thing? I think it was already enabled anyway. > The problem I'm getting is with message logging, not with > enabling. > > Paul, the messages I'm getting are the following. > >>> > May 4 16:50:32 bd1 kernel: audit(1146786631.723:22): avc: granted > { execmem } for pid=2159 comm="java" > scontext=root:system_r:initrc_t:s0 tcontext=root:system_r:initrc_t:s0 > tclass=process > <<< $ rpm -q --changelog selinux-policy-targeted * Fri Apr 21 2006 Dan Walsh 2.2.34-3.fc5 - Bump for fc5 ... ... ... * Mon Apr 03 2006 Dan Walsh 2.2.29-2 - Add mono dbus support - Lots of file_context fixes for textrel_shlib_t in FC5 - Turn off execmem auditallow since they are filling log files This one appears to be exactly the problem you are seeing, so it should be fixed on an up to date system. > Why would installing in other than /opt make a difference? I used to > install in > /usr/java, but Fedora says that /opt is where you should install a > comprehensive > package like the JDK. It should work under /opt but, depending on how it got installed there, you might need to set file contexts manually. Installing using the JPackage rpms means that rpm gets to install it, and since rpm is an selinux-aware tool, it can set the correct file contexts for you, provided the policy includes the correct file contexts (which I think it does). > How do you update to the latest policy for SELinux? I yumed to the > latest Kernel. I can't find a package for SELinux, though. Well, what do you currently have? I have these versions: $ rpm -qa selinux\* selinux-policy-targeted-2.2.34-3.fc5 selinux-policy-2.2.34-3.fc5 If that's not what you have, try this: # yum update selinux\* > I think I'm not getting some very basic stuff about working with > SELinux. It's pretty confusing to me. I've searched most of the > FAQs and explanations > I can find on Google. Is there a simple, good link that explains it > all? http://fedoraproject.org/wiki/SELinux is a good starting point I think. > For instance I have this basic question about whether or not you can > turn off > monitoring for a specific application like java_home/bin/java. It > seems to me that something like that would be absolutely necessary > while apps get up to speed with SELinux. It shouldn't be necessary at all really if the policy is working correctly. Most of the daemons protected in the targeted policy have a "disable_trans" boolean that effectively turns off SELinux protection for them. However, for Java processes the problem is a bit different since it's the memory protection that causes issues, and that applies across the board rather than to specific daemon domains. Paul. From smooge at gmail.com Fri May 5 17:11:55 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 5 May 2006 11:11:55 -0600 Subject: NFS sharing is blocked In-Reply-To: References: Message-ID: <80d7e4090605051011y57d1f05dn1b191fc58cb4cf2e@mail.gmail.com> On 5/5/06, Aurelien Bompard wrote: > Hi all, > > Since the last policy upgrade, I can't share my NFS dir. Since this > directory is also available through apache, I had to set its type to > httpd_sys_content_t. > > I'm getting this type of message : > type=AVC msg=audit(1146845517.056:16545): avc: denied { getattr } for > pid=8729 comm="rpc.mountd" name="musique" dev=md0 ino=17039419 > scontext=user_u:system_r:nfsd_t:s0 > tcontext=user_u:object_r:httpd_sys_content_t:s0 tclass=dir > > Which type should it be labeled to to be seen from NFS and from Apache (and > from FTP by the way) ? > > Which leads me to another question: is there a tool to view which > file_contexts a program is allowed to access ? If there isn't, do you think > it wouldn't be hard to write one (can the python bindings do that) ? > > Thanks I think the sledgehammer fix is to do a setsebool -P nfsd_disable_trans on There is most likely a better way using a change of policies.. but all my background is way outdated with the new policies and stuff. -- Stephen J Smoogen. CSIRT/Linux System Administrator From frharris27 at yahoo.com Sat May 6 14:23:21 2006 From: frharris27 at yahoo.com (Fred Harris) Date: Sat, 6 May 2006 07:23:21 -0700 (PDT) Subject: Disable for java? In-Reply-To: <1146848806.19738.76.camel@laurel.intra.city-fan.org> Message-ID: <20060506142321.71870.qmail@web36411.mail.mud.yahoo.com> Thanks Paul. It was a matter of updating to the latest version. Paul Howarth wrote: On Fri, 2006-05-05 at 08:31 -0700, Fred Harris wrote: > Thanks for replying. > > Bruno, I tried doing what you said, but had to use > setsebool -P allow_execmem true ('true' instead of 'on') > > is that the same thing? I think it was already enabled anyway. > The problem I'm getting is with message logging, not with > enabling. > > Paul, the messages I'm getting are the following. > >>> > May 4 16:50:32 bd1 kernel: audit(1146786631.723:22): avc: granted > { execmem } for pid=2159 comm="java" > scontext=root:system_r:initrc_t:s0 tcontext=root:system_r:initrc_t:s0 > tclass=process > <<< $ rpm -q --changelog selinux-policy-targeted * Fri Apr 21 2006 Dan Walsh 2.2.34-3.fc5 - Bump for fc5 ... ... ... * Mon Apr 03 2006 Dan Walsh 2.2.29-2 - Add mono dbus support - Lots of file_context fixes for textrel_shlib_t in FC5 - Turn off execmem auditallow since they are filling log files This one appears to be exactly the problem you are seeing, so it should be fixed on an up to date system. > Why would installing in other than /opt make a difference? I used to > install in > /usr/java, but Fedora says that /opt is where you should install a > comprehensive > package like the JDK. It should work under /opt but, depending on how it got installed there, you might need to set file contexts manually. Installing using the JPackage rpms means that rpm gets to install it, and since rpm is an selinux-aware tool, it can set the correct file contexts for you, provided the policy includes the correct file contexts (which I think it does). > How do you update to the latest policy for SELinux? I yumed to the > latest Kernel. I can't find a package for SELinux, though. Well, what do you currently have? I have these versions: $ rpm -qa selinux\* selinux-policy-targeted-2.2.34-3.fc5 selinux-policy-2.2.34-3.fc5 If that's not what you have, try this: # yum update selinux\* > I think I'm not getting some very basic stuff about working with > SELinux. It's pretty confusing to me. I've searched most of the > FAQs and explanations > I can find on Google. Is there a simple, good link that explains it > all? http://fedoraproject.org/wiki/SELinux is a good starting point I think. > For instance I have this basic question about whether or not you can > turn off > monitoring for a specific application like java_home/bin/java. It > seems to me that something like that would be absolutely necessary > while apps get up to speed with SELinux. It shouldn't be necessary at all really if the policy is working correctly. Most of the daemons protected in the targeted policy have a "disable_trans" boolean that effectively turns off SELinux protection for them. However, for Java processes the problem is a bit different since it's the memory protection that causes issues, and that applies across the board rather than to specific daemon domains. Paul. --------------------------------- Get amazing travel prices for air and hotel in one click on Yahoo! FareChase -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmorris at namei.org Sun May 7 16:05:29 2006 From: jmorris at namei.org (James Morris) Date: Sun, 7 May 2006 12:05:29 -0400 (EDT) Subject: New SECMARK based network controls posted Message-ID: For those not on the main SELinux list (or netdev or netfilter-devel), I've just posted an RFC and patches for a new scheme for per-packet network controls. See: http://thread.gmane.org/gmane.linux.network/34927/focus=34927 http://people.redhat.com/jmorris/selinux/secmark/ - James -- James Morris From dwalsh at redhat.com Tue May 9 13:37:20 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 09 May 2006 09:37:20 -0400 Subject: Disable for java? In-Reply-To: <20060505153126.23433.qmail@web38510.mail.mud.yahoo.com> References: <20060505153126.23433.qmail@web38510.mail.mud.yahoo.com> Message-ID: <44609B10.8020109@redhat.com> Fred Harris wrote: > Thanks for replying. > > Bruno, I tried doing what you said, but had to use > setsebool -P allow_execmem true ('true' instead of 'on') > > is that the same thing? I think it was already enabled anyway. > The problem I'm getting is with message logging, not with > enabling. > > Paul, the messages I'm getting are the following. > >>> > May 4 16:50:32 bd1 kernel: audit(1146786631.723:22): avc: granted { > execmem } for pid=2159 comm="java" scontext=root:system_r:initrc_t:s0 > tcontext=root:system_r:initrc_t:s0 tclass=process > <<< > > Why would installing in other than /opt make a difference? I used to > install in > /usr/java, but Fedora says that /opt is where you should install a > comprehensive > package like the JDK. I purposely don't install the GNU JDK because there > are lots of bugs in it I've found. > > How do you update to the latest policy for SELinux? I yumed to the > latest Kernel. I can't find a package for SELinux, though. > > I think I'm not getting some very basic stuff about working with > SELinux. It's pretty confusing to me. I've searched most of the > FAQs and explanations > I can find on Google. Is there a simple, good link that explains it > all? For instance I have this basic question about whether or not you > can turn off > monitoring for a specific application like java_home/bin/java. It > seems to me that something like that would be absolutely necessary > while apps get itup to speed with SELinux. > > > Thanks. To update selinux policy you need to execute yum upgrade selinux-policy The latest policy should not be showing the "granted"s. What is the context of the java executable ls -lZ PATHTO/java If it is not java_exec_t then do chcon -t java_exec_t PATHTO/java Dan > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > ------------------------------------------------------------------------ > > -- > 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 May 9 13:48:09 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 09 May 2006 09:48:09 -0400 Subject: NFS sharing is blocked In-Reply-To: References: Message-ID: <44609D99.1020802@redhat.com> Aurelien Bompard wrote: > Hi all, > > Since the last policy upgrade, I can't share my NFS dir. Since this > directory is also available through apache, I had to set its type to > httpd_sys_content_t. > > I'm getting this type of message : > type=AVC msg=audit(1146845517.056:16545): avc: denied { getattr } for > pid=8729 comm="rpc.mountd" name="musique" dev=md0 ino=17039419 > scontext=user_u:system_r:nfsd_t:s0 > tcontext=user_u:object_r:httpd_sys_content_t:s0 tclass=dir > > Which type should it be labeled to to be seen from NFS and from Apache (and > from FTP by the way) ? > public_content_t should do it, although I am not sure for nfs. Is the boolean nfs_export_all_ro turned on getsebool nfs_export_all_ro If not turn it on via setsebool -P nfs_export_all_ro=1 > Which leads me to another question: is there a tool to view which > file_contexts a program is allowed to access ? If there isn't, do you think > it wouldn't be hard to write one (can the python bindings do that) ? > > Thanks > > Aur?lien > From selinux at gmail.com Tue May 9 15:18:52 2006 From: selinux at gmail.com (Tom London) Date: Tue, 9 May 2006 08:18:52 -0700 Subject: prelink and ssh_keysign_exec_t Message-ID: <4c4ba1530605090818g56680305j631d47723cd6b1b5@mail.gmail.com> Running latest rawhide, targeted/enforcing (selinux-policy-targeted-2.2.38-1): Prelink produces the following AVC: type=AVC msg=audit(1147186351.884:41): avc: denied { read } for pid=4803 comm="prelink" name="ssh-keysign" dev=dm-0 ino=9242507 scontext=system_u:system_r:prelink_t:s0 tcontext=system_u:object_r:ssh_keysign_exec_t:s0 tclass=file type=SYSCALL msg=audit(1147186351.884:41): arch=40000003 syscall=5 success=no exit=-13 a0=8de2b68 a1=8000 a2=0 a3=0 items=1 pid=4803 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="prelink" exe="/usr/sbin/prelink" subj=system_u:system_r:prelink_t:s0 type=CWD msg=audit(1147186351.884:41): cwd="/" type=PATH msg=audit(1147186351.884:41): item=0 name="/usr/libexec/openssh/ssh-keysign" inode=9242507 dev=fd:00 mode=0104711 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ssh_keysign_exec_t:s0 tom -- Tom London From st.gross at gmx.de Tue May 9 18:36:48 2006 From: st.gross at gmx.de (Stephan =?iso-8859-15?q?Gro=DF?=) Date: Tue, 9 May 2006 20:36:48 +0200 Subject: FC5: Problem with acroread and CISCO VPN In-Reply-To: <4451ECE8.9080804@city-fan.org> References: <200604270739.27984.Klaus.Steinberger@physik.uni-muenchen.de> <200604281215.09305.st.gross@gmx.de> <4451ECE8.9080804@city-fan.org> Message-ID: <200605092036.52451.st.gross@gmx.de> On Friday 28 April 2006 12:22, Paul Howarth wrote: > >>> I have the above mentioned selinux-policy-2.2.34-3.fc5 installed. > >>> However, a "restorecon -vR /usr/local/Adobe" results in > >>> > >>> "/etc/selinux/targeted/contexts/files/file_contexts: Multiple different > >>> specifications for /opt (system_u:object_r:home_root_t and > >>> system_u:object_r:usr_t). > >>> /etc/selinux/targeted/contexts/files/file_contexts: Multiple different > >>> specifications for /opt (system_u:object_r:home_root_t and > >>> system_u:object_r:usr_t)." > >> > >> Have you moved root's home directory from /root to somewhere under /opt? > > > > No, its still in /root. I only have the Brockhaus Multimedia Encyclopedia > > (the german answer to MS Encarte) installed that registers a user bmm > > having its home directory in /opt/bmm. However, I just checked that /opt > > is of type home_root_t and all of its subdirectories are of type > > user_home_dir_t. Should I change any of these settings? > > Moving its home directory to somewhere under /home might help. I finally found a solution for that issue. Changing the bmm users login shell to /sbin/nologin (he must not login anyway) did the trick. Then I ran a /usr/sbin/genhomedircon to generate a new /etc/selinux/targeted/contexts/files/file_contexts.homedirs. Now Adobe Acroread works like a charm (using selinux-policy-targeted-2.2.36-2.fc5). Stephan. From Valdis.Kletnieks at vt.edu Tue May 9 22:07:01 2006 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 09 May 2006 18:07:01 -0400 Subject: selinux-policy.spec wierdness? Message-ID: <200605092207.k49M71Q6018985@turing-police.cc.vt.edu> Am looking at selinux-policy-2.2.38-1.src.rpm. Does anybody know why there isn't a %build section in the .SPEC file? I was *hoping* to do a 'rpmbuild -bc' to assist in debugging an outstanding problem I'm having with strict policy, but apparently all the building gets done in the %install. Blech. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From udjinrg at forenet.by Wed May 10 07:53:16 2006 From: udjinrg at forenet.by (Maxim Britov) Date: Wed, 10 May 2006 10:53:16 +0300 Subject: selinux-policy.spec wierdness? In-Reply-To: <200605092207.k49M71Q6018985@turing-police.cc.vt.edu> References: <200605092207.k49M71Q6018985@turing-police.cc.vt.edu> Message-ID: <20060510105316.7279abf3@maxim.office.modum.by> On Tue, 09 May 2006 18:07:01 -0400 Valdis.Kletnieks at vt.edu wrote: > Am looking at selinux-policy-2.2.38-1.src.rpm. Does anybody know > why there isn't a %build section in the .SPEC file? I was *hoping* > to do a 'rpmbuild -bc' to assist in debugging an outstanding problem > I'm having with strict policy, but apparently all the building gets > done in the %install. Blech. Confirm. selinux-policy-strict-2.2.38-1 in fc5 updates is broken :( Updating : selinux-policy-strict ####################### [ 4/10] libsepol.scope_copy_callback: authlogin: Duplicate declaration in module: type/attribute system_chkpwd_t libsemanage.semanage_link_sandbox: Link packages failed semodule: Failed! -- Maxim Britov GnuPG KeyID 0x4580A6D66F3DB1FB xmpp:maxim at modum.by icq 198171258 Fingerprint: 4059 B5C5 8985 5A47 8F5A 8623 4580 A6D6 6F3D B1FB GnuPG-ru Team (http://lists.gnupg.org/mailman/listinfo/gnupg-ru xmpp:gnupg-ru at conference.jabber.ru) From Valdis.Kletnieks at vt.edu Wed May 10 08:07:11 2006 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 10 May 2006 04:07:11 -0400 Subject: selinux-policy.spec wierdness? In-Reply-To: Your message of "Wed, 10 May 2006 10:53:16 +0300." <20060510105316.7279abf3@maxim.office.modum.by> References: <200605092207.k49M71Q6018985@turing-police.cc.vt.edu> <20060510105316.7279abf3@maxim.office.modum.by> Message-ID: <200605100807.k4A87Cul018290@turing-police.cc.vt.edu> On Wed, 10 May 2006 10:53:16 +0300, Maxim Britov said: > On Tue, 09 May 2006 18:07:01 -0400 > Valdis.Kletnieks at vt.edu wrote: > > > Am looking at selinux-policy-2.2.38-1.src.rpm. Does anybody know > > why there isn't a %build section in the .SPEC file? I was *hoping* > > to do a 'rpmbuild -bc' to assist in debugging an outstanding problem > > I'm having with strict policy, but apparently all the building gets > > done in the %install. Blech. > > Confirm. selinux-policy-strict-2.2.38-1 in fc5 updates is broken :( > > Updating : selinux-policy-strict ####################### [ 4/10] > libsepol.scope_copy_callback: authlogin: Duplicate declaration in module: typ e/attribute system_chkpwd_t > libsemanage.semanage_link_sandbox: Link packages failed > semodule: Failed! https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188060 is already open for the system_chkpwd_t problem. I came across the specfile problem while trying to debug that problem. The interesting part is that Horst opened that bug against 2.2.29, I finally got fed up with rpm complaining and found the bugzilla - and nobody else has attached themselves to the cc: list. For a while, I was wondering if Horst and I were the only two trying to use the Rawhide 'strict' policy... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From lehmann at cnm.de Wed May 10 09:13:44 2006 From: lehmann at cnm.de (Marten Lehmann) Date: Wed, 10 May 2006 11:13:44 +0200 Subject: noexec mount-option with selinux? Message-ID: Hello, I would like to mount the /tmp directory with the noexec option, so that no files can be executed directly from /tmp. But the problem is, that I don't have a separate partition for /tmp. It would be useless to create one, because the users on this system have strict quota limits, which wouldn't apply on a separate /tmp partition. Lots of example policies only show ways to restrict certain applications. But is there a way to restrict access to the /tmp directory in general, too? Regards Marten From sds at tycho.nsa.gov Wed May 10 11:27:19 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 10 May 2006 07:27:19 -0400 Subject: selinux-policy.spec wierdness? In-Reply-To: <200605092207.k49M71Q6018985@turing-police.cc.vt.edu> References: <200605092207.k49M71Q6018985@turing-police.cc.vt.edu> Message-ID: <1147260439.8341.18.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2006-05-09 at 18:07 -0400, Valdis.Kletnieks at vt.edu wrote: > Am looking at selinux-policy-2.2.38-1.src.rpm. Does anybody know > why there isn't a %build section in the .SPEC file? I was *hoping* > to do a 'rpmbuild -bc' to assist in debugging an outstanding problem > I'm having with strict policy, but apparently all the building gets > done in the %install. Blech. 1) strict policy is known to be broken simply due to the current brokenness of optionals-in-base support in checkpolicy/libsepol. Patches are coming soon. It isn't really strict policy per se, but fully modularized policy where the base has to contain optional sections that need to be dynamically enabled at link time. 2) At present, you can build a working copy of a given policy build tree via: rpmbuild -bb --define "BUILD_xxx 0" --define "BUILD_yyy 0" selinux-policy.spec where xxx and yyy are MLS, STRICT, or TARGETED, and you are disabling the ones you don't want. e.g. to build a working copy of a build tree for just strict, you'd use: rpmbuild -bb --define "BUILD_MLS 0" --define "BUILD_TARGETED 0" selinux-policy.spec This tries to build a binary package, of course, but leaves the build tree intact so that you can then go use it. We do need a cleaner way of doing this, or at least for it to be documented in the FAQ. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Wed May 10 11:29:19 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 10 May 2006 07:29:19 -0400 Subject: noexec mount-option with selinux? In-Reply-To: References: Message-ID: <1147260559.8341.20.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-05-10 at 11:13 +0200, Marten Lehmann wrote: > Hello, > > I would like to mount the /tmp directory with the noexec option, so that no > files can be executed directly from /tmp. But the problem is, that I don't > have a separate partition for /tmp. It would be useless to create one, because > the users on this system have strict quota limits, which wouldn't apply on a > separate /tmp partition. > > Lots of example policies only show ways to restrict certain applications. But > is there a way to restrict access to the /tmp directory in general, too? You can certainly not allow execute permission to *_tmp_t (the types applied to files created in /tmp) in your policy. In fact, most domains should already be that way. unconfined_t naturally can do that (since it is unconfined); you could create a customized version of it that isn't allowed to do that, but only via a custom policy. -- Stephen Smalley National Security Agency From dac at tresys.com Wed May 10 11:54:19 2006 From: dac at tresys.com (david caplan) Date: Wed, 10 May 2006 07:54:19 -0400 Subject: noexec mount-option with selinux? In-Reply-To: <1147260559.8341.20.camel@moss-spartans.epoch.ncsc.mil> References: <1147260559.8341.20.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1147262059.29111.20.camel@acme.columbia.tresys.com> On Wed, 2006-05-10 at 07:29 -0400, Stephen Smalley wrote: > On Wed, 2006-05-10 at 11:13 +0200, Marten Lehmann wrote: > > Hello, > > > > I would like to mount the /tmp directory with the noexec option, so that no > > files can be executed directly from /tmp. But the problem is, that I don't > > have a separate partition for /tmp. It would be useless to create one, because > > the users on this system have strict quota limits, which wouldn't apply on a > > separate /tmp partition. > > > > Lots of example policies only show ways to restrict certain applications. But > > is there a way to restrict access to the /tmp directory in general, too? > > You can certainly not allow execute permission to *_tmp_t (the types > applied to files created in /tmp) in your policy. In fact, most domains > should already be that way. unconfined_t naturally can do that (since > it is unconfined); you could create a customized version of it that > isn't allowed to do that, but only via a custom policy. > Keep in mind that not every file created in /tmp gets a *_tmp_t type. (sesearch --type -t tmp_t policy.conf) I think this ("not allow execute permission to *_tmp_t") may be harder than you think unless you want to restrict a single domain type. On my FC5 machine (with a default policy) I see almost 30 domains with execute access on various tmp file types: sesearch --allow -t tmp -i -p execute -c file I see over 30 in a strict version of the reference policy. I don't know if the execute access is necessary, but I suspect a lot of things will break if the access is removed. David (Note sesearch is part of the setools package and gives you some of the policy searching capabilities of apol on the command line.) From sds at tycho.nsa.gov Wed May 10 12:21:55 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 10 May 2006 08:21:55 -0400 Subject: noexec mount-option with selinux? In-Reply-To: <1147262059.29111.20.camel@acme.columbia.tresys.com> References: <1147260559.8341.20.camel@moss-spartans.epoch.ncsc.mil> <1147262059.29111.20.camel@acme.columbia.tresys.com> Message-ID: <1147263715.8341.30.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-05-10 at 07:54 -0400, david caplan wrote: > Keep in mind that not every file created in /tmp gets a *_tmp_t type. > (sesearch --type -t tmp_t policy.conf) On FC5, default policy, the only types I get from that output (applied to the installed binary policy, as there is no policy.conf) that don't include a _tmp_t suffix are httpd_sys_script_rw_t (for files created under /tmp by CGIs) and cardmgr_dev_t (for device nodes created by cardmgr). Offhand, I don't see why those should be executable either. > I think this ("not allow execute permission to *_tmp_t") may be harder > than you think unless you want to restrict a single domain type. On my > FC5 machine (with a default policy) I see almost 30 domains with execute > access on various tmp file types: > sesearch --allow -t tmp -i -p execute -c file I tried this command on FC5, default policy, and I get 5 rules, two based on attributes, one rule for initrc_t, and two rules for logrotate_t. So most of the cases appear to be attribute-based, likely one for unconfined domains and not certain about the other. Being able to execute files from /tmp is not desirable in general. > I see over 30 in a strict version of the reference policy. I don't know > if the execute access is necessary, but I suspect a lot of things will > break if the access is removed. -- Stephen Smalley National Security Agency From paul at city-fan.org Wed May 10 14:34:15 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 10 May 2006 15:34:15 +0100 Subject: rndc and chroot Message-ID: <4461F9E7.2060504@city-fan.org> It appears that rndc and chroot named don't mix nicely. I got these denials: May 10 15:07:08 goalkeeper kernel: audit(1147270028.236:15088): avc: denied { read } for pid=19767 comm="rndc" name="rndc.conf" dev=dm-0 ino=381773 scontext=root:system_r:ndc_t:s0 tcontext=system_u:object_r:named_conf_t:s0 tclass=lnk_file May 10 15:07:08 goalkeeper kernel: audit(1147270028.272:15089): avc: denied { read } for pid=19767 comm="rndc" name="rndc.key" dev=dm-0 ino=381783 scontext=root:system_r:ndc_t:s0 tcontext=system_u:object_r:dnssec_t:s0 tclass=lnk_file because rndc isn't allowed to follow symlinks into the chroot named environment: $ ls -lZ /etc/rndc.* lrwxrwxrwx root named system_u:object_r:named_conf_t /etc/rndc.conf -> /var/named/chroot//etc/rndc.conf lrwxrwxrwx root named system_u:object_r:dnssec_t /etc/rndc.key -> /var/named/chroot/etc/rndc.key $ ls -lZL /etc/rndc.* -rw-r----- root named system_u:object_r:named_conf_t /etc/rndc.conf -rw-r----- root named system_u:object_r:dnssec_t /etc/rndc.key I think ndc_t should be able to follow these links. Paul. From paul at city-fan.org Wed May 10 14:59:11 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 10 May 2006 15:59:11 +0100 Subject: procmail In-Reply-To: <4448DD27.90605@city-fan.org> References: <443BCBFB.2050104@city-fan.org> <443FB650.1040309@redhat.com> <4445212A.2060708@city-fan.org> <4448AD9E.1090909@city-fan.org> <1145625342.18861.16.camel@sgc.columbia.tresys.com> <4448DD27.90605@city-fan.org> Message-ID: <4461FFBF.6070205@city-fan.org> Paul Howarth wrote: > Christopher J. PeBenito wrote: >> On Fri, 2006-04-21 at 11:02 +0100, Paul Howarth wrote: >>> Paul Howarth wrote: >> >>> module procmail 0.1; >>> >>> require { >> [cut] >>> class dir { add_name getattr read remove_name search write }; >>> class file { append create execute execute_no_trans getattr >>> ioctl lock read rename unlink write }; >>> class lnk_file read; >>> class process { noatsecure sigchld siginh transition >>> rlimitinh }; >>> class fd { use }; >>> class fifo_file { getattr read write append ioctl lock }; >> [cut] >>> This does seem to work but surely there's a tidier way of handling >>> those class requirements? What am I missing? >> >> You want to use the "policy_module(procmail,0.1)" macro instead of the >> module statement at the top. It adds all of the kernel object classes, >> so you don't have to write them all out. > > Thanks, that's much better: > > policy_module(procmail, 0.2) > > require { > type procmail_t; > type sbin_t; > type var_log_t; > }; > > # Needed for writing to /var/log/procmail.log > allow procmail_t var_log_t:dir search; > allow procmail_t var_log_t:file append; > > # ============================================== > # Procmail needs to call sendmail for forwarding > # ============================================== > # This should be in selinux-policy-2.2.34-2 onwards > > # Read alternatives link > allow procmail_t sbin_t:lnk_file read; > > # Allow transition to sendmail > # (may need similar code for other MTAs that can replace sendmail) > optional_policy(`sendmail',` > sendmail_domtrans(procmail_t) > ') selinux-policy-2.2.34-2 has the domain transition allowing procmail to run sendmail, but: 1. it still doesn't allow the sbin_t:lnk_file read to follow the "alternatives" link /usr/sbin/sendmail -> /etc/alternatives/mta 2. there will need to be a transition enabled for other MTAs that can replace sendmail, such as postfix, exim, etc. if their sendmail-compatible command-line program is not labelled sendmail_exec_t. Paul. From bruno at wolff.to Wed May 10 16:18:41 2006 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 10 May 2006 11:18:41 -0500 Subject: selinux-policy.spec wierdness? In-Reply-To: <200605100807.k4A87Cul018290@turing-police.cc.vt.edu> References: <200605092207.k49M71Q6018985@turing-police.cc.vt.edu> <20060510105316.7279abf3@maxim.office.modum.by> <200605100807.k4A87Cul018290@turing-police.cc.vt.edu> Message-ID: <20060510161841.GB3752@wolff.to> On Wed, May 10, 2006 at 04:07:11 -0400, Valdis.Kletnieks at vt.edu wrote: > On Wed, 10 May 2006 10:53:16 +0300, Maxim Britov said: > > On Tue, 09 May 2006 18:07:01 -0400 > > Valdis.Kletnieks at vt.edu wrote: > > > > > Am looking at selinux-policy-2.2.38-1.src.rpm. Does anybody know > > > why there isn't a %build section in the .SPEC file? I was *hoping* > > > to do a 'rpmbuild -bc' to assist in debugging an outstanding problem > > > I'm having with strict policy, but apparently all the building gets > > > done in the %install. Blech. > > > > Confirm. selinux-policy-strict-2.2.38-1 in fc5 updates is broken :( > > > > Updating : selinux-policy-strict ####################### [ 4/10] > > libsepol.scope_copy_callback: authlogin: Duplicate declaration in module: typ > e/attribute system_chkpwd_t > > libsemanage.semanage_link_sandbox: Link packages failed > > semodule: Failed! > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188060 > > is already open for the system_chkpwd_t problem. I came across the specfile > problem while trying to debug that problem. > > The interesting part is that Horst opened that bug against 2.2.29, I finally > got fed up with rpm complaining and found the bugzilla - and nobody else has > attached themselves to the cc: list. For a while, I was wondering if Horst and > I were the only two trying to use the Rawhide 'strict' policy... I have been seeing this for a while in FC5 and have an open ticket (190012) that I am about to update saying the problem isn't fixed with 2.2.38-1.fc5. From dwalsh at redhat.com Wed May 10 19:38:36 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 10 May 2006 15:38:36 -0400 Subject: rndc and chroot In-Reply-To: <4461F9E7.2060504@city-fan.org> References: <4461F9E7.2060504@city-fan.org> Message-ID: <4462413C.20607@redhat.com> Paul Howarth wrote: > It appears that rndc and chroot named don't mix nicely. > > I got these denials: > > May 10 15:07:08 goalkeeper kernel: audit(1147270028.236:15088): avc: > denied { read } for pid=19767 comm="rndc" name="rndc.conf" dev=dm-0 > ino=381773 scontext=root:system_r:ndc_t:s0 > tcontext=system_u:object_r:named_conf_t:s0 tclass=lnk_file > > May 10 15:07:08 goalkeeper kernel: audit(1147270028.272:15089): avc: > denied { read } for pid=19767 comm="rndc" name="rndc.key" dev=dm-0 > ino=381783 scontext=root:system_r:ndc_t:s0 > tcontext=system_u:object_r:dnssec_t:s0 tclass=lnk_file > > because rndc isn't allowed to follow symlinks into the chroot named > environment: > > $ ls -lZ /etc/rndc.* > lrwxrwxrwx root named system_u:object_r:named_conf_t > /etc/rndc.conf -> /var/named/chroot//etc/rndc.conf > lrwxrwxrwx root named system_u:object_r:dnssec_t /etc/rndc.key > -> /var/named/chroot/etc/rndc.key > > $ ls -lZL /etc/rndc.* > -rw-r----- root named system_u:object_r:named_conf_t > /etc/rndc.conf > -rw-r----- root named system_u:object_r:dnssec_t > /etc/rndc.key > > I think ndc_t should be able to follow these links. > Those links should be etc_t? > Paul. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From kmahaindra at axalto.com Thu May 11 05:17:28 2006 From: kmahaindra at axalto.com (Ketut Mahaindra) Date: Thu, 11 May 2006 13:17:28 +0800 Subject: Allowing vsftpd access for user's home directory Message-ID: <008a01c674ba$340acd20$9c4d1bac@axalto.com> Hello all, I have installation of FC5. I want to make vsftpd run with chroot environment of user home directory. So far it does not work because SELinux prevents the vsftpd to access the home directory. What's the best way to configure SELinux for this purpose? I don't want to disable it. I have been googling it around but so far has not came up with any easy solution. Any help will be appreciated. P.S. - I have the following AVC error messages: avc: denied { dac_override } for pid=9099 comm="vsftpd" capability=1 scontext=system_u:system_r:ftpd_t:s0 tcontext=system_u:system_r:ftpd_t:s0 tclass=capability avc: denied { dac_read_search } for pid=9099 comm="vsftpd" capability=2 scontext=system_u:system_r:ftpd_t:s0 tcontext=system_u:system_r:ftpd_t:s0 tclass=capability -- Best regards, Ketut Mahaindra (Ito) From kayvan at sylvan.com Thu May 11 05:28:57 2006 From: kayvan at sylvan.com (Kayvan A. Sylvan) Date: Wed, 10 May 2006 22:28:57 -0700 Subject: Allowing vsftpd access for user's home directory In-Reply-To: <008a01c674ba$340acd20$9c4d1bac@axalto.com> References: <008a01c674ba$340acd20$9c4d1bac@axalto.com> Message-ID: <20060511052857.GA5202@satyr.sylvan.com> On Thu, May 11, 2006 at 01:17:28PM +0800, Ketut Mahaindra wrote: > Hello all, > > I have installation of FC5. > I want to make vsftpd run with chroot environment of user home directory. > So far it does not work because SELinux prevents the vsftpd to access the > home directory. > > What's the best way to configure SELinux for this purpose? > I don't want to disable it. > I have been googling it around but so far has not came up with any easy > solution. > > Any help will be appreciated. > > P.S. > - I have the following AVC error messages: > avc: denied { dac_override } for pid=9099 comm="vsftpd" capability=1 > scontext=system_u:system_r:ftpd_t:s0 tcontext=system_u:system_r:ftpd_t:s0 > tclass=capability > avc: denied { dac_read_search } for pid=9099 comm="vsftpd" capability=2 > scontext=system_u:system_r:ftpd_t:s0 tcontext=system_u:system_r:ftpd_t:s0 > tclass=capability You can use audit2allow and the local.te file to allow what you want. See http://www.samag.com/documents/s=9820/sam0508a/0508a.htm Best regards, ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan, | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | my beautiful Queen. | Robin Gregory (2/28/92) From paul at city-fan.org Thu May 11 05:31:57 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 11 May 2006 06:31:57 +0100 Subject: rndc and chroot In-Reply-To: <4462413C.20607@redhat.com> References: <4461F9E7.2060504@city-fan.org> <4462413C.20607@redhat.com> Message-ID: <1147325517.20848.1.camel@laurel.intra.city-fan.org> On Wed, 2006-05-10 at 15:38 -0400, Daniel J Walsh wrote: > Paul Howarth wrote: > > It appears that rndc and chroot named don't mix nicely. > > > > I got these denials: > > > > May 10 15:07:08 goalkeeper kernel: audit(1147270028.236:15088): avc: > > denied { read } for pid=19767 comm="rndc" name="rndc.conf" dev=dm-0 > > ino=381773 scontext=root:system_r:ndc_t:s0 > > tcontext=system_u:object_r:named_conf_t:s0 tclass=lnk_file > > > > May 10 15:07:08 goalkeeper kernel: audit(1147270028.272:15089): avc: > > denied { read } for pid=19767 comm="rndc" name="rndc.key" dev=dm-0 > > ino=381783 scontext=root:system_r:ndc_t:s0 > > tcontext=system_u:object_r:dnssec_t:s0 tclass=lnk_file > > > > because rndc isn't allowed to follow symlinks into the chroot named > > environment: > > > > $ ls -lZ /etc/rndc.* > > lrwxrwxrwx root named system_u:object_r:named_conf_t > > /etc/rndc.conf -> /var/named/chroot//etc/rndc.conf > > lrwxrwxrwx root named system_u:object_r:dnssec_t /etc/rndc.key > > -> /var/named/chroot/etc/rndc.key > > > > $ ls -lZL /etc/rndc.* > > -rw-r----- root named system_u:object_r:named_conf_t > > /etc/rndc.conf > > -rw-r----- root named system_u:object_r:dnssec_t > > /etc/rndc.key > > > > I think ndc_t should be able to follow these links. > > > Those links should be etc_t? Hmm, you're right: # restorecon -v /etc/rndc.* restorecon reset /etc/rndc.conf context system_u:object_r:named_conf_t->system_u:object_r:etc_t restorecon reset /etc/rndc.key context system_u:object_r:dnssec_t->system_u:object_r:etc_t I wonder how they got those contexts? Paul. From paul at city-fan.org Thu May 11 05:51:51 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 11 May 2006 06:51:51 +0100 Subject: Allowing vsftpd access for user's home directory In-Reply-To: <008a01c674ba$340acd20$9c4d1bac@axalto.com> References: <008a01c674ba$340acd20$9c4d1bac@axalto.com> Message-ID: <1147326711.20848.14.camel@laurel.intra.city-fan.org> On Thu, 2006-05-11 at 13:17 +0800, Ketut Mahaindra wrote: > Hello all, > > I have installation of FC5. > I want to make vsftpd run with chroot environment of user home directory. > So far it does not work because SELinux prevents the vsftpd to access the > home directory. > > What's the best way to configure SELinux for this purpose? > I don't want to disable it. > I have been googling it around but so far has not came up with any easy > solution. > > Any help will be appreciated. > > P.S. > - I have the following AVC error messages: > avc: denied { dac_override } for pid=9099 comm="vsftpd" capability=1 > scontext=system_u:system_r:ftpd_t:s0 tcontext=system_u:system_r:ftpd_t:s0 > tclass=capability > avc: denied { dac_read_search } for pid=9099 comm="vsftpd" capability=2 > scontext=system_u:system_r:ftpd_t:s0 tcontext=system_u:system_r:ftpd_t:s0 > tclass=capability Have you set the ftp_home_dir boolean as suggested in "man ftpd_selinux"? Paul. From kmahaindra at axalto.com Thu May 11 06:05:47 2006 From: kmahaindra at axalto.com (Ketut Mahaindra) Date: Thu, 11 May 2006 14:05:47 +0800 Subject: Allowing vsftpd access for user's home directory In-Reply-To: <1147326711.20848.14.camel@laurel.intra.city-fan.org> Message-ID: <008b01c674c0$f37a4fe0$9c4d1bac@axalto.com> Hello, Yes, I have tried to do the following as recommended by man ftpd_selinux # setsebool -P ftp_home_dir 1 # setsebool -P ftpd_is_daemon 1 But I still get the same AVC error messages each time an FTP client attempt to connect. Here is what the audit.log give me: type=USER_AUTH msg=audit(1147327523.025:325): user pid=3608 uid=0 auid=500 msg='PAM: authentication acct=kmahaindra : exe="/usr/sbin/vsftpd" (hostname=172.27.77.156, addr=172.27.77.156, terminal=? res=success)' type=USER_ACCT msg=audit(1147327523.025:326): user pid=3608 uid=0 auid=500 msg='PAM: accounting acct=kmahaindra : exe="/usr/sbin/vsftpd" (hostname=172.27.77.156, addr=172.27.77.156, terminal=? res=success)' type=CRED_ACQ msg=audit(1147327523.029:327): user pid=3608 uid=0 auid=500 msg='PAM: setcred acct=kmahaindra : exe="/usr/sbin/vsftpd" (hostname=172.27.77.156, addr=172.27.77.156, terminal=? res=success)' type=AVC msg=audit(1147327523.029:328): avc: denied { dac_override } for pid=3612 comm="vsftpd" capability=1 scontext=user_u:system_r:ftpd_t:s0 tcontext=user_u:system_r:ftpd_t:s0 tclass=capability type=AVC msg=audit(1147327523.029:328): avc: denied { dac_read_search } for pid=3612 comm="vsftpd" capability=2 scontext=user_u:system_r:ftpd_t:s0 tcontext=user_u:system_r:ftpd_t:s0 tclass=capability type=SYSCALL msg=audit(1147327523.029:328): arch=40000003 syscall=61 success=no exit=-13 a0=66c6f6 a1=0 a2=6732dc a3=1 items=1 pid=3612 auid=500 uid=0 gid=0 euid=0 suid=500 fsuid=0 egid=0 sgid=500 fsgid=0 comm="vsftpd" exe="/usr/sbin/vsftpd" type=CWD msg=audit(1147327523.029:328): cwd="/home/kmahaindra" type=PATH msg=audit(1147327523.029:328): item=0 name="." flags=3 Any other clues? Or perhaps I was missing something / some steps? -- Best regards, Ketut Mahaindra (Ito) "The race for perfection has no finish line" -----Original Message----- From: Paul Howarth [mailto:paul at city-fan.org] Sent: Thursday, May 11, 2006 1:52 PM To: Ketut Mahaindra Cc: fedora-selinux-list at redhat.com Subject: Re: Allowing vsftpd access for user's home directory On Thu, 2006-05-11 at 13:17 +0800, Ketut Mahaindra wrote: > Hello all, > > I have installation of FC5. > I want to make vsftpd run with chroot environment of user home directory. > So far it does not work because SELinux prevents the vsftpd to access the > home directory. > > What's the best way to configure SELinux for this purpose? > I don't want to disable it. > I have been googling it around but so far has not came up with any easy > solution. > > Any help will be appreciated. > > P.S. > - I have the following AVC error messages: > avc: denied { dac_override } for pid=9099 comm="vsftpd" capability=1 > scontext=system_u:system_r:ftpd_t:s0 tcontext=system_u:system_r:ftpd_t:s0 > tclass=capability > avc: denied { dac_read_search } for pid=9099 comm="vsftpd" capability=2 > scontext=system_u:system_r:ftpd_t:s0 tcontext=system_u:system_r:ftpd_t:s0 > tclass=capability Have you set the ftp_home_dir boolean as suggested in "man ftpd_selinux"? Paul. From kmahaindra at axalto.com Thu May 11 06:32:59 2006 From: kmahaindra at axalto.com (Ketut Mahaindra) Date: Thu, 11 May 2006 14:32:59 +0800 Subject: Allowing vsftpd access for user's home directory In-Reply-To: <20060511052857.GA5202@satyr.sylvan.com> Message-ID: <00aa01c674c4$bfce7af0$9c4d1bac@axalto.com> Hello, I tried your suggestion in conjunction with the FC5 SELinux FAQ: http://fedora.redhat.com/docs/selinux-faq-fc5/#id2958106 So, I did the following # audit2allow -m local -l -i /var/log/audit/audit.log Which give me something like: module local 1.0; require { class capability { dac_override dac_read_search }; type ftpd_t; }; allow ftpd_t self:capability { dac_override dac_read_search }; So, naturally I want it to be inside a file for compilation. Then I did: # audit2allow -m local -l -i /var/log/audit/audit.log > local.te # checkmodule -M -m -o local.mod local.te # semodule_package -o local.pp -m local.mod # semodule -i local.pp But, on that last step I get an error message "semodule: Could not read file 'local.pp':" It's strange, because the file local.pp is created normally by the semodule_package command. Did I miss anything? -- Best regards, Ketut Mahaindra (Ito) "The race for perfection has no finish line" -----Original Message----- From: Kayvan A. Sylvan [mailto:kayvan at sylvan.com] Sent: Thursday, May 11, 2006 1:29 PM To: Ketut Mahaindra Cc: fedora-selinux-list at redhat.com Subject: Re: Allowing vsftpd access for user's home directory On Thu, May 11, 2006 at 01:17:28PM +0800, Ketut Mahaindra wrote: > Hello all, > > I have installation of FC5. > I want to make vsftpd run with chroot environment of user home directory. > So far it does not work because SELinux prevents the vsftpd to access the > home directory. > > What's the best way to configure SELinux for this purpose? > I don't want to disable it. > I have been googling it around but so far has not came up with any easy > solution. > > Any help will be appreciated. > > P.S. > - I have the following AVC error messages: > avc: denied { dac_override } for pid=9099 comm="vsftpd" capability=1 > scontext=system_u:system_r:ftpd_t:s0 tcontext=system_u:system_r:ftpd_t:s0 > tclass=capability > avc: denied { dac_read_search } for pid=9099 comm="vsftpd" capability=2 > scontext=system_u:system_r:ftpd_t:s0 tcontext=system_u:system_r:ftpd_t:s0 > tclass=capability You can use audit2allow and the local.te file to allow what you want. See http://www.samag.com/documents/s=9820/sam0508a/0508a.htm Best regards, ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan, | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | my beautiful Queen. | Robin Gregory (2/28/92) From paul at city-fan.org Thu May 11 06:52:59 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 11 May 2006 07:52:59 +0100 Subject: Allowing vsftpd access for user's home directory In-Reply-To: <00aa01c674c4$bfce7af0$9c4d1bac@axalto.com> References: <00aa01c674c4$bfce7af0$9c4d1bac@axalto.com> Message-ID: <1147330379.20848.37.camel@laurel.intra.city-fan.org> On Thu, 2006-05-11 at 14:32 +0800, Ketut Mahaindra wrote: > Hello, > > I tried your suggestion in conjunction with the FC5 SELinux FAQ: > http://fedora.redhat.com/docs/selinux-faq-fc5/#id2958106 > > So, I did the following > # audit2allow -m local -l -i /var/log/audit/audit.log > > Which give me something like: > > module local 1.0; > require { > class capability { dac_override dac_read_search }; > > type ftpd_t; > }; > allow ftpd_t self:capability { dac_override dac_read_search }; > > So, naturally I want it to be inside a file for compilation. > Then I did: > > # audit2allow -m local -l -i /var/log/audit/audit.log > local.te > # checkmodule -M -m -o local.mod local.te > # semodule_package -o local.pp -m local.mod > # semodule -i local.pp > > But, on that last step I get an error message "semodule: Could not read > file 'local.pp':" > It's strange, because the file local.pp is created normally by the > semodule_package command. > > Did I miss anything? Try this: Move the files you've used for this process (the .te/.pp files etc.) to a new, empty directory (I used /root/selinux.local) and change to that directory. Then do: # chcon -Rh -t usr_t . Then try the semanage command again. Paul. From bleher at informatik.uni-muenchen.de Thu May 11 07:16:35 2006 From: bleher at informatik.uni-muenchen.de (Thomas Bleher) Date: Thu, 11 May 2006 09:16:35 +0200 Subject: Allowing vsftpd access for user's home directory In-Reply-To: <008a01c674ba$340acd20$9c4d1bac@axalto.com> References: <008a01c674ba$340acd20$9c4d1bac@axalto.com> Message-ID: <20060511071634.GA7571@thorium.jmh.mhn.de> * Ketut Mahaindra [2006-05-11 07:19]: > Hello all, > > I have installation of FC5. > I want to make vsftpd run with chroot environment of user home directory. > So far it does not work because SELinux prevents the vsftpd to access the > home directory. > > P.S. > - I have the following AVC error messages: > avc: denied { dac_override } for pid=9099 comm="vsftpd" capability=1 > scontext=system_u:system_r:ftpd_t:s0 tcontext=system_u:system_r:ftpd_t:s0 > tclass=capability > avc: denied { dac_read_search } for pid=9099 comm="vsftpd" capability=2 > scontext=system_u:system_r:ftpd_t:s0 tcontext=system_u:system_r:ftpd_t:s0 > tclass=capability This means that vsftpd can't access some files or directories because it does not have DAC rights on it. Probably some home directory is mode 0700. Either you change the rights on the directory or you allow the capabilities as discussed in this thread. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: Digital signature URL: From kmahaindra at axalto.com Thu May 11 08:47:19 2006 From: kmahaindra at axalto.com (Ketut Mahaindra) Date: Thu, 11 May 2006 16:47:19 +0800 Subject: Allowing vsftpd access for user's home directory In-Reply-To: <1147330379.20848.37.camel@laurel.intra.city-fan.org> Message-ID: <00f901c674d7$8497a840$9c4d1bac@axalto.com> Hello, Tried that as well, I am using ~/selinux/local After the change by chcon # ls -Z ~/selinux drwxr-xr-x root root user_u:object_r:usr_t local # ls -Z ~/selinux/local -rw-r--r-- root root user_u:object_r:usr_t local.mod -rw-r--r-- root root user_u:object_r:usr_t local.pp -rw-r--r-- root root user_u:object_r:usr_t local.te # semodule -i local.pp libsemanage.semanage_commit_sandbox: Could not remove previous backup /etc/selinux/targeted/modules/previous. In fact I have now solved the issue. It involves enabling the boolean as you suggested before : # setsebool -P ftp_home_dir 1 # setsebool -P ftpd_is_daemon 1 Plus, changing the corresponding user home directory ACL to be less restrictive than 0700 -> 0755 ( thanks to Thomas Bleher for the hint ) -- Best regards, Ketut Mahaindra (Ito) "The race for perfection has no finish line" -----Original Message----- From: Paul Howarth Sent: Thursday, May 11, 2006 2:53 PM To: Ketut Mahaindra Cc: fedora-selinux-list at redhat.com Subject: RE: Allowing vsftpd access for user's home directory On Thu, 2006-05-11 at 14:32 +0800, Ketut Mahaindra wrote: > Hello, > > I tried your suggestion in conjunction with the FC5 SELinux FAQ: > http://fedora.redhat.com/docs/selinux-faq-fc5/#id2958106 > > So, I did the following > # audit2allow -m local -l -i /var/log/audit/audit.log > > Which give me something like: > > module local 1.0; > require { > class capability { dac_override dac_read_search }; > > type ftpd_t; > }; > allow ftpd_t self:capability { dac_override dac_read_search }; > > So, naturally I want it to be inside a file for compilation. > Then I did: > > # audit2allow -m local -l -i /var/log/audit/audit.log > local.te > # checkmodule -M -m -o local.mod local.te > # semodule_package -o local.pp -m local.mod > # semodule -i local.pp > > But, on that last step I get an error message "semodule: Could not read > file 'local.pp':" > It's strange, because the file local.pp is created normally by the > semodule_package command. > > Did I miss anything? Try this: Move the files you've used for this process (the .te/.pp files etc.) to a new, empty directory (I used /root/selinux.local) and change to that directory. Then do: # chcon -Rh -t usr_t . Then try the semanage command again. Paul. From kmahaindra at axalto.com Thu May 11 08:48:40 2006 From: kmahaindra at axalto.com (Ketut Mahaindra) Date: Thu, 11 May 2006 16:48:40 +0800 Subject: Allowing vsftpd access for user's home directory In-Reply-To: <20060511071634.GA7571@thorium.jmh.mhn.de> Message-ID: <00fa01c674d7$b3cd3a80$9c4d1bac@axalto.com> Hello, Thanks a lot, that solves it! Of course prior to that I need to enable the corresponding boolean # setsebool -P ftp_home_dir 1 # setsebool -P ftpd_is_daemon 1 -- Best regards, Ketut Mahaindra (Ito) "The race for perfection has no finish line" -----Original Message----- From: Thomas Bleher Sent: Thursday, May 11, 2006 3:17 PM To: Ketut Mahaindra Cc: fedora-selinux-list at redhat.com Subject: Re: Allowing vsftpd access for user's home directory * Ketut Mahaindra [2006-05-11 07:19]: > Hello all, > > I have installation of FC5. > I want to make vsftpd run with chroot environment of user home directory. > So far it does not work because SELinux prevents the vsftpd to access the > home directory. > > P.S. > - I have the following AVC error messages: > avc: denied { dac_override } for pid=9099 comm="vsftpd" capability=1 > scontext=system_u:system_r:ftpd_t:s0 tcontext=system_u:system_r:ftpd_t:s0 > tclass=capability > avc: denied { dac_read_search } for pid=9099 comm="vsftpd" capability=2 > scontext=system_u:system_r:ftpd_t:s0 tcontext=system_u:system_r:ftpd_t:s0 > tclass=capability This means that vsftpd can't access some files or directories because it does not have DAC rights on it. Probably some home directory is mode 0700. Either you change the rights on the directory or you allow the capabilities as discussed in this thread. Thomas From bleher at informatik.uni-muenchen.de Thu May 11 08:57:51 2006 From: bleher at informatik.uni-muenchen.de (Thomas Bleher) Date: Thu, 11 May 2006 10:57:51 +0200 Subject: Allowing vsftpd access for user's home directory In-Reply-To: <20060511071634.GA7571@thorium.jmh.mhn.de> References: <008a01c674ba$340acd20$9c4d1bac@axalto.com> <20060511071634.GA7571@thorium.jmh.mhn.de> Message-ID: <20060511085750.GB7571@thorium.jmh.mhn.de> * Thomas Bleher [2006-05-11 09:16]: > * Ketut Mahaindra [2006-05-11 07:19]: > > - I have the following AVC error messages: > > avc: denied { dac_override } for pid=9099 comm="vsftpd" capability=1 > > scontext=system_u:system_r:ftpd_t:s0 tcontext=system_u:system_r:ftpd_t:s0 > > tclass=capability > > avc: denied { dac_read_search } for pid=9099 comm="vsftpd" capability=2 > > scontext=system_u:system_r:ftpd_t:s0 tcontext=system_u:system_r:ftpd_t:s0 > > tclass=capability > > This means that vsftpd can't access some files or directories because it > does not have DAC rights on it. Probably some home directory is mode > 0700. Either you change the rights on the directory or you allow the > capabilities as discussed in this thread. BTW: Is there some way to get more information out of the kernel about which file is being accessed? This would be really helpful in debugging why an application needs dac_override. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: Digital signature URL: From kmahaindra at axalto.com Thu May 11 09:34:30 2006 From: kmahaindra at axalto.com (Ketut Mahaindra) Date: Thu, 11 May 2006 17:34:30 +0800 Subject: Allowing vsftpd access for user's home directory In-Reply-To: <00f901c674d7$8497a840$9c4d1bac@axalto.com> Message-ID: <011701c674de$1b4d4b90$9c4d1bac@axalto.com> On the following problem: # semodule -i local.pp libsemanage.semanage_commit_sandbox: Could not remove previous backup /etc/selinux/targeted/modules/previous. semodule: Failed! ----- I found the following on this list April thread to temporarily fix the issue: Stephen Smalley wrote: > Looks like the type isn't getting preserved > on /etc/selinux/$SELINUXTYPE/modules/{active,previous} upon updates - > they are reverting from semanage_store_t to selinux_config_t (the type > on their parent directory. We either need to put semanage_store_t > on /etc/selinux/$SELINUXTYPE/modules as well or we need to make > libsemanage preserve the types. > Aurelien Bompard wrote: > OK, so it's something to fix at the main policy level, right (I can't do > anything about it) ? Stephen Smalley wrote: > Correct. You can restorecon -R /etc/selinux/targeted to temporarily > fix it, but it will keep reverting on each transaction. chcon -t > semanage_store_t /etc/selinux/targeted/modules may solve the problem > with keeping the type on the active and previous subdirectories, but > ultimately needs to be applied in the policy. ----- So, I did: # restorecon -R /etc/selinux/targeted # semodule -i local.pp And I no longer have the failed message above. This helps me to solve to make local policy module for ftpd access over resources with type httpd_sys_content_t ( enabling ftp access over user web resources ) :) -- Best regards, Ketut Mahaindra (Ito) "The race for perfection has no finish line" -----Original Message----- From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux-list-bounces at redhat.com] On Behalf Of Ketut Mahaindra Sent: Thursday, May 11, 2006 4:47 PM To: fedora-selinux-list at redhat.com Subject: RE: Allowing vsftpd access for user's home directory Hello, Tried that as well, I am using ~/selinux/local After the change by chcon # ls -Z ~/selinux drwxr-xr-x root root user_u:object_r:usr_t local # ls -Z ~/selinux/local -rw-r--r-- root root user_u:object_r:usr_t local.mod -rw-r--r-- root root user_u:object_r:usr_t local.pp -rw-r--r-- root root user_u:object_r:usr_t local.te # semodule -i local.pp libsemanage.semanage_commit_sandbox: Could not remove previous backup /etc/selinux/targeted/modules/previous. In fact I have now solved the issue. It involves enabling the boolean as you suggested before : # setsebool -P ftp_home_dir 1 # setsebool -P ftpd_is_daemon 1 Plus, changing the corresponding user home directory ACL to be less restrictive than 0700 -> 0755 ( thanks to Thomas Bleher for the hint ) -- Best regards, Ketut Mahaindra (Ito) "The race for perfection has no finish line" -----Original Message----- From: Paul Howarth Sent: Thursday, May 11, 2006 2:53 PM To: Ketut Mahaindra Cc: fedora-selinux-list at redhat.com Subject: RE: Allowing vsftpd access for user's home directory On Thu, 2006-05-11 at 14:32 +0800, Ketut Mahaindra wrote: > Hello, > > I tried your suggestion in conjunction with the FC5 SELinux FAQ: > http://fedora.redhat.com/docs/selinux-faq-fc5/#id2958106 > > So, I did the following > # audit2allow -m local -l -i /var/log/audit/audit.log > > Which give me something like: > > module local 1.0; > require { > class capability { dac_override dac_read_search }; > > type ftpd_t; > }; > allow ftpd_t self:capability { dac_override dac_read_search }; > > So, naturally I want it to be inside a file for compilation. > Then I did: > > # audit2allow -m local -l -i /var/log/audit/audit.log > local.te > # checkmodule -M -m -o local.mod local.te > # semodule_package -o local.pp -m local.mod > # semodule -i local.pp > > But, on that last step I get an error message "semodule: Could not read > file 'local.pp':" > It's strange, because the file local.pp is created normally by the > semodule_package command. > > Did I miss anything? Try this: Move the files you've used for this process (the .te/.pp files etc.) to a new, empty directory (I used /root/selinux.local) and change to that directory. Then do: # chcon -Rh -t usr_t . Then try the semanage command again. Paul. -- fedora-selinux-list mailing list fedora-selinux-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list From sds at tycho.nsa.gov Thu May 11 11:50:01 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 11 May 2006 07:50:01 -0400 Subject: Allowing vsftpd access for user's home directory In-Reply-To: <20060511085750.GB7571@thorium.jmh.mhn.de> References: <008a01c674ba$340acd20$9c4d1bac@axalto.com> <20060511071634.GA7571@thorium.jmh.mhn.de> <20060511085750.GB7571@thorium.jmh.mhn.de> Message-ID: <1147348201.8341.52.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-05-11 at 10:57 +0200, Thomas Bleher wrote: > * Thomas Bleher [2006-05-11 09:16]: > > * Ketut Mahaindra [2006-05-11 07:19]: > > > - I have the following AVC error messages: > > > avc: denied { dac_override } for pid=9099 comm="vsftpd" capability=1 > > > scontext=system_u:system_r:ftpd_t:s0 tcontext=system_u:system_r:ftpd_t:s0 > > > tclass=capability > > > avc: denied { dac_read_search } for pid=9099 comm="vsftpd" capability=2 > > > scontext=system_u:system_r:ftpd_t:s0 tcontext=system_u:system_r:ftpd_t:s0 > > > tclass=capability > > > > This means that vsftpd can't access some files or directories because it > > does not have DAC rights on it. Probably some home directory is mode > > 0700. Either you change the rights on the directory or you allow the > > capabilities as discussed in this thread. > > BTW: Is there some way to get more information out of the kernel about > which file is being accessed? This would be really helpful in debugging > why an application needs dac_override. If you have syscall auditing enabled, then a syscall audit record should be emitted at syscall exit that includes the path data whenever an AVC audit record was generated during the syscall processing. -- Stephen Smalley National Security Agency From lehmann at cnm.de Thu May 11 14:00:54 2006 From: lehmann at cnm.de (Marten Lehmann) Date: Thu, 11 May 2006 16:00:54 +0200 Subject: noexec mount-option with selinux? In-Reply-To: <1147260559.8341.20.camel@moss-spartans.epoch.ncsc.mil> References: <1147260559.8341.20.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <44634396.9050402@cnm.de> Hello, > You can certainly not allow execute permission to *_tmp_t (the types > applied to files created in /tmp) in your policy. In fact, most domains > should already be that way. but I don't want to create a policy for every single application. Just think of file permissions: They are valid for every user, no matter which application or service tries to access a certain file. The permissions apply for all processes. The same is true if I would mount /tmp on a separate partition wich noexec. So, how can I setup a noexec-policy for /tmp selinux that applies for all processes as file permissions or mount options do? Regards Marten From Valdis.Kletnieks at vt.edu Thu May 11 16:01:35 2006 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 11 May 2006 12:01:35 -0400 Subject: noexec mount-option with selinux? In-Reply-To: Your message of "Thu, 11 May 2006 16:00:54 +0200." <44634396.9050402@cnm.de> References: <1147260559.8341.20.camel@moss-spartans.epoch.ncsc.mil> <44634396.9050402@cnm.de> Message-ID: <200605111601.k4BG1ZCc003554@turing-police.cc.vt.edu> On Thu, 11 May 2006 16:00:54 +0200, Marten Lehmann said: > So, how can I setup a noexec-policy for /tmp selinux that applies for > all processes as file permissions or mount options do? At some point, you'll have to decide whether to do A or B: A) Build a custom SELinux policy, and maintain it as reference policy is updated, and debug all the issues yourself. B) Bite the bullet, and repartition with a separate /tmp (which is a good idea even without SELinux, as it kills off a whole class of attacks using hardlinks from /tmp to places on the root partition). Personally, I recommend redoing the disk with LVM, and leaving a bit of unallocated space, so if your initial guesses for partition sizes is wrong you can grow them on the fly. My standard Fedora builds have separate /, /boot, /usr, /usr/share, /usr/local, /var, and /tmp, all with suitably restrictive uses of 'ro', 'noexec', 'nodev', and 'nosuid'.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From dwalsh at redhat.com Thu May 11 17:08:11 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 11 May 2006 13:08:11 -0400 Subject: Allowing vsftpd access for user's home directory In-Reply-To: <008a01c674ba$340acd20$9c4d1bac@axalto.com> References: <008a01c674ba$340acd20$9c4d1bac@axalto.com> Message-ID: <44636F7B.5040405@redhat.com> Ketut Mahaindra wrote: > Hello all, > > I have installation of FC5. > I want to make vsftpd run with chroot environment of user home directory. > So far it does not work because SELinux prevents the vsftpd to access the > home directory. > > What's the best way to configure SELinux for this purpose? > I don't want to disable it. > I have been googling it around but so far has not came up with any easy > solution. > > Any help will be appreciated. > > P.S. > - I have the following AVC error messages: > avc: denied { dac_override } for pid=9099 comm="vsftpd" capability=1 > scontext=system_u:system_r:ftpd_t:s0 tcontext=system_u:system_r:ftpd_t:s0 > tclass=capability > avc: denied { dac_read_search } for pid=9099 comm="vsftpd" capability=2 > scontext=system_u:system_r:ftpd_t:s0 tcontext=system_u:system_r:ftpd_t:s0 > tclass=capability > > I added these to policy when homedirs are used. You might want to look at man ftpd_selinux. IF you want to share files between ftp and html you might want to label them public_content_t. From jhg at athensgroup.com Thu May 11 12:26:23 2006 From: jhg at athensgroup.com (James Garrison) Date: Thu, 11 May 2006 07:26:23 -0500 Subject: Where are targeted policy sources for FC5? Message-ID: <44632D6F.1000607@athensgroup.com> Many references exist to an RPM package called selinux-policy-targeted-sources in FC4, but this package doesn't seem to exist in FC5. Anyonw know where the corresponding package for FC5 is located? -- James Garrison Athens Group, Inc. mailto:jhg at athensgroup.com 5608 Parkcrest Dr http://www.athensgroup.com Austin, TX 78731 SKYPE callto:jhg-athensgroup (512) 345-0600 x150 PGP: RSA=0x92E90A3B DH/DSS=0x498D331C From paul at city-fan.org Thu May 11 21:08:47 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 11 May 2006 22:08:47 +0100 Subject: Where are targeted policy sources for FC5? In-Reply-To: <44632D6F.1000607@athensgroup.com> References: <44632D6F.1000607@athensgroup.com> Message-ID: <1147381728.21889.8.camel@laurel.intra.city-fan.org> On Thu, 2006-05-11 at 07:26 -0500, James Garrison wrote: > Many references exist to an RPM package called > selinux-policy-targeted-sources in FC4, but this > package doesn't seem to exist in FC5. Anyonw know > where the corresponding package for FC5 is located? The policies are built from the selinux-policy SRPM in FC5. Like with kernel-source, shipping a binary package for sources is no longer done. Paul. From jhg at athensgroup.com Thu May 11 22:41:20 2006 From: jhg at athensgroup.com (James Garrison) Date: Thu, 11 May 2006 17:41:20 -0500 Subject: selinux preventing Bugzilla on FC5 In-Reply-To: <1147381728.21889.8.camel@laurel.intra.city-fan.org> References: <44632D6F.1000607@athensgroup.com> <1147381728.21889.8.camel@laurel.intra.city-fan.org> Message-ID: <4463BD90.5030608@athensgroup.com> Objective: Run bugzilla on FC5 Problem: selinux is getting in the way First I had to change the file context for all of Bugzilla to httpd_sys_content_t, and the .cgi components to httpd_sys_script_exec_t. Next, I get the following when Bugzilla tries to open a tcp socket to talk to the database: > May 11 16:26:34 bugzilla kernel: audit(1147382794.700:3): avc: > denied { create } for pid=18527 comm="index.cgi" > scontext=user_u:system_r:httpd_sys_script_t:s0 > tcontext=user_u:system_r:httpd_sys_script_t:s0 tclass=tcp_socket No problem, according to the FAQ, just make a local module with audit2allow and install it with semodule. Here's what actually happens: > [jhg at bugzilla ~]$ audit2allow -M local < avc.dat > Generating type enforcment file: local.te > Compiling policy > checkmodule -M -m -o local.mod local.te > semodule_package -o local.pp -m local.mod > > ******************** IMPORTANT *********************** > > In order to load this newly created policy package into the kernel, > you are required to execute > > semodule -i local.pp > > > [jhg at bugzilla ~]$ sudo semodule -i local.pp > semodule: Could not read file 'local.pp': > [jhg at bugzilla ~]$ ls local* > local.mod local.pp local.te > [jhg at bugzilla ~]$ The problem is that semodule is not being allowed to read local.pp by selinux itself: > May 11 17:36:53 bugzilla kernel: audit(1147387013.477:14): avc: > denied { search } for pid=19191 comm="semodule" name="root" dev=md1 > ino=942849 scontext=user_u:system_r:semanage_t:s0 > tcontext=root:object_r:user_home_dir_t:s0 tclass=dir I've tried various combinations of sudo vs being logged on as root. So I'm stuck. At this point I'm inclined to switch back to non-enforcing mode and be done with it. Is it supposed to be this hard to configure? -- James Garrison Athens Group, Inc. mailto:jhg at athensgroup.com 5608 Parkcrest Dr http://www.athensgroup.com Austin, TX 78731 SKYPE callto:jhg-athensgroup (512) 345-0600 x150 PGP: RSA=0x92E90A3B DH/DSS=0x498D331C From paul at city-fan.org Thu May 11 22:54:20 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 11 May 2006 23:54:20 +0100 Subject: selinux preventing Bugzilla on FC5 In-Reply-To: <4463BD90.5030608@athensgroup.com> References: <44632D6F.1000607@athensgroup.com> <1147381728.21889.8.camel@laurel.intra.city-fan.org> <4463BD90.5030608@athensgroup.com> Message-ID: <1147388060.21889.17.camel@laurel.intra.city-fan.org> On Thu, 2006-05-11 at 17:41 -0500, James Garrison wrote: > Objective: Run bugzilla on FC5 > Problem: selinux is getting in the way > > First I had to change the file context for all of Bugzilla > to httpd_sys_content_t, and the .cgi components to > httpd_sys_script_exec_t. Next, I get the following when > Bugzilla tries to open a tcp socket to talk to the database: > > > May 11 16:26:34 bugzilla kernel: audit(1147382794.700:3): avc: > > denied { create } for pid=18527 comm="index.cgi" > > scontext=user_u:system_r:httpd_sys_script_t:s0 > > tcontext=user_u:system_r:httpd_sys_script_t:s0 tclass=tcp_socket > > No problem, according to the FAQ, just make a local module with audit2allow > and install it with semodule. Here's what actually happens: > > > [jhg at bugzilla ~]$ audit2allow -M local < avc.dat > > Generating type enforcment file: local.te > > Compiling policy > > checkmodule -M -m -o local.mod local.te > > semodule_package -o local.pp -m local.mod > > > > ******************** IMPORTANT *********************** > > > > In order to load this newly created policy package into the kernel, > > you are required to execute > > > > semodule -i local.pp > > > > > > [jhg at bugzilla ~]$ sudo semodule -i local.pp > > semodule: Could not read file 'local.pp': > > [jhg at bugzilla ~]$ ls local* > > local.mod local.pp local.te > > [jhg at bugzilla ~]$ > > The problem is that semodule is not being allowed to read local.pp > by selinux itself: > > > May 11 17:36:53 bugzilla kernel: audit(1147387013.477:14): avc: > > denied { search } for pid=19191 comm="semodule" name="root" dev=md1 > > ino=942849 scontext=user_u:system_r:semanage_t:s0 > > tcontext=root:object_r:user_home_dir_t:s0 tclass=dir Try this: Move the files you've used for this process (the .te/.pp files etc.) to a new, empty directory (I used /root/selinux.local) and change to that directory. Then do: # chcon -Rh -t usr_t . Then try the semanage command again. Paul. From jhg at athensgroup.com Thu May 11 23:21:51 2006 From: jhg at athensgroup.com (James Garrison) Date: Thu, 11 May 2006 18:21:51 -0500 Subject: selinux preventing Bugzilla on FC5 In-Reply-To: <1147388060.21889.17.camel@laurel.intra.city-fan.org> References: <44632D6F.1000607@athensgroup.com> <1147381728.21889.8.camel@laurel.intra.city-fan.org> <4463BD90.5030608@athensgroup.com> <1147388060.21889.17.camel@laurel.intra.city-fan.org> Message-ID: <4463C70F.6030108@athensgroup.com> The continuing saga.... > May 11 18:11:05 bugzilla kernel: audit(1147389065.041:16): avc: > denied { read } for pid=19398 comm="index.cgi" name="resolv.conf" > dev=md1 ino=1106152 scontext=user_u:system_r:httpd_sys_script_t:s0 > tcontext=system_u:object_r:net_conf_t:s0 tclass=file > May 11 18:11:05 bugzilla kernel: audit(1147389065.045:17): avc: > denied { create } for pid=19398 comm="index.cgi" > scontext=user_u:system_r:httpd_sys_script_t:s0 > tcontext=user_u:system_r:httpd_sys_script_t:s0 tclass=udp_socket > May 11 18:11:05 bugzilla kernel: audit(1147389065.045:18): avc: > denied { create } for pid=19398 comm="index.cgi" > scontext=user_u:system_r:httpd_sys_script_t:s0 > tcontext=user_u:system_r:httpd_sys_script_t:s0 tclass=udp_socket > May 11 18:11:05 bugzilla kernel: audit(1147389065.045:19): avc: > denied { shutdown } for pid=19398 comm="index.cgi" > scontext=user_u:system_r:httpd_sys_script_t:s0 > tcontext=user_u:system_r:httpd_sys_script_t:s0 tclass=tcp_socket It seems like I'm just going to have to keep trying and adding new allow rules, 2 or 3 at a time, until I've hit everything not allowed by selinux. Surely I'm not the first person to try to get Bugzilla running on FC5? Is there a better way to do this than trial and error? -- James Garrison Athens Group, Inc. mailto:jhg at athensgroup.com 5608 Parkcrest Dr http://www.athensgroup.com Austin, TX 78731 SKYPE callto:jhg-athensgroup (512) 345-0600 x150 PGP: RSA=0x92E90A3B DH/DSS=0x498D331C From lehmann at cnm.de Fri May 12 00:26:20 2006 From: lehmann at cnm.de (Marten Lehmann) Date: Fri, 12 May 2006 02:26:20 +0200 Subject: noexec mount-option with selinux? In-Reply-To: <200605111601.k4BG1ZCc003554@turing-police.cc.vt.edu> References: <1147260559.8341.20.camel@moss-spartans.epoch.ncsc.mil> <44634396.9050402@cnm.de> <200605111601.k4BG1ZCc003554@turing-police.cc.vt.edu> Message-ID: > A) Build a custom SELinux policy, and maintain it as reference policy is > updated, and debug all the issues yourself. I just need a hint on how to create a system-wide policy, not just an application level policy. Where can I find details on this? > B) Bite the bullet, and repartition with a separate /tmp (which is a good > idea even without SELinux, as it kills off a whole class of attacks using > hardlinks from /tmp to places on the root partition). It is not a technical problem to create a separate partition. But as I wrote in my first email I just cannot do it, because there is no way in linux to have system-wide quotas. Quotas are always only valid for one single partition. If I have quotas on the root partition (which includes /home) but /tmp is on a separate partition, then the quotas of / (and thus /home) don't apply for /tmp. That is the only reason why I have a look at selinux. If you have any other idea to have the same quotas for /home and /tmp while /tmp doesn't allow to execute files but /home does, then please tell me. Regards Marten From lamont at gurulabs.com Fri May 12 02:19:13 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Thu, 11 May 2006 20:19:13 -0600 Subject: noexec mount-option with selinux? In-Reply-To: References: <200605111601.k4BG1ZCc003554@turing-police.cc.vt.edu> Message-ID: <200605112019.17257.lamont@gurulabs.com> On Thursday 11 May 2006 06:26pm, Marten Lehmann wrote: > > A) Build a custom SELinux policy, and maintain it as reference policy is > > updated, and debug all the issues yourself. > > I just need a hint on how to create a system-wide policy, not just an > application level policy. Where can I find details on this? > > > B) Bite the bullet, and repartition with a separate /tmp (which is a good > > idea even without SELinux, as it kills off a whole class of attacks using > > hardlinks from /tmp to places on the root partition). > > It is not a technical problem to create a separate partition. But as I > wrote in my first email I just cannot do it, because there is no way in > linux to have system-wide quotas. Quotas are always only valid for one > single partition. If I have quotas on the root partition (which includes > /home) but /tmp is on a separate partition, then the quotas of / (and thus > /home) don't apply for /tmp. That is the only reason why I have a look at > selinux. > > If you have any other idea to have the same quotas for /home and /tmp while > /tmp doesn't allow to execute files but /home does, then please tell me. Do something like this in fstab (obviously, you might want to do something a little different with the mount options, but you get the idea): / /dev/vg0/root ext3 defaults 1 1 /home /dev/vg0/home ext3 usrquota,grpquota,nosuid 1 2 /tmp /dev/vg0/tmp ext3 usrquota,grpquota,noexec,nosuid 1 2 When you want to change the quotas or set them, run: # setquota username block-soft block-hard inode-soft inode-hard -a It's the -a at the end that make it set them the same for all filesystems. You can have multiple filesystems with quotas and they can have different values set. However, I don't think that's what you really want. After all, it might make sense to limit users to 100MB in their home directory, but maybe only 1MB in /tmp/ instead. Of course, if you have both /tmp/ and /home/ on the same filesystem, what's to stop a user with a 100MB from just using it up in /tmp/ ? Nothing. If the quota limits need to be as strict as your first message indicates, then I'm surprised you haven't already had /tmp/ on a separate filesystem, with separate quotas set. Additionally, I always split off /tmp/ so *if* it fills, it doesn't "damage" my root filesystem. HTH. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From paul at city-fan.org Fri May 12 08:07:53 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 12 May 2006 09:07:53 +0100 Subject: selinux preventing Bugzilla on FC5 In-Reply-To: <4463C70F.6030108@athensgroup.com> References: <44632D6F.1000607@athensgroup.com> <1147381728.21889.8.camel@laurel.intra.city-fan.org> <4463BD90.5030608@athensgroup.com> <1147388060.21889.17.camel@laurel.intra.city-fan.org> <4463C70F.6030108@athensgroup.com> Message-ID: <1147421273.2405.12.camel@laurel.intra.city-fan.org> On Thu, 2006-05-11 at 18:21 -0500, James Garrison wrote: > The continuing saga.... > > > May 11 18:11:05 bugzilla kernel: audit(1147389065.041:16): avc: > > denied { read } for pid=19398 comm="index.cgi" name="resolv.conf" > > dev=md1 ino=1106152 scontext=user_u:system_r:httpd_sys_script_t:s0 > > tcontext=system_u:object_r:net_conf_t:s0 tclass=file > > May 11 18:11:05 bugzilla kernel: audit(1147389065.045:17): avc: > > denied { create } for pid=19398 comm="index.cgi" > > scontext=user_u:system_r:httpd_sys_script_t:s0 > > tcontext=user_u:system_r:httpd_sys_script_t:s0 tclass=udp_socket > > May 11 18:11:05 bugzilla kernel: audit(1147389065.045:18): avc: > > denied { create } for pid=19398 comm="index.cgi" > > scontext=user_u:system_r:httpd_sys_script_t:s0 > > tcontext=user_u:system_r:httpd_sys_script_t:s0 tclass=udp_socket > > May 11 18:11:05 bugzilla kernel: audit(1147389065.045:19): avc: > > denied { shutdown } for pid=19398 comm="index.cgi" > > scontext=user_u:system_r:httpd_sys_script_t:s0 > > tcontext=user_u:system_r:httpd_sys_script_t:s0 tclass=tcp_socket > > It seems like I'm just going to have to keep trying and adding new > allow rules, 2 or 3 at a time, until I've hit everything not allowed > by selinux. Surely I'm not the first person to try to get Bugzilla > running on FC5? > > Is there a better way to do this than trial and error? You could put SELinux in permissive mode: # setenforce 0 then run bugzilla and get all of the SELinux denials logged, so you can deal with them all in one go. Then turn enforcing mode back on: # setenforce 1 You might also consider looking at the bugzilla package currently making its way through the Fedora Extras review process: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188359 This probably doesn't include any SELinux support (at least not yet), but might be better to use from a maintainability standpoint. Paul. From paul at city-fan.org Fri May 12 12:05:53 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 12 May 2006 13:05:53 +0100 Subject: Dovecot quota support Message-ID: <44647A21.1000805@city-fan.org> Dovecot now has quota support and it uses getmntent() to find the mountpoints. However, it's not allowed to read /etc/mtab: May 12 12:52:51 goalkeeper kernel: audit(1147434771.028:15131): avc: denied { read } for pid=15788 comm="dovecot" name="mtab" dev=dm-0 ino=381458 scontext=user_u:system_r:dovecot_t:s0 tcontext=user_u:object_r:etc_runtime_t:s0 tclass=file May 12 12:52:51 goalkeeper kernel: audit(1147434771.028:15132): avc: denied { getattr } for pid=15788 comm="dovecot" name="mtab" dev=dm-0 ino=381458 scontext=user_u:system_r:dovecot_t:s0 tcontext=user_u:object_r:etc_runtime_t:s0 tclass=file These getattr denials are for the three non-LVM partitions I have (/dev/shm being the tmpfs one). The 6 LVM volumes didn't generate these: May 12 12:52:51 goalkeeper kernel: audit(1147434771.048:15133): avc: denied { getattr } for pid=15788 comm="dovecot" name="/" dev=hda2 ino=2 scontext=user_u:system_r:dovecot_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=dir May 12 12:52:51 goalkeeper kernel: audit(1147434771.048:15134): avc: denied { getattr } for pid=15788 comm="dovecot" name="/" dev=hda1 ino=2 scontext=user_u:system_r:dovecot_t:s0 tcontext=system_u:object_r:boot_t:s0 tclass=dir May 12 12:52:51 goalkeeper kernel: audit(1147434771.048:15135): avc: denied { getattr } for pid=15788 comm="dovecot" name="/" dev=tmpfs ino=4523 scontext=user_u:system_r:dovecot_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir No big deal for me as I don't use quotas but someone will complain about it eventually... Paul. From lehmann at cnm.de Fri May 12 13:46:21 2006 From: lehmann at cnm.de (Marten Lehmann) Date: Fri, 12 May 2006 15:46:21 +0200 Subject: noexec mount-option with selinux? In-Reply-To: <200605112019.17257.lamont@gurulabs.com> References: <200605111601.k4BG1ZCc003554@turing-police.cc.vt.edu> <200605112019.17257.lamont@gurulabs.com> Message-ID: <446491AD.9090408@cnm.de> > When you want to change the quotas or set them, run: > # setquota username block-soft block-hard inode-soft inode-hard -a But I'm looking for a clean way to do it without workarounds with selinux! The system includes a webserver and when someone uses the fileupload of PHP, then the uploaded file will be stored in /tmp. So a quota of just 1 MB on /tmp for every user is not enough. > If the quota limits need to be as strict as your first message indicates, then > I'm surprised you haven't already had /tmp/ on a separate filesystem, with > separate quotas set. Additionally, I always split off /tmp/ so *if* it > fills, it doesn't "damage" my root filesystem. Actually, /home is not part of the root-partition and /tmp could be a symlink to /home/tmp so both can use the some quota definitions. But how can I setup a system-wide policy that disallows to execute files from /tmp or /home/tmp? Regards Marten From sds at tycho.nsa.gov Fri May 12 14:22:29 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 12 May 2006 10:22:29 -0400 Subject: noexec mount-option with selinux? In-Reply-To: <446491AD.9090408@cnm.de> References: <200605111601.k4BG1ZCc003554@turing-police.cc.vt.edu> <200605112019.17257.lamont@gurulabs.com> <446491AD.9090408@cnm.de> Message-ID: <1147443749.23563.43.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2006-05-12 at 15:46 +0200, Marten Lehmann wrote: > > When you want to change the quotas or set them, run: > > # setquota username block-soft block-hard inode-soft inode-hard -a > > But I'm looking for a clean way to do it without workarounds with selinux! > > The system includes a webserver and when someone uses the fileupload of > PHP, then the uploaded file will be stored in /tmp. So a quota of just 1 > MB on /tmp for every user is not enough. > > > If the quota limits need to be as strict as your first message indicates, then > > I'm surprised you haven't already had /tmp/ on a separate filesystem, with > > separate quotas set. Additionally, I always split off /tmp/ so *if* it > > fills, it doesn't "damage" my root filesystem. > > Actually, /home is not part of the root-partition and /tmp could be a > symlink to /home/tmp so both can use the some quota definitions. But how > can I setup a system-wide policy that disallows to execute files from > /tmp or /home/tmp? SELinux permission checks are pair-based checks between the process' domain and the object type (or to be precise, triple-based, with the security class as the third component). They aren't analogous to inode flags. So you can achieve the effect of such a policy by not allowing any process domain execute permission to any file type that can exist in /tmp, but not in the way you describe. -- Stephen Smalley National Security Agency From lists at ebourne.me.uk Fri May 12 15:18:31 2006 From: lists at ebourne.me.uk (Martin Ebourne) Date: Fri, 12 May 2006 16:18:31 +0100 Subject: noexec mount-option with selinux? In-Reply-To: <446491AD.9090408@cnm.de> References: <200605111601.k4BG1ZCc003554@turing-police.cc.vt.edu> <200605112019.17257.lamont@gurulabs.com> <446491AD.9090408@cnm.de> Message-ID: <1147447112.19324.2.camel@avenin.ebourne.me.uk> On Fri, 2006-05-12 at 15:46 +0200, Marten Lehmann wrote: > > If the quota limits need to be as strict as your first message indicates, then > > I'm surprised you haven't already had /tmp/ on a separate filesystem, with > > separate quotas set. Additionally, I always split off /tmp/ so *if* it > > fills, it doesn't "damage" my root filesystem. > > Actually, /home is not part of the root-partition and /tmp could be a > symlink to /home/tmp so both can use the some quota definitions. But how > can I setup a system-wide policy that disallows to execute files from > /tmp or /home/tmp? That sounds like a very hard way of doing things. And difficult to prove correct too. How about: mkdir /home/tmp mount -o bind,noexec,nosuid /home/tmp /tmp Much easier, guaranteed secure. Cheers, Martin. From dwalsh at redhat.com Fri May 12 17:22:24 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 12 May 2006 13:22:24 -0400 Subject: selinux preventing Bugzilla on FC5 In-Reply-To: <1147421273.2405.12.camel@laurel.intra.city-fan.org> References: <44632D6F.1000607@athensgroup.com> <1147381728.21889.8.camel@laurel.intra.city-fan.org> <4463BD90.5030608@athensgroup.com> <1147388060.21889.17.camel@laurel.intra.city-fan.org> <4463C70F.6030108@athensgroup.com> <1147421273.2405.12.camel@laurel.intra.city-fan.org> Message-ID: <4464C450.9040904@redhat.com> Paul Howarth wrote: > On Thu, 2006-05-11 at 18:21 -0500, James Garrison wrote: > >> The continuing saga.... >> >> >>> May 11 18:11:05 bugzilla kernel: audit(1147389065.041:16): avc: >>> denied { read } for pid=19398 comm="index.cgi" name="resolv.conf" >>> dev=md1 ino=1106152 scontext=user_u:system_r:httpd_sys_script_t:s0 >>> tcontext=system_u:object_r:net_conf_t:s0 tclass=file >>> May 11 18:11:05 bugzilla kernel: audit(1147389065.045:17): avc: >>> denied { create } for pid=19398 comm="index.cgi" >>> scontext=user_u:system_r:httpd_sys_script_t:s0 >>> tcontext=user_u:system_r:httpd_sys_script_t:s0 tclass=udp_socket >>> May 11 18:11:05 bugzilla kernel: audit(1147389065.045:18): avc: >>> denied { create } for pid=19398 comm="index.cgi" >>> scontext=user_u:system_r:httpd_sys_script_t:s0 >>> tcontext=user_u:system_r:httpd_sys_script_t:s0 tclass=udp_socket >>> May 11 18:11:05 bugzilla kernel: audit(1147389065.045:19): avc: >>> denied { shutdown } for pid=19398 comm="index.cgi" >>> scontext=user_u:system_r:httpd_sys_script_t:s0 >>> tcontext=user_u:system_r:httpd_sys_script_t:s0 tclass=tcp_socket >>> >> It seems like I'm just going to have to keep trying and adding new >> allow rules, 2 or 3 at a time, until I've hit everything not allowed >> by selinux. Surely I'm not the first person to try to get Bugzilla >> running on FC5? >> >> Is there a better way to do this than trial and error? >> > > The latest policy will allow semodule to read users home directories also. Since this bug seems to be coming up often. Please send me you final policy files when you have it working. > You could put SELinux in permissive mode: > > # setenforce 0 > > then run bugzilla and get all of the SELinux denials logged, so you can > deal with them all in one go. Then turn enforcing mode back on: > > # setenforce 1 > > You might also consider looking at the bugzilla package currently making > its way through the Fedora Extras review process: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188359 > > This probably doesn't include any SELinux support (at least not yet), > but might be better to use from a maintainability standpoint. > > Paul. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > The latest policy will allow semodule to read users home directories also. Since this bug seems to be coming up often. > > Please send me you final policy files > > From dragoran at feuerpokemon.de Fri May 12 18:09:13 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Fri, 12 May 2006 20:09:13 +0200 Subject: selinux breaks nfs In-Reply-To: <444E33C3.1000108@feuerpokemon.de> References: <444B3F1C.2030608@feuerpokemon.de> <444E33C3.1000108@feuerpokemon.de> Message-ID: <4464CF49.1010903@feuerpokemon.de> dragoran wrote: > dragoran wrote: >> hello >> I tryed to share a partition using nfs (using system-config-nfs), but >> selinux prevents it from beeing mounted: >> audit(1145781795.498:64): avc: denied { dac_override } for >> pid=26228 comm="rpc.mountd" capability=1 >> scontext=system_u:system_r:nfsd_t:s0 >> tcontext=system_u:system_r:nfsd_t:s0 tclass=capability >> audit(1145781795.498:65): avc: denied { dac_read_search } for >> pid=26228 comm="rpc.mountd" capability=2 >> scontext=system_u:system_r:nfsd_t:s0 >> tcontext=system_u:system_r:nfsd_t:s0 tclass=capability >> audit(1145781795.498:66): avc: denied { dac_override } for >> pid=26228 comm="rpc.mountd" capability=1 >> scontext=system_u:system_r:nfsd_t:s0 >> tcontext=system_u:system_r:nfsd_t:s0 tclass=capability >> audit(1145781795.498:67): avc: denied { dac_read_search } for >> pid=26228 comm="rpc.mountd" capability=2 >> scontext=system_u:system_r:nfsd_t:s0 >> tcontext=system_u:system_r:nfsd_t:s0 tclass=capability >> audit(1145781817.496:68): avc: denied { dac_override } for >> pid=26228 comm="rpc.mountd" capability=1 >> scontext=system_u:system_r:nfsd_t:s0 >> tcontext=system_u:system_r:nfsd_t:s0 tclass=capability >> audit(1145781817.496:69): avc: denied { dac_read_search } for >> pid=26228 comm="rpc.mountd" capability=2 >> scontext=system_u:system_r:nfsd_t:s0 >> tcontext=system_u:system_r:nfsd_t:s0 tclass=capability >> audit(1145781817.496:70): avc: denied { dac_override } for >> pid=26228 comm="rpc.mountd" capability=1 >> scontext=system_u:system_r:nfsd_t:s0 >> tcontext=system_u:system_r:nfsd_t:s0 tclass=capability >> audit(1145781817.496:71): avc: denied { dac_read_search } for >> pid=26228 comm="rpc.mountd" capability=2 >> scontext=system_u:system_r:nfsd_t:s0 >> tcontext=system_u:system_r:nfsd_t:s0 tclass=capability >> All boleans for nfs are set to true, if I do setenforce 0 it works. >> I am using selinux-policy-targeted-2.2.34-3.fc5 (from updates >> testing) on FC x86_64. >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >> > any ideas? or should I bugzilla this? > > am I the only one seeing ths? From bleher at informatik.uni-muenchen.de Fri May 12 18:22:41 2006 From: bleher at informatik.uni-muenchen.de (Thomas Bleher) Date: Fri, 12 May 2006 20:22:41 +0200 Subject: noexec mount-option with selinux? In-Reply-To: <1147447112.19324.2.camel@avenin.ebourne.me.uk> References: <200605111601.k4BG1ZCc003554@turing-police.cc.vt.edu> <200605112019.17257.lamont@gurulabs.com> <446491AD.9090408@cnm.de> <1147447112.19324.2.camel@avenin.ebourne.me.uk> Message-ID: <20060512182241.GA7535@thorium.jmh.mhn.de> * Martin Ebourne [2006-05-12 17:19]: > On Fri, 2006-05-12 at 15:46 +0200, Marten Lehmann wrote: > > > If the quota limits need to be as strict as your first message indicates, then > > > I'm surprised you haven't already had /tmp/ on a separate filesystem, with > > > separate quotas set. Additionally, I always split off /tmp/ so *if* it > > > fills, it doesn't "damage" my root filesystem. > > > > Actually, /home is not part of the root-partition and /tmp could be a > > symlink to /home/tmp so both can use the some quota definitions. But how > > can I setup a system-wide policy that disallows to execute files from > > /tmp or /home/tmp? > > That sounds like a very hard way of doing things. And difficult to prove > correct too. > > How about: > > mkdir /home/tmp > mount -o bind,noexec,nosuid /home/tmp /tmp I don't think this will work. I just tried to do it and I could still execute files in the mounted dir. I thought that per-mountpoint noexec flags were in the kernel, but I can't find any definitive information on it and fs/namespace.c is not the best information source either. (Anyone knows why this doesn't work? It would be really neat.) The other issue here is that the user still can execute files through /home/tmp. So you should --move the dir instead of bind-mounting it. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: Digital signature URL: From bleher at informatik.uni-muenchen.de Fri May 12 18:39:13 2006 From: bleher at informatik.uni-muenchen.de (Thomas Bleher) Date: Fri, 12 May 2006 20:39:13 +0200 Subject: noexec mount-option with selinux? In-Reply-To: <20060512182241.GA7535@thorium.jmh.mhn.de> References: <200605111601.k4BG1ZCc003554@turing-police.cc.vt.edu> <200605112019.17257.lamont@gurulabs.com> <446491AD.9090408@cnm.de> <1147447112.19324.2.camel@avenin.ebourne.me.uk> <20060512182241.GA7535@thorium.jmh.mhn.de> Message-ID: <20060512183913.GB7535@thorium.jmh.mhn.de> * Thomas Bleher [2006-05-12 20:22]: > * Martin Ebourne [2006-05-12 17:19]: > > On Fri, 2006-05-12 at 15:46 +0200, Marten Lehmann wrote: > > > > If the quota limits need to be as strict as your first message indicates, then > > > > I'm surprised you haven't already had /tmp/ on a separate filesystem, with > > > > separate quotas set. Additionally, I always split off /tmp/ so *if* it > > > > fills, it doesn't "damage" my root filesystem. > > > > > > Actually, /home is not part of the root-partition and /tmp could be a > > > symlink to /home/tmp so both can use the some quota definitions. But how > > > can I setup a system-wide policy that disallows to execute files from > > > /tmp or /home/tmp? > > > > That sounds like a very hard way of doing things. And difficult to prove > > correct too. > > > > How about: > > > > mkdir /home/tmp > > mount -o bind,noexec,nosuid /home/tmp /tmp > > I don't think this will work. I just tried to do it and I could still > execute files in the mounted dir. I thought that per-mountpoint noexec > flags were in the kernel, but I can't find any definitive information on > it and fs/namespace.c is not the best information source either. (Anyone > knows why this doesn't work? It would be really neat.) Umm, this mailing list post explains it: http://www.cs.helsinki.fi/linux/linux-kernel/2001-41/0082.html (plus followup from Al Viro). Mount seems really broken in this regard as it reports the noexec flags in /etc/mtab. > The other issue here is that the user still can execute files through > /home/tmp. So you should --move the dir instead of bind-mounting it. There's another issue here: You can't mount --move a directory that is not a mountpoint. So if you want to guard against people accessing /home/tmp directly, either move it to /home/secure/tmp and bind-mount it from there (where /home/secure is mode 0000), or bind mount /home/tmp over itself. That means a fully working solution looks something like this: $ mount --bind /home/tmp/ /home/tmp/ $ mount -o remount,noexec /home/tmp/ $ mount --bind /home/tmp/ /tmp/ Lesson learnt here: Test to see if you actually protect against your threats. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: Digital signature URL: From lamont at gurulabs.com Sat May 13 04:19:42 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Fri, 12 May 2006 22:19:42 -0600 Subject: noexec mount-option with selinux? In-Reply-To: <446491AD.9090408@cnm.de> References: <200605112019.17257.lamont@gurulabs.com> <446491AD.9090408@cnm.de> Message-ID: <200605122219.47242.lamont@gurulabs.com> On Friday 12 May 2006 07:46, Marten Lehmann wrote: > > When you want to change the quotas or set them, run: > > # setquota username block-soft block-hard inode-soft inode-hard -a > > But I'm looking for a clean way to do it without workarounds with selinux! That's not an SELinux command, that's quota management. So, if you do *not* want to use SELinux, then why is this thread on this list? Or am I misunderstanding what you are saying there? > The system includes a webserver and when someone uses the fileupload of > PHP, then the uploaded file will be stored in /tmp. That is not a good idea. Instead, either create a separate location on your filesystem(s). It is dangerous to allow any network access of any kind to /tmp/. For that purpose, change the app to upload the files to a directory somewhere on the system that has a subdirectory for each user and you can then symlink the per-user subdirectories into each user's home directory. Or, you could just have the app upload files into the particular user's home directory. Both of these options would be much better (from a security standpoint) than what you are currently trying to do. > So a quota of just 1 > MB on /tmp for every user is not enough. Well, 1MB was just a relative number I used as an example. > > If the quota limits need to be as strict as your first message indicates, > > then I'm surprised you haven't already had /tmp/ on a separate > > filesystem, with separate quotas set. Additionally, I always split off > > /tmp/ so *if* it fills, it doesn't "damage" my root filesystem. > > Actually, /home is not part of the root-partition Yes, I understood that. You asked how to make them share the same quota-space and that would require them to be on the same partition. So, I phrased that as an example of having both /home/ and /tmp/ on a common filesystem. Sorry for the confusion, there. > and /tmp could be a > symlink to /home/tmp so both can use the some quota definitions. But how > can I setup a system-wide policy that disallows to execute files from > /tmp or /home/tmp? The best way, as I see it, is to stop trying to use /tmp/ for this. If the reason you are using /tmp/ is because you want old files to be removed automatically once they get "stale enough," then create your own cron job that runs tmpwatch and clears your upload director(y|ies). Simple. More secure. No danger in /tmp/. Quotas could be applied as you like. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From hongwei at wustl.edu Mon May 15 13:35:16 2006 From: hongwei at wustl.edu (Hongwei Li) Date: Mon, 15 May 2006 08:35:16 -0500 (CDT) Subject: selinux in fc5 Message-ID: <3374.128.252.85.103.1147700116.squirrel@morpheus.wustl.edu> Hi, I have a question about selinux in fc5. My system: kernel: 2.6.16-1.2111_FC5smp selinux-policy-targeted: 2.2.38-1.fc5 I need to modify the policy to meet our requests. But, when I search targeted-sources, I could not find anything. Is the targeted-sources excluded from fc5 selinux? If yes, how to modify the policy? Where to put my local.te and where to run "make load" as in fc4, or I should do it in a completely different way, how? Thanks! Hongwei Li From paul at city-fan.org Mon May 15 13:38:51 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 15 May 2006 14:38:51 +0100 Subject: selinux in fc5 In-Reply-To: <3374.128.252.85.103.1147700116.squirrel@morpheus.wustl.edu> References: <3374.128.252.85.103.1147700116.squirrel@morpheus.wustl.edu> Message-ID: <4468846B.9090906@city-fan.org> Hongwei Li wrote: > Hi, > > I have a question about selinux in fc5. My system: > > kernel: 2.6.16-1.2111_FC5smp > selinux-policy-targeted: 2.2.38-1.fc5 > > I need to modify the policy to meet our requests. But, when I search > targeted-sources, I could not find anything. > > Is the targeted-sources excluded from fc5 selinux? > If yes, how to modify the policy? Where to put my local.te and where to run > "make load" as in fc4, or I should do it in a completely different way, how? Tweaking policy is different in FC5 (and IMHO much better/simpler), using loadable modules. I'd suggest reading http://fedoraproject.org/wiki/SELinux/FC5Features and some of the other selinux pages on the Fedora wiki. Paul. From paul at city-fan.org Mon May 15 13:44:52 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 15 May 2006 14:44:52 +0100 Subject: FastCGI applications Message-ID: <446885D4.8050505@city-fan.org> I've just moved my personal moin wiki from mod_python to FastCGI for performance reasons (it's well worth it!). For people that don't know, FastCGI works by starting up one or more copies of a CGI application and then keeping them running, passing requests from server to application over a socket. This avoids the startup overhead of the CGI application for each request that is necessary with regular CGI. I needed the policy module below to get it working. I'm not sure what exactly all of the "allows" are allowing, so advice would be welcome (sample AVCs included). Regarding support for FastCGI in the standard policy, perhaps appropriate rules could be added under a boolean httpd_enable_fastcgi or even added to the features enabled with httpd_enable_cgi? policy_module(apache, 0.1.0) require { type httpd_sys_script_t; type httpd_log_t; type httpd_t; type devpts_t; type var_run_t; }; # ========================================================== # Needed for mod_fcgid # ========================================================== # This is the FastCGI application doing something to the httpd error log # ---------------------------------------------------------------------- #type=AVC msg=audit(1147697748.197:15226): avc: denied { ioctl } for pid=15684 comm="python" name="error_log" dev=dm-4 ino=851988 scontext=user_u:system_r:httpd_sys_script_t:s0 tcontext=user_u:object_r:httpd_log_t:s0 tclass=file #type=SYSCALL msg=audit(1147697748.197:15226): arch=40000003 syscall=54 success=no exit=-25 a0=1 a1=5401 a2=bffd4cf8 a3=bffd4d38 items=0 pid=15684 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 comm="python" exe="/usr/bin/python" #type=AVC_PATH msg=audit(1147697748.197:15226): path="/var/log/httpd/error_log" allow httpd_sys_script_t httpd_log_t:file ioctl; # This is the FastCGI application listening for FastCGI requests on its socket allow httpd_sys_script_t httpd_t:unix_stream_socket { accept getattr ioctl listen }; # Not sure what this is doing # --------------------------- #type=AVC msg=audit(1147699050.131:15341): avc: denied { ioctl } for pid=16705 comm="httpd" name="2" dev=devpts ino=4 scontext=user_u:system_r:httpd_t:s0 tcontext=user_u:object_r:devpts_t:s0 tclass=chr_file #type=SYSCALL msg=audit(1147699050.131:15341): arch=40000003 syscall=54 success=yes exit=0 a0=0 a1=5401 a2=bff4ee38 a3=bff4ee78 items=0 pid=16705 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="httpd" exe="/usr/sbin/httpd" #type=AVC_PATH msg=audit(1147699050.131:15341): path="/dev/pts/2" allow httpd_t devpts_t:chr_file ioctl; # perhaps it should be term_ioctl_generic_ptys(httpd_t) # mod_fcgid setting attr of its socket dir # ---------------------------------------- # type=AVC msg=audit(1147697688.037:15216): avc: denied { setattr } for pid=15656 comm="httpd" name="mod_fcgid" dev=dm-4 ino=458818 scontext=user_u:system_r:httpd_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=dir # type=SYSCALL msg=audit(1147697688.037:15216): arch=40000003 syscall=212 success=yes exit=0 a0=91aa148 a1=30 a2=ffffffff a3=30 items=1 pid=15656 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="httpd" exe="/usr/sbin/httpd" # type=CWD msg=audit(1147697688.037:15216): cwd="/" # type=PATH msg=audit(1147697688.037:15216): item=0 name="/etc/httpd/run/mod_fcgid" flags=1 inode=458818 dev=fd:04 mode=040755 ouid=48 ogid=48 rdev=00:00 allow httpd_t var_run_t:dir setattr; Paul. From dwalsh at redhat.com Mon May 15 18:23:13 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 15 May 2006 14:23:13 -0400 Subject: FastCGI applications In-Reply-To: <446885D4.8050505@city-fan.org> References: <446885D4.8050505@city-fan.org> Message-ID: <4468C711.9040600@redhat.com> Paul Howarth wrote: > I've just moved my personal moin wiki from mod_python to FastCGI for > performance reasons (it's well worth it!). For people that don't know, > FastCGI works by starting up one or more copies of a CGI application > and then keeping them running, passing requests from server to > application over a socket. This avoids the startup overhead of the CGI > application for each request that is necessary with regular CGI. > > I needed the policy module below to get it working. I'm not sure what > exactly all of the "allows" are allowing, so advice would be welcome > (sample AVCs included). > > Regarding support for FastCGI in the standard policy, perhaps > appropriate rules could be added under a boolean httpd_enable_fastcgi > or even added to the features enabled with httpd_enable_cgi? > > policy_module(apache, 0.1.0) > > require { > type httpd_sys_script_t; > type httpd_log_t; > type httpd_t; > type devpts_t; > type var_run_t; > }; > > # ========================================================== > # Needed for mod_fcgid > # ========================================================== > > # This is the FastCGI application doing something to the httpd error log > # ---------------------------------------------------------------------- > #type=AVC msg=audit(1147697748.197:15226): avc: denied { ioctl } for > pid=15684 comm="python" name="error_log" dev=dm-4 ino=851988 > scontext=user_u:system_r:httpd_sys_script_t:s0 > tcontext=user_u:object_r:httpd_log_t:s0 tclass=file > #type=SYSCALL msg=audit(1147697748.197:15226): arch=40000003 > syscall=54 success=no exit=-25 a0=1 a1=5401 a2=bffd4cf8 a3=bffd4d38 > items=0 pid=15684 auid=4294967295 uid=48 gid=48 euid=48 suid=48 > fsuid=48 egid=48 sgid=48 fsgid=48 comm="python" exe="/usr/bin/python" > #type=AVC_PATH msg=audit(1147697748.197:15226): > path="/var/log/httpd/error_log" > allow httpd_sys_script_t httpd_log_t:file ioctl; Would dontaudit work? > > # This is the FastCGI application listening for FastCGI requests on > its socket > allow httpd_sys_script_t httpd_t:unix_stream_socket { accept getattr > ioctl listen }; > Might be worth creating a new type for this httpd_fastcgi_script_t??? > # Not sure what this is doing > # --------------------------- > #type=AVC msg=audit(1147699050.131:15341): avc: denied { ioctl } for > pid=16705 comm="httpd" name="2" dev=devpts ino=4 > scontext=user_u:system_r:httpd_t:s0 > tcontext=user_u:object_r:devpts_t:s0 tclass=chr_file > #type=SYSCALL msg=audit(1147699050.131:15341): arch=40000003 > syscall=54 success=yes exit=0 a0=0 a1=5401 a2=bff4ee38 a3=bff4ee78 > items=0 pid=16705 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 > egid=0 sgid=0 fsgid=0 comm="httpd" exe="/usr/sbin/httpd" > #type=AVC_PATH msg=audit(1147699050.131:15341): path="/dev/pts/2" > allow httpd_t devpts_t:chr_file ioctl; > # perhaps it should be term_ioctl_generic_ptys(httpd_t) Should probably be dontaudit. term_dontaudit_use_generic_ptys(httpd_t) ioctl not handled by this right now, but it would probably have been prevented if you were not running in permissive mode. > > # mod_fcgid setting attr of its socket dir > # ---------------------------------------- # type=AVC > msg=audit(1147697688.037:15216): avc: denied { setattr } for > pid=15656 comm="httpd" name="mod_fcgid" dev=dm-4 ino=458818 > scontext=user_u:system_r:httpd_t:s0 > tcontext=system_u:object_r:var_run_t:s0 tclass=dir # type=SYSCALL > msg=audit(1147697688.037:15216): arch=40000003 syscall=212 success=yes > exit=0 a0=91aa148 a1=30 a2=ffffffff a3=30 items=1 pid=15656 > auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 comm="httpd" exe="/usr/sbin/httpd" > # type=CWD msg=audit(1147697688.037:15216): cwd="/" # type=PATH > msg=audit(1147697688.037:15216): item=0 > name="/etc/httpd/run/mod_fcgid" flags=1 inode=458818 dev=fd:04 > mode=040755 ouid=48 ogid=48 rdev=00:00 > allow httpd_t var_run_t:dir setattr; > What dir is it doing this to? Should this directory be labeled httpd_var_run_t? > > Paul. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From paul at city-fan.org Mon May 15 19:58:40 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 15 May 2006 20:58:40 +0100 Subject: FastCGI applications In-Reply-To: <4468C711.9040600@redhat.com> References: <446885D4.8050505@city-fan.org> <4468C711.9040600@redhat.com> Message-ID: <1147723120.23407.6.camel@laurel.intra.city-fan.org> On Mon, 2006-05-15 at 14:23 -0400, Daniel J Walsh wrote: > Paul Howarth wrote: > > I've just moved my personal moin wiki from mod_python to FastCGI for > > performance reasons (it's well worth it!). For people that don't know, > > FastCGI works by starting up one or more copies of a CGI application > > and then keeping them running, passing requests from server to > > application over a socket. This avoids the startup overhead of the CGI > > application for each request that is necessary with regular CGI. > > > > I needed the policy module below to get it working. I'm not sure what > > exactly all of the "allows" are allowing, so advice would be welcome > > (sample AVCs included). > > > > Regarding support for FastCGI in the standard policy, perhaps > > appropriate rules could be added under a boolean httpd_enable_fastcgi > > or even added to the features enabled with httpd_enable_cgi? > > > > policy_module(apache, 0.1.0) > > > > require { > > type httpd_sys_script_t; > > type httpd_log_t; > > type httpd_t; > > type devpts_t; > > type var_run_t; > > }; > > > > # ========================================================== > > # Needed for mod_fcgid > > # ========================================================== > > > > # This is the FastCGI application doing something to the httpd error log > > # ---------------------------------------------------------------------- > > #type=AVC msg=audit(1147697748.197:15226): avc: denied { ioctl } for > > pid=15684 comm="python" name="error_log" dev=dm-4 ino=851988 > > scontext=user_u:system_r:httpd_sys_script_t:s0 > > tcontext=user_u:object_r:httpd_log_t:s0 tclass=file > > #type=SYSCALL msg=audit(1147697748.197:15226): arch=40000003 > > syscall=54 success=no exit=-25 a0=1 a1=5401 a2=bffd4cf8 a3=bffd4d38 > > items=0 pid=15684 auid=4294967295 uid=48 gid=48 euid=48 suid=48 > > fsuid=48 egid=48 sgid=48 fsgid=48 comm="python" exe="/usr/bin/python" > > #type=AVC_PATH msg=audit(1147697748.197:15226): > > path="/var/log/httpd/error_log" > > allow httpd_sys_script_t httpd_log_t:file ioctl; > Would dontaudit work? It appears to, yes. > > # This is the FastCGI application listening for FastCGI requests on > > its socket > > allow httpd_sys_script_t httpd_t:unix_stream_socket { accept getattr > > ioctl listen }; > > > Might be worth creating a new type for this httpd_fastcgi_script_t??? Probably, yes. I found after turning on enforcing mode that I needed: # This is the FastCGI application listening for FastCGI requests on its socket and communicating allow httpd_sys_script_t httpd_t:unix_stream_socket { accept getattr ioctl listen read write }; > > # Not sure what this is doing > > # --------------------------- > > #type=AVC msg=audit(1147699050.131:15341): avc: denied { ioctl } for > > pid=16705 comm="httpd" name="2" dev=devpts ino=4 > > scontext=user_u:system_r:httpd_t:s0 > > tcontext=user_u:object_r:devpts_t:s0 tclass=chr_file > > #type=SYSCALL msg=audit(1147699050.131:15341): arch=40000003 > > syscall=54 success=yes exit=0 a0=0 a1=5401 a2=bff4ee38 a3=bff4ee78 > > items=0 pid=16705 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 > > egid=0 sgid=0 fsgid=0 comm="httpd" exe="/usr/sbin/httpd" > > #type=AVC_PATH msg=audit(1147699050.131:15341): path="/dev/pts/2" > > allow httpd_t devpts_t:chr_file ioctl; > > # perhaps it should be term_ioctl_generic_ptys(httpd_t) > Should probably be dontaudit. term_dontaudit_use_generic_ptys(httpd_t) > ioctl not handled by this right now, but it would probably have been > prevented if you were not > running in permissive mode. dontaudit seems to be OK here too. > > # mod_fcgid setting attr of its socket dir > > # ---------------------------------------- # type=AVC > > msg=audit(1147697688.037:15216): avc: denied { setattr } for > > pid=15656 comm="httpd" name="mod_fcgid" dev=dm-4 ino=458818 > > scontext=user_u:system_r:httpd_t:s0 > > tcontext=system_u:object_r:var_run_t:s0 tclass=dir # type=SYSCALL > > msg=audit(1147697688.037:15216): arch=40000003 syscall=212 success=yes > > exit=0 a0=91aa148 a1=30 a2=ffffffff a3=30 items=1 pid=15656 > > auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > > fsgid=0 comm="httpd" exe="/usr/sbin/httpd" > > # type=CWD msg=audit(1147697688.037:15216): cwd="/" # type=PATH > > msg=audit(1147697688.037:15216): item=0 > > name="/etc/httpd/run/mod_fcgid" flags=1 inode=458818 dev=fd:04 > > mode=040755 ouid=48 ogid=48 rdev=00:00 > > allow httpd_t var_run_t:dir setattr; > > > What dir is it doing this to? Should this directory be labeled > httpd_var_run_t? Yes, it should. /etc/httpd/run is a symlink to /var/run; I've created a directory /var/run/mod_fcgid, which gets labelled var_run_t by default, and mod_fcgid creates and uses sockets in that directory to communicate with FastCGI applications, and these sockets get labelled httpd_var_run_t, which I think is OK. If you can think of a better place for this directory, let me know. Paul. From kmahaindra at axalto.com Tue May 16 01:28:21 2006 From: kmahaindra at axalto.com (Ketut Mahaindra) Date: Tue, 16 May 2006 09:28:21 +0800 Subject: selinux in fc5 In-Reply-To: <3374.128.252.85.103.1147700116.squirrel@morpheus.wustl.edu> Message-ID: <009301c67888$056d91b0$9c4d1bac@axalto.com> Hello, You may find the following entry useful: http://fedora.redhat.com/docs/selinux-faq-fc5/#faq-entry-local.te -- Best regards, Ketut Mahaindra (Ito) "The race for perfection has no finish line" -----Original Message----- From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux-list-bounces at redhat.com] On Behalf Of Hongwei Li Sent: Monday, May 15, 2006 9:35 PM To: fedora-selinux-list at redhat.com Subject: selinux in fc5 Hi, I have a question about selinux in fc5. My system: kernel: 2.6.16-1.2111_FC5smp selinux-policy-targeted: 2.2.38-1.fc5 I need to modify the policy to meet our requests. But, when I search targeted-sources, I could not find anything. Is the targeted-sources excluded from fc5 selinux? If yes, how to modify the policy? Where to put my local.te and where to run "make load" as in fc4, or I should do it in a completely different way, how? Thanks! Hongwei Li -- fedora-selinux-list mailing list fedora-selinux-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list From paul at city-fan.org Tue May 16 14:08:49 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 16 May 2006 15:08:49 +0100 Subject: SELinux Module Packaging in FC5 In-Reply-To: <1142341123.3713.36.camel@moss-spartans.epoch.ncsc.mil> References: <44169B09.3050508@city-fan.org> <1142341123.3713.36.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4469DCF1.2080406@city-fan.org> Stephen Smalley wrote: > On Tue, 2006-03-14 at 10:29 +0000, Paul Howarth wrote: >> Is there any documentation anywhere on including SELinux Policy Modules >> in packages (e.g. for Extras) in FC5? For instance, is there a directory >> where modules can be dropped into so that they get picked up >> aotomatically? Where should they live? > > Yes, this would be useful to document in the Fedora SELinux wiki. > Ideally, policy for a given software package should live in its own > package on which the software package depends so that the package > manager will install (and thus load) the policy before it tries to > unpack the software package (thereby ensuring that any necessary file > types are already defined in the kernel policy), e.g. package foo would > depend on foo-policy. Not certain where the foo-policy package should > drop its policy module, possibly under /usr/share/selinux/foo, and then > it can install it by running semodule -i from its %post scriptlet. I've tried this and it doesn't quite work as I expected. I have a main package "contagged" and a subpackage "contagged-policy". The "contagged" packages has: Requires: contagged-policy = %{version}-%{release} Requires(pre): contagged-policy = %{version}-%{release} This ensures that the policy package is installed before the main package, and hangs around as long as the main package itself. The policy package dumps policy in %{_datadir}/selinux/packages/contagged and uses scriptlets to handle module insertion and removal: %post policy [ -x /usr/sbin/semodule ] && /usr/sbin/semodule -i %{_datadir}/selinux/packages/contagged/contagged.pp || : %postun policy [ $1 -eq 0 ] && [ -x /usr/sbin/semodule ] && /usr/sbin/semodule -r contagged || : The only thing the policy module is actually doing is specifying a file context in contagged.fc: /var/cache/contagged(/.*)? gen_context(system_u:object_r:httpd_cache_t,s0) If contagged-policy is installed first, and then the contagged package is installed (separate rpm transactions), the file contexts get set up as expected. However, if both are done in the same RPM transaction, the packages get installed in the right order (and there is a noticeable delay after installing the policy subpackage where semodule is being called) but the context for directory /var/cache/contagged is left as system_u:object_r:var_t. I suspect that the reason for this is that rpm installs the files for all packages in the transaction and sets their file contexts before running (presumably in order) the %post scripts for the packages. This rather defeats the purpose of having the separate -policy package, since I need to use restorecon to fix the file contexts at post-install time in case both packages are installed in the same transaction (a likely scenario). I could do this equally well using a single package, but it's untidy (I have to specify the pathnames that need non-standard contexts in both the .fc policy file and as an argument to restorecon in %post). I really prefer the separate package solution, but I think that would need changes in rpm, which might be hard to get done. Any thoughts? Paul. From sds at tycho.nsa.gov Tue May 16 14:25:35 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 16 May 2006 10:25:35 -0400 Subject: SELinux Module Packaging in FC5 In-Reply-To: <4469DCF1.2080406@city-fan.org> References: <44169B09.3050508@city-fan.org> <1142341123.3713.36.camel@moss-spartans.epoch.ncsc.mil> <4469DCF1.2080406@city-fan.org> Message-ID: <1147789535.30789.133.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2006-05-16 at 15:08 +0100, Paul Howarth wrote: > Stephen Smalley wrote: > > On Tue, 2006-03-14 at 10:29 +0000, Paul Howarth wrote: > >> Is there any documentation anywhere on including SELinux Policy Modules > >> in packages (e.g. for Extras) in FC5? For instance, is there a directory > >> where modules can be dropped into so that they get picked up > >> aotomatically? Where should they live? > > > > Yes, this would be useful to document in the Fedora SELinux wiki. > > Ideally, policy for a given software package should live in its own > > package on which the software package depends so that the package > > manager will install (and thus load) the policy before it tries to > > unpack the software package (thereby ensuring that any necessary file > > types are already defined in the kernel policy), e.g. package foo would > > depend on foo-policy. Not certain where the foo-policy package should > > drop its policy module, possibly under /usr/share/selinux/foo, and then > > it can install it by running semodule -i from its %post scriptlet. > > I've tried this and it doesn't quite work as I expected. > > I have a main package "contagged" and a subpackage "contagged-policy". > > The "contagged" packages has: > > Requires: contagged-policy = %{version}-%{release} > Requires(pre): contagged-policy = %{version}-%{release} > > This ensures that the policy package is installed before the main > package, and hangs around as long as the main package itself. > > The policy package dumps policy in > %{_datadir}/selinux/packages/contagged and uses scriptlets to handle > module insertion and removal: > > %post policy > [ -x /usr/sbin/semodule ] && /usr/sbin/semodule -i > %{_datadir}/selinux/packages/contagged/contagged.pp || : > > %postun policy > [ $1 -eq 0 ] && [ -x /usr/sbin/semodule ] && /usr/sbin/semodule -r > contagged || : > > The only thing the policy module is actually doing is specifying a file > context in contagged.fc: > > /var/cache/contagged(/.*)? > gen_context(system_u:object_r:httpd_cache_t,s0) > > If contagged-policy is installed first, and then the contagged package > is installed (separate rpm transactions), the file contexts get set up > as expected. However, if both are done in the same RPM transaction, the > packages get installed in the right order (and there is a noticeable > delay after installing the policy subpackage where semodule is being > called) but the context for directory /var/cache/contagged is left as > system_u:object_r:var_t. I suspect that the reason for this is that rpm > installs the files for all packages in the transaction and sets their > file contexts before running (presumably in order) the %post scripts for > the packages. > > This rather defeats the purpose of having the separate -policy package, > since I need to use restorecon to fix the file contexts at post-install > time in case both packages are installed in the same transaction (a > likely scenario). I could do this equally well using a single package, > but it's untidy (I have to specify the pathnames that need non-standard > contexts in both the .fc policy file and as an argument to restorecon in > %post). I really prefer the separate package solution, but I think that > would need changes in rpm, which might be hard to get done. > > Any thoughts? Yes, it appears that the separate -policy package approach isn't going to work after all (also raised separately on selinux list), so a different approach is under investigation. It requires some changes kernel side (to allow rpm to set down files in their proper contexts first, then load the policy module that defines them - see kernel patch posted to selinux list), as well as some userland changes to allow rpm to determine the file contexts from the .pp file without having to install it first. And I think that they want to have rpm compute the file contexts and store them in the rpm headers again as in FC2 at build time, then only override them at install time if you aren't using the default policy. -- Stephen Smalley National Security Agency From bench at silentmedia.com Tue May 16 15:12:39 2006 From: bench at silentmedia.com (Ben) Date: Tue, 16 May 2006 08:12:39 -0700 Subject: httpd can't execute bash? Message-ID: <59DFCC57-4C95-40B3-BB20-AEFCEC844CFB@silentmedia.com> Is it a new thing that httpd can't execute bash? After a recent policy upgrade, I'm seeing a lot of these: audit(1147792088.616:148): avc: denied { execute } for pid=1262 comm="httpd" name="bash" dev=dm-0 ino=3267269 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file From smooge at gmail.com Tue May 16 15:34:14 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 16 May 2006 09:34:14 -0600 Subject: SELinux Module Packaging in FC5 In-Reply-To: <4469DCF1.2080406@city-fan.org> References: <44169B09.3050508@city-fan.org> <1142341123.3713.36.camel@moss-spartans.epoch.ncsc.mil> <4469DCF1.2080406@city-fan.org> Message-ID: <80d7e4090605160834r1efc0d6ata7ee23d9ea67d6f9@mail.gmail.com> On 5/16/06, Paul Howarth wrote: > Stephen Smalley wrote: > > On Tue, 2006-03-14 at 10:29 +0000, Paul Howarth wrote: > >> Is there any documentation anywhere on including SELinux Policy Modules > >> in packages (e.g. for Extras) in FC5? For instance, is there a directory > >> where modules can be dropped into so that they get picked up > >> aotomatically? Where should they live? > > > > This rather defeats the purpose of having the separate -policy package, > since I need to use restorecon to fix the file contexts at post-install > time in case both packages are installed in the same transaction (a > likely scenario). I could do this equally well using a single package, > but it's untidy (I have to specify the pathnames that need non-standard > contexts in both the .fc policy file and as an argument to restorecon in > %post). I really prefer the separate package solution, but I think that > would need changes in rpm, which might be hard to get done. > > Any thoughts? > An ugly ugly ugly fix might be to have a triggerpost that does a restorecon/setcon on the files when the parent package is installed. That way it ensures the package is reset correctly. Again ugly and might not work. > Paul. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- Stephen J Smoogen. CSIRT/Linux System Administrator From dragoran at feuerpokemon.de Tue May 16 15:53:25 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 16 May 2006 17:53:25 +0200 Subject: selinux prelink avc's Message-ID: <4469F575.30609@feuerpokemon.de> audit(1147793154.831:353): avc: denied { execute_no_trans } for pid=5195 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 scontext=system_u:system_r:prelink_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file audit(1147793154.831:354): avc: denied { execute_no_trans } for pid=5196 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 scontext=system_u:system_r:prelink_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file audit(1147793155.019:355): avc: denied { execute_no_trans } for pid=5197 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 scontext=system_u:system_r:prelink_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file audit(1147793155.447:356): avc: denied { execute_no_trans } for pid=5198 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 scontext=system_u:system_r:prelink_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file audit(1147793156.255:357): avc: denied { execute_no_trans } for pid=5199 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 scontext=system_u:system_r:prelink_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file I am using FC5 with selinux-policy-targeted-2.2.36-2.fc5 whats gonig on? is a file misslabeled or is this a policy bug? From paul at city-fan.org Tue May 16 15:56:25 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 16 May 2006 16:56:25 +0100 Subject: SELinux Module Packaging in FC5 In-Reply-To: <80d7e4090605160834r1efc0d6ata7ee23d9ea67d6f9@mail.gmail.com> References: <44169B09.3050508@city-fan.org> <1142341123.3713.36.camel@moss-spartans.epoch.ncsc.mil> <4469DCF1.2080406@city-fan.org> <80d7e4090605160834r1efc0d6ata7ee23d9ea67d6f9@mail.gmail.com> Message-ID: <4469F629.4010803@city-fan.org> Stephen John Smoogen wrote: > On 5/16/06, Paul Howarth wrote: >> Stephen Smalley wrote: >> > On Tue, 2006-03-14 at 10:29 +0000, Paul Howarth wrote: >> >> Is there any documentation anywhere on including SELinux Policy >> Modules >> >> in packages (e.g. for Extras) in FC5? For instance, is there a >> directory >> >> where modules can be dropped into so that they get picked up >> >> aotomatically? Where should they live? >> > > >> >> This rather defeats the purpose of having the separate -policy package, >> since I need to use restorecon to fix the file contexts at post-install >> time in case both packages are installed in the same transaction (a >> likely scenario). I could do this equally well using a single package, >> but it's untidy (I have to specify the pathnames that need non-standard >> contexts in both the .fc policy file and as an argument to restorecon in >> %post). I really prefer the separate package solution, but I think that >> would need changes in rpm, which might be hard to get done. >> >> Any thoughts? >> > > An ugly ugly ugly fix might be to have a triggerpost that does a > restorecon/setcon on the files when the parent package is installed. > That way it ensures the package is reset correctly. Again ugly and > might not work. For now I've merged the two packages back into one and am using restorecon in %post after semodule to fix up the context. Next problem: I built and tested the package on one system, which was fully up to date. Worked fine. Then tried installing the package on other system that was running an older kernel and had older libsepol and selinux-policy-targeted packages. The result was: # rpm -Uvh contagged-0.3-2.noarch.rpm Preparing... ########################################### [100%] 1:contagged warning: /etc/httpd/conf.d/contagged.conf created as /etc/httpd/conf.d/contagged.conf.rpmnew ########################################### [100%] libsepol.class_copy_callback: contagged: Modules may not yet declare new classes. libsemanage.semanage_link_sandbox: Link packages failed /usr/sbin/semodule: Failed! # rpm -q selinux-policy-targeted libsepol libsemanage selinux-policy-targeted-2.2.34-3.fc5 libsepol-1.12.4-1.fc5 libsemanage-1.6.2-2.fc5 After doing a "yum update" on this system, the package installed cleanly. Is this a result of the required feature being missing from one of these (or some other) packages, or is a compiled .pp module compatible only with the specific version of something it was built against? Is there some way of specifying the necessary dependency in the package containing the binary policy module, or is it so volatile (like a kernel module for instance) that the best bet would be to ship policy sources and build them in %post? Paul. From sds at tycho.nsa.gov Tue May 16 16:30:25 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 16 May 2006 12:30:25 -0400 Subject: SELinux Module Packaging in FC5 In-Reply-To: <4469F629.4010803@city-fan.org> References: <44169B09.3050508@city-fan.org> <1142341123.3713.36.camel@moss-spartans.epoch.ncsc.mil> <4469DCF1.2080406@city-fan.org> <80d7e4090605160834r1efc0d6ata7ee23d9ea67d6f9@mail.gmail.com> <4469F629.4010803@city-fan.org> Message-ID: <1147797025.30789.180.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2006-05-16 at 16:56 +0100, Paul Howarth wrote: > Next problem: > > I built and tested the package on one system, which was fully up to > date. Worked fine. Then tried installing the package on other system > that was running an older kernel and had older libsepol and > selinux-policy-targeted packages. The result was: > > # rpm -Uvh contagged-0.3-2.noarch.rpm > Preparing... ########################################### > [100%] > 1:contagged warning: /etc/httpd/conf.d/contagged.conf > created as /etc/httpd/conf.d/contagged.conf.rpmnew > ########################################### [100%] > libsepol.class_copy_callback: contagged: Modules may not yet declare new > classes. > libsemanage.semanage_link_sandbox: Link packages failed > /usr/sbin/semodule: Failed! > # rpm -q selinux-policy-targeted libsepol libsemanage > selinux-policy-targeted-2.2.34-3.fc5 > libsepol-1.12.4-1.fc5 > libsemanage-1.6.2-2.fc5 > > After doing a "yum update" on this system, the package installed cleanly. > > Is this a result of the required feature being missing from one of these > (or some other) packages, or is a compiled .pp module compatible only > with the specific version of something it was built against? I'm confused - I thought you said that the policy package only contained a file contexts section, not a policy module. Was there a policy module? If so, what was the source? The above looks like a bug to me. The receiving system has to have a libsepol that understands the policy package format and module format, which are versioned, but the above doesn't appear to be a format issue. There is a pending change in the module format, but you will be able to tell checkmodule to generate the older format as well, and libsepol provides backward compatibility for older formats. > Is there some way of specifying the necessary dependency in the package > containing the binary policy module, or is it so volatile (like a kernel > module for instance) that the best bet would be to ship policy sources > and build them in %post? No, they are intended to allow separate building and distribution. -- Stephen Smalley National Security Agency From paul at city-fan.org Tue May 16 16:33:50 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 16 May 2006 17:33:50 +0100 Subject: SELinux Module Packaging in FC5 In-Reply-To: <1147797025.30789.180.camel@moss-spartans.epoch.ncsc.mil> References: <44169B09.3050508@city-fan.org> <1142341123.3713.36.camel@moss-spartans.epoch.ncsc.mil> <4469DCF1.2080406@city-fan.org> <80d7e4090605160834r1efc0d6ata7ee23d9ea67d6f9@mail.gmail.com> <4469F629.4010803@city-fan.org> <1147797025.30789.180.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4469FEEE.5090403@city-fan.org> Stephen Smalley wrote: > On Tue, 2006-05-16 at 16:56 +0100, Paul Howarth wrote: >> Next problem: >> >> I built and tested the package on one system, which was fully up to >> date. Worked fine. Then tried installing the package on other system >> that was running an older kernel and had older libsepol and >> selinux-policy-targeted packages. The result was: >> >> # rpm -Uvh contagged-0.3-2.noarch.rpm >> Preparing... ########################################### >> [100%] >> 1:contagged warning: /etc/httpd/conf.d/contagged.conf >> created as /etc/httpd/conf.d/contagged.conf.rpmnew >> ########################################### [100%] >> libsepol.class_copy_callback: contagged: Modules may not yet declare new >> classes. >> libsemanage.semanage_link_sandbox: Link packages failed >> /usr/sbin/semodule: Failed! >> # rpm -q selinux-policy-targeted libsepol libsemanage >> selinux-policy-targeted-2.2.34-3.fc5 >> libsepol-1.12.4-1.fc5 >> libsemanage-1.6.2-2.fc5 >> >> After doing a "yum update" on this system, the package installed cleanly. >> >> Is this a result of the required feature being missing from one of these >> (or some other) packages, or is a compiled .pp module compatible only >> with the specific version of something it was built against? > > I'm confused - I thought you said that the policy package only contained > a file contexts section, not a policy module. Was there a policy > module? If so, what was the source? The above looks like a bug to me. It contains a policy module, but the module only includes file contexts. The .if file is empty. The .te file is just: --------------------------------------------------------------------- # It's currently only necessary to set file contexts for the cache directory # in this policy, but doing it in a module is easier from a package maintenance # point of view than using semanage and chcon in scriptlets policy_module(contagged, 0.1) ######################################## # # Declarations # # (none needed) ######################################## # # Local policy # # (none needed) --------------------------------------------------------------------- The .fc file is: --------------------------------------------------------------------- /var/cache/contagged(/.*)? gen_context(system_u:object_r:httpd_cache_t,s0) --------------------------------------------------------------------- The module was built on a system with: $ rpm -q selinux-policy-targeted libsepol libsemanage selinux-policy-targeted-2.2.38-1.fc5 libsepol-1.12.6-1.fc5 libsemanage-1.6.2-2.fc5 The error occurred when the package was installed on a system with: $ rpm -q selinux-policy-targeted libsepol libsemanage selinux-policy-targeted-2.2.34-3.fc5 libsepol-1.12.4-1.fc5 libsemanage-1.6.2-2.fc5 Paul. From paul at city-fan.org Tue May 16 16:38:39 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 16 May 2006 17:38:39 +0100 Subject: procmail In-Reply-To: <4461FFBF.6070205@city-fan.org> References: <443BCBFB.2050104@city-fan.org> <443FB650.1040309@redhat.com> <4445212A.2060708@city-fan.org> <4448AD9E.1090909@city-fan.org> <1145625342.18861.16.camel@sgc.columbia.tresys.com> <4448DD27.90605@city-fan.org> <4461FFBF.6070205@city-fan.org> Message-ID: <446A000F.8020004@city-fan.org> Paul Howarth wrote: > Paul Howarth wrote: > selinux-policy-2.2.34-2 has the domain transition allowing procmail to > run sendmail, but: > > 1. it still doesn't allow the sbin_t:lnk_file read to follow the > "alternatives" link /usr/sbin/sendmail -> /etc/alternatives/mta > > 2. there will need to be a transition enabled for other MTAs that can > replace sendmail, such as postfix, exim, etc. if their > sendmail-compatible command-line program is not labelled sendmail_exec_t. My latest policy module is: policy_module(procmail, 0.4.1) type procmail_tmp_t; require { type procmail_t; type sbin_t; type var_log_t; }; # Needed for writing to /var/log/procmail.log allow procmail_t var_log_t:dir search; allow procmail_t var_log_t:file append; # Needed for scripts called from procmail to read/write temp files allow procmail_t procmail_tmp_t:dir create_dir_perms; allow procmail_t procmail_tmp_t:file create_file_perms; files_tmp_filetrans(procmail_t, procmail_tmp_t, { file dir }) # ============================================== # Procmail needs to call sendmail for forwarding # ============================================== # Read alternatives link (still not in policy) allow procmail_t sbin_t:lnk_file read; # Allow transition to sendmail # This is in selinux-policy-2.2.34-2 onwards # (may need similar code for other MTAs that can replace sendmail) # optional_policy(`sendmail',` # sendmail_domtrans(procmail_t) # ') I think I'm nearly there now as the procmail avcs are now few and far between. I just got one I don't understand though: type=AVC msg=audit(1147796926.268:24816): avc: denied { associate } for pid=27085 comm="bounced-mail" name="bm27083.1" scontext=user_u:object_r:procmail_tmp_t:s0 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem type=SYSCALL msg=audit(1147796926.268:24816): arch=40000003 syscall=5 success=yes exit=3 a0=92962d0 a1=8241 a2=1b6 a3=8241 items=1 pid=27085 auid=4294967295 uid=502 gid=502 euid=502 suid=502 fsuid=502 egid=502 sgid=502 fsgid=502 comm="bounced-mail" exe="/bin/bash" type=CWD msg=audit(1147796926.268:24816): cwd="/home/mcivta/mail" type=PATH msg=audit(1147796926.268:24816): item=0 name="/tmp/bm27083.1" flags=310 inode=2 dev=fd:02 mode=041777 ouid=0 ogid=0 rdev=00:00 (this is in permissive mode btw) What's being denied here? "bounced-mail" is a script I'm using to process mailing list bounces. Paul. From sds at tycho.nsa.gov Tue May 16 16:54:54 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 16 May 2006 12:54:54 -0400 Subject: procmail In-Reply-To: <446A000F.8020004@city-fan.org> References: <443BCBFB.2050104@city-fan.org> <443FB650.1040309@redhat.com> <4445212A.2060708@city-fan.org> <4448AD9E.1090909@city-fan.org> <1145625342.18861.16.camel@sgc.columbia.tresys.com> <4448DD27.90605@city-fan.org> <4461FFBF.6070205@city-fan.org> <446A000F.8020004@city-fan.org> Message-ID: <1147798494.30789.193.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2006-05-16 at 17:38 +0100, Paul Howarth wrote: > I think I'm nearly there now as the procmail avcs are now few and far > between. I just got one I don't understand though: > > type=AVC msg=audit(1147796926.268:24816): avc: denied { associate } > for pid=27085 comm="bounced-mail" name="bm27083.1" > scontext=user_u:object_r:procmail_tmp_t:s0 > tcontext=system_u:object_r:fs_t:s0 tclass=filesystem > type=SYSCALL msg=audit(1147796926.268:24816): arch=40000003 syscall=5 > success=yes exit=3 a0=92962d0 a1=8241 a2=1b6 a3=8241 items=1 pid=27085 > auid=4294967295 uid=502 gid=502 euid=502 suid=502 fsuid=502 egid=502 > sgid=502 fsgid=502 comm="bounced-mail" exe="/bin/bash" > type=CWD msg=audit(1147796926.268:24816): cwd="/home/mcivta/mail" > type=PATH msg=audit(1147796926.268:24816): item=0 name="/tmp/bm27083.1" > flags=310 inode=2 dev=fd:02 mode=041777 ouid=0 ogid=0 rdev=00:00 > > (this is in permissive mode btw) > > What's being denied here? The file type (procmail_tmp_t) hasn't been allowed to be associated with the filesystem type (fs_t). Add: files_type(procmail_tmp_t) to your module source. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Tue May 16 16:58:58 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 16 May 2006 12:58:58 -0400 Subject: SELinux Module Packaging in FC5 In-Reply-To: <4469FEEE.5090403@city-fan.org> References: <44169B09.3050508@city-fan.org> <1142341123.3713.36.camel@moss-spartans.epoch.ncsc.mil> <4469DCF1.2080406@city-fan.org> <80d7e4090605160834r1efc0d6ata7ee23d9ea67d6f9@mail.gmail.com> <4469F629.4010803@city-fan.org> <1147797025.30789.180.camel@moss-spartans.epoch.ncsc.mil> <4469FEEE.5090403@city-fan.org> Message-ID: <1147798738.30789.200.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2006-05-16 at 17:33 +0100, Paul Howarth wrote: > It contains a policy module, but the module only includes file contexts. Clarification: it is a policy package (.pp), but the policy package only includes file contexts. The module itself is just the .mod file created by checkmodule; it never includes file contexts. If this is going to be common, then semodule_package and libsemanage need to allow for policy packages that have no policy module. > The .te file is just: > --------------------------------------------------------------------- > # It's currently only necessary to set file contexts for the cache directory > # in this policy, but doing it in a module is easier from a package > maintenance > # point of view than using semanage and chcon in scriptlets > > policy_module(contagged, 0.1) This pulls in requires statements for the kernel classes and permissions. Which it seems are being confused with an attempt to declare classes/permissions in the module by the older libsepol. > The .fc file is: > --------------------------------------------------------------------- > /var/cache/contagged(/.*)? > gen_context(system_u:object_r:httpd_cache_t,s0) > --------------------------------------------------------------------- You can't use gen_context() there, can you? I thought it had to be preprocessed already. > The module was built on a system with: > $ rpm -q selinux-policy-targeted libsepol libsemanage > selinux-policy-targeted-2.2.38-1.fc5 > libsepol-1.12.6-1.fc5 > libsemanage-1.6.2-2.fc5 > > The error occurred when the package was installed on a system with: > $ rpm -q selinux-policy-targeted libsepol libsemanage > selinux-policy-targeted-2.2.34-3.fc5 > libsepol-1.12.4-1.fc5 > libsemanage-1.6.2-2.fc5 Hmmm...and what version of checkmodule was used to build it? -- Stephen Smalley National Security Agency From paul at city-fan.org Tue May 16 17:10:27 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 16 May 2006 18:10:27 +0100 Subject: SELinux Module Packaging in FC5 In-Reply-To: <1147798738.30789.200.camel@moss-spartans.epoch.ncsc.mil> References: <44169B09.3050508@city-fan.org> <1142341123.3713.36.camel@moss-spartans.epoch.ncsc.mil> <4469DCF1.2080406@city-fan.org> <80d7e4090605160834r1efc0d6ata7ee23d9ea67d6f9@mail.gmail.com> <4469F629.4010803@city-fan.org> <1147797025.30789.180.camel@moss-spartans.epoch.ncsc.mil> <4469FEEE.5090403@city-fan.org> <1147798738.30789.200.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <446A0783.1010503@city-fan.org> Stephen Smalley wrote: > On Tue, 2006-05-16 at 17:33 +0100, Paul Howarth wrote: >> It contains a policy module, but the module only includes file contexts. > > Clarification: it is a policy package (.pp), but the policy package > only includes file contexts. The module itself is just the .mod file > created by checkmodule; it never includes file contexts. Ah, right, thanks for the clarification. > If this is going to be common, then semodule_package and libsemanage > need to allow for policy packages that have no policy module. I think it is, because changes to file contexts are much more easily managed using semodule, since the policy packages are versioned and semodule will always do the right thing when any newer version is installed. The alternative, using semanage to tweak file contexts, could quickly become unmanageable. For example, suppose package foo went through some major revisions, moving files around the filesystem hierarchy that needed custom contexts. So the first version of the package would contain an semanage call to set contexts for say: /var/www/foo/cache(/.*) The next version moved the cache directory to /var/cache/foo, so a package upgrade would need to remove the context object set up in the first version and create a new one for: /var/cache/foo(/.*) There might then be an upstream name change from foo to bar, requiring contexts for: /var/cache/bar(/.*) The %post script for this package would need to identify the version of the package being upgraded (none, foo-1, foo-2, or bar), remove the appropriate context object (none, /var/www/foo/cache(/.*), /var/cache/foo(/.*)) if necessary and then install the new context object. Using semanage, if the policy package remained as foo.pp throughout, "semodule -i foo.pp" would always do the right thing. If for the last version, the policy package changed to bar.pp, it could do "semodule -r foo.pp" first and discard any error messages or failure codes before running "semodule -i bar.pp". Much better I think. >> The .te file is just: >> --------------------------------------------------------------------- >> # It's currently only necessary to set file contexts for the cache directory >> # in this policy, but doing it in a module is easier from a package >> maintenance >> # point of view than using semanage and chcon in scriptlets >> >> policy_module(contagged, 0.1) > > This pulls in requires statements for the kernel classes and > permissions. Which it seems are being confused with an attempt to > declare classes/permissions in the module by the older libsepol. > >> The .fc file is: >> --------------------------------------------------------------------- >> /var/cache/contagged(/.*)? >> gen_context(system_u:object_r:httpd_cache_t,s0) >> --------------------------------------------------------------------- > > You can't use gen_context() there, can you? I thought it had to be > preprocessed already. I just copied from other .fc files I found in the policy sources, and it seems to work (usually). If I'm wrong, what should I be using? >> The module was built on a system with: >> $ rpm -q selinux-policy-targeted libsepol libsemanage >> selinux-policy-targeted-2.2.38-1.fc5 >> libsepol-1.12.6-1.fc5 >> libsemanage-1.6.2-2.fc5 >> >> The error occurred when the package was installed on a system with: >> $ rpm -q selinux-policy-targeted libsepol libsemanage >> selinux-policy-targeted-2.2.34-3.fc5 >> libsepol-1.12.4-1.fc5 >> libsemanage-1.6.2-2.fc5 > > Hmmm...and what version of checkmodule was used to build it? $ rpm -q checkpolicy checkpolicy-1.30.3-1.fc5 Paul. From malejandra.castillo at gmail.com Wed May 17 01:08:39 2006 From: malejandra.castillo at gmail.com (Ma. Alejandra Castillo) Date: Tue, 16 May 2006 21:08:39 -0400 Subject: tools... LOG Message-ID: <25a49afb0605161808wcc4a0c0h87fa26b085f5a9f6@mail.gmail.com> Dear, besides seaudit, aureport and ausearch. Other tools exist to revise LOG? Saludos -- Ma. Alejandra Castillo M. From linux_4ever at yahoo.com Wed May 17 13:44:47 2006 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 17 May 2006 06:44:47 -0700 (PDT) Subject: tools... LOG In-Reply-To: <25a49afb0605161808wcc4a0c0h87fa26b085f5a9f6@mail.gmail.com> Message-ID: <20060517134447.64324.qmail@web51503.mail.yahoo.com> >Dear, besides seaudit, aureport and ausearch. Other tools exist to >revise LOG? Revise or review? :) ausearch is the intended tool to look at audit log entries. Is there something that you need that it doesn't do? -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From shin216 at xf7.so-net.ne.jp Thu May 18 00:33:28 2006 From: shin216 at xf7.so-net.ne.jp (Shintaro Fujiwara) Date: Thu, 18 May 2006 09:33:28 +0900 Subject: cron does not run on strict policy-2.x Message-ID: <002601c67a12$af393600$0401a8c0@test.com> Hi, I have a sever strict-policy newest package, but my cron fails. When I see /var/log/cron, ENTRYPOINT FAILED line I could get. /etc/crontab has system_u:object_r:system_cron_spool_t. I have two FC5 strict-policy server and both fails on cron,although anacron runs faily fine. From selinux at gmail.com Thu May 18 01:21:58 2006 From: selinux at gmail.com (Tom London) Date: Wed, 17 May 2006 18:21:58 -0700 Subject: unconfined_execmem_t for /usr/lib/jvm/java-1.5.0-sun-1.5.0.06/jre/bin/java ? Message-ID: <4c4ba1530605171821s45b2eec8r664c81bce41c799@mail.gmail.com> I'm getting execmem AVCs with latest policy and with SUN Java: type=AVC msg=audit(1147912677.425:256): avc: denied { execmem } for pid=10059 comm="java" scontext=user_u:system_r:unconfined_t:s0 tcontext=user_u:system_r:unconfined_t:s0 tclass=process type=SYSCALL msg=audit(1147912677.425:256): arch=40000003 syscall=192 per=400000 success=no exit=-1082810368 a0=bf75a000 a1=3000 a2=7 a3=32 items=0 pid=10059 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="java" exe="/usr/lib/jvm/java-1.5.0-sun-1.5.0.06/jre/bin/java" subj=user_u:system_r:unconfined_t:s0 Is it appropriate to label as unconfined_exemem_t? tom -- Tom London From paul at city-fan.org Thu May 18 06:29:37 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 18 May 2006 07:29:37 +0100 Subject: unconfined_execmem_t for /usr/lib/jvm/java-1.5.0-sun-1.5.0.06/jre/bin/java ? In-Reply-To: <4c4ba1530605171821s45b2eec8r664c81bce41c799@mail.gmail.com> References: <4c4ba1530605171821s45b2eec8r664c81bce41c799@mail.gmail.com> Message-ID: <1147933777.2403.14.camel@laurel.intra.city-fan.org> On Wed, 2006-05-17 at 18:21 -0700, Tom London wrote: > I'm getting execmem AVCs with latest policy and with SUN Java: > type=AVC msg=audit(1147912677.425:256): avc: denied { execmem } for > pid=10059 comm="java" scontext=user_u:system_r:unconfined_t:s0 > tcontext=user_u:system_r:unconfined_t:s0 tclass=process > type=SYSCALL msg=audit(1147912677.425:256): arch=40000003 syscall=192 > per=400000 success=no exit=-1082810368 a0=bf75a000 a1=3000 a2=7 a3=32 > items=0 pid=10059 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=pts0 comm="java" > exe="/usr/lib/jvm/java-1.5.0-sun-1.5.0.06/jre/bin/java" > subj=user_u:system_r:unconfined_t:s0 > > Is it appropriate to label as unconfined_exemem_t? I think /usr/lib/jvm/java-1.5.0-sun-1.5.0.06/jre/bin/java* should be java_exec_t: # semanage fcontext -l | grep java_exec /usr/bin/gcj-dbtool regular file system_u:object_r:java_exec_t:s0 /usr/(.*/)?bin/java.* regular file system_u:object_r:java_exec_t:s0 /opt/(.*/)?bin/java([^/]*)? regular file system_u:object_r:java_exec_t:s0 /usr/lib(.*/)?bin/java([^/]*)? regular file system_u:object_r:java_exec_t:s0 /usr/bin/gij regular file system_u:object_r:java_exec_t:s0 Unfortunately restorecon is leaving these as bin_t here, for reasons I can't fathom. # rpm -q policycoreutils selinux-policy-targeted policycoreutils-1.30.8-1.fc5 selinux-policy-targeted-2.2.38-1.fc5 Paul. From selke at thi.uni-hannover.de Thu May 18 11:18:45 2006 From: selke at thi.uni-hannover.de (Joachim Selke) Date: Thu, 18 May 2006 13:18:45 +0200 Subject: acroread again Message-ID: <446C5815.2050302@joachim-selke.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, one or two weeks ago the Adobe Reader RPM from Adobe got a special treatment in default policy (FC5). It looks like this: | semanage fcontext -l | grep -Ei 'adobe|intellinux' | /usr/(local/)?acroread/(.*/)?intellinux/nppdf\.so regular file system_u:object_r:textrel_shlib_t:s0 | /usr/(local/)?Adobe/.*\.api regular file system_u:object_r:textrel_shlib_t:s0 | /usr/(local/)?Adobe/(.*/)?lib/[^/]*\.so(\.[^/]*)* regular file system_u:object_r:textrel_shlib_t:s0 | /usr/(.*/)?intellinux/SPPlugins/ADMPlugin\.apl regular file system_u:object_r:textrel_shlib_t:s0 | /usr/(local/)?Adobe/(.*/)?intellinux/nppdf\.so regular file system_u:object_r:textrel_shlib_t:s0 But there is a repackaged version of this RPM available from Dries RPM Repository (), which fixes some problems with the original RPM and changes the install path from /usr/local/Adobe/Acrobat7.0 to /usr/lib/acroread. But this change bypasses the rules for acroread in current default policy. Can these rules be extended so that they cover the acroread RPM from Dries RPM Repository? Joachim - -- B. Sc. Joachim Selke Universit?t Hannover, Institut f?r Theoretische Informatik Appelstra?e 4, 30167 Hannover, Germany -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEbFgVq7fYj4TsIUwRAvRCAJsFVzD+/5keLPbUuDLes3jkGhXZUQCglzHJ /mCEUanWqbf66R7sELGp7Co= =GeKx -----END PGP SIGNATURE----- From paul at city-fan.org Thu May 18 12:39:50 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 18 May 2006 13:39:50 +0100 Subject: SELinux Module Packaging in FC5 In-Reply-To: <446A0783.1010503@city-fan.org> References: <44169B09.3050508@city-fan.org> <1142341123.3713.36.camel@moss-spartans.epoch.ncsc.mil> <4469DCF1.2080406@city-fan.org> <80d7e4090605160834r1efc0d6ata7ee23d9ea67d6f9@mail.gmail.com> <4469F629.4010803@city-fan.org> <1147797025.30789.180.camel@moss-spartans.epoch.ncsc.mil> <4469FEEE.5090403@city-fan.org> <1147798738.30789.200.camel@moss-spartans.epoch.ncsc.mil> <446A0783.1010503@city-fan.org> Message-ID: <446C6B16.4060709@city-fan.org> Paul Howarth wrote: > Stephen Smalley wrote: >> On Tue, 2006-05-16 at 17:33 +0100, Paul Howarth wrote: >>> It contains a policy module, but the module only includes file contexts. >> >> Clarification: it is a policy package (.pp), but the policy package >> only includes file contexts. The module itself is just the .mod file >> created by checkmodule; it never includes file contexts. > > Ah, right, thanks for the clarification. > >> If this is going to be common, then semodule_package and libsemanage >> need to allow for policy packages that have no policy module. Is the absence of a policy module the actual cause of this error? If so, would having a "dummy" policy module that was effectively a no-op (e.g. by including an allow rule that was already in the base policy) be a usable workaround? Should this be bugzilla-ed? Paul. From paul at city-fan.org Thu May 18 13:18:06 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 18 May 2006 14:18:06 +0100 Subject: SELinux Module Packaging in FC5 In-Reply-To: <446C6B16.4060709@city-fan.org> References: <44169B09.3050508@city-fan.org> <1142341123.3713.36.camel@moss-spartans.epoch.ncsc.mil> <4469DCF1.2080406@city-fan.org> <80d7e4090605160834r1efc0d6ata7ee23d9ea67d6f9@mail.gmail.com> <4469F629.4010803@city-fan.org> <1147797025.30789.180.camel@moss-spartans.epoch.ncsc.mil> <4469FEEE.5090403@city-fan.org> <1147798738.30789.200.camel@moss-spartans.epoch.ncsc.mil> <446A0783.1010503@city-fan.org> <446C6B16.4060709@city-fan.org> Message-ID: <446C740E.4090706@city-fan.org> Another query regarding policy module packages in RPMs: Supposing a package is installed when the system has SELinux disabled. What would happen if semodule was called to install a policy module? If the result is that nothing happens (or semodule bombs out with an error of some sort), what would then happen if the system subsequently had SELinux enabled and the system was relabelled? Would the package containing the policy module have to be reinstalled? I'd try it myself but I can't bring myself to disable SELinux on any of my boxes and go through the whole relabelling process. Paul. From selinux at gmail.com Thu May 18 16:15:42 2006 From: selinux at gmail.com (Tom London) Date: Thu, 18 May 2006 09:15:42 -0700 Subject: unconfined_execmem_t for /usr/lib/jvm/java-1.5.0-sun-1.5.0.06/jre/bin/java ? In-Reply-To: <1147933777.2403.14.camel@laurel.intra.city-fan.org> References: <4c4ba1530605171821s45b2eec8r664c81bce41c799@mail.gmail.com> <1147933777.2403.14.camel@laurel.intra.city-fan.org> Message-ID: <4c4ba1530605180915v47bbace5sf1489df1782a076@mail.gmail.com> On 5/17/06, Paul Howarth wrote: > On Wed, 2006-05-17 at 18:21 -0700, Tom London wrote: > > I'm getting execmem AVCs with latest policy and with SUN Java: > > type=AVC msg=audit(1147912677.425:256): avc: denied { execmem } for > > pid=10059 comm="java" scontext=user_u:system_r:unconfined_t:s0 > > tcontext=user_u:system_r:unconfined_t:s0 tclass=process > > type=SYSCALL msg=audit(1147912677.425:256): arch=40000003 syscall=192 > > per=400000 success=no exit=-1082810368 a0=bf75a000 a1=3000 a2=7 a3=32 > > items=0 pid=10059 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > > sgid=0 fsgid=0 tty=pts0 comm="java" > > exe="/usr/lib/jvm/java-1.5.0-sun-1.5.0.06/jre/bin/java" > > subj=user_u:system_r:unconfined_t:s0 > > > > Is it appropriate to label as unconfined_exemem_t? > > I think /usr/lib/jvm/java-1.5.0-sun-1.5.0.06/jre/bin/java* should be > java_exec_t: > > # semanage fcontext -l | grep java_exec > /usr/bin/gcj-dbtool regular file > system_u:object_r:java_exec_t:s0 > /usr/(.*/)?bin/java.* regular file > system_u:object_r:java_exec_t:s0 > /opt/(.*/)?bin/java([^/]*)? regular file > system_u:object_r:java_exec_t:s0 > /usr/lib(.*/)?bin/java([^/]*)? regular file > system_u:object_r:java_exec_t:s0 > /usr/bin/gij regular file > system_u:object_r:java_exec_t:s0 > > Unfortunately restorecon is leaving these as bin_t here, for reasons I > can't fathom. > > # rpm -q policycoreutils selinux-policy-targeted > policycoreutils-1.30.8-1.fc5 > selinux-policy-targeted-2.2.38-1.fc5 > > Paul. OK.... How about this (notice the last entry). Doesn't that 'override' the previous java_exec_t entry? tom [root at localhost ~]# semanage fcontext -l | grep java /usr/bin/gcj-dbtool regular file system_u:object_r:java_exec_t:s0 /usr/(.*/)?bin/java.* regular file system_u:object_r:java_exec_t:s0 /opt/(.*/)?bin/java([^/]*)? regular file system_u:object_r:java_exec_t:s0 /emul/ia32-linux/usr(/.*)?/java/.*\.so(\.[^/]*)* regular file system_u:object_r:shlib_t:s0 /usr/lib(.*/)?bin/java([^/]*)? regular file system_u:object_r:java_exec_t:s0 /usr/bin/gij regular file system_u:object_r:java_exec_t:s0 /emul/ia32-linux/usr(/.*)?/java/.*\.jsa regular file system_u:object_r:shlib_t:s0 /usr/(.*/)?java/.*\.jsa regular file system_u:object_r:shlib_t:s0 /emul/ia32-linux/usr(/.*)?/java/.*\.jar regular file system_u:object_r:shlib_t:s0 /usr/lib/jvm/java.*/bin directory system_u:object_r:bin_t:s0 /usr/(.*/)?java/.*\.so(\.[^/]*)* regular file system_u:object_r:textrel_shlib_t:s0 /usr/(.*/)?java/.*\.jar regular file system_u:object_r:shlib_t:s0 /usr/lib/jvm/java.*/bin/.* all files system_u:object_r:bin_t:s0 -- Tom London From udjinrg at forenet.by Fri May 19 11:02:18 2006 From: udjinrg at forenet.by (Maxim Britov) Date: Fri, 19 May 2006 14:02:18 +0300 Subject: mailman Message-ID: <20060519140218.5797cd6a@maxim.office.modum.by> # rpm -q kernel mailman selinux-policy-strict kernel-2.6.16-1.2111_FC5 mailman-2.1.8-1 selinux-policy-strict-2.2.38-1.fc5 SELINUX=permissive SELINUXTYPE=targeted kernel: audit(1148035969.958:832): avc: denied { search } for pid=23052 comm="smtpd" name="mailman" dev=hda3 ino=588209 scontext=ro ot:system_r:postfix_smtpd_t:s0 tcontext=system_u:object_r:mailman_data_t:s0 tclass=dir kernel: audit(1148035969.958:833): avc: denied { read } for pid=23052 comm="smtpd" name="aliases.db" dev=hda3 ino=588256 scontext=r oot:system_r:postfix_smtpd_t:s0 tcontext=root:object_r:mailman_data_t:s0 tclass=file kernel: audit(1148035969.958:834): avc: denied { lock } for pid=23052 comm="smtpd" name="aliases.db" dev=hda3 ino=588256 scontext=r oot:system_r:postfix_smtpd_t:s0 tcontext=root:object_r:mailman_data_t:s0 tclass=file kernel: audit(1148035969.962:835): avc: denied { getattr } for pid=23052 comm="smtpd" name="aliases.db" dev=hda3 ino=588256 scontex t=root:system_r:postfix_smtpd_t:s0 tcontext=root:object_r:mailman_data_t:s0 tclass=file # ps axZ|fgrep mailman user_u:system_r:initrc_t 23331 ? Ss 0:00 /usr/bin/python /usr/lib/mailman/bin/mailmanctl -s -q start user_u:system_r:initrc_t 23334 ? S 0:00 /usr/bin/python /usr/lib/mailman/bin/qrunner --runner=ArchRunner:0:1 -s user_u:system_r:initrc_t 23335 ? S 0:00 /usr/bin/python /usr/lib/mailman/bin/qrunner --runner=BounceRunner:0:1 -s user_u:system_r:initrc_t 23336 ? S 0:00 /usr/bin/python /usr/lib/mailman/bin/qrunner --runner=CommandRunner:0:1 -s user_u:system_r:initrc_t 23337 ? S 0:00 /usr/bin/python /usr/lib/mailman/bin/qrunner --runner=IncomingRunner:0:1 -s user_u:system_r:initrc_t 23338 ? S 0:00 /usr/bin/python /usr/lib/mailman/bin/qrunner --runner=NewsRunner:0:1 -s user_u:system_r:initrc_t 23339 ? S 0:00 /usr/bin/python /usr/lib/mailman/bin/qrunner --runner=OutgoingRunner:0:1 -s user_u:system_r:initrc_t 23340 ? S 0:00 /usr/bin/python /usr/lib/mailman/bin/qrunner --runner=VirginRunner:0:1 -s user_u:system_r:initrc_t 23341 ? S 0:00 /usr/bin/python /usr/lib/mailman/bin/qrunner --runner=RetryRunner:0:1 -s -- Maxim Britov GnuPG KeyID 0x4580A6D66F3DB1FB xmpp:maxim at modum.by icq 198171258 Fingerprint: 4059 B5C5 8985 5A47 8F5A 8623 4580 A6D6 6F3D B1FB GnuPG-ru Team (http://lists.gnupg.org/mailman/listinfo/gnupg-ru xmpp:gnupg-ru at conference.jabber.ru) From sds at tycho.nsa.gov Fri May 19 12:03:03 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 19 May 2006 08:03:03 -0400 Subject: SELinux Module Packaging in FC5 In-Reply-To: <446C6B16.4060709@city-fan.org> References: <44169B09.3050508@city-fan.org> <1142341123.3713.36.camel@moss-spartans.epoch.ncsc.mil> <4469DCF1.2080406@city-fan.org> <80d7e4090605160834r1efc0d6ata7ee23d9ea67d6f9@mail.gmail.com> <4469F629.4010803@city-fan.org> <1147797025.30789.180.camel@moss-spartans.epoch.ncsc.mil> <4469FEEE.5090403@city-fan.org> <1147798738.30789.200.camel@moss-spartans.epoch.ncsc.mil> <446A0783.1010503@city-fan.org> <446C6B16.4060709@city-fan.org> Message-ID: <1148040183.25168.22.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-05-18 at 13:39 +0100, Paul Howarth wrote: > Paul Howarth wrote: > > Stephen Smalley wrote: > >> On Tue, 2006-05-16 at 17:33 +0100, Paul Howarth wrote: > >>> It contains a policy module, but the module only includes file contexts. > >> > >> Clarification: it is a policy package (.pp), but the policy package > >> only includes file contexts. The module itself is just the .mod file > >> created by checkmodule; it never includes file contexts. > > > > Ah, right, thanks for the clarification. > > > >> If this is going to be common, then semodule_package and libsemanage > >> need to allow for policy packages that have no policy module. > > Is the absence of a policy module the actual cause of this error? If so, > would having a "dummy" policy module that was effectively a no-op (e.g. > by including an allow rule that was already in the base policy) be a > usable workaround? No, per Chad (via private email), the problem you encountered was actually caused by an unintended side effect of the helpful policy_module() macro in refpolicy. Since that macro expands to include require statements for all kernel classes and permissions (so that the policy writer doesn't have to manually specify them for each kernel class and permission he uses), it unfortunately can pick up requires for new classes and permissions in the refpolicy on the build system that are not yet defined in the base policy on the target system (in your case, due to not having fully updated the target system). There are some changes in progress that should help with that problem. > Should this be bugzilla-ed? I suppose there are two separate issues here: - Avoiding unnecessary dependencies in policy modules on the build system's refpolicy (of which this is only one instance). There is already more general effort in progress to introduce real interfaces into the language and module format so that modules can be truly linked against the interfaces of the base policy on the target system. - Cleanly supporting policy packages that do not include a binary policy module in the tools (e.g. semodule_package) and libraries (e.g. libsemanage, libsepol), so that they can be used to ship just file contexts or other components. I don't know of any work in progress yet on that issue, so it may make sense to bugzilla it, although it is really an upstream issue, and there isn't presently an upstream bugzilla for selinux (just the mailing list). -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Fri May 19 13:12:03 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 19 May 2006 09:12:03 -0400 Subject: SELinux Module Packaging in FC5 In-Reply-To: <446C740E.4090706@city-fan.org> References: <44169B09.3050508@city-fan.org> <1142341123.3713.36.camel@moss-spartans.epoch.ncsc.mil> <4469DCF1.2080406@city-fan.org> <80d7e4090605160834r1efc0d6ata7ee23d9ea67d6f9@mail.gmail.com> <4469F629.4010803@city-fan.org> <1147797025.30789.180.camel@moss-spartans.epoch.ncsc.mil> <4469FEEE.5090403@city-fan.org> <1147798738.30789.200.camel@moss-spartans.epoch.ncsc.mil> <446A0783.1010503@city-fan.org> <446C6B16.4060709@city-fan.org> <446C740E.4090706@city-fan.org> Message-ID: <1148044323.25168.81.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-05-18 at 14:18 +0100, Paul Howarth wrote: > Another query regarding policy module packages in RPMs: > > Supposing a package is installed when the system has SELinux disabled. > > What would happen if semodule was called to install a policy module? > > If the result is that nothing happens (or semodule bombs out with an > error of some sort), what would then happen if the system subsequently > had SELinux enabled and the system was relabelled? Would the package > containing the policy module have to be reinstalled? > > I'd try it myself but I can't bring myself to disable SELinux on any of > my boxes and go through the whole relabelling process. If policy is installed on the system, then semodule (actually libsemanage) will install the module and rebuild the generated files, but will not try to load policy into the kernel since SELinux is disabled. Then, if you enable SELinux, the module will already be included in the policy. If policy is not installed on the system, then semodule will abort with an error like this: semodule: SELinux policy is not managed or store cannot be accessed. Note also that one should generally use semodule -s as in the selinux-policy .spec file to indicate which kind of policy your module is built for (targeted, strict, mls). Then, if the system is running a different kind of policy, semodule will know to install the module to the proper location (not the active policy) and to not try to load it. -- Stephen Smalley National Security Agency From Valdis.Kletnieks at vt.edu Fri May 19 13:36:41 2006 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 19 May 2006 09:36:41 -0400 Subject: mailman In-Reply-To: Your message of "Fri, 19 May 2006 14:02:18 +0300." <20060519140218.5797cd6a@maxim.office.modum.by> References: <20060519140218.5797cd6a@maxim.office.modum.by> Message-ID: <200605191336.k4JDagXP004050@turing-police.cc.vt.edu> On Fri, 19 May 2006 14:02:18 +0300, Maxim Britov said: > # rpm -q kernel mailman selinux-policy-strict > kernel-2.6.16-1.2111_FC5 > mailman-2.1.8-1 > selinux-policy-strict-2.2.38-1.fc5 ^^^^^^ > SELINUX=permissive > SELINUXTYPE=targeted ^^^^^^^^ "I see a bad moon rising... I see troubles on the way" -- CCR I hope that there's a policy-targeted installed too? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From hongwei at wustl.edu Fri May 19 14:58:10 2006 From: hongwei at wustl.edu (Hongwei Li) Date: Fri, 19 May 2006 09:58:10 -0500 (CDT) Subject: need help for local.te Message-ID: <3584.128.252.85.103.1148050690.squirrel@morpheus.wustl.edu> Hi, I need help about local.te. My system: kernel: 2.6.16-1.2111_FC5smp selinux-policy-targeted: 2.2.38-1.fc5 audit: 1.1.5-1 sendmail: 8.13.6-0.FC5.1 squirrelmail: 1.4.6-5.fc5 When I try to create an email folder in squirrelmail, I got Error. So, I run the following to create my local.te and add my module. Here are what I run and get: # audit2allow -M local < /var/log/audit/audit.log Generating type enforcment file: local.te Compiling policy checkmodule -M -m -o local.mod local.te semodule_package -o local.pp -m local.mod ******************** IMPORTANT *********************** In order to load this newly created policy package into the kernel, you are required to execute semodule -i local.pp # ls -l total 40 -rw-r--r-- 1 root root 2448 May 19 09:46 local.mod -rw-r--r-- 1 root root 2464 May 19 09:46 local.pp -rw-r--r-- 1 root root 733 May 19 09:46 local.te # semodule -i local.pp libsepol.check_assertion_helper: assertion on line 0 violated by allow httpd_t shadow_t:file { read }; libsepol.check_assertions: 1 assertion violations occured libsemanage.semanage_expand_sandbox: Expand module failed semodule: Failed! How to solve the problem? Thanks! Hongwei From sds at tycho.nsa.gov Fri May 19 15:14:47 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 19 May 2006 11:14:47 -0400 Subject: need help for local.te In-Reply-To: <3584.128.252.85.103.1148050690.squirrel@morpheus.wustl.edu> References: <3584.128.252.85.103.1148050690.squirrel@morpheus.wustl.edu> Message-ID: <1148051687.25168.140.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2006-05-19 at 09:58 -0500, Hongwei Li wrote: > Hi, > > I need help about local.te. My system: > > kernel: 2.6.16-1.2111_FC5smp > selinux-policy-targeted: 2.2.38-1.fc5 > audit: 1.1.5-1 > sendmail: 8.13.6-0.FC5.1 > squirrelmail: 1.4.6-5.fc5 > > When I try to create an email folder in squirrelmail, I got Error. So, I run > the following to create my local.te and add my module. Here are what I run > and get: > > # audit2allow -M local < /var/log/audit/audit.log > Generating type enforcment file: local.te > Compiling policy > checkmodule -M -m -o local.mod local.te > semodule_package -o local.pp -m local.mod > > ******************** IMPORTANT *********************** > > In order to load this newly created policy package into the kernel, > you are required to execute > > semodule -i local.pp > > # ls -l > total 40 > -rw-r--r-- 1 root root 2448 May 19 09:46 local.mod > -rw-r--r-- 1 root root 2464 May 19 09:46 local.pp > -rw-r--r-- 1 root root 733 May 19 09:46 local.te > > # semodule -i local.pp > libsepol.check_assertion_helper: assertion on line 0 violated by allow httpd_t > shadow_t:file { read }; > libsepol.check_assertions: 1 assertion violations occured > libsemanage.semanage_expand_sandbox: Expand module failed > semodule: Failed! > > How to solve the problem? > > Thanks! This means that your local.te file includes a rule that allows httpd to read your /etc/shadow file, and this violates an assertion in the base policy. Review your local.te file, prune entries that are not legitimate, and rebuild the .mod and .pp files, e.g. # vi local.te # edit out bogus entries or replace them with dontaudit rules # checkmodule -m -M -o local.mod local.te # semodule_package -o local.pp -m local.mod # semodule -i local.pp -- Stephen Smalley National Security Agency From selinux at gmail.com Fri May 19 16:02:35 2006 From: selinux at gmail.com (Tom London) Date: Fri, 19 May 2006 09:02:35 -0700 Subject: printer AVCs.... Message-ID: <4c4ba1530605190902q5c981798m31d36366654f159@mail.gmail.com> Running latest Rawhide, targeted/enforcing. I get the following when 'deactivating/activating' a USB printer (and printing fails): type=AVC msg=audit(1148052935.119:30): avc: denied { create } for pid=1902 comm="python" scontext=system_u:system_r:hplip_t:s0 tcontext=system_u:system_r:hplip_t:s0 tclass=netlink_route_socket type=SYSCALL msg=audit(1148052935.119:30): arch=40000003 syscall=102 success=no exit=-13 a0=1 a1=bffa4878 a2=49ebaff4 a3=bffa4e69 items=0 pid=1902 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="python" exe="/usr/bin/python" subj=system_u:system_r:hplip_t:s0 type=SOCKETCALL msg=audit(1148052935.119:30): nargs=3 a0=10 a1=3 a2=0 type=USER_AVC msg=audit(1148053114.333:32): user pid=1735 uid=81 auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0 msg='avc: denied { send_msg } for msgtype=signal interface=com.redhat.PrinterSpooler member=JobQueuedLocal dest=org.freedesktop.DBus spid=1913 tpid=2748 scontext=system_u:system_r:cupsd_t:SystemLow-SystemHigh tcontext=user_u:system_r:unconfined_execmem_t tclass=dbus : exe="?" (sauid=81, hostname=?, addr=?, terminal=?)' The following messages were in /var/log/messages: May 19 08:35:33 localhost dbus: Can't send to audit system: USER_AVC avc: denied { send_msg } for msgtype=signal interface=com.redhat.PrinterSpooler member=JobQueuedLocal dest=org.freedesktop.DBus spid=1913 tpid=2748 scontext=system_u:system_r:cupsd_t:SystemLow-SystemHigh tcontext=user_u:system_r:unconfined_execmem_t tclass=dbus : exe="?" (sauid=81, hostname=?, addr=?, terminal=?) May 19 08:35:33 localhost dbus: Can't send to audit system: USER_AVC avc: denied { send_msg } for msgtype=signal interface=com.redhat.PrinterSpooler member=QueueChanged dest=org.freedesktop.DBus spid=1913 tpid=2748 scontext=system_u:system_r:cupsd_t:SystemLow-SystemHigh tcontext=user_u:system_r:unconfined_execmem_t tclass=dbus : exe="?" (sauid=81, hostname=?, addr=?, terminal=?) May 19 08:35:33 localhost dbus: Can't send to audit system: USER_AVC avc: denied { send_msg } for msgtype=signal interface=com.redhat.PrinterSpooler member=JobStartedLocal dest=org.freedesktop.DBus spid=1913 tpid=2748 scontext=system_u:system_r:cupsd_t:SystemLow-SystemHigh tcontext=user_u:system_r:unconfined_execmem_t tclass=dbus : exe="?" (sauid=81, hostname=?, addr=?, terminal=?) May 19 08:35:35 localhost hpiod: invalid product id string: Broken pipe io/hpiod/device.cpp 623 May 19 08:35:35 localhost hpiod: unable to Device::Open hp:/usb/hp_LaserJet_1300?serial=00CNCB954325 io/hpiod/device.cpp 862 May 19 08:35:35 localhost hp_LaserJet_1300?serial=00CNCB954325: INFO: open device failed; will retry in 30 seconds... May 19 08:36:05 localhost hpiod: invalid product id string: Broken pipe io/hpiod/device.cpp 623 tom -- Tom London From hongwei at wustl.edu Fri May 19 17:13:15 2006 From: hongwei at wustl.edu (Hongwei Li) Date: Fri, 19 May 2006 12:13:15 -0500 (CDT) Subject: need help for local.te In-Reply-To: <1148051687.25168.140.camel@moss-spartans.epoch.ncsc.mil> References: <3584.128.252.85.103.1148050690.squirrel@morpheus.wustl.edu> <1148051687.25168.140.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1866.128.252.85.103.1148058795.squirrel@morpheus.wustl.edu> > On Fri, 2006-05-19 at 09:58 -0500, Hongwei Li wrote: >> Hi, >> >> I need help about local.te. My system: >> >> kernel: 2.6.16-1.2111_FC5smp >> selinux-policy-targeted: 2.2.38-1.fc5 >> audit: 1.1.5-1 >> sendmail: 8.13.6-0.FC5.1 >> squirrelmail: 1.4.6-5.fc5 >> >> When I try to create an email folder in squirrelmail, I got Error. So, I >> run >> the following to create my local.te and add my module. Here are what I run >> and get: >> >> # audit2allow -M local < /var/log/audit/audit.log >> Generating type enforcment file: local.te >> Compiling policy >> checkmodule -M -m -o local.mod local.te >> semodule_package -o local.pp -m local.mod >> >> ******************** IMPORTANT *********************** >> >> In order to load this newly created policy package into the kernel, >> you are required to execute >> >> semodule -i local.pp >> >> # ls -l >> total 40 >> -rw-r--r-- 1 root root 2448 May 19 09:46 local.mod >> -rw-r--r-- 1 root root 2464 May 19 09:46 local.pp >> -rw-r--r-- 1 root root 733 May 19 09:46 local.te >> >> # semodule -i local.pp >> libsepol.check_assertion_helper: assertion on line 0 violated by allow >> httpd_t >> shadow_t:file { read }; >> libsepol.check_assertions: 1 assertion violations occured >> libsemanage.semanage_expand_sandbox: Expand module failed >> semodule: Failed! >> >> How to solve the problem? >> >> Thanks! > > This means that your local.te file includes a rule that allows httpd to > read your /etc/shadow file, and this violates an assertion in the base > policy. Review your local.te file, prune entries that are not > legitimate, and rebuild the .mod and .pp files, e.g. > # vi local.te # edit out bogus entries or replace them with dontaudit rules > # checkmodule -m -M -o local.mod local.te > # semodule_package -o local.pp -m local.mod > # semodule -i local.pp > > -- > Stephen Smalley > National Security Agency The problem is I need to re-do for local.te from time to time, and whenver I run (after rebooting) # audit2allow -M local < /var/log/audit/audit.log the line allow httpd_t shadow_t:file { getattr read write }; is automatically added to local.te -- this time, it added more, not just read. I believe that this is because I need to run change_password plugin in squirrelmail. It is not a problem in fc4 selinux -- I run audit2allow to add entry into local.te and run make load, then everything is working. But, in fc5, it is a problem. If I remove that line, then whenever I run the above command, it is automatically added. How to fix the problem? Thanks! Hongwei From kayvan at sylvan.com Sat May 20 01:30:37 2006 From: kayvan at sylvan.com (Kayvan A. Sylvan) Date: Fri, 19 May 2006 18:30:37 -0700 Subject: need help for local.te In-Reply-To: <1866.128.252.85.103.1148058795.squirrel@morpheus.wustl.edu> References: <3584.128.252.85.103.1148050690.squirrel@morpheus.wustl.edu> <1148051687.25168.140.camel@moss-spartans.epoch.ncsc.mil> <1866.128.252.85.103.1148058795.squirrel@morpheus.wustl.edu> Message-ID: <20060520013037.GD2422@satyr.sylvan.com> On Fri, May 19, 2006 at 12:13:15PM -0500, Hongwei Li wrote: > > The problem is I need to re-do for local.te from time to time, and whenver I > run (after rebooting) > # audit2allow -M local < /var/log/audit/audit.log > the line > > allow httpd_t shadow_t:file { getattr read write }; > > is automatically added to local.te -- [...] > How to fix the problem? How about something like this? audit2allow -l -i /var/log/audit/audit.log | grep -v shadow >> local.te -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan, | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | my beautiful Queen. | Robin Gregory (2/28/92) From hongwei at wustl.edu Sat May 20 03:16:44 2006 From: hongwei at wustl.edu (Hongwei Li) Date: Fri, 19 May 2006 22:16:44 -0500 (CDT) Subject: need help for local.te In-Reply-To: <20060520013037.GD2422@satyr.sylvan.com> References: <3584.128.252.85.103.1148050690.squirrel@morpheus.wustl.edu> <1148051687.25168.140.camel@moss-spartans.epoch.ncsc.mil> <1866.128.252.85.103.1148058795.squirrel@morpheus.wustl.edu> <20060520013037.GD2422@satyr.sylvan.com> Message-ID: <1808.70.230.152.93.1148095004.squirrel@morpheus.wustl.edu> > On Fri, May 19, 2006 at 12:13:15PM -0500, Hongwei Li wrote: >> >> The problem is I need to re-do for local.te from time to time, and whenver I >> run (after rebooting) >> # audit2allow -M local < /var/log/audit/audit.log >> the line >> >> allow httpd_t shadow_t:file { getattr read write }; >> >> is automatically added to local.te -- [...] >> How to fix the problem? > > How about something like this? > > audit2allow -l -i /var/log/audit/audit.log | grep -v shadow >> local.te > > -- > Kayvan A. Sylvan | Proud husband of | Father to my kids: > Sylvan Associates, Inc. | Laura Isabella Sylvan, | Katherine Yelena (8/8/89) I did and got: # audit2allow -l -i /var/log/audit/audit.log | grep -v shadow >> local.te # checkmodule -M -m -o local.mod local.te checkmodule: loading policy configuration from local.te (unknown source)::ERROR 'unknown type dovecot_auth_t' at token ';' on line 33: allow procmail_t tmp_t:dir { search write }; allow dovecot_auth_t initrc_var_run_t:file { read write }; checkmodule: error(s) encountered while parsing configuration I manually edit local.te to add a line type dovecot_auth_t; and run it again, then got # checkmodule -M -m -o local.mod local.te checkmodule: loading policy configuration from local.te (unknown source)::ERROR 'unknown type initrc_var_run_t' at token ';' on line 34: allow procmail_t tmp_t:dir { search write }; allow dovecot_auth_t initrc_var_run_t:file { read write }; checkmodule: error(s) encountered while parsing configuration The line 34 is: allow dovecot_auth_t initrc_var_run_t:file { read write }; What to do next? Thanks! Hongwei From dragoran at feuerpokemon.de Sat May 20 11:18:35 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Sat, 20 May 2006 13:18:35 +0200 Subject: selinux prelink avc's In-Reply-To: <4469F575.30609@feuerpokemon.de> References: <4469F575.30609@feuerpokemon.de> Message-ID: <446EFB0B.8030508@feuerpokemon.de> dragoran wrote: > audit(1147793154.831:353): avc: denied { execute_no_trans } for > pid=5195 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 > scontext=system_u:system_r:prelink_t:s0 > tcontext=system_u:object_r:lib_t:s0 tclass=file > audit(1147793154.831:354): avc: denied { execute_no_trans } for > pid=5196 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 > scontext=system_u:system_r:prelink_t:s0 > tcontext=system_u:object_r:lib_t:s0 tclass=file > audit(1147793155.019:355): avc: denied { execute_no_trans } for > pid=5197 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 > scontext=system_u:system_r:prelink_t:s0 > tcontext=system_u:object_r:lib_t:s0 tclass=file > audit(1147793155.447:356): avc: denied { execute_no_trans } for > pid=5198 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 > scontext=system_u:system_r:prelink_t:s0 > tcontext=system_u:object_r:lib_t:s0 tclass=file > audit(1147793156.255:357): avc: denied { execute_no_trans } for > pid=5199 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 > scontext=system_u:system_r:prelink_t:s0 > tcontext=system_u:object_r:lib_t:s0 tclass=file > I am using FC5 with selinux-policy-targeted-2.2.36-2.fc5 > whats gonig on? is a file misslabeled or is this a policy bug? > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > hello? any solution for this problem? From justin.conover at gmail.com Sat May 20 13:22:57 2006 From: justin.conover at gmail.com (Justin Conover) Date: Sat, 20 May 2006 08:22:57 -0500 Subject: Trusted Solaris over SELinux Message-ID: http://blogs.sun.com/roller/page/darren?entry=dear_ibm_please_consider_trusted I thought this was interesting. Yeah, I use Solaris to so I read some Sun blogs too. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at warmcat.com Sat May 20 14:04:33 2006 From: andy at warmcat.com (Andy Green) Date: Sat, 20 May 2006 15:04:33 +0100 Subject: Trusted Solaris over SELinux In-Reply-To: References: Message-ID: <446F21F1.5020607@warmcat.com> Justin Conover wrote: > http://blogs.sun.com/roller/page/darren?entry=dear_ibm_please_consider_trusted > > I thought this was interesting. Yeah, I use Solaris to so I read some > Sun blogs too. :) Get thee to somewhere far away from the NHS... http://globalspecials.sun.com/servlet/ControllerServlet?Action=DisplayPage&Locale=en_US&id=ProductDetailsPage&SiteID=sunstor&productID=36446400&Env=BASE ...with yer $995 - $27K trusted Solaris junk. Give me Linux+selinux at $0 per unit when I am flat on my back... or happy and healthy and paying my taxes. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From lists at ebourne.me.uk Sat May 20 14:15:12 2006 From: lists at ebourne.me.uk (Martin Ebourne) Date: Sat, 20 May 2006 15:15:12 +0100 Subject: Trusted Solaris over SELinux In-Reply-To: References: Message-ID: <1148134512.6512.14.camel@avenin.ebourne.me.uk> On Sat, 2006-05-20 at 08:22 -0500, Justin Conover wrote: > http://blogs.sun.com/roller/page/darren?entry=dear_ibm_please_consider_trusted > > I thought this was interesting. Yeah, I use Solaris to so I read some > Sun blogs too. :) High on opinion, low on fact. Just how was that interesting? As a measure of desperation? Martin. From justin.conover at gmail.com Sat May 20 14:46:35 2006 From: justin.conover at gmail.com (Justin Conover) Date: Sat, 20 May 2006 09:46:35 -0500 Subject: Trusted Solaris over SELinux In-Reply-To: <446F21F1.5020607@warmcat.com> References: <446F21F1.5020607@warmcat.com> Message-ID: On 5/20/06, Andy Green wrote: > > Justin Conover wrote: > > > > http://blogs.sun.com/roller/page/darren?entry=dear_ibm_please_consider_trusted > > > > I thought this was interesting. Yeah, I use Solaris to so I read some > > Sun blogs too. :) > > Get thee to somewhere far away from the NHS... > > > http://globalspecials.sun.com/servlet/ControllerServlet?Action=DisplayPage&Locale=en_US&id=ProductDetailsPage&SiteID=sunstor&productID=36446400&Env=BASE > > ...with yer $995 - $27K trusted Solaris junk. Give me Linux+selinux at > $0 per unit when I am flat on my back... or happy and healthy and paying > my taxes. > > -Andy Actually Solaris 10 is intergrating the bits of Trusted Solaris which will make it FREE. I'm not saying one is better than the other, simply wondering what the SELinux developers thought. To say that Trusted Solaris is junk seems a bit silly, if your only talking of price, ok, but if your talking the OS, than your just mis-informed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at warmcat.com Sat May 20 15:35:32 2006 From: andy at warmcat.com (Andy Green) Date: Sat, 20 May 2006 16:35:32 +0100 Subject: Trusted Solaris over SELinux In-Reply-To: References: <446F21F1.5020607@warmcat.com> Message-ID: <446F3744.3090509@warmcat.com> Justin Conover wrote: > http://globalspecials.sun.com/servlet/ControllerServlet?Action=DisplayPage&Locale=en_US&id=ProductDetailsPage&SiteID=sunstor&productID=36446400&Env=BASE > > ...with yer $995 - $27K trusted Solaris junk. Give me Linux+selinux at > $0 per unit when I am flat on my back... or happy and healthy and paying > Actually Solaris 10 is intergrating the bits of Trusted Solaris which > will make it FREE. I'm not saying one is better than the other, simply > wondering what the SELinux developers thought. > > To say that Trusted Solaris is junk seems a bit silly, if your only > talking of price, ok, but if your talking the OS, than your just > mis-informed. I'm talking of the price. I'm sure IBM take their cut for managing it, but at $995+ /cpu, $0 linux+selinux has to win out here even if Trusted Solaris poops golden eggs. The benchmark is Windows level of security. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From smooge at gmail.com Sat May 20 16:53:28 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Sat, 20 May 2006 10:53:28 -0600 Subject: Trusted Solaris over SELinux In-Reply-To: <1148134512.6512.14.camel@avenin.ebourne.me.uk> References: <1148134512.6512.14.camel@avenin.ebourne.me.uk> Message-ID: <80d7e4090605200953y53199d7bt22523686f7242fa6@mail.gmail.com> On 5/20/06, Martin Ebourne wrote: > On Sat, 2006-05-20 at 08:22 -0500, Justin Conover wrote: > > http://blogs.sun.com/roller/page/darren?entry=dear_ibm_please_consider_trusted > > > > I thought this was interesting. Yeah, I use Solaris to so I read some > > Sun blogs too. :) > > High on opinion, low on fact. > > Just how was that interesting? As a measure of desperation? > It is low on fact, but in some ways is influential as Darren is a well known security person. On a cost area it does have an item that many business managers may have to look at: Solaris is EAL4+ with various subsets already and is a known quantity. SeLinux implementations are not by themselves EAL4+.. a companies version might be in the future but not now. And if you are doing end of fiscal year purchasing.. -- Stephen J Smoogen. CSIRT/Linux System Administrator From Douglas.D.Hartman at cox.net Sat May 20 16:54:53 2006 From: Douglas.D.Hartman at cox.net (Douglas.D.Hartman) Date: Sat, 20 May 2006 12:54:53 -0400 Subject: Help unsubscribe Message-ID: <446f49db.357a4b15.61f6.ffffd709@mx.gmail.com> Help -----Original Message----- From: fedora-selinux-list-request at redhat.com To: fedora-selinux-list at redhat.com Sent: 5/20/06 12:00 PM Subject: fedora-selinux-list Digest, Vol 27, Issue 19 Send fedora-selinux-list mailing list submissions to fedora-selinux-list at redhat.com To subscribe or unsubscribe via the World Wide Web, visit https://www.redhat.com/mailman/listinfo/fedora-selinux-list or, via email, send a message with subject or body 'help' to fedora-selinux-list-request at redhat.com You can reach the person managing the list at fedora-selinux-list-owner at redhat.com When replying, please edit your Subject line so it is more specific than "Re: Contents of fedora-selinux-list digest..." Today's Topics: 1. printer AVCs.... (Tom London) 2. Re: need help for local.te (Hongwei Li) 3. Re: need help for local.te (Kayvan A. Sylvan) 4. Re: need help for local.te (Hongwei Li) 5. Re: selinux prelink avc's (dragoran) 6. Trusted Solaris over SELinux (Justin Conover) 7. Re: Trusted Solaris over SELinux (Andy Green) 8. Re: Trusted Solaris over SELinux (Martin Ebourne) 9. Re: Trusted Solaris over SELinux (Justin Conover) 10. Re: Trusted Solaris over SELinux (Andy Green) ---------------------------------------------------------------------- Message: 1 Date: Fri, 19 May 2006 09:02:35 -0700 From: "Tom London" Subject: printer AVCs.... To: "Fedora SELinux support list for users & developers." Message-ID: <4c4ba1530605190902q5c981798m31d36366654f159 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Running latest Rawhide, targeted/enforcing. I get the following when 'deactivating/activating' a USB printer (and printing fails): type=AVC msg=audit(1148052935.119:30): avc: denied { create } for pid=1902 comm="python" scontext=system_u:system_r:hplip_t:s0 tcontext=system_u:system_r:hplip_t:s0 tclass=netlink_route_socket type=SYSCALL msg=audit(1148052935.119:30): arch=40000003 syscall=102 success=no exit=-13 a0=1 a1=bffa4878 a2=49ebaff4 a3=bffa4e69 items=0 pid=1902 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="python" exe="/usr/bin/python" subj=system_u:system_r:hplip_t:s0 type=SOCKETCALL msg=audit(1148052935.119:30): nargs=3 a0=10 a1=3 a2=0 type=USER_AVC msg=audit(1148053114.333:32): user pid=1735 uid=81 auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0 msg='avc: denied { send_msg } for msgtype=signal interface=com.redhat.PrinterSpooler member=JobQueuedLocal dest=org.freedesktop.DBus spid=1913 tpid=2748 scontext=system_u:system_r:cupsd_t:SystemLow-SystemHigh tcontext=user_u:system_r:unconfined_execmem_t tclass=dbus : exe="?" (sauid=81, hostname=?, addr=?, terminal=?)' The following messages were in /var/log/messages: May 19 08:35:33 localhost dbus: Can't send to audit system: USER_AVC avc: denied { send_msg } for msgtype=signal interface=com.redhat.PrinterSpooler member=JobQueuedLocal dest=org.freedesktop.DBus spid=1913 tpid=2748 scontext=system_u:system_r:cupsd_t:SystemLow-SystemHigh tcontext=user_u:system_r:unconfined_execmem_t tclass=dbus : exe="?" (sauid=81, hostname=?, addr=?, terminal=?) May 19 08:35:33 localhost dbus: Can't send to audit system: USER_AVC avc: denied { send_msg } for msgtype=signal interface=com.redhat.PrinterSpooler member=QueueChanged dest=org.freedesktop.DBus spid=1913 tpid=2748 scontext=system_u:system_r:cupsd_t:SystemLow-SystemHigh tcontext=user_u:system_r:unconfined_execmem_t tclass=dbus : exe="?" (sauid=81, hostname=?, addr=?, terminal=?) May 19 08:35:33 localhost dbus: Can't send to audit system: USER_AVC avc: denied { send_msg } for msgtype=signal interface=com.redhat.PrinterSpooler member=JobStartedLocal dest=org.freedesktop.DBus spid=1913 tpid=2748 scontext=system_u:system_r:cupsd_t:SystemLow-SystemHigh tcontext=user_u:system_r:unconfined_execmem_t tclass=dbus : exe="?" (sauid=81, hostname=?, addr=?, terminal=?) May 19 08:35:35 localhost hpiod: invalid product id string: Broken pipe io/hpiod/device.cpp 623 May 19 08:35:35 localhost hpiod: unable to Device::Open hp:/usb/hp_LaserJet_1300?serial=00CNCB954325 io/hpiod/device.cpp 862 May 19 08:35:35 localhost hp_LaserJet_1300?serial=00CNCB954325: INFO: open device failed; will retry in 30 seconds... May 19 08:36:05 localhost hpiod: invalid product id string: Broken pipe io/hpiod/device.cpp 623 tom -- Tom London ------------------------------ Message: 2 Date: Fri, 19 May 2006 12:13:15 -0500 (CDT) From: "Hongwei Li" Subject: Re: need help for local.te To: fedora-selinux-list at redhat.com Message-ID: <1866.128.252.85.103.1148058795.squirrel at morpheus.wustl.edu> Content-Type: text/plain;charset=iso-8859-1 > On Fri, 2006-05-19 at 09:58 -0500, Hongwei Li wrote: >> Hi, >> >> I need help about local.te. My system: >> >> kernel: 2.6.16-1.2111_FC5smp >> selinux-policy-targeted: 2.2.38-1.fc5 >> audit: 1.1.5-1 >> sendmail: 8.13.6-0.FC5.1 >> squirrelmail: 1.4.6-5.fc5 >> >> When I try to create an email folder in squirrelmail, I got Error. So, I >> run >> the following to create my local.te and add my module. Here are what I run >> and get: >> >> # audit2allow -M local < /var/log/audit/audit.log >> Generating type enforcment file: local.te >> Compiling policy >> checkmodule -M -m -o local.mod local.te >> semodule_package -o local.pp -m local.mod >> >> ******************** IMPORTANT *********************** >> >> In order to load this newly created policy package into the kernel, >> you are required to execute >> >> semodule -i local.pp >> >> # ls -l >> total 40 >> -rw-r--r-- 1 root root 2448 May 19 09:46 local.mod >> -rw-r--r-- 1 root root 2464 May 19 09:46 local.pp >> -rw-r--r-- 1 root root 733 May 19 09:46 local.te >> >> # semodule -i local.pp >> libsepol.check_assertion_helper: assertion on line 0 violated by allow >> httpd_t >> shadow_t:file { read }; >> libsepol.check_assertions: 1 assertion violations occured >> libsemanage.semanage_expand_sandbox: Expand module failed >> semodule: Failed! >> >> How to solve the problem? >> >> Thanks! > > This means that your local.te file includes a rule that allows httpd to > read your /etc/shadow file, and this violates an assertion in the base > policy. Review your local.te file, prune entries that are not > legitimate, and rebuild the .mod and .pp files, e.g. > # vi local.te # edit out bogus entries or replace them with dontaudit rules > # checkmodule -m -M -o local.mod local.te > # semodule_package -o local.pp -m local.mod > # semodule -i local.pp > > -- > Stephen Smalley > National Security Agency The problem is I need to re-do for local.te from time to time, and whenver I run (after rebooting) # audit2allow -M local < /var/log/audit/audit.log the line allow httpd_t shadow_t:file { getattr read write }; is automatically added to local.te -- this time, it added more, not just read. I believe that this is because I need to run change_password plugin in squirrelmail. It is not a problem in fc4 selinux -- I run audit2allow to add entry into local.te and run make load, then everything is working. But, in fc5, it is a problem. If I remove that line, then whenever I run the above command, it is automatically added. How to fix the problem? Thanks! Hongwei ------------------------------ Message: 3 Date: Fri, 19 May 2006 18:30:37 -0700 From: "Kayvan A. Sylvan" Subject: Re: need help for local.te To: Hongwei Li Cc: fedora-selinux-list at redhat.com Message-ID: <20060520013037.GD2422 at satyr.sylvan.com> Content-Type: text/plain; charset=us-ascii On Fri, May 19, 2006 at 12:13:15PM -0500, Hongwei Li wrote: > > The problem is I need to re-do for local.te from time to time, and whenver I > run (after rebooting) > # audit2allow -M local < /var/log/audit/audit.log > the line > > allow httpd_t shadow_t:file { getattr read write }; > > is automatically added to local.te -- [...] > How to fix the problem? How about something like this? audit2allow -l -i /var/log/audit/audit.log | grep -v shadow >> local.te -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan, | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | my beautiful Queen. | Robin Gregory (2/28/92) ------------------------------ Message: 4 Date: Fri, 19 May 2006 22:16:44 -0500 (CDT) From: "Hongwei Li" Subject: Re: need help for local.te To: fedora-selinux-list at redhat.com Message-ID: <1808.70.230.152.93.1148095004.squirrel at morpheus.wustl.edu> Content-Type: text/plain;charset=iso-8859-1 > On Fri, May 19, 2006 at 12:13:15PM -0500, Hongwei Li wrote: >> >> The problem is I need to re-do for local.te from time to time, and whenver I >> run (after rebooting) >> # audit2allow -M local < /var/log/audit/audit.log >> the line >> >> allow httpd_t shadow_t:file { getattr read write }; >> >> is automatically added to local.te -- [...] >> How to fix the problem? > > How about something like this? > > audit2allow -l -i /var/log/audit/audit.log | grep -v shadow >> local.te > > -- > Kayvan A. Sylvan | Proud husband of | Father to my kids: > Sylvan Associates, Inc. | Laura Isabella Sylvan, | Katherine Yelena (8/8/89) I did and got: # audit2allow -l -i /var/log/audit/audit.log | grep -v shadow >> local.te # checkmodule -M -m -o local.mod local.te checkmodule: loading policy configuration from local.te (unknown source)::ERROR 'unknown type dovecot_auth_t' at token ';' on line 33: allow procmail_t tmp_t:dir { search write }; allow dovecot_auth_t initrc_var_run_t:file { read write }; checkmodule: error(s) encountered while parsing configuration I manually edit local.te to add a line type dovecot_auth_t; and run it again, then got # checkmodule -M -m -o local.mod local.te checkmodule: loading policy configuration from local.te (unknown source)::ERROR 'unknown type initrc_var_run_t' at token ';' on line 34: allow procmail_t tmp_t:dir { search write }; allow dovecot_auth_t initrc_var_run_t:file { read write }; checkmodule: error(s) encountered while parsing configuration The line 34 is: allow dovecot_auth_t initrc_var_run_t:file { read write }; What to do next? Thanks! Hongwei ------------------------------ Message: 5 Date: Sat, 20 May 2006 13:18:35 +0200 From: dragoran Subject: Re: selinux prelink avc's To: dragoran Cc: fedora-selinux-list at redhat.com Message-ID: <446EFB0B.8030508 at feuerpokemon.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed dragoran wrote: > audit(1147793154.831:353): avc: denied { execute_no_trans } for > pid=5195 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 > scontext=system_u:system_r:prelink_t:s0 > tcontext=system_u:object_r:lib_t:s0 tclass=file > audit(1147793154.831:354): avc: denied { execute_no_trans } for > pid=5196 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 > scontext=system_u:system_r:prelink_t:s0 > tcontext=system_u:object_r:lib_t:s0 tclass=file > audit(1147793155.019:355): avc: denied { execute_no_trans } for > pid=5197 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 > scontext=system_u:system_r:prelink_t:s0 > tcontext=system_u:object_r:lib_t:s0 tclass=file > audit(1147793155.447:356): avc: denied { execute_no_trans } for > pid=5198 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 > scontext=system_u:system_r:prelink_t:s0 > tcontext=system_u:object_r:lib_t:s0 tclass=file > audit(1147793156.255:357): avc: denied { execute_no_trans } for > pid=5199 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 > scontext=system_u:system_r:prelink_t:s0 > tcontext=system_u:object_r:lib_t:s0 tclass=file > I am using FC5 with selinux-policy-targeted-2.2.36-2.fc5 > whats gonig on? is a file misslabeled or is this a policy bug? > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > hello? any solution for this problem? ------------------------------ Message: 6 Date: Sat, 20 May 2006 08:22:57 -0500 From: "Justin Conover" Subject: Trusted Solaris over SELinux To: "Fedora SELinux support list for users & developers." Message-ID: Content-Type: text/plain; charset="iso-8859-1" http://blogs.sun.com/roller/page/darren?entry=dear_ibm_please_consider_trusted I thought this was interesting. Yeah, I use Solaris to so I read some Sun blogs too. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www.redhat.com/archives/fedora-selinux-list/attachments/20060520/947ff5bd/attachment.html ------------------------------ Message: 7 Date: Sat, 20 May 2006 15:04:33 +0100 From: Andy Green Subject: Re: Trusted Solaris over SELinux To: "Fedora SELinux support list for users & developers." Message-ID: <446F21F1.5020607 at warmcat.com> Content-Type: text/plain; charset="iso-8859-1" Justin Conover wrote: > http://blogs.sun.com/roller/page/darren?entry=dear_ibm_please_consider_trusted > > I thought this was interesting. Yeah, I use Solaris to so I read some > Sun blogs too. :) Get thee to somewhere far away from the NHS... http://globalspecials.sun.com/servlet/ControllerServlet?Action=DisplayPage&Locale=en_US&id=ProductDetailsPage&SiteID=sunstor&productID=36446400&Env=BASE ...with yer $995 - $27K trusted Solaris junk. Give me Linux+selinux at $0 per unit when I am flat on my back... or happy and healthy and paying my taxes. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature Url : https://www.redhat.com/archives/fedora-selinux-list/attachments/20060520/1efab05f/smime.bin ------------------------------ Message: 8 Date: Sat, 20 May 2006 15:15:12 +0100 From: Martin Ebourne Subject: Re: Trusted Solaris over SELinux To: fedora-selinux-list at redhat.com Message-ID: <1148134512.6512.14.camel at avenin.ebourne.me.uk> Content-Type: text/plain On Sat, 2006-05-20 at 08:22 -0500, Justin Conover wrote: > http://blogs.sun.com/roller/page/darren?entry=dear_ibm_please_consider_trusted > > I thought this was interesting. Yeah, I use Solaris to so I read some > Sun blogs too. :) High on opinion, low on fact. Just how was that interesting? As a measure of desperation? Martin. ------------------------------ Message: 9 Date: Sat, 20 May 2006 09:46:35 -0500 From: "Justin Conover" Subject: Re: Trusted Solaris over SELinux To: "Andy Green" Cc: "Fedora SELinux support list for users & developers." Message-ID: Content-Type: text/plain; charset="iso-8859-1" On 5/20/06, Andy Green wrote: > > Justin Conover wrote: > > > > http://blogs.sun.com/roller/page/darren?entry=dear_ibm_please_consider_trusted > > > > I thought this was interesting. Yeah, I use Solaris to so I read some > > Sun blogs too. :) > > Get thee to somewhere far away from the NHS... > > > http://globalspecials.sun.com/servlet/ControllerServlet?Action=DisplayPage&Locale=en_US&id=ProductDetailsPage&SiteID=sunstor&productID=36446400&Env=BASE > > ...with yer $995 - $27K trusted Solaris junk. Give me Linux+selinux at > $0 per unit when I am flat on my back... or happy and healthy and paying > my taxes. > > -Andy Actually Solaris 10 is intergrating the bits of Trusted Solaris which will make it FREE. I'm not saying one is better than the other, simply wondering what the SELinux developers thought. To say that Trusted Solaris is junk seems a bit silly, if your only talking of price, ok, but if your talking the OS, than your just mis-informed. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www.redhat.com/archives/fedora-selinux-list/attachments/20060520/8407fb7b/attachment.html ------------------------------ Message: 10 Date: Sat, 20 May 2006 16:35:32 +0100 From: Andy Green Subject: Re: Trusted Solaris over SELinux To: Justin Conover Cc: "Fedora SELinux support list for users & developers." Message-ID: <446F3744.3090509 at warmcat.com> Content-Type: text/plain; charset="iso-8859-1" Justin Conover wrote: > http://globalspecials.sun.com/servlet/ControllerServlet?Action=DisplayPage&Locale=en_US&id=ProductDetailsPage&SiteID=sunstor&productID=36446400&Env=BASE > > ...with yer $995 - $27K trusted Solaris junk. Give me Linux+selinux at > $0 per unit when I am flat on my back... or happy and healthy and paying > Actually Solaris 10 is intergrating the bits of Trusted Solaris which > will make it FREE. I'm not saying one is better than the other, simply > wondering what the SELinux developers thought. > > To say that Trusted Solaris is junk seems a bit silly, if your only > talking of price, ok, but if your talking the OS, than your just > mis-informed. I'm talking of the price. I'm sure IBM take their cut for managing it, but at $995+ /cpu, $0 linux+selinux has to win out here even if Trusted Solaris poops golden eggs. The benchmark is Windows level of security. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature Url : https://www.redhat.com/archives/fedora-selinux-list/attachments/20060520/0dfd33b5/smime.bin ------------------------------ -- fedora-selinux-list mailing list fedora-selinux-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list End of fedora-selinux-list Digest, Vol 27, Issue 19 *************************************************** From Douglas.D.Hartman at cox.net Sat May 20 17:21:09 2006 From: Douglas.D.Hartman at cox.net (Douglas.D.Hartman) Date: Sat, 20 May 2006 13:21:09 -0400 Subject: unsubscribe In-Reply-To: <20060520160012.C2CEA734BA@hormel.redhat.com> Message-ID: <000a01c67c31$c9c54bf0$6a01a8c0@venus> unsubscribe -----Original Message----- From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux-list-bounces at redhat.com] On Behalf Of fedora-selinux-list-request at redhat.com Sent: Saturday, May 20, 2006 12:00 PM To: fedora-selinux-list at redhat.com Subject: fedora-selinux-list Digest, Vol 27, Issue 19 Send fedora-selinux-list mailing list submissions to fedora-selinux-list at redhat.com To subscribe or unsubscribe via the World Wide Web, visit https://www.redhat.com/mailman/listinfo/fedora-selinux-list or, via email, send a message with subject or body 'help' to fedora-selinux-list-request at redhat.com You can reach the person managing the list at fedora-selinux-list-owner at redhat.com When replying, please edit your Subject line so it is more specific than "Re: Contents of fedora-selinux-list digest..." Today's Topics: 1. printer AVCs.... (Tom London) 2. Re: need help for local.te (Hongwei Li) 3. Re: need help for local.te (Kayvan A. Sylvan) 4. Re: need help for local.te (Hongwei Li) 5. Re: selinux prelink avc's (dragoran) 6. Trusted Solaris over SELinux (Justin Conover) 7. Re: Trusted Solaris over SELinux (Andy Green) 8. Re: Trusted Solaris over SELinux (Martin Ebourne) 9. Re: Trusted Solaris over SELinux (Justin Conover) 10. Re: Trusted Solaris over SELinux (Andy Green) ---------------------------------------------------------------------- Message: 1 Date: Fri, 19 May 2006 09:02:35 -0700 From: "Tom London" Subject: printer AVCs.... To: "Fedora SELinux support list for users & developers." Message-ID: <4c4ba1530605190902q5c981798m31d36366654f159 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Running latest Rawhide, targeted/enforcing. I get the following when 'deactivating/activating' a USB printer (and printing fails): type=AVC msg=audit(1148052935.119:30): avc: denied { create } for pid=1902 comm="python" scontext=system_u:system_r:hplip_t:s0 tcontext=system_u:system_r:hplip_t:s0 tclass=netlink_route_socket type=SYSCALL msg=audit(1148052935.119:30): arch=40000003 syscall=102 success=no exit=-13 a0=1 a1=bffa4878 a2=49ebaff4 a3=bffa4e69 items=0 pid=1902 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="python" exe="/usr/bin/python" subj=system_u:system_r:hplip_t:s0 type=SOCKETCALL msg=audit(1148052935.119:30): nargs=3 a0=10 a1=3 a2=0 type=USER_AVC msg=audit(1148053114.333:32): user pid=1735 uid=81 auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0 msg='avc: denied { send_msg } for msgtype=signal interface=com.redhat.PrinterSpooler member=JobQueuedLocal dest=org.freedesktop.DBus spid=1913 tpid=2748 scontext=system_u:system_r:cupsd_t:SystemLow-SystemHigh tcontext=user_u:system_r:unconfined_execmem_t tclass=dbus : exe="?" (sauid=81, hostname=?, addr=?, terminal=?)' The following messages were in /var/log/messages: May 19 08:35:33 localhost dbus: Can't send to audit system: USER_AVC avc: denied { send_msg } for msgtype=signal interface=com.redhat.PrinterSpooler member=JobQueuedLocal dest=org.freedesktop.DBus spid=1913 tpid=2748 scontext=system_u:system_r:cupsd_t:SystemLow-SystemHigh tcontext=user_u:system_r:unconfined_execmem_t tclass=dbus : exe="?" (sauid=81, hostname=?, addr=?, terminal=?) May 19 08:35:33 localhost dbus: Can't send to audit system: USER_AVC avc: denied { send_msg } for msgtype=signal interface=com.redhat.PrinterSpooler member=QueueChanged dest=org.freedesktop.DBus spid=1913 tpid=2748 scontext=system_u:system_r:cupsd_t:SystemLow-SystemHigh tcontext=user_u:system_r:unconfined_execmem_t tclass=dbus : exe="?" (sauid=81, hostname=?, addr=?, terminal=?) May 19 08:35:33 localhost dbus: Can't send to audit system: USER_AVC avc: denied { send_msg } for msgtype=signal interface=com.redhat.PrinterSpooler member=JobStartedLocal dest=org.freedesktop.DBus spid=1913 tpid=2748 scontext=system_u:system_r:cupsd_t:SystemLow-SystemHigh tcontext=user_u:system_r:unconfined_execmem_t tclass=dbus : exe="?" (sauid=81, hostname=?, addr=?, terminal=?) May 19 08:35:35 localhost hpiod: invalid product id string: Broken pipe io/hpiod/device.cpp 623 May 19 08:35:35 localhost hpiod: unable to Device::Open hp:/usb/hp_LaserJet_1300?serial=00CNCB954325 io/hpiod/device.cpp 862 May 19 08:35:35 localhost hp_LaserJet_1300?serial=00CNCB954325: INFO: open device failed; will retry in 30 seconds... May 19 08:36:05 localhost hpiod: invalid product id string: Broken pipe io/hpiod/device.cpp 623 tom -- Tom London ------------------------------ Message: 2 Date: Fri, 19 May 2006 12:13:15 -0500 (CDT) From: "Hongwei Li" Subject: Re: need help for local.te To: fedora-selinux-list at redhat.com Message-ID: <1866.128.252.85.103.1148058795.squirrel at morpheus.wustl.edu> Content-Type: text/plain;charset=iso-8859-1 > On Fri, 2006-05-19 at 09:58 -0500, Hongwei Li wrote: >> Hi, >> >> I need help about local.te. My system: >> >> kernel: 2.6.16-1.2111_FC5smp >> selinux-policy-targeted: 2.2.38-1.fc5 >> audit: 1.1.5-1 >> sendmail: 8.13.6-0.FC5.1 >> squirrelmail: 1.4.6-5.fc5 >> >> When I try to create an email folder in squirrelmail, I got Error. So, I >> run >> the following to create my local.te and add my module. Here are what I run >> and get: >> >> # audit2allow -M local < /var/log/audit/audit.log >> Generating type enforcment file: local.te >> Compiling policy >> checkmodule -M -m -o local.mod local.te >> semodule_package -o local.pp -m local.mod >> >> ******************** IMPORTANT *********************** >> >> In order to load this newly created policy package into the kernel, >> you are required to execute >> >> semodule -i local.pp >> >> # ls -l >> total 40 >> -rw-r--r-- 1 root root 2448 May 19 09:46 local.mod >> -rw-r--r-- 1 root root 2464 May 19 09:46 local.pp >> -rw-r--r-- 1 root root 733 May 19 09:46 local.te >> >> # semodule -i local.pp >> libsepol.check_assertion_helper: assertion on line 0 violated by allow >> httpd_t >> shadow_t:file { read }; >> libsepol.check_assertions: 1 assertion violations occured >> libsemanage.semanage_expand_sandbox: Expand module failed >> semodule: Failed! >> >> How to solve the problem? >> >> Thanks! > > This means that your local.te file includes a rule that allows httpd to > read your /etc/shadow file, and this violates an assertion in the base > policy. Review your local.te file, prune entries that are not > legitimate, and rebuild the .mod and .pp files, e.g. > # vi local.te # edit out bogus entries or replace them with dontaudit rules > # checkmodule -m -M -o local.mod local.te > # semodule_package -o local.pp -m local.mod > # semodule -i local.pp > > -- > Stephen Smalley > National Security Agency The problem is I need to re-do for local.te from time to time, and whenver I run (after rebooting) # audit2allow -M local < /var/log/audit/audit.log the line allow httpd_t shadow_t:file { getattr read write }; is automatically added to local.te -- this time, it added more, not just read. I believe that this is because I need to run change_password plugin in squirrelmail. It is not a problem in fc4 selinux -- I run audit2allow to add entry into local.te and run make load, then everything is working. But, in fc5, it is a problem. If I remove that line, then whenever I run the above command, it is automatically added. How to fix the problem? Thanks! Hongwei ------------------------------ Message: 3 Date: Fri, 19 May 2006 18:30:37 -0700 From: "Kayvan A. Sylvan" Subject: Re: need help for local.te To: Hongwei Li Cc: fedora-selinux-list at redhat.com Message-ID: <20060520013037.GD2422 at satyr.sylvan.com> Content-Type: text/plain; charset=us-ascii On Fri, May 19, 2006 at 12:13:15PM -0500, Hongwei Li wrote: > > The problem is I need to re-do for local.te from time to time, and whenver I > run (after rebooting) > # audit2allow -M local < /var/log/audit/audit.log > the line > > allow httpd_t shadow_t:file { getattr read write }; > > is automatically added to local.te -- [...] > How to fix the problem? How about something like this? audit2allow -l -i /var/log/audit/audit.log | grep -v shadow >> local.te -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan, | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | my beautiful Queen. | Robin Gregory (2/28/92) ------------------------------ Message: 4 Date: Fri, 19 May 2006 22:16:44 -0500 (CDT) From: "Hongwei Li" Subject: Re: need help for local.te To: fedora-selinux-list at redhat.com Message-ID: <1808.70.230.152.93.1148095004.squirrel at morpheus.wustl.edu> Content-Type: text/plain;charset=iso-8859-1 > On Fri, May 19, 2006 at 12:13:15PM -0500, Hongwei Li wrote: >> >> The problem is I need to re-do for local.te from time to time, and whenver I >> run (after rebooting) >> # audit2allow -M local < /var/log/audit/audit.log >> the line >> >> allow httpd_t shadow_t:file { getattr read write }; >> >> is automatically added to local.te -- [...] >> How to fix the problem? > > How about something like this? > > audit2allow -l -i /var/log/audit/audit.log | grep -v shadow >> local.te > > -- > Kayvan A. Sylvan | Proud husband of | Father to my kids: > Sylvan Associates, Inc. | Laura Isabella Sylvan, | Katherine Yelena (8/8/89) I did and got: # audit2allow -l -i /var/log/audit/audit.log | grep -v shadow >> local.te # checkmodule -M -m -o local.mod local.te checkmodule: loading policy configuration from local.te (unknown source)::ERROR 'unknown type dovecot_auth_t' at token ';' on line 33: allow procmail_t tmp_t:dir { search write }; allow dovecot_auth_t initrc_var_run_t:file { read write }; checkmodule: error(s) encountered while parsing configuration I manually edit local.te to add a line type dovecot_auth_t; and run it again, then got # checkmodule -M -m -o local.mod local.te checkmodule: loading policy configuration from local.te (unknown source)::ERROR 'unknown type initrc_var_run_t' at token ';' on line 34: allow procmail_t tmp_t:dir { search write }; allow dovecot_auth_t initrc_var_run_t:file { read write }; checkmodule: error(s) encountered while parsing configuration The line 34 is: allow dovecot_auth_t initrc_var_run_t:file { read write }; What to do next? Thanks! Hongwei ------------------------------ Message: 5 Date: Sat, 20 May 2006 13:18:35 +0200 From: dragoran Subject: Re: selinux prelink avc's To: dragoran Cc: fedora-selinux-list at redhat.com Message-ID: <446EFB0B.8030508 at feuerpokemon.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed dragoran wrote: > audit(1147793154.831:353): avc: denied { execute_no_trans } for > pid=5195 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 > scontext=system_u:system_r:prelink_t:s0 > tcontext=system_u:object_r:lib_t:s0 tclass=file > audit(1147793154.831:354): avc: denied { execute_no_trans } for > pid=5196 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 > scontext=system_u:system_r:prelink_t:s0 > tcontext=system_u:object_r:lib_t:s0 tclass=file > audit(1147793155.019:355): avc: denied { execute_no_trans } for > pid=5197 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 > scontext=system_u:system_r:prelink_t:s0 > tcontext=system_u:object_r:lib_t:s0 tclass=file > audit(1147793155.447:356): avc: denied { execute_no_trans } for > pid=5198 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 > scontext=system_u:system_r:prelink_t:s0 > tcontext=system_u:object_r:lib_t:s0 tclass=file > audit(1147793156.255:357): avc: denied { execute_no_trans } for > pid=5199 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 > scontext=system_u:system_r:prelink_t:s0 > tcontext=system_u:object_r:lib_t:s0 tclass=file > I am using FC5 with selinux-policy-targeted-2.2.36-2.fc5 > whats gonig on? is a file misslabeled or is this a policy bug? > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > hello? any solution for this problem? ------------------------------ Message: 6 Date: Sat, 20 May 2006 08:22:57 -0500 From: "Justin Conover" Subject: Trusted Solaris over SELinux To: "Fedora SELinux support list for users & developers." Message-ID: Content-Type: text/plain; charset="iso-8859-1" http://blogs.sun.com/roller/page/darren?entry=dear_ibm_please_consider_trust ed I thought this was interesting. Yeah, I use Solaris to so I read some Sun blogs too. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www.redhat.com/archives/fedora-selinux-list/attachments/20060520/947 ff5bd/attachment.html ------------------------------ Message: 7 Date: Sat, 20 May 2006 15:04:33 +0100 From: Andy Green Subject: Re: Trusted Solaris over SELinux To: "Fedora SELinux support list for users & developers." Message-ID: <446F21F1.5020607 at warmcat.com> Content-Type: text/plain; charset="iso-8859-1" Justin Conover wrote: > http://blogs.sun.com/roller/page/darren?entry=dear_ibm_please_consider_trust ed > > I thought this was interesting. Yeah, I use Solaris to so I read some > Sun blogs too. :) Get thee to somewhere far away from the NHS... http://globalspecials.sun.com/servlet/ControllerServlet?Action=DisplayPage&L ocale=en_US&id=ProductDetailsPage&SiteID=sunstor&productID=36446400&Env=BASE ...with yer $995 - $27K trusted Solaris junk. Give me Linux+selinux at $0 per unit when I am flat on my back... or happy and healthy and paying my taxes. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature Url : https://www.redhat.com/archives/fedora-selinux-list/attachments/20060520/1ef ab05f/smime.bin ------------------------------ Message: 8 Date: Sat, 20 May 2006 15:15:12 +0100 From: Martin Ebourne Subject: Re: Trusted Solaris over SELinux To: fedora-selinux-list at redhat.com Message-ID: <1148134512.6512.14.camel at avenin.ebourne.me.uk> Content-Type: text/plain On Sat, 2006-05-20 at 08:22 -0500, Justin Conover wrote: > http://blogs.sun.com/roller/page/darren?entry=dear_ibm_please_consider_trust ed > > I thought this was interesting. Yeah, I use Solaris to so I read some > Sun blogs too. :) High on opinion, low on fact. Just how was that interesting? As a measure of desperation? Martin. ------------------------------ Message: 9 Date: Sat, 20 May 2006 09:46:35 -0500 From: "Justin Conover" Subject: Re: Trusted Solaris over SELinux To: "Andy Green" Cc: "Fedora SELinux support list for users & developers." Message-ID: Content-Type: text/plain; charset="iso-8859-1" On 5/20/06, Andy Green wrote: > > Justin Conover wrote: > > > > http://blogs.sun.com/roller/page/darren?entry=dear_ibm_please_consider_trust ed > > > > I thought this was interesting. Yeah, I use Solaris to so I read some > > Sun blogs too. :) > > Get thee to somewhere far away from the NHS... > > > http://globalspecials.sun.com/servlet/ControllerServlet?Action=DisplayPage&L ocale=en_US&id=ProductDetailsPage&SiteID=sunstor&productID=36446400&Env=BASE > > ...with yer $995 - $27K trusted Solaris junk. Give me Linux+selinux at > $0 per unit when I am flat on my back... or happy and healthy and paying > my taxes. > > -Andy Actually Solaris 10 is intergrating the bits of Trusted Solaris which will make it FREE. I'm not saying one is better than the other, simply wondering what the SELinux developers thought. To say that Trusted Solaris is junk seems a bit silly, if your only talking of price, ok, but if your talking the OS, than your just mis-informed. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www.redhat.com/archives/fedora-selinux-list/attachments/20060520/840 7fb7b/attachment.html ------------------------------ Message: 10 Date: Sat, 20 May 2006 16:35:32 +0100 From: Andy Green Subject: Re: Trusted Solaris over SELinux To: Justin Conover Cc: "Fedora SELinux support list for users & developers." Message-ID: <446F3744.3090509 at warmcat.com> Content-Type: text/plain; charset="iso-8859-1" Justin Conover wrote: > http://globalspecials.sun.com/servlet/ControllerServlet?Action=DisplayPage&L ocale=en_US&id=ProductDetailsPage&SiteID=sunstor&productID=36446400&Env=BASE > > ...with yer $995 - $27K trusted Solaris junk. Give me Linux+selinux at > $0 per unit when I am flat on my back... or happy and healthy and paying > Actually Solaris 10 is intergrating the bits of Trusted Solaris which > will make it FREE. I'm not saying one is better than the other, simply > wondering what the SELinux developers thought. > > To say that Trusted Solaris is junk seems a bit silly, if your only > talking of price, ok, but if your talking the OS, than your just > mis-informed. I'm talking of the price. I'm sure IBM take their cut for managing it, but at $995+ /cpu, $0 linux+selinux has to win out here even if Trusted Solaris poops golden eggs. The benchmark is Windows level of security. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature Url : https://www.redhat.com/archives/fedora-selinux-list/attachments/20060520/0df d33b5/smime.bin ------------------------------ -- fedora-selinux-list mailing list fedora-selinux-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list End of fedora-selinux-list Digest, Vol 27, Issue 19 *************************************************** From jaaksimm at firm.ee Sat May 20 18:54:21 2006 From: jaaksimm at firm.ee (Jaak Simm) Date: Sat, 20 May 2006 21:54:21 +0300 Subject: denied execheap, for httpd with zend optimizer (fc5) Message-ID: <446F65DD.3070600@firm.ee> Hi all, I'm installing Zend Optimizer 3.0 for httpd in FC5. After giving correct security context with chcon and removing execstack requirement from its .so files I'm still stuck with "denied {execheap}" error in the /var/log/messages, when the httpd starts: May 20 21:33:26 web2 kernel: audit(1148150006.772:751): avc: denied { execheap } for pid=2584 comm="httpd" scontext=root:system_r:httpd_t:s0 tcontext=root:system_r:httpd_t:s0 tclass=process I have enabled allow_execheap: # getsebool allow_execheap allow_execheap --> on Also restarted the computer, but "denied {execheap}" message is present and Zend Optimizer does not work. Any comments and hints from selinux gurus, besides disabling selinux? Thanks, Jaak From jaaksimm at firm.ee Sat May 20 20:10:12 2006 From: jaaksimm at firm.ee (Jaak Simm) Date: Sat, 20 May 2006 23:10:12 +0300 Subject: denied execheap, for httpd with zend optimizer (fc5) In-Reply-To: <446F65DD.3070600@firm.ee> References: <446F65DD.3070600@firm.ee> Message-ID: <446F77A4.2000908@firm.ee> One additional comment. The command line version of php works with zend optimizer, no selinux troubles there. Only httpd with php and zend optimizer creates the execheap problem. The context of Zend Optimizer's .so files is: system_u:object_r:httpd_modules_t Is execheap allowed in some contexts and disabled in others? Regards, Jaak Jaak Simm wrote: > Hi all, > > I'm installing Zend Optimizer 3.0 for httpd in FC5. After giving > correct security context with chcon and removing execstack requirement > from its .so files I'm still stuck with "denied {execheap}" error in > the /var/log/messages, when the httpd starts: > May 20 21:33:26 web2 kernel: audit(1148150006.772:751): avc: denied > { execheap } for pid=2584 comm="httpd" > scontext=root:system_r:httpd_t:s0 tcontext=root:system_r:httpd_t:s0 > tclass=process > > I have enabled allow_execheap: > # getsebool allow_execheap > allow_execheap --> on > > Also restarted the computer, but "denied {execheap}" message is > present and Zend Optimizer does not work. > > Any comments and hints from selinux gurus, besides disabling selinux? > > Thanks, > Jaak > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From i.pilcher at comcast.net Sat May 20 21:33:49 2006 From: i.pilcher at comcast.net (Ian Pilcher) Date: Sat, 20 May 2006 16:33:49 -0500 Subject: SELinux/nss_ldap tracking bug Message-ID: For anyone who's interested, I have created a tracking bug for SELinux/ nss_ldap interactions. Thus far, I've entered subordinate bugs for the dbus-daemon (messagebus), ntpd, and xfs. You can find the bug at: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192555 -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From kmahaindra at axalto.com Sun May 21 04:01:28 2006 From: kmahaindra at axalto.com (Ketut Mahaindra) Date: Sun, 21 May 2006 12:01:28 +0800 Subject: need help for local.te In-Reply-To: <1866.128.252.85.103.1148058795.squirrel@morpheus.wustl.edu> Message-ID: <012e01c67c8b$3cc6aeb0$9c4d1bac@axalto.com> Hello, Everytime I need to make a local.te I always localized (read: make new file, and extract the msg) the corresponding AVC denied messages to another log file to be sure that I will get from audit2allow only those needed policies related to the localized AVC denied message and not from the whole audit.log file. You might try to use that practice. -- Best regards, Ketut Mahaindra (Ito) "The race for perfection has no finish line" -----Original Message----- From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux-list-bounces at redhat.com] On Behalf Of Hongwei Li Sent: Saturday, May 20, 2006 1:13 AM To: fedora-selinux-list at redhat.com Subject: Re: need help for local.te > This means that your local.te file includes a rule that allows httpd to > read your /etc/shadow file, and this violates an assertion in the base > policy. Review your local.te file, prune entries that are not > legitimate, and rebuild the .mod and .pp files, e.g. > # vi local.te # edit out bogus entries or replace them with dontaudit rules > # checkmodule -m -M -o local.mod local.te > # semodule_package -o local.pp -m local.mod > # semodule -i local.pp > > -- > Stephen Smalley > National Security Agency The problem is I need to re-do for local.te from time to time, and whenver I run (after rebooting) # audit2allow -M local < /var/log/audit/audit.log the line allow httpd_t shadow_t:file { getattr read write }; is automatically added to local.te -- this time, it added more, not just read. I believe that this is because I need to run change_password plugin in squirrelmail. It is not a problem in fc4 selinux -- I run audit2allow to add entry into local.te and run make load, then everything is working. But, in fc5, it is a problem. If I remove that line, then whenever I run the above command, it is automatically added. How to fix the problem? Thanks! Hongwei -- fedora-selinux-list mailing list fedora-selinux-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list From paul at city-fan.org Sun May 21 12:26:10 2006 From: paul at city-fan.org (Paul Howarth) Date: Sun, 21 May 2006 13:26:10 +0100 Subject: SELinux Module Packaging in FC5 In-Reply-To: <1148040183.25168.22.camel@moss-spartans.epoch.ncsc.mil> References: <44169B09.3050508@city-fan.org> <1142341123.3713.36.camel@moss-spartans.epoch.ncsc.mil> <4469DCF1.2080406@city-fan.org> <80d7e4090605160834r1efc0d6ata7ee23d9ea67d6f9@mail.gmail.com> <4469F629.4010803@city-fan.org> <1147797025.30789.180.camel@moss-spartans.epoch.ncsc.mil> <4469FEEE.5090403@city-fan.org> <1147798738.30789.200.camel@moss-spartans.epoch.ncsc.mil> <446A0783.1010503@city-fan.org> <446C6B16.4060709@city-fan.org> <1148040183.25168.22.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1148214371.7586.38.camel@laurel.intra.city-fan.org> On Fri, 2006-05-19 at 08:03 -0400, Stephen Smalley wrote: > On Thu, 2006-05-18 at 13:39 +0100, Paul Howarth wrote: > > Paul Howarth wrote: > > > Stephen Smalley wrote: > > >> On Tue, 2006-05-16 at 17:33 +0100, Paul Howarth wrote: > > >>> It contains a policy module, but the module only includes file contexts. > > >> > > >> Clarification: it is a policy package (.pp), but the policy package > > >> only includes file contexts. The module itself is just the .mod file > > >> created by checkmodule; it never includes file contexts. > > > > > > Ah, right, thanks for the clarification. > > > > > >> If this is going to be common, then semodule_package and libsemanage > > >> need to allow for policy packages that have no policy module. > > > > Is the absence of a policy module the actual cause of this error? If so, > > would having a "dummy" policy module that was effectively a no-op (e.g. > > by including an allow rule that was already in the base policy) be a > > usable workaround? > > No, per Chad (via private email), the problem you encountered was > actually caused by an unintended side effect of the helpful > policy_module() macro in refpolicy. Since that macro expands to include > require statements for all kernel classes and permissions (so that the > policy writer doesn't have to manually specify them for each kernel > class and permission he uses), it unfortunately can pick up requires for > new classes and permissions in the refpolicy on the build system that > are not yet defined in the base policy on the target system (in your > case, due to not having fully updated the target system). There are > some changes in progress that should help with that problem. A possible workaround for that might be for a package to conflict with selinux-policy versions older than the one it was built against. Is there a convenient way of finding the selinux-policy version short of doing an rpm query? > > Should this be bugzilla-ed? > > I suppose there are two separate issues here: > - Avoiding unnecessary dependencies in policy modules on the build > system's refpolicy (of which this is only one instance). There is > already more general effort in progress to introduce real interfaces > into the language and module format so that modules can be truly linked > against the interfaces of the base policy on the target system. > - Cleanly supporting policy packages that do not include a binary policy > module in the tools (e.g. semodule_package) and libraries (e.g. > libsemanage, libsepol), so that they can be used to ship just file > contexts or other components. I don't know of any work in progress yet > on that issue, so it may make sense to bugzilla it, although it is > really an upstream issue, and there isn't presently an upstream bugzilla > for selinux (just the mailing list). OK I'll bugzilla it, but which component should I use? Paul. From paul at city-fan.org Sun May 21 12:36:27 2006 From: paul at city-fan.org (Paul Howarth) Date: Sun, 21 May 2006 13:36:27 +0100 Subject: SELinux Module Packaging in FC5 In-Reply-To: <1148044323.25168.81.camel@moss-spartans.epoch.ncsc.mil> References: <44169B09.3050508@city-fan.org> <1142341123.3713.36.camel@moss-spartans.epoch.ncsc.mil> <4469DCF1.2080406@city-fan.org> <80d7e4090605160834r1efc0d6ata7ee23d9ea67d6f9@mail.gmail.com> <4469F629.4010803@city-fan.org> <1147797025.30789.180.camel@moss-spartans.epoch.ncsc.mil> <4469FEEE.5090403@city-fan.org> <1147798738.30789.200.camel@moss-spartans.epoch.ncsc.mil> <446A0783.1010503@city-fan.org> <446C6B16.4060709@city-fan.org> <446C740E.4090706@city-fan.org> <1148044323.25168.81.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1148214987.7586.50.camel@laurel.intra.city-fan.org> On Fri, 2006-05-19 at 09:12 -0400, Stephen Smalley wrote: > On Thu, 2006-05-18 at 14:18 +0100, Paul Howarth wrote: > > Another query regarding policy module packages in RPMs: > > > > Supposing a package is installed when the system has SELinux disabled. > > > > What would happen if semodule was called to install a policy module? > > > > If the result is that nothing happens (or semodule bombs out with an > > error of some sort), what would then happen if the system subsequently > > had SELinux enabled and the system was relabelled? Would the package > > containing the policy module have to be reinstalled? > > > > I'd try it myself but I can't bring myself to disable SELinux on any of > > my boxes and go through the whole relabelling process. > > If policy is installed on the system, then semodule (actually > libsemanage) will install the module and rebuild the generated files, > but will not try to load policy into the kernel since SELinux is > disabled. Then, if you enable SELinux, the module will already be > included in the policy. > > If policy is not installed on the system, then semodule will abort with > an error like this: > semodule: SELinux policy is not managed or store cannot be accessed. > > Note also that one should generally use semodule -s as in > the selinux-policy .spec file to indicate which kind of policy your > module is built for (targeted, strict, mls). Then, if the system is > running a different kind of policy, semodule will know to install the > module to the proper location (not the active policy) and to not try to > load it. OK, this leads on to some other issues: Ideally, I'd like to be able to package up policy modules built for each of the base policies that are shipped in Core. The Makefile currently defaults to targeted policy - how should modules for other base policies be built, particularly in the mock environment used for the Extras build system, where SELinux is disabled. Following on from that, at package install-time it would be necessary to identify which base policy/policies is/are installed, and install the appropriate modules. Is there a convenient way of finding out which policy/policies are installed without doing an rpm query? There's also the awkward problem of what to do if a base policy is installed at a later date than a package containing a policy module. For instance, someone might decide to try out the strict policy. Any package containing policy modules for the strict policy would already have skipped its chance to install the strict module during its %post. This could be addressed using triggers but the complexity that would involve for handling all possible policies would make it a struggle to get it past a package review :-) Perhaps an alternative would be for packages to have some way of registering the modules they have available for each base policy, so that they were automatically picked up if that base policy was installed? Paul. From tmz at pobox.com Sun May 21 20:58:17 2006 From: tmz at pobox.com (Todd Zullinger) Date: Sun, 21 May 2006 16:58:17 -0400 Subject: Mailman/Postfix execute_no_trans denial Message-ID: <20060521205817.GC18213@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I installed an FC5 system a few days ago and was testing mailman with postfix. I've run into a problem when trying to send messages to any I've created. SELinux is running in Enforcing mode. Setting it to permissive allows list posts to go through. Here's the avc denial I get: audit(1148242843.454:41): avc: denied { execute_no_trans } for pid=27763 comm="local" name="mailman" dev=sda2 ino=163878 scontext=user_u:system_r:postfix_local_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file I read a thread from a month or so back where another fellow was using mailman and postfix, but he was using the postfix-to-mailman-2.1.py script for integration. I am using mailman's builtin postfix integration by specifying MTA='Postfix' in /etc/mailman/mm_cfg.py. This lets mailman create the proper list aliases automatically on list creation. In /etc/postfix/main.cf, hash:/etc/mailman/aliases is added to the alias_maps parameter. I'm not very familiar with selinux, so I'm unsure whether this is a problem requiring a change in file context(s), a policy tweak, or both. Could someone tap me in the right direction with the cluestick? $ rpm -qa mailman postfix selinux-policy\* selinux-policy-targeted-2.2.38-1.fc5 selinux-policy-2.2.38-1.fc5 postfix-2.2.8-1.2 mailman-2.1.7-1.2 Thanks, - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== Honesty is the best policy, but insanity is a better defense. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iGwEARECAC0FAkRw1GkmGGh0dHA6Ly93d3cucG9ib3guY29tL350bXovcGdwL3Rt ei5hc2MACgkQuv+09NZUB1qDmgCY9oSS1Uj/9dj6yMEftzCljdLZOACfcX1SDI5E dhxBfD88LYbgA4vEX2A= =/+Fu -----END PGP SIGNATURE----- From shin216 at xf7.so-net.ne.jp Sun May 21 23:16:28 2006 From: shin216 at xf7.so-net.ne.jp (Shintaro Fujiwara) Date: Mon, 22 May 2006 08:16:28 +0900 Subject: cron does not run on strict policy-2.x References: <002601c67a12$af393600$0401a8c0@test.com> Message-ID: <000d01c67d2c$a2a20d00$0401a8c0@test.com> Hello. I solved the problem rewriting cron.te and updating a module. Thanks. ----- Original Message ----- From: "Shintaro Fujiwara" To: Sent: Thursday, May 18, 2006 9:33 AM Subject: cron does not run on strict policy-2.x > Hi, > I have a sever strict-policy newest package, > but my cron fails. > When I see /var/log/cron, > ENTRYPOINT FAILED > line I could get. > > /etc/crontab has > system_u:object_r:system_cron_spool_t. > > I have two FC5 strict-policy server and > both fails on cron,although anacron runs > faily fine. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From paul at city-fan.org Mon May 22 07:40:01 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 22 May 2006 08:40:01 +0100 Subject: Mailman/Postfix execute_no_trans denial In-Reply-To: <20060521205817.GC18213@psilocybe.teonanacatl.org> References: <20060521205817.GC18213@psilocybe.teonanacatl.org> Message-ID: <1148283602.7586.57.camel@laurel.intra.city-fan.org> On Sun, 2006-05-21 at 16:58 -0400, Todd Zullinger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I installed an FC5 system a few days ago and was testing mailman with > postfix. I've run into a problem when trying to send messages to any > I've created. SELinux is running in Enforcing mode. Setting it to > permissive allows list posts to go through. > > Here's the avc denial I get: > > audit(1148242843.454:41): avc: denied { execute_no_trans } for pid=27763 comm="local" name="mailman" dev=sda2 ino=163878 scontext=user_u:system_r:postfix_local_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file > > I read a thread from a month or so back where another fellow was using > mailman and postfix, but he was using the postfix-to-mailman-2.1.py > script for integration. This looks similar to issues I had running scripts from procmail. I wonder if the script you're running here should be bin_t rather than lib_t? Paul. From paul at city-fan.org Mon May 22 13:19:57 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 22 May 2006 14:19:57 +0100 Subject: webalizer/cron Message-ID: <4471BA7D.60803@city-fan.org> What's happening here? type=AVC msg=audit(1148266965.669:78582): avc: denied { create } for pid=17006 comm="webalizer" scontext=user_u:system_r:webalizer_t:s0 tcontext=user_u:system_r:webalizer_t:s0 tclass=netlink_route_socket type=SYSCALL msg=audit(1148266965.669:78582): arch=40000003 syscall=102 success=no exit=-13 a0=1 a1=bffea6b8 a2=7bdff4 a3=1 items=0 pid=17006 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="webalizer" exe="/usr/bin/webalizer" type=SOCKETCALL msg=audit(1148266965.669:78582): nargs=3 a0=10 a1=3 a2=0 I'm getting *lots* of these with every night's webalizer cron job. It doesn't seem to stop it working though. Paul. From sds at tycho.nsa.gov Mon May 22 12:53:01 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 22 May 2006 08:53:01 -0400 Subject: Trusted Solaris over SELinux In-Reply-To: References: <446F21F1.5020607@warmcat.com> Message-ID: <1148302381.24463.16.camel@moss-spartans.epoch.ncsc.mil> On Sat, 2006-05-20 at 09:46 -0500, Justin Conover wrote: > Actually Solaris 10 is intergrating the bits of Trusted Solaris which > will make it FREE. I'm not saying one is better than the other, > simply wondering what the SELinux developers thought. Not exactly. IIUC, trusted extensions for Solaris 10 are quite different from past Trusted Solaris implementations and principally rely on their zone mechanism rather than providing per-process and per-file labeling and access control. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Mon May 22 12:51:25 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 22 May 2006 08:51:25 -0400 Subject: Trusted Solaris over SELinux In-Reply-To: <80d7e4090605200953y53199d7bt22523686f7242fa6@mail.gmail.com> References: <1148134512.6512.14.camel@avenin.ebourne.me.uk> <80d7e4090605200953y53199d7bt22523686f7242fa6@mail.gmail.com> Message-ID: <1148302285.24463.13.camel@moss-spartans.epoch.ncsc.mil> On Sat, 2006-05-20 at 10:53 -0600, Stephen John Smoogen wrote: > On 5/20/06, Martin Ebourne wrote: > > On Sat, 2006-05-20 at 08:22 -0500, Justin Conover wrote: > > > http://blogs.sun.com/roller/page/darren?entry=dear_ibm_please_consider_trusted > > > > > > I thought this was interesting. Yeah, I use Solaris to so I read some > > > Sun blogs too. :) > > > > High on opinion, low on fact. > > > > Just how was that interesting? As a measure of desperation? > > > > It is low on fact, but in some ways is influential as Darren is a well > known security person. On a cost area it does have an item that many > business managers may have to look at: > > Solaris is EAL4+ with various subsets already and is a known quantity. > SeLinux implementations are not by themselves EAL4+.. a companies > version might be in the future but not now. Validated products: http://niap.nist.gov/cc-scheme/vpl/vpl_type.html#operatingsystem http://www.commoncriteriaportal.org/public/consumer/index.php?menu=4&orderindex=1&showcatagories=256 Products in evaluation: http://niap.nist.gov/cc-scheme/in_evaluation.html -- Stephen Smalley National Security Agency From paul at city-fan.org Mon May 22 16:14:47 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 22 May 2006 17:14:47 +0100 Subject: OpenLDAP PID and args files Message-ID: <4471E377.9000609@city-fan.org> FC5 has file contexts for /var/run/slapd.pid and /var/run/slapd.args # semanage fcontext -l | grep slapd /var/lib/ldap(/.*)? all files system_u:object_r:slapd_db_t:s0 /etc/ldap/slapd\.conf regular file system_u:object_r:slapd_etc_t:s0 /usr/sbin/slapd regular file system_u:object_r:slapd_exec_t:s0 /var/run/slapd\.args regular file system_u:object_r:slapd_var_run_t:s0 /var/lib/ldap/replog(/.*)? all files system_u:object_r:slapd_replog_t:s0 /var/run/slapd\.pid regular file system_u:object_r:slapd_var_run_t:s0 However, in FC5 the default slapd.conf file puts these files in /var/run/openldap, so the file contexts don't get set properly, at least not for the args file: pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args I've fixed this for now using restorecon but it would be nice for policy to be fixed. Not sure if it applies to FC4 or not. Paul. From tmz at pobox.com Mon May 22 20:54:32 2006 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 22 May 2006 16:54:32 -0400 Subject: Mailman/Postfix execute_no_trans denial In-Reply-To: <1148283602.7586.57.camel@laurel.intra.city-fan.org> References: <20060521205817.GC18213@psilocybe.teonanacatl.org> <1148283602.7586.57.camel@laurel.intra.city-fan.org> Message-ID: <20060522205432.GM10533@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Howarth wrote: > On Sun, 2006-05-21 at 16:58 -0400, Todd Zullinger wrote: [...] >> Here's the avc denial I get: >> >> audit(1148242843.454:41): avc: denied { execute_no_trans } for pid=27763 comm="local" name="mailman" dev=sda2 ino=163878 scontext=user_u:system_r:postfix_local_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file >> >> I read a thread from a month or so back where another fellow was using >> mailman and postfix, but he was using the postfix-to-mailman-2.1.py >> script for integration. > > This looks similar to issues I had running scripts from procmail. I > wonder if the script you're running here should be bin_t rather than > lib_t? I supposed it might help if I posted the error from postfix. :) May 21 15:28:35 localhost postfix/pickup[26079]: 8DBFC28076: uid=500 from= May 21 15:28:35 localhost postfix/cleanup[26290]: 8DBFC28076: message-id=<20060521192835.8DBFC28076 at localhost.localdomain> May 21 15:28:35 localhost postfix/qmgr[26080]: 8DBFC28076: from=, size=325, nrcpt=1 (queue active) May 21 15:28:35 localhost local[26399]: fatal: execvp /usr/lib/mailman/mail/mailman: Permission denied May 21 15:28:36 localhost postfix/local[26291]: 8DBFC28076: to=, orig_to=, relay=local, delay=1, status=bounced (Command died with status 1: "/usr/lib/mailman/mail/mailman post pgp-test") M Does this still seem similar to the procmail issue you were seeing Paul? I know that postfix tries to execute commands run via aliases as the user which owns the alias file and I am guessing that's what's causing the problem here. Would changing /usr/lib/mailman/mail/mailman from lib_t to bin_t negatively affect those using mailman with Sendmail as their MTA? When I get a moment I'll boot to FC5 and try changing the context to see what happens. Thanks for the response. - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== The income tax created more criminals than any other single act of government. -- Sen. Barry M. Goldwater, 1989 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iG0EARECAC0FAkRyJQgmGGh0dHA6Ly93d3cucG9ib3guY29tL350bXovcGdwL3Rt ei5hc2MACgkQuv+09NZUB1oRAwCgvTaIhXkbhs2tGOL/SB8oOYVizDAAoN72TPb6 GVSit9lb/WzfA0lmi6td =2Vuv -----END PGP SIGNATURE----- From tmz at pobox.com Tue May 23 00:17:41 2006 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 22 May 2006 20:17:41 -0400 Subject: Mailman/Postfix execute_no_trans denial In-Reply-To: <20060522205432.GM10533@psilocybe.teonanacatl.org> References: <20060521205817.GC18213@psilocybe.teonanacatl.org> <1148283602.7586.57.camel@laurel.intra.city-fan.org> <20060522205432.GM10533@psilocybe.teonanacatl.org> Message-ID: <20060523001741.GA12063@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I wrote: > When I get a moment I'll boot to FC5 and try changing the context to > see what happens. Changing the context on /usr/lib/mailman/mail/mailman from lib_t to bin_t does get things further, and on to the next set of denials. The avc messages: May 22 20:06:36 localhost kernel: audit(1148342796.414:35): avc: denied { create } for pid=9382 comm="python" scontext=user_u:system_r:postfix_local_t:s0 tcontext=user_u:system_r:postfix_local_t:s0 tclass=netlink_route_socket May 22 20:06:36 localhost kernel: audit(1148342796.578:36): avc: denied { search } for pid=9382 comm="python" name="log" dev=sda2 ino=489147 scontext=user_u:system_r:postfix_local_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=dir May 22 20:06:36 localhost kernel: audit(1148342796.582:37): avc: denied { write } for pid=9382 comm="python" name="in" dev=sda2 ino=491751 scontext=user_u:system_r:postfix_local_t:s0 tcontext=user_u:object_r:mailman_data_t:s0 tclass=dir The postfix messages: May 22 20:06:36 localhost postfix/pickup[9212]: 4CD6513687C: uid=500 from= May 22 20:06:36 localhost postfix/cleanup[9379]: 4CD6513687C: message-id=<20060523000636.GE9258 at localhost.localdomain> May 22 20:06:36 localhost postfix/qmgr[9213]: 4CD6513687C: from=, size=463, nrcpt=1 (queue active) May 22 20:06:36 localhost postfix/local[9381]: 4CD6513687C: to=, relay=local, delay=0, status=bounced (Command died with status 1: "/usr/lib/mailman/mail/mailman post pgp-test". Command output: Traceback (most recent call last): File "/usr/lib/mailman/scripts/post", line 69, in ? main() File "/usr/lib/mailman/scripts/post", line 64, in main tolist=1, _plaintext=1) File "/usr/lib/mailman/Mailman/Queue/Switchboard.py", line 126, in enqueue fp = open(tmpfile, 'w') IOError: [Errno 13] Permission denied: '/var/spool/mailman/in/1148342796.5827579+b203c4871f8a8269deaef98890980ed0bff9cedb.pck.tmp' ) May 22 20:06:36 localhost postfix/cleanup[9379]: 989B4136A2C: message-id=<20060523000636.989B4136A2C at localhost.localdomain> I'm not sure whether it's worth trying to chase every denial down this path or if there is a better fix that can be applied. - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== life, n.: A whim of several billion cells to be you for a while. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iG0EARECAC0FAkRyVKUmGGh0dHA6Ly93d3cucG9ib3guY29tL350bXovcGdwL3Rt ei5hc2MACgkQuv+09NZUB1rmngCfc27XjGsipxCQBzLedxAVxAgyz0MAn3CMcE4l 5SzqENSLqmG001dYT4id =Ts1k -----END PGP SIGNATURE----- From knute at frazmtn.com Tue May 23 00:42:16 2006 From: knute at frazmtn.com (Knute Johnson) Date: Mon, 22 May 2006 17:42:16 -0700 Subject: ftp and home directories? Message-ID: <4471F7F8.21674.A00843@knute.frazmtn.com> I'm running a stock FC5 box for a mail server and web server. I configured vsftp to use home directories so I had a place to send my files to. I used /usr/sbin/setsebool ftp_home_dir 1 so I could upload files. The next time I went to upload files it was 0 and I had to set it again. Does this get reset when new SELinux stuff is installed? Is it possible to make this permanent and if so how? Thanks, -- Knute Johnson Molon Labe... From smooge at gmail.com Tue May 23 02:13:40 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 22 May 2006 20:13:40 -0600 Subject: ftp and home directories? In-Reply-To: <4471F7F8.21674.A00843@knute.frazmtn.com> References: <4471F7F8.21674.A00843@knute.frazmtn.com> Message-ID: <80d7e4090605221913p444323f0h8b9ffac6638e03f4@mail.gmail.com> On 5/22/06, Knute Johnson wrote: > I'm running a stock FC5 box for a mail server and web server. I > configured vsftp to use home directories so I had a place to send my > files to. I used /usr/sbin/setsebool ftp_home_dir 1 so I could > upload files. The next time I went to upload files it was 0 and I > had to set it again. Does this get reset when new SELinux stuff is > installed? Is it possible to make this permanent and if so how? > You need to use the -P to set the policy permanently setsebool -P ftp_home_dir 1 > Thanks, > > -- > Knute Johnson > Molon Labe... > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- Stephen J Smoogen. CSIRT/Linux System Administrator From knute at frazmtn.com Tue May 23 04:33:41 2006 From: knute at frazmtn.com (Knute Johnson) Date: Mon, 22 May 2006 21:33:41 -0700 Subject: ftp and home directories? In-Reply-To: <80d7e4090605221913p444323f0h8b9ffac6638e03f4@mail.gmail.com> References: <4471F7F8.21674.A00843@knute.frazmtn.com> Message-ID: <44722E35.16657.173E65C@knute.frazmtn.com> >On 5/22/06, Knute Johnson wrote: >> I'm running a stock FC5 box for a mail server and web server. I >> configured vsftp to use home directories so I had a place to send my >> files to. I used /usr/sbin/setsebool ftp_home_dir 1 so I could >> upload files. The next time I went to upload files it was 0 and I >> had to set it again. Does this get reset when new SELinux stuff is >> installed? Is it possible to make this permanent and if so how? >> > >You need to use the -P to set the policy permanently > >setsebool -P ftp_home_dir 1 > Thanks very much Stephen. -- Knute Johnson Molon Labe... From paul at city-fan.org Tue May 23 07:08:56 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 23 May 2006 08:08:56 +0100 Subject: Mailman/Postfix execute_no_trans denial In-Reply-To: <20060523001741.GA12063@psilocybe.teonanacatl.org> References: <20060521205817.GC18213@psilocybe.teonanacatl.org> <1148283602.7586.57.camel@laurel.intra.city-fan.org> <20060522205432.GM10533@psilocybe.teonanacatl.org> <20060523001741.GA12063@psilocybe.teonanacatl.org> Message-ID: <1148368136.29091.21.camel@laurel.intra.city-fan.org> On Mon, 2006-05-22 at 20:17 -0400, Todd Zullinger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I wrote: > > When I get a moment I'll boot to FC5 and try changing the context to > > see what happens. > > Changing the context on /usr/lib/mailman/mail/mailman from lib_t to > bin_t does get things further, and on to the next set of denials. > > The avc messages: > > May 22 20:06:36 localhost kernel: audit(1148342796.414:35): avc: denied { create } for pid=9382 comm="python" scontext=user_u:system_r:postfix_local_t:s0 tcontext=user_u:system_r:postfix_local_t:s0 tclass=netlink_route_socket I get lots of these for webalizer run from cron, which I queried about yesterday. I don't know what this is. > May 22 20:06:36 localhost kernel: audit(1148342796.578:36): avc: denied { search } for pid=9382 comm="python" name="log" dev=sda2 ino=489147 scontext=user_u:system_r:postfix_local_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=dir Looks like mailman trying to read the log file directory. May need a policy change for this - I needed something similar for procmail. > May 22 20:06:36 localhost kernel: audit(1148342796.582:37): avc: denied { write } for pid=9382 comm="python" name="in" dev=sda2 ino=491751 scontext=user_u:system_r:postfix_local_t:s0 tcontext=user_u:object_r:mailman_data_t:s0 tclass=dir Failed trying to write new file to directory /var/spool/mailman/in. I wonder if the mailman policy was written specifically with sendmail in mind rather than postfix? > The postfix messages: > > May 22 20:06:36 localhost postfix/pickup[9212]: 4CD6513687C: uid=500 from= > May 22 20:06:36 localhost postfix/cleanup[9379]: 4CD6513687C: message-id=<20060523000636.GE9258 at localhost.localdomain> > May 22 20:06:36 localhost postfix/qmgr[9213]: 4CD6513687C: from=, size=463, nrcpt=1 (queue active) > May 22 20:06:36 localhost postfix/local[9381]: 4CD6513687C: to=, relay=local, delay=0, status=bounced (Command died with status 1: "/usr/lib/mailman/mail/mailman post pgp-test". Command output: Traceback (most recent call last): File "/usr/lib/mailman/scripts/post", line 69, in ? main() File "/usr/lib/mailman/scripts/post", line 64, in main tolist=1, _plaintext=1) File "/usr/lib/mailman/Mailman/Queue/Switchboard.py", line 126, in enqueue fp = open(tmpfile, 'w') IOError: [Errno 13] Permission denied: '/var/spool/mailman/in/1148342796.5827579+b203c4871f8a8269deaef98890980ed0bff9cedb.pck.tmp' ) > May 22 20:06:36 localhost postfix/cleanup[9379]: 989B4136A2C: message-id=<20060523000636.989B4136A2C at localhost.localdomain> > > I'm not sure whether it's worth trying to chase every denial down this > path or if there is a better fix that can be applied. I'm not sure. Running in permissive mode for a while should show up all the denials you'll come across, but they might not all need allowing, and if something has the wrong label, as appears to be the case with /usr/lib/mailman/mail/mailman, then the denials won't be useful anyway. Paul. From jaaksimm at firm.ee Tue May 23 08:13:41 2006 From: jaaksimm at firm.ee (Jaak Simm) Date: Tue, 23 May 2006 11:13:41 +0300 Subject: denied execheap, for httpd with zend optimizer (fc5) In-Reply-To: <446F77A4.2000908@firm.ee> References: <446F65DD.3070600@firm.ee> <446F77A4.2000908@firm.ee> Message-ID: <4472C435.9060308@firm.ee> Hi again, Can anyone verify that Zend Optimizer generates a execheap denial in FC5? Or is it just my problem? Zend Optimizer is needed to run binary php code, which is common for commercial php projects. Simple steps to install Zend Optimizer and verify the problem: 0. you have to have httpd and php installed (yum install httpd php) 1. Download and unpack Zend Optimizer 3 http://www.zend.com/products/zend_optimizer (requires a zend.com user, which can be created for free at the download site) 2. Run ./install in the unpacked dir of Zend Optimizer It will ask few questions, but defaults should be fine. 3. Allow execheap, give zend files correct security context, and remove their execstack requirement: setsebool allow_execheap 1 chcon -t httpd_modules_t -u system_u `find /usr/local/Zend/lib/ -name \*.so` execstack -c `find /usr/local/Zend/lib/ -name \*.so` 4. restart httpd: service httpd restart 5. check /var/log/messages (whether an avc execheap denial occured, when httpd restarted) Send an e-mail to the list or to me with your results. If it is a common problem, then I'll report a bug. Regards, Jaak Jaak Simm wrote: > One additional comment. The command line version of php works with > zend optimizer, no selinux troubles there. > Only httpd with php and zend optimizer creates the execheap problem. > > The context of Zend Optimizer's .so files is: > system_u:object_r:httpd_modules_t > > Is execheap allowed in some contexts and disabled in others? > > Regards, > Jaak > > Jaak Simm wrote: >> Hi all, >> >> I'm installing Zend Optimizer 3.0 for httpd in FC5. After giving >> correct security context with chcon and removing execstack >> requirement from its .so files I'm still stuck with "denied >> {execheap}" error in the /var/log/messages, when the httpd starts: >> May 20 21:33:26 web2 kernel: audit(1148150006.772:751): avc: denied >> { execheap } for pid=2584 comm="httpd" >> scontext=root:system_r:httpd_t:s0 tcontext=root:system_r:httpd_t:s0 >> tclass=process >> >> I have enabled allow_execheap: >> # getsebool allow_execheap >> allow_execheap --> on >> >> Also restarted the computer, but "denied {execheap}" message is >> present and Zend Optimizer does not work. >> >> Any comments and hints from selinux gurus, besides disabling selinux? >> >> Thanks, >> Jaak >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From dragoran at feuerpokemon.de Tue May 23 14:28:45 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 23 May 2006 16:28:45 +0200 Subject: selinux prelink avc's In-Reply-To: <446EFB0B.8030508@feuerpokemon.de> References: <4469F575.30609@feuerpokemon.de> <446EFB0B.8030508@feuerpokemon.de> Message-ID: <44731C1D.609@feuerpokemon.de> dragoran wrote: > dragoran wrote: >> audit(1147793154.831:353): avc: denied { execute_no_trans } for >> pid=5195 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 >> scontext=system_u:system_r:prelink_t:s0 >> tcontext=system_u:object_r:lib_t:s0 tclass=file >> audit(1147793154.831:354): avc: denied { execute_no_trans } for >> pid=5196 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 >> scontext=system_u:system_r:prelink_t:s0 >> tcontext=system_u:object_r:lib_t:s0 tclass=file >> audit(1147793155.019:355): avc: denied { execute_no_trans } for >> pid=5197 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 >> scontext=system_u:system_r:prelink_t:s0 >> tcontext=system_u:object_r:lib_t:s0 tclass=file >> audit(1147793155.447:356): avc: denied { execute_no_trans } for >> pid=5198 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 >> scontext=system_u:system_r:prelink_t:s0 >> tcontext=system_u:object_r:lib_t:s0 tclass=file >> audit(1147793156.255:357): avc: denied { execute_no_trans } for >> pid=5199 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 >> scontext=system_u:system_r:prelink_t:s0 >> tcontext=system_u:object_r:lib_t:s0 tclass=file >> I am using FC5 with selinux-policy-targeted-2.2.36-2.fc5 >> whats gonig on? is a file misslabeled or is this a policy bug? >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >> > hello? > any solution for this problem? > > it happend again... am I the only one seeing this? audit(1148393411.538:2907): avc: denied { execute_no_trans } for pid=16856 comm="prelink" name="ld-2.4.so" dev=md0 ino=8060939 scontext=system_u:system_r:prelink_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file audit(1148393411.794:2908): avc: denied { execmod } for pid=16859 comm="ld-linux.so.2" name="libGLcore.so.1.0.8762" dev=md0 ino=29797475 scontext=system_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0 tclass=file audit(1148393411.814:2909): avc: denied { execmod } for pid=16860 comm="ld-linux.so.2" name="libnvidia-tls.so.1.0.8762" dev=md0 ino=30869146 scontext=system_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0 tclass=file audit(1148393412.438:2910): avc: denied { unlink } for pid=13702 comm="prelink" name="prelink.cache" dev=md0 ino=7012828 scontext=system_u:system_r:prelink_t:s0 tcontext=user_u:object_r:etc_t:s0 tclass=file prelink seems to be completly broken and nobody seems to notice it? From paul at city-fan.org Tue May 23 14:42:38 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 23 May 2006 15:42:38 +0100 Subject: selinux prelink avc's In-Reply-To: <44731C1D.609@feuerpokemon.de> References: <4469F575.30609@feuerpokemon.de> <446EFB0B.8030508@feuerpokemon.de> <44731C1D.609@feuerpokemon.de> Message-ID: <1148395359.5228.2.camel@laurel.intra.city-fan.org> On Tue, 2006-05-23 at 16:28 +0200, dragoran wrote: > dragoran wrote: > > dragoran wrote: > >> audit(1147793154.831:353): avc: denied { execute_no_trans } for > >> pid=5195 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 > >> scontext=system_u:system_r:prelink_t:s0 > >> tcontext=system_u:object_r:lib_t:s0 tclass=file > >> audit(1147793154.831:354): avc: denied { execute_no_trans } for > >> pid=5196 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 > >> scontext=system_u:system_r:prelink_t:s0 > >> tcontext=system_u:object_r:lib_t:s0 tclass=file > >> audit(1147793155.019:355): avc: denied { execute_no_trans } for > >> pid=5197 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 > >> scontext=system_u:system_r:prelink_t:s0 > >> tcontext=system_u:object_r:lib_t:s0 tclass=file > >> audit(1147793155.447:356): avc: denied { execute_no_trans } for > >> pid=5198 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 > >> scontext=system_u:system_r:prelink_t:s0 > >> tcontext=system_u:object_r:lib_t:s0 tclass=file > >> audit(1147793156.255:357): avc: denied { execute_no_trans } for > >> pid=5199 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 > >> scontext=system_u:system_r:prelink_t:s0 > >> tcontext=system_u:object_r:lib_t:s0 tclass=file > >> I am using FC5 with selinux-policy-targeted-2.2.36-2.fc5 > >> whats gonig on? is a file misslabeled or is this a policy bug? > >> > >> -- > >> fedora-selinux-list mailing list > >> fedora-selinux-list at redhat.com > >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > >> > >> > > hello? > > any solution for this problem? > > > > > > it happend again... > am I the only one seeing this? > audit(1148393411.538:2907): avc: denied { execute_no_trans } for > pid=16856 comm="prelink" name="ld-2.4.so" dev=md0 ino=8060939 > scontext=system_u:system_r:prelink_t:s0 > tcontext=system_u:object_r:lib_t:s0 tclass=file > audit(1148393411.794:2908): avc: denied { execmod } for pid=16859 > comm="ld-linux.so.2" name="libGLcore.so.1.0.8762" dev=md0 ino=29797475 > scontext=system_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0 > tclass=file > audit(1148393411.814:2909): avc: denied { execmod } for pid=16860 > comm="ld-linux.so.2" name="libnvidia-tls.so.1.0.8762" dev=md0 > ino=30869146 scontext=system_u:system_r:prelink_t:s0 > tcontext=root:object_r:lib_t:s0 tclass=file > audit(1148393412.438:2910): avc: denied { unlink } for pid=13702 > comm="prelink" name="prelink.cache" dev=md0 ino=7012828 > scontext=system_u:system_r:prelink_t:s0 > tcontext=user_u:object_r:etc_t:s0 tclass=file > prelink seems to be completly broken and nobody seems to notice it? I'm not seeing this anywhere. Perhaps it's because /lib/ld-2.4.so is lib_t rather than ld_so_t on your system? Paul. From dragoran at feuerpokemon.de Tue May 23 15:06:52 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 23 May 2006 17:06:52 +0200 Subject: selinux prelink avc's In-Reply-To: <1148395359.5228.2.camel@laurel.intra.city-fan.org> References: <4469F575.30609@feuerpokemon.de> <446EFB0B.8030508@feuerpokemon.de> <44731C1D.609@feuerpokemon.de> <1148395359.5228.2.camel@laurel.intra.city-fan.org> Message-ID: <4473250C.4020401@feuerpokemon.de> Paul Howarth wrote: > On Tue, 2006-05-23 at 16:28 +0200, dragoran wrote: > >> dragoran wrote: >> >>> dragoran wrote: >>> >>>> audit(1147793154.831:353): avc: denied { execute_no_trans } for >>>> pid=5195 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 >>>> scontext=system_u:system_r:prelink_t:s0 >>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>> audit(1147793154.831:354): avc: denied { execute_no_trans } for >>>> pid=5196 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 >>>> scontext=system_u:system_r:prelink_t:s0 >>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>> audit(1147793155.019:355): avc: denied { execute_no_trans } for >>>> pid=5197 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 >>>> scontext=system_u:system_r:prelink_t:s0 >>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>> audit(1147793155.447:356): avc: denied { execute_no_trans } for >>>> pid=5198 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 >>>> scontext=system_u:system_r:prelink_t:s0 >>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>> audit(1147793156.255:357): avc: denied { execute_no_trans } for >>>> pid=5199 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 >>>> scontext=system_u:system_r:prelink_t:s0 >>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>> I am using FC5 with selinux-policy-targeted-2.2.36-2.fc5 >>>> whats gonig on? is a file misslabeled or is this a policy bug? >>>> >>>> -- >>>> fedora-selinux-list mailing list >>>> fedora-selinux-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>>> >>>> >>>> >>> hello? >>> any solution for this problem? >>> >>> >>> >> it happend again... >> am I the only one seeing this? >> audit(1148393411.538:2907): avc: denied { execute_no_trans } for >> pid=16856 comm="prelink" name="ld-2.4.so" dev=md0 ino=8060939 >> scontext=system_u:system_r:prelink_t:s0 >> tcontext=system_u:object_r:lib_t:s0 tclass=file >> audit(1148393411.794:2908): avc: denied { execmod } for pid=16859 >> comm="ld-linux.so.2" name="libGLcore.so.1.0.8762" dev=md0 ino=29797475 >> scontext=system_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0 >> tclass=file >> audit(1148393411.814:2909): avc: denied { execmod } for pid=16860 >> comm="ld-linux.so.2" name="libnvidia-tls.so.1.0.8762" dev=md0 >> ino=30869146 scontext=system_u:system_r:prelink_t:s0 >> tcontext=root:object_r:lib_t:s0 tclass=file >> audit(1148393412.438:2910): avc: denied { unlink } for pid=13702 >> comm="prelink" name="prelink.cache" dev=md0 ino=7012828 >> scontext=system_u:system_r:prelink_t:s0 >> tcontext=user_u:object_r:etc_t:s0 tclass=file >> prelink seems to be completly broken and nobody seems to notice it? >> > > I'm not seeing this anywhere. > > Perhaps it's because /lib/ld-2.4.so is lib_t rather than ld_so_t on your > system? > > Paul. > > > > ls -Z /lib/ld-2.4.so -rwxr-xr-x root root system_u:object_r:ld_so_t /lib/ld-2.4.so ls -Z /lib64/ld-2.4.so -rwxr-xr-x root root system_u:object_r:lib_t seems that you are correct lets hope that this wont happen again. From dragoran at feuerpokemon.de Tue May 23 15:08:40 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 23 May 2006 17:08:40 +0200 Subject: selinux prelink avc's In-Reply-To: <4473250C.4020401@feuerpokemon.de> References: <4469F575.30609@feuerpokemon.de> <446EFB0B.8030508@feuerpokemon.de> <44731C1D.609@feuerpokemon.de> <1148395359.5228.2.camel@laurel.intra.city-fan.org> <4473250C.4020401@feuerpokemon.de> Message-ID: <44732578.70403@feuerpokemon.de> dragoran wrote: > Paul Howarth wrote: >> On Tue, 2006-05-23 at 16:28 +0200, dragoran wrote: >> >>> dragoran wrote: >>> >>>> dragoran wrote: >>>> >>>>> audit(1147793154.831:353): avc: denied { execute_no_trans } for >>>>> pid=5195 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 >>>>> scontext=system_u:system_r:prelink_t:s0 >>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>> audit(1147793154.831:354): avc: denied { execute_no_trans } for >>>>> pid=5196 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 >>>>> scontext=system_u:system_r:prelink_t:s0 >>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>> audit(1147793155.019:355): avc: denied { execute_no_trans } for >>>>> pid=5197 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 >>>>> scontext=system_u:system_r:prelink_t:s0 >>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>> audit(1147793155.447:356): avc: denied { execute_no_trans } for >>>>> pid=5198 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 >>>>> scontext=system_u:system_r:prelink_t:s0 >>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>> audit(1147793156.255:357): avc: denied { execute_no_trans } for >>>>> pid=5199 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 >>>>> scontext=system_u:system_r:prelink_t:s0 >>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>> I am using FC5 with selinux-policy-targeted-2.2.36-2.fc5 >>>>> whats gonig on? is a file misslabeled or is this a policy bug? >>>>> >>>>> -- >>>>> fedora-selinux-list mailing list >>>>> fedora-selinux-list at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>>>> >>>>> >>>>> >>>> hello? >>>> any solution for this problem? >>>> >>>> >>>> >>> it happend again... >>> am I the only one seeing this? >>> audit(1148393411.538:2907): avc: denied { execute_no_trans } for >>> pid=16856 comm="prelink" name="ld-2.4.so" dev=md0 ino=8060939 >>> scontext=system_u:system_r:prelink_t:s0 >>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>> audit(1148393411.794:2908): avc: denied { execmod } for pid=16859 >>> comm="ld-linux.so.2" name="libGLcore.so.1.0.8762" dev=md0 >>> ino=29797475 scontext=system_u:system_r:prelink_t:s0 >>> tcontext=root:object_r:lib_t:s0 tclass=file >>> audit(1148393411.814:2909): avc: denied { execmod } for pid=16860 >>> comm="ld-linux.so.2" name="libnvidia-tls.so.1.0.8762" dev=md0 >>> ino=30869146 scontext=system_u:system_r:prelink_t:s0 >>> tcontext=root:object_r:lib_t:s0 tclass=file >>> audit(1148393412.438:2910): avc: denied { unlink } for pid=13702 >>> comm="prelink" name="prelink.cache" dev=md0 ino=7012828 >>> scontext=system_u:system_r:prelink_t:s0 >>> tcontext=user_u:object_r:etc_t:s0 tclass=file >>> prelink seems to be completly broken and nobody seems to notice it? >>> >> >> I'm not seeing this anywhere. >> >> Perhaps it's because /lib/ld-2.4.so is lib_t rather than ld_so_t on your >> system? >> >> Paul. >> >> >> >> > ls -Z /lib/ld-2.4.so > -rwxr-xr-x root root system_u:object_r:ld_so_t > /lib/ld-2.4.so > ls -Z /lib64/ld-2.4.so > -rwxr-xr-x root root system_u:object_r:lib_t > seems that you are correct lets hope that this wont happen again. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > this *is* a bug restorecon /lib64/ld-2.4.so does not change it to ld_so_t (had to do a chcon) From dragoran at feuerpokemon.de Tue May 23 15:17:06 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 23 May 2006 17:17:06 +0200 Subject: selinux prelink avc's (broken paths in policy?) In-Reply-To: <44732578.70403@feuerpokemon.de> References: <4469F575.30609@feuerpokemon.de> <446EFB0B.8030508@feuerpokemon.de> <44731C1D.609@feuerpokemon.de> <1148395359.5228.2.camel@laurel.intra.city-fan.org> <4473250C.4020401@feuerpokemon.de> <44732578.70403@feuerpokemon.de> Message-ID: <44732772.7090302@feuerpokemon.de> dragoran wrote: > dragoran wrote: >> Paul Howarth wrote: >>> On Tue, 2006-05-23 at 16:28 +0200, dragoran wrote: >>> >>>> dragoran wrote: >>>> >>>>> dragoran wrote: >>>>> >>>>>> audit(1147793154.831:353): avc: denied { execute_no_trans } >>>>>> for pid=5195 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 >>>>>> scontext=system_u:system_r:prelink_t:s0 >>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>>> audit(1147793154.831:354): avc: denied { execute_no_trans } >>>>>> for pid=5196 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 >>>>>> scontext=system_u:system_r:prelink_t:s0 >>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>>> audit(1147793155.019:355): avc: denied { execute_no_trans } >>>>>> for pid=5197 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 >>>>>> scontext=system_u:system_r:prelink_t:s0 >>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>>> audit(1147793155.447:356): avc: denied { execute_no_trans } >>>>>> for pid=5198 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 >>>>>> scontext=system_u:system_r:prelink_t:s0 >>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>>> audit(1147793156.255:357): avc: denied { execute_no_trans } >>>>>> for pid=5199 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 >>>>>> scontext=system_u:system_r:prelink_t:s0 >>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>>> I am using FC5 with selinux-policy-targeted-2.2.36-2.fc5 >>>>>> whats gonig on? is a file misslabeled or is this a policy bug? >>>>>> >>>>>> -- >>>>>> fedora-selinux-list mailing list >>>>>> fedora-selinux-list at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>>>>> >>>>>> >>>>>> >>>>> hello? >>>>> any solution for this problem? >>>>> >>>>> >>>>> >>>> it happend again... >>>> am I the only one seeing this? >>>> audit(1148393411.538:2907): avc: denied { execute_no_trans } for >>>> pid=16856 comm="prelink" name="ld-2.4.so" dev=md0 ino=8060939 >>>> scontext=system_u:system_r:prelink_t:s0 >>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>> audit(1148393411.794:2908): avc: denied { execmod } for >>>> pid=16859 comm="ld-linux.so.2" name="libGLcore.so.1.0.8762" dev=md0 >>>> ino=29797475 scontext=system_u:system_r:prelink_t:s0 >>>> tcontext=root:object_r:lib_t:s0 tclass=file >>>> audit(1148393411.814:2909): avc: denied { execmod } for >>>> pid=16860 comm="ld-linux.so.2" name="libnvidia-tls.so.1.0.8762" >>>> dev=md0 ino=30869146 scontext=system_u:system_r:prelink_t:s0 >>>> tcontext=root:object_r:lib_t:s0 tclass=file >>>> audit(1148393412.438:2910): avc: denied { unlink } for pid=13702 >>>> comm="prelink" name="prelink.cache" dev=md0 ino=7012828 >>>> scontext=system_u:system_r:prelink_t:s0 >>>> tcontext=user_u:object_r:etc_t:s0 tclass=file >>>> prelink seems to be completly broken and nobody seems to notice it? >>>> >>> >>> I'm not seeing this anywhere. >>> >>> Perhaps it's because /lib/ld-2.4.so is lib_t rather than ld_so_t on >>> your >>> system? >>> >>> Paul. >>> >>> >>> >>> >> ls -Z /lib/ld-2.4.so >> -rwxr-xr-x root root system_u:object_r:ld_so_t >> /lib/ld-2.4.so >> ls -Z /lib64/ld-2.4.so >> -rwxr-xr-x root root system_u:object_r:lib_t >> seems that you are correct lets hope that this wont happen again. >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >> > this *is* a bug > restorecon /lib64/ld-2.4.so > does not change it to ld_so_t (had to do a chcon) > > > I did a complete relabel and the result is ls -Z /lib64/ld-2.4.so -rwxr-xr-x root root system_u:object_r:lib_t /lib64/ld-2.4.so I also noticed this: drwxr-xr-x root root system_u:object_r:bin_t bin drwxr-xr-x root root system_u:object_r:boot_t boot drwxr-xr-x root root system_u:object_r:device_t dev drwxr-xr-x root root system_u:object_r:etc_t etc drwxr-xr-x root root system_u:object_r:home_root_t home drwxr-xr-x root root system_u:object_r:lib_t lib drwxr-xr-x root root system_u:object_r:lib_t lib64 drwx------ root root system_u:object_r:lost_found_t lost+found drwxr-xr-x root root system_u:object_r:mnt_t media drwxr-xr-x root root system_u:object_r:mnt_t misc drwxr-xr-x root root system_u:object_r:mnt_t mnt dr-xr-xr-x root root system_u:object_r:mnt_t net drwxr-xr-x root root system_u:object_r:usr_t opt dr-xr-xr-x root root system_u:object_r:proc_t proc drwxr-x--- root root root:object_r:user_home_dir_t root drwxr-xr-x root root system_u:object_r:sbin_t sbin drwxr-xr-x root root system_u:object_r:security_t selinux drwxr-xr-x root root system_u:object_r:var_t srv drwxr-xr-x root root system_u:object_r:sysfs_t sys drwxrwxrwt root root system_u:object_r:tmp_t tmp drwxr-xr-x root root system_u:object_r:usr_t usr drwxr-xr-x root root system_u:object_r:var_t var looks incorrect too whats going on here? From dragoran at feuerpokemon.de Tue May 23 15:28:52 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 23 May 2006 17:28:52 +0200 Subject: selinux prelink avc's (broken paths in policy?) In-Reply-To: <44732772.7090302@feuerpokemon.de> References: <4469F575.30609@feuerpokemon.de> <446EFB0B.8030508@feuerpokemon.de> <44731C1D.609@feuerpokemon.de> <1148395359.5228.2.camel@laurel.intra.city-fan.org> <4473250C.4020401@feuerpokemon.de> <44732578.70403@feuerpokemon.de> <44732772.7090302@feuerpokemon.de> Message-ID: <44732A34.8080101@feuerpokemon.de> dragoran wrote: > dragoran wrote: >> dragoran wrote: >>> Paul Howarth wrote: >>>> On Tue, 2006-05-23 at 16:28 +0200, dragoran wrote: >>>> >>>>> dragoran wrote: >>>>> >>>>>> dragoran wrote: >>>>>> >>>>>>> audit(1147793154.831:353): avc: denied { execute_no_trans } >>>>>>> for pid=5195 comm="prelink" name="ld-2.4.so" dev=md0 >>>>>>> ino=8061163 scontext=system_u:system_r:prelink_t:s0 >>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>>>> audit(1147793154.831:354): avc: denied { execute_no_trans } >>>>>>> for pid=5196 comm="prelink" name="ld-2.4.so" dev=md0 >>>>>>> ino=8061163 scontext=system_u:system_r:prelink_t:s0 >>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>>>> audit(1147793155.019:355): avc: denied { execute_no_trans } >>>>>>> for pid=5197 comm="prelink" name="ld-2.4.so" dev=md0 >>>>>>> ino=8061163 scontext=system_u:system_r:prelink_t:s0 >>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>>>> audit(1147793155.447:356): avc: denied { execute_no_trans } >>>>>>> for pid=5198 comm="prelink" name="ld-2.4.so" dev=md0 >>>>>>> ino=8061163 scontext=system_u:system_r:prelink_t:s0 >>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>>>> audit(1147793156.255:357): avc: denied { execute_no_trans } >>>>>>> for pid=5199 comm="prelink" name="ld-2.4.so" dev=md0 >>>>>>> ino=8061163 scontext=system_u:system_r:prelink_t:s0 >>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>>>> I am using FC5 with selinux-policy-targeted-2.2.36-2.fc5 >>>>>>> whats gonig on? is a file misslabeled or is this a policy bug? >>>>>>> >>>>>>> -- >>>>>>> fedora-selinux-list mailing list >>>>>>> fedora-selinux-list at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>>>>>> >>>>>>> >>>>>>> >>>>>> hello? >>>>>> any solution for this problem? >>>>>> >>>>>> >>>>>> >>>>> it happend again... >>>>> am I the only one seeing this? >>>>> audit(1148393411.538:2907): avc: denied { execute_no_trans } >>>>> for pid=16856 comm="prelink" name="ld-2.4.so" dev=md0 ino=8060939 >>>>> scontext=system_u:system_r:prelink_t:s0 >>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>> audit(1148393411.794:2908): avc: denied { execmod } for >>>>> pid=16859 comm="ld-linux.so.2" name="libGLcore.so.1.0.8762" >>>>> dev=md0 ino=29797475 scontext=system_u:system_r:prelink_t:s0 >>>>> tcontext=root:object_r:lib_t:s0 tclass=file >>>>> audit(1148393411.814:2909): avc: denied { execmod } for >>>>> pid=16860 comm="ld-linux.so.2" name="libnvidia-tls.so.1.0.8762" >>>>> dev=md0 ino=30869146 scontext=system_u:system_r:prelink_t:s0 >>>>> tcontext=root:object_r:lib_t:s0 tclass=file >>>>> audit(1148393412.438:2910): avc: denied { unlink } for >>>>> pid=13702 comm="prelink" name="prelink.cache" dev=md0 ino=7012828 >>>>> scontext=system_u:system_r:prelink_t:s0 >>>>> tcontext=user_u:object_r:etc_t:s0 tclass=file >>>>> prelink seems to be completly broken and nobody seems to notice it? >>>>> >>>> >>>> I'm not seeing this anywhere. >>>> >>>> Perhaps it's because /lib/ld-2.4.so is lib_t rather than ld_so_t on >>>> your >>>> system? >>>> >>>> Paul. >>>> >>>> >>>> >>>> >>> ls -Z /lib/ld-2.4.so >>> -rwxr-xr-x root root system_u:object_r:ld_so_t >>> /lib/ld-2.4.so >>> ls -Z /lib64/ld-2.4.so >>> -rwxr-xr-x root root system_u:object_r:lib_t >>> seems that you are correct lets hope that this wont happen again. >>> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>> >>> >> this *is* a bug >> restorecon /lib64/ld-2.4.so >> does not change it to ld_so_t (had to do a chcon) >> >> >> > > I did a complete relabel and the result is > ls -Z /lib64/ld-2.4.so > -rwxr-xr-x root root system_u:object_r:lib_t > /lib64/ld-2.4.so > I also noticed this: > drwxr-xr-x root root system_u:object_r:bin_t bin > drwxr-xr-x root root system_u:object_r:boot_t boot > drwxr-xr-x root root system_u:object_r:device_t dev > drwxr-xr-x root root system_u:object_r:etc_t etc > drwxr-xr-x root root system_u:object_r:home_root_t home > drwxr-xr-x root root system_u:object_r:lib_t lib > drwxr-xr-x root root system_u:object_r:lib_t lib64 > drwx------ root root system_u:object_r:lost_found_t lost+found > drwxr-xr-x root root system_u:object_r:mnt_t media > drwxr-xr-x root root system_u:object_r:mnt_t misc > drwxr-xr-x root root system_u:object_r:mnt_t mnt > dr-xr-xr-x root root system_u:object_r:mnt_t net > drwxr-xr-x root root system_u:object_r:usr_t opt > dr-xr-xr-x root root system_u:object_r:proc_t proc > drwxr-x--- root root root:object_r:user_home_dir_t root > drwxr-xr-x root root system_u:object_r:sbin_t sbin > drwxr-xr-x root root system_u:object_r:security_t selinux > drwxr-xr-x root root system_u:object_r:var_t srv > drwxr-xr-x root root system_u:object_r:sysfs_t sys > drwxrwxrwt root root system_u:object_r:tmp_t tmp > drwxr-xr-x root root system_u:object_r:usr_t usr > drwxr-xr-x root root system_u:object_r:var_t var > looks incorrect too whats going on here? > bug filled: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192839 From paul at city-fan.org Tue May 23 15:30:46 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 23 May 2006 16:30:46 +0100 Subject: selinux prelink avc's (broken paths in policy?) In-Reply-To: <44732772.7090302@feuerpokemon.de> References: <4469F575.30609@feuerpokemon.de> <446EFB0B.8030508@feuerpokemon.de> <44731C1D.609@feuerpokemon.de> <1148395359.5228.2.camel@laurel.intra.city-fan.org> <4473250C.4020401@feuerpokemon.de> <44732578.70403@feuerpokemon.de> <44732772.7090302@feuerpokemon.de> Message-ID: <1148398247.5228.26.camel@laurel.intra.city-fan.org> On Tue, 2006-05-23 at 17:17 +0200, dragoran wrote: > dragoran wrote: > > dragoran wrote: > >> Paul Howarth wrote: > >>> On Tue, 2006-05-23 at 16:28 +0200, dragoran wrote: > >>> > >>>> dragoran wrote: > >>>> > >>>>> dragoran wrote: > >>>>> > >>>>>> audit(1147793154.831:353): avc: denied { execute_no_trans } > >>>>>> for pid=5195 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 > >>>>>> scontext=system_u:system_r:prelink_t:s0 > >>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file > >>>>>> audit(1147793154.831:354): avc: denied { execute_no_trans } > >>>>>> for pid=5196 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 > >>>>>> scontext=system_u:system_r:prelink_t:s0 > >>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file > >>>>>> audit(1147793155.019:355): avc: denied { execute_no_trans } > >>>>>> for pid=5197 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 > >>>>>> scontext=system_u:system_r:prelink_t:s0 > >>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file > >>>>>> audit(1147793155.447:356): avc: denied { execute_no_trans } > >>>>>> for pid=5198 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 > >>>>>> scontext=system_u:system_r:prelink_t:s0 > >>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file > >>>>>> audit(1147793156.255:357): avc: denied { execute_no_trans } > >>>>>> for pid=5199 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 > >>>>>> scontext=system_u:system_r:prelink_t:s0 > >>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file > >>>>>> I am using FC5 with selinux-policy-targeted-2.2.36-2.fc5 > >>>>>> whats gonig on? is a file misslabeled or is this a policy bug? > >>>>>> > >>>>>> -- > >>>>>> fedora-selinux-list mailing list > >>>>>> fedora-selinux-list at redhat.com > >>>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > >>>>>> > >>>>>> > >>>>>> > >>>>> hello? > >>>>> any solution for this problem? > >>>>> > >>>>> > >>>>> > >>>> it happend again... > >>>> am I the only one seeing this? > >>>> audit(1148393411.538:2907): avc: denied { execute_no_trans } for > >>>> pid=16856 comm="prelink" name="ld-2.4.so" dev=md0 ino=8060939 > >>>> scontext=system_u:system_r:prelink_t:s0 > >>>> tcontext=system_u:object_r:lib_t:s0 tclass=file > >>>> audit(1148393411.794:2908): avc: denied { execmod } for > >>>> pid=16859 comm="ld-linux.so.2" name="libGLcore.so.1.0.8762" dev=md0 > >>>> ino=29797475 scontext=system_u:system_r:prelink_t:s0 > >>>> tcontext=root:object_r:lib_t:s0 tclass=file > >>>> audit(1148393411.814:2909): avc: denied { execmod } for > >>>> pid=16860 comm="ld-linux.so.2" name="libnvidia-tls.so.1.0.8762" > >>>> dev=md0 ino=30869146 scontext=system_u:system_r:prelink_t:s0 > >>>> tcontext=root:object_r:lib_t:s0 tclass=file > >>>> audit(1148393412.438:2910): avc: denied { unlink } for pid=13702 > >>>> comm="prelink" name="prelink.cache" dev=md0 ino=7012828 > >>>> scontext=system_u:system_r:prelink_t:s0 > >>>> tcontext=user_u:object_r:etc_t:s0 tclass=file > >>>> prelink seems to be completly broken and nobody seems to notice it? > >>>> > >>> > >>> I'm not seeing this anywhere. > >>> > >>> Perhaps it's because /lib/ld-2.4.so is lib_t rather than ld_so_t on > >>> your > >>> system? > >>> > >>> Paul. > >>> > >>> > >>> > >>> > >> ls -Z /lib/ld-2.4.so > >> -rwxr-xr-x root root system_u:object_r:ld_so_t > >> /lib/ld-2.4.so > >> ls -Z /lib64/ld-2.4.so > >> -rwxr-xr-x root root system_u:object_r:lib_t > >> seems that you are correct lets hope that this wont happen again. > >> > >> -- > >> fedora-selinux-list mailing list > >> fedora-selinux-list at redhat.com > >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > >> > >> > > this *is* a bug > > restorecon /lib64/ld-2.4.so > > does not change it to ld_so_t (had to do a chcon) > > > > > > > > I did a complete relabel and the result is > ls -Z /lib64/ld-2.4.so > -rwxr-xr-x root root system_u:object_r:lib_t > /lib64/ld-2.4.so The context line that *should* match this appears to be: /lib(64)?(/.*)?/ld-[^/]*\.so(\.[^/]*)* regular file system_u:object_r:ld_so_t:s0 But this appears to be overruled by one of these: /lib(/.*)? all files system_u:object_r:lib_t:s0 /lib64(/.*)? all files system_u:object_r:lib_t:s0 I'm not sure what it is that decides which is the best match. The top one is longer and appears to me to be more specific, but it does have more wildcards in it... > I also noticed this: > drwxr-xr-x root root system_u:object_r:bin_t bin > drwxr-xr-x root root system_u:object_r:boot_t boot > drwxr-xr-x root root system_u:object_r:device_t dev > drwxr-xr-x root root system_u:object_r:etc_t etc > drwxr-xr-x root root system_u:object_r:home_root_t home > drwxr-xr-x root root system_u:object_r:lib_t lib > drwxr-xr-x root root system_u:object_r:lib_t lib64 > drwx------ root root system_u:object_r:lost_found_t lost+found > drwxr-xr-x root root system_u:object_r:mnt_t media > drwxr-xr-x root root system_u:object_r:mnt_t misc > drwxr-xr-x root root system_u:object_r:mnt_t mnt > dr-xr-xr-x root root system_u:object_r:mnt_t net > drwxr-xr-x root root system_u:object_r:usr_t opt > dr-xr-xr-x root root system_u:object_r:proc_t proc > drwxr-x--- root root root:object_r:user_home_dir_t root > drwxr-xr-x root root system_u:object_r:sbin_t sbin > drwxr-xr-x root root system_u:object_r:security_t selinux > drwxr-xr-x root root system_u:object_r:var_t srv > drwxr-xr-x root root system_u:object_r:sysfs_t sys > drwxrwxrwt root root system_u:object_r:tmp_t tmp > drwxr-xr-x root root system_u:object_r:usr_t usr > drwxr-xr-x root root system_u:object_r:var_t var > looks incorrect too whats going on here? Looks like mine. What do you think is wrong with this? Nothing stands out to me. Paul. From dragoran at feuerpokemon.de Tue May 23 15:34:59 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 23 May 2006 17:34:59 +0200 Subject: selinux prelink avc's (broken paths in policy?) In-Reply-To: <1148398247.5228.26.camel@laurel.intra.city-fan.org> References: <4469F575.30609@feuerpokemon.de> <446EFB0B.8030508@feuerpokemon.de> <44731C1D.609@feuerpokemon.de> <1148395359.5228.2.camel@laurel.intra.city-fan.org> <4473250C.4020401@feuerpokemon.de> <44732578.70403@feuerpokemon.de> <44732772.7090302@feuerpokemon.de> <1148398247.5228.26.camel@laurel.intra.city-fan.org> Message-ID: <44732BA3.9050707@feuerpokemon.de> Paul Howarth wrote: > On Tue, 2006-05-23 at 17:17 +0200, dragoran wrote: > >> dragoran wrote: >> >>> dragoran wrote: >>> >>>> Paul Howarth wrote: >>>> >>>>> On Tue, 2006-05-23 at 16:28 +0200, dragoran wrote: >>>>> >>>>> >>>>>> dragoran wrote: >>>>>> >>>>>> >>>>>>> dragoran wrote: >>>>>>> >>>>>>> >>>>>>>> audit(1147793154.831:353): avc: denied { execute_no_trans } >>>>>>>> for pid=5195 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 >>>>>>>> scontext=system_u:system_r:prelink_t:s0 >>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>>>>> audit(1147793154.831:354): avc: denied { execute_no_trans } >>>>>>>> for pid=5196 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 >>>>>>>> scontext=system_u:system_r:prelink_t:s0 >>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>>>>> audit(1147793155.019:355): avc: denied { execute_no_trans } >>>>>>>> for pid=5197 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 >>>>>>>> scontext=system_u:system_r:prelink_t:s0 >>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>>>>> audit(1147793155.447:356): avc: denied { execute_no_trans } >>>>>>>> for pid=5198 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 >>>>>>>> scontext=system_u:system_r:prelink_t:s0 >>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>>>>> audit(1147793156.255:357): avc: denied { execute_no_trans } >>>>>>>> for pid=5199 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 >>>>>>>> scontext=system_u:system_r:prelink_t:s0 >>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>>>>> I am using FC5 with selinux-policy-targeted-2.2.36-2.fc5 >>>>>>>> whats gonig on? is a file misslabeled or is this a policy bug? >>>>>>>> >>>>>>>> -- >>>>>>>> fedora-selinux-list mailing list >>>>>>>> fedora-selinux-list at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> hello? >>>>>>> any solution for this problem? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> it happend again... >>>>>> am I the only one seeing this? >>>>>> audit(1148393411.538:2907): avc: denied { execute_no_trans } for >>>>>> pid=16856 comm="prelink" name="ld-2.4.so" dev=md0 ino=8060939 >>>>>> scontext=system_u:system_r:prelink_t:s0 >>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>>> audit(1148393411.794:2908): avc: denied { execmod } for >>>>>> pid=16859 comm="ld-linux.so.2" name="libGLcore.so.1.0.8762" dev=md0 >>>>>> ino=29797475 scontext=system_u:system_r:prelink_t:s0 >>>>>> tcontext=root:object_r:lib_t:s0 tclass=file >>>>>> audit(1148393411.814:2909): avc: denied { execmod } for >>>>>> pid=16860 comm="ld-linux.so.2" name="libnvidia-tls.so.1.0.8762" >>>>>> dev=md0 ino=30869146 scontext=system_u:system_r:prelink_t:s0 >>>>>> tcontext=root:object_r:lib_t:s0 tclass=file >>>>>> audit(1148393412.438:2910): avc: denied { unlink } for pid=13702 >>>>>> comm="prelink" name="prelink.cache" dev=md0 ino=7012828 >>>>>> scontext=system_u:system_r:prelink_t:s0 >>>>>> tcontext=user_u:object_r:etc_t:s0 tclass=file >>>>>> prelink seems to be completly broken and nobody seems to notice it? >>>>>> >>>>>> >>>>> I'm not seeing this anywhere. >>>>> >>>>> Perhaps it's because /lib/ld-2.4.so is lib_t rather than ld_so_t on >>>>> your >>>>> system? >>>>> >>>>> Paul. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> ls -Z /lib/ld-2.4.so >>>> -rwxr-xr-x root root system_u:object_r:ld_so_t >>>> /lib/ld-2.4.so >>>> ls -Z /lib64/ld-2.4.so >>>> -rwxr-xr-x root root system_u:object_r:lib_t >>>> seems that you are correct lets hope that this wont happen again. >>>> >>>> -- >>>> fedora-selinux-list mailing list >>>> fedora-selinux-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>>> >>>> >>>> >>> this *is* a bug >>> restorecon /lib64/ld-2.4.so >>> does not change it to ld_so_t (had to do a chcon) >>> >>> >>> >>> >> I did a complete relabel and the result is >> ls -Z /lib64/ld-2.4.so >> -rwxr-xr-x root root system_u:object_r:lib_t >> /lib64/ld-2.4.so >> > > The context line that *should* match this appears to be: > /lib(64)?(/.*)?/ld-[^/]*\.so(\.[^/]*)* regular file > system_u:object_r:ld_so_t:s0 > > But this appears to be overruled by one of these: > /lib(/.*)? all files > system_u:object_r:lib_t:s0 > /lib64(/.*)? all files > system_u:object_r:lib_t:s0 > > I'm not sure what it is that decides which is the best match. The top > one is longer and appears to me to be more specific, but it does have > more wildcards in it... > > >> I also noticed this: >> drwxr-xr-x root root system_u:object_r:bin_t bin >> drwxr-xr-x root root system_u:object_r:boot_t boot >> drwxr-xr-x root root system_u:object_r:device_t dev >> drwxr-xr-x root root system_u:object_r:etc_t etc >> drwxr-xr-x root root system_u:object_r:home_root_t home >> drwxr-xr-x root root system_u:object_r:lib_t lib >> drwxr-xr-x root root system_u:object_r:lib_t lib64 >> drwx------ root root system_u:object_r:lost_found_t lost+found >> drwxr-xr-x root root system_u:object_r:mnt_t media >> drwxr-xr-x root root system_u:object_r:mnt_t misc >> drwxr-xr-x root root system_u:object_r:mnt_t mnt >> dr-xr-xr-x root root system_u:object_r:mnt_t net >> drwxr-xr-x root root system_u:object_r:usr_t opt >> dr-xr-xr-x root root system_u:object_r:proc_t proc >> drwxr-x--- root root root:object_r:user_home_dir_t root >> drwxr-xr-x root root system_u:object_r:sbin_t sbin >> drwxr-xr-x root root system_u:object_r:security_t selinux >> drwxr-xr-x root root system_u:object_r:var_t srv >> drwxr-xr-x root root system_u:object_r:sysfs_t sys >> drwxrwxrwt root root system_u:object_r:tmp_t tmp >> drwxr-xr-x root root system_u:object_r:usr_t usr >> drwxr-xr-x root root system_u:object_r:var_t var >> looks incorrect too whats going on here? >> > > Looks like mine. What do you think is wrong with this? Nothing stands > out to me. > > Paul. > > > > root:object_r:user_home_dir_t root should be /home and system_u:object_r:home_root_t home should be /root something weird is going on here... From paul at city-fan.org Tue May 23 16:03:01 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 23 May 2006 17:03:01 +0100 Subject: selinux prelink avc's (broken paths in policy?) In-Reply-To: <44732BA3.9050707@feuerpokemon.de> References: <4469F575.30609@feuerpokemon.de> <446EFB0B.8030508@feuerpokemon.de> <44731C1D.609@feuerpokemon.de> <1148395359.5228.2.camel@laurel.intra.city-fan.org> <4473250C.4020401@feuerpokemon.de> <44732578.70403@feuerpokemon.de> <44732772.7090302@feuerpokemon.de> <1148398247.5228.26.camel@laurel.intra.city-fan.org> <44732BA3.9050707@feuerpokemon.de> Message-ID: <1148400182.5228.43.camel@laurel.intra.city-fan.org> On Tue, 2006-05-23 at 17:34 +0200, dragoran wrote: > Paul Howarth wrote: > > On Tue, 2006-05-23 at 17:17 +0200, dragoran wrote: > > > >> dragoran wrote: > >> > >>> dragoran wrote: > >>> > >>>> Paul Howarth wrote: > >>>> > >>>>> On Tue, 2006-05-23 at 16:28 +0200, dragoran wrote: > >>>>> > >>>>> > >>>>>> dragoran wrote: > >>>>>> > >>>>>> > >>>>>>> dragoran wrote: > >>>>>>> > >>>>>>> > >>>>>>>> audit(1147793154.831:353): avc: denied { execute_no_trans } > >>>>>>>> for pid=5195 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 > >>>>>>>> scontext=system_u:system_r:prelink_t:s0 > >>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file > >>>>>>>> audit(1147793154.831:354): avc: denied { execute_no_trans } > >>>>>>>> for pid=5196 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 > >>>>>>>> scontext=system_u:system_r:prelink_t:s0 > >>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file > >>>>>>>> audit(1147793155.019:355): avc: denied { execute_no_trans } > >>>>>>>> for pid=5197 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 > >>>>>>>> scontext=system_u:system_r:prelink_t:s0 > >>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file > >>>>>>>> audit(1147793155.447:356): avc: denied { execute_no_trans } > >>>>>>>> for pid=5198 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 > >>>>>>>> scontext=system_u:system_r:prelink_t:s0 > >>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file > >>>>>>>> audit(1147793156.255:357): avc: denied { execute_no_trans } > >>>>>>>> for pid=5199 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 > >>>>>>>> scontext=system_u:system_r:prelink_t:s0 > >>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file > >>>>>>>> I am using FC5 with selinux-policy-targeted-2.2.36-2.fc5 > >>>>>>>> whats gonig on? is a file misslabeled or is this a policy bug? > >>>>>>>> > >>>>>>>> -- > >>>>>>>> fedora-selinux-list mailing list > >>>>>>>> fedora-selinux-list at redhat.com > >>>>>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> hello? > >>>>>>> any solution for this problem? > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> it happend again... > >>>>>> am I the only one seeing this? > >>>>>> audit(1148393411.538:2907): avc: denied { execute_no_trans } for > >>>>>> pid=16856 comm="prelink" name="ld-2.4.so" dev=md0 ino=8060939 > >>>>>> scontext=system_u:system_r:prelink_t:s0 > >>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file > >>>>>> audit(1148393411.794:2908): avc: denied { execmod } for > >>>>>> pid=16859 comm="ld-linux.so.2" name="libGLcore.so.1.0.8762" dev=md0 > >>>>>> ino=29797475 scontext=system_u:system_r:prelink_t:s0 > >>>>>> tcontext=root:object_r:lib_t:s0 tclass=file > >>>>>> audit(1148393411.814:2909): avc: denied { execmod } for > >>>>>> pid=16860 comm="ld-linux.so.2" name="libnvidia-tls.so.1.0.8762" > >>>>>> dev=md0 ino=30869146 scontext=system_u:system_r:prelink_t:s0 > >>>>>> tcontext=root:object_r:lib_t:s0 tclass=file > >>>>>> audit(1148393412.438:2910): avc: denied { unlink } for pid=13702 > >>>>>> comm="prelink" name="prelink.cache" dev=md0 ino=7012828 > >>>>>> scontext=system_u:system_r:prelink_t:s0 > >>>>>> tcontext=user_u:object_r:etc_t:s0 tclass=file > >>>>>> prelink seems to be completly broken and nobody seems to notice it? > >>>>>> > >>>>>> > >>>>> I'm not seeing this anywhere. > >>>>> > >>>>> Perhaps it's because /lib/ld-2.4.so is lib_t rather than ld_so_t on > >>>>> your > >>>>> system? > >>>>> > >>>>> Paul. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> ls -Z /lib/ld-2.4.so > >>>> -rwxr-xr-x root root system_u:object_r:ld_so_t > >>>> /lib/ld-2.4.so > >>>> ls -Z /lib64/ld-2.4.so > >>>> -rwxr-xr-x root root system_u:object_r:lib_t > >>>> seems that you are correct lets hope that this wont happen again. > >>>> > >>>> -- > >>>> fedora-selinux-list mailing list > >>>> fedora-selinux-list at redhat.com > >>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > >>>> > >>>> > >>>> > >>> this *is* a bug > >>> restorecon /lib64/ld-2.4.so > >>> does not change it to ld_so_t (had to do a chcon) > >>> > >>> > >>> > >>> > >> I did a complete relabel and the result is > >> ls -Z /lib64/ld-2.4.so > >> -rwxr-xr-x root root system_u:object_r:lib_t > >> /lib64/ld-2.4.so > >> > > > > The context line that *should* match this appears to be: > > /lib(64)?(/.*)?/ld-[^/]*\.so(\.[^/]*)* regular file > > system_u:object_r:ld_so_t:s0 > > > > But this appears to be overruled by one of these: > > /lib(/.*)? all files > > system_u:object_r:lib_t:s0 > > /lib64(/.*)? all files > > system_u:object_r:lib_t:s0 > > > > I'm not sure what it is that decides which is the best match. The top > > one is longer and appears to me to be more specific, but it does have > > more wildcards in it... > > > > > >> I also noticed this: > >> drwxr-xr-x root root system_u:object_r:bin_t bin > >> drwxr-xr-x root root system_u:object_r:boot_t boot > >> drwxr-xr-x root root system_u:object_r:device_t dev > >> drwxr-xr-x root root system_u:object_r:etc_t etc > >> drwxr-xr-x root root system_u:object_r:home_root_t home > >> drwxr-xr-x root root system_u:object_r:lib_t lib > >> drwxr-xr-x root root system_u:object_r:lib_t lib64 > >> drwx------ root root system_u:object_r:lost_found_t lost+found > >> drwxr-xr-x root root system_u:object_r:mnt_t media > >> drwxr-xr-x root root system_u:object_r:mnt_t misc > >> drwxr-xr-x root root system_u:object_r:mnt_t mnt > >> dr-xr-xr-x root root system_u:object_r:mnt_t net > >> drwxr-xr-x root root system_u:object_r:usr_t opt > >> dr-xr-xr-x root root system_u:object_r:proc_t proc > >> drwxr-x--- root root root:object_r:user_home_dir_t root > >> drwxr-xr-x root root system_u:object_r:sbin_t sbin > >> drwxr-xr-x root root system_u:object_r:security_t selinux > >> drwxr-xr-x root root system_u:object_r:var_t srv > >> drwxr-xr-x root root system_u:object_r:sysfs_t sys > >> drwxrwxrwt root root system_u:object_r:tmp_t tmp > >> drwxr-xr-x root root system_u:object_r:usr_t usr > >> drwxr-xr-x root root system_u:object_r:var_t var > >> looks incorrect too whats going on here? > >> > > > > Looks like mine. What do you think is wrong with this? Nothing stands > > out to me. > > > > Paul. > > > > > > > > > > root:object_r:user_home_dir_t root should be /home and > system_u:object_r:home_root_t home should be /root something weird is going on here... I disagree. I think these are correct. /root is the home directory for user "root" and should be user_home_dir_t, just like any other user's home directory. /home is the root of the "home" directory tree, where most user home directories live, so home_root_t seems OK for that. Perhaps it's just the names of the context types that are confusing? Paul. From dragoran at feuerpokemon.de Tue May 23 16:08:26 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 23 May 2006 18:08:26 +0200 Subject: selinux prelink avc's (broken paths in policy?) In-Reply-To: <1148400182.5228.43.camel@laurel.intra.city-fan.org> References: <4469F575.30609@feuerpokemon.de> <446EFB0B.8030508@feuerpokemon.de> <44731C1D.609@feuerpokemon.de> <1148395359.5228.2.camel@laurel.intra.city-fan.org> <4473250C.4020401@feuerpokemon.de> <44732578.70403@feuerpokemon.de> <44732772.7090302@feuerpokemon.de> <1148398247.5228.26.camel@laurel.intra.city-fan.org> <44732BA3.9050707@feuerpokemon.de> <1148400182.5228.43.camel@laurel.intra.city-fan.org> Message-ID: <4473337A.9060802@feuerpokemon.de> Paul Howarth wrote: > On Tue, 2006-05-23 at 17:34 +0200, dragoran wrote: > >> Paul Howarth wrote: >> >>> On Tue, 2006-05-23 at 17:17 +0200, dragoran wrote: >>> >>> >>>> dragoran wrote: >>>> >>>> >>>>> dragoran wrote: >>>>> >>>>> >>>>>> Paul Howarth wrote: >>>>>> >>>>>> >>>>>>> On Tue, 2006-05-23 at 16:28 +0200, dragoran wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> dragoran wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> dragoran wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> audit(1147793154.831:353): avc: denied { execute_no_trans } >>>>>>>>>> for pid=5195 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 >>>>>>>>>> scontext=system_u:system_r:prelink_t:s0 >>>>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>>>>>>> audit(1147793154.831:354): avc: denied { execute_no_trans } >>>>>>>>>> for pid=5196 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 >>>>>>>>>> scontext=system_u:system_r:prelink_t:s0 >>>>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>>>>>>> audit(1147793155.019:355): avc: denied { execute_no_trans } >>>>>>>>>> for pid=5197 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 >>>>>>>>>> scontext=system_u:system_r:prelink_t:s0 >>>>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>>>>>>> audit(1147793155.447:356): avc: denied { execute_no_trans } >>>>>>>>>> for pid=5198 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 >>>>>>>>>> scontext=system_u:system_r:prelink_t:s0 >>>>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>>>>>>> audit(1147793156.255:357): avc: denied { execute_no_trans } >>>>>>>>>> for pid=5199 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 >>>>>>>>>> scontext=system_u:system_r:prelink_t:s0 >>>>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>>>>>>> I am using FC5 with selinux-policy-targeted-2.2.36-2.fc5 >>>>>>>>>> whats gonig on? is a file misslabeled or is this a policy bug? >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> fedora-selinux-list mailing list >>>>>>>>>> fedora-selinux-list at redhat.com >>>>>>>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> hello? >>>>>>>>> any solution for this problem? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> it happend again... >>>>>>>> am I the only one seeing this? >>>>>>>> audit(1148393411.538:2907): avc: denied { execute_no_trans } for >>>>>>>> pid=16856 comm="prelink" name="ld-2.4.so" dev=md0 ino=8060939 >>>>>>>> scontext=system_u:system_r:prelink_t:s0 >>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>>>>> audit(1148393411.794:2908): avc: denied { execmod } for >>>>>>>> pid=16859 comm="ld-linux.so.2" name="libGLcore.so.1.0.8762" dev=md0 >>>>>>>> ino=29797475 scontext=system_u:system_r:prelink_t:s0 >>>>>>>> tcontext=root:object_r:lib_t:s0 tclass=file >>>>>>>> audit(1148393411.814:2909): avc: denied { execmod } for >>>>>>>> pid=16860 comm="ld-linux.so.2" name="libnvidia-tls.so.1.0.8762" >>>>>>>> dev=md0 ino=30869146 scontext=system_u:system_r:prelink_t:s0 >>>>>>>> tcontext=root:object_r:lib_t:s0 tclass=file >>>>>>>> audit(1148393412.438:2910): avc: denied { unlink } for pid=13702 >>>>>>>> comm="prelink" name="prelink.cache" dev=md0 ino=7012828 >>>>>>>> scontext=system_u:system_r:prelink_t:s0 >>>>>>>> tcontext=user_u:object_r:etc_t:s0 tclass=file >>>>>>>> prelink seems to be completly broken and nobody seems to notice it? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> I'm not seeing this anywhere. >>>>>>> >>>>>>> Perhaps it's because /lib/ld-2.4.so is lib_t rather than ld_so_t on >>>>>>> your >>>>>>> system? >>>>>>> >>>>>>> Paul. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> ls -Z /lib/ld-2.4.so >>>>>> -rwxr-xr-x root root system_u:object_r:ld_so_t >>>>>> /lib/ld-2.4.so >>>>>> ls -Z /lib64/ld-2.4.so >>>>>> -rwxr-xr-x root root system_u:object_r:lib_t >>>>>> seems that you are correct lets hope that this wont happen again. >>>>>> >>>>>> -- >>>>>> fedora-selinux-list mailing list >>>>>> fedora-selinux-list at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>>>>> >>>>>> >>>>>> >>>>>> >>>>> this *is* a bug >>>>> restorecon /lib64/ld-2.4.so >>>>> does not change it to ld_so_t (had to do a chcon) >>>>> >>>>> >>>>> >>>>> >>>>> >>>> I did a complete relabel and the result is >>>> ls -Z /lib64/ld-2.4.so >>>> -rwxr-xr-x root root system_u:object_r:lib_t >>>> /lib64/ld-2.4.so >>>> >>>> >>> The context line that *should* match this appears to be: >>> /lib(64)?(/.*)?/ld-[^/]*\.so(\.[^/]*)* regular file >>> system_u:object_r:ld_so_t:s0 >>> >>> But this appears to be overruled by one of these: >>> /lib(/.*)? all files >>> system_u:object_r:lib_t:s0 >>> /lib64(/.*)? all files >>> system_u:object_r:lib_t:s0 >>> >>> I'm not sure what it is that decides which is the best match. The top >>> one is longer and appears to me to be more specific, but it does have >>> more wildcards in it... >>> >>> >>> >>>> I also noticed this: >>>> drwxr-xr-x root root system_u:object_r:bin_t bin >>>> drwxr-xr-x root root system_u:object_r:boot_t boot >>>> drwxr-xr-x root root system_u:object_r:device_t dev >>>> drwxr-xr-x root root system_u:object_r:etc_t etc >>>> drwxr-xr-x root root system_u:object_r:home_root_t home >>>> drwxr-xr-x root root system_u:object_r:lib_t lib >>>> drwxr-xr-x root root system_u:object_r:lib_t lib64 >>>> drwx------ root root system_u:object_r:lost_found_t lost+found >>>> drwxr-xr-x root root system_u:object_r:mnt_t media >>>> drwxr-xr-x root root system_u:object_r:mnt_t misc >>>> drwxr-xr-x root root system_u:object_r:mnt_t mnt >>>> dr-xr-xr-x root root system_u:object_r:mnt_t net >>>> drwxr-xr-x root root system_u:object_r:usr_t opt >>>> dr-xr-xr-x root root system_u:object_r:proc_t proc >>>> drwxr-x--- root root root:object_r:user_home_dir_t root >>>> drwxr-xr-x root root system_u:object_r:sbin_t sbin >>>> drwxr-xr-x root root system_u:object_r:security_t selinux >>>> drwxr-xr-x root root system_u:object_r:var_t srv >>>> drwxr-xr-x root root system_u:object_r:sysfs_t sys >>>> drwxrwxrwt root root system_u:object_r:tmp_t tmp >>>> drwxr-xr-x root root system_u:object_r:usr_t usr >>>> drwxr-xr-x root root system_u:object_r:var_t var >>>> looks incorrect too whats going on here? >>>> >>>> >>> Looks like mine. What do you think is wrong with this? Nothing stands >>> out to me. >>> >>> Paul. >>> >>> >>> >>> >>> >> root:object_r:user_home_dir_t root should be /home and >> system_u:object_r:home_root_t home should be /root something weird is going on here... >> > > I disagree. I think these are correct. > > /root is the home directory for user "root" and should be > user_home_dir_t, just like any other user's home directory. > > /home is the root of the "home" directory tree, where most user home > directories live, so home_root_t seems OK for that. > > thx got it > Perhaps it's just the names of the context types that are confusing? > yes > Paul. > > > > From steve at atc-nycorp.com Tue May 23 19:08:43 2006 From: steve at atc-nycorp.com (Steve Brueckner) Date: Tue, 23 May 2006 15:08:43 -0400 Subject: Audit messages to console Message-ID: <60D45469A1AAD311A04C009027B6BF6805F0ED5F@server20.inside.oracorp.com> Can anyone think of a reason my avc messages are being printed to the console as well as /var/log/messages? This is in an FC5 xenU (guest domain), with no auditd running. Steve Brueckner, ATC-NY From sds at tycho.nsa.gov Tue May 23 19:24:14 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 23 May 2006 15:24:14 -0400 Subject: Audit messages to console In-Reply-To: <60D45469A1AAD311A04C009027B6BF6805F0ED5F@server20.inside.oracorp.com> References: <60D45469A1AAD311A04C009027B6BF6805F0ED5F@server20.inside.oracorp.com> Message-ID: <1148412254.24463.244.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2006-05-23 at 15:08 -0400, Steve Brueckner wrote: > Can anyone think of a reason my avc messages are being printed to the > console as well as /var/log/messages? This is in an FC5 xenU (guest > domain), with no auditd running. That would be the expected behavior, unless you suppress them, e.g. dmesg -n 5 -- Stephen Smalley National Security Agency From shin216 at xf7.so-net.ne.jp Tue May 23 22:50:36 2006 From: shin216 at xf7.so-net.ne.jp (Shintaro Fujiwara) Date: Wed, 24 May 2006 07:50:36 +0900 Subject: faied update a module Message-ID: <1148424636.1931.23.camel@papa.intrajp-yokosuka.co.jp> I yum updated lately. I edited .te file and made apache.pp When I tried to update apache.pp [root at intrajp devel]# semodule -u apache.pp libsepol.class_copy_callback: apache: Modules may not yet declare new classes. libsemanage.semanage_link_sandbox: Link packages failed semodule: Failed! Why and how shoul I do ? Thanks. From knute at frazmtn.com Wed May 24 00:12:37 2006 From: knute at frazmtn.com (Knute Johnson) Date: Tue, 23 May 2006 17:12:37 -0700 Subject: Stuff I found in my log? Message-ID: <44734285.13828.5D7877@knute.frazmtn.com> I found some interesting things in my 'messages' log today. I'm not sure what they mean and would appreciate any information. This one is the most bothersome. It appears that 'useradd' was prevented from running this morning only I didn't run it. Would any other programs run 'useradd' and what would cause it to be denied? May 23 05:11:49 rabbitbrush kernel: audit(1148386309.877:556): avc: denied { write } for pid=13906 comm="useradd" name="[1708464]" dev=pipefs ino=1708464 scontext=user_u:system_r:useradd_t:s0 tcontext=user_u:system_r:unconfined_t:s0 tclass=fifo_file There are a boatload of these messages. I know that 'webalizer' is a statistics formatter for the web server but why would it be run dozens of times and be denied? May 23 04:02:02 rabbitbrush kernel: audit(1148382121.861:514): avc: denied { create } for pid=12313 comm="webalizer" scontext=user_u:system_r:webalizer_t:s0 tcontext=user_u:system_r:webalizer_t:s0 tclass=netlink_route_socket May 23 04:02:02 rabbitbrush kernel: audit(1148382122.237:515): avc: denied { create } for pid=12313 comm="webalizer" scontext=user_u:system_r:webalizer_t:s0 tcontext=user_u:system_r:webalizer_t:s0 tclass=netlink_route_socket May 23 04:02:02 rabbitbrush kernel: audit(1148382122.237:516): avc: denied { create } for pid=12313 comm="webalizer" scontext=user_u:system_r:webalizer_t:s0 tcontext=user_u:system_r:webalizer_t:s0 tclass=netlink_route_socket What would cause hundreds of these messages to appear in the log. I know I played with setsebool but I only changed one item. May 22 17:33:58 rabbitbrush kernel: audit(1148344436.645:286): avc: granted { setbool } for pid=2303 comm="setsebool" scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=security May 22 17:33:58 rabbitbrush kernel: audit(1148344436.645:287): avc: granted { setbool } for pid=2303 comm="setsebool" scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=security May 22 17:33:58 rabbitbrush kernel: audit(1148344436.645:288): avc: granted { setbool } for pid=2303 comm="setsebool" scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=security May 22 17:33:58 rabbitbrush kernel: audit(1148344436.645:289): avc: granted { setbool } for pid=2303 comm="setsebool" scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=security Thanks very much, -- Knute Johnson Molon Labe... From smooge at gmail.com Wed May 24 02:00:33 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 23 May 2006 20:00:33 -0600 Subject: Stuff I found in my log? In-Reply-To: <44734285.13828.5D7877@knute.frazmtn.com> References: <44734285.13828.5D7877@knute.frazmtn.com> Message-ID: <80d7e4090605231900p518a085aq83d660963060c875@mail.gmail.com> On 5/23/06, Knute Johnson wrote: > I found some interesting things in my 'messages' log today. I'm not > sure what they mean and would appreciate any information. > > This one is the most bothersome. It appears that 'useradd' was > prevented from running this morning only I didn't run it. Would any > other programs run 'useradd' and what would cause it to be denied? > > May 23 05:11:49 rabbitbrush kernel: audit(1148386309.877:556): avc: > denied { write } for pid=13906 comm="useradd" name="[1708464]" > dev=pipefs ino=1708464 scontext=user_u:system_r:useradd_t:s0 > tcontext=user_u:system_r:unconfined_t:s0 tclass=fifo_file > Need some more information to help on this: What is your OS and its version? What is your selinux set to? When was the last time you updated your system to? > There are a boatload of these messages. I know that 'webalizer' is a > statistics formatter for the web server but why would it be run > dozens of times and be denied? > > May 23 04:02:02 rabbitbrush kernel: audit(1148382121.861:514): avc: > denied { create } for pid=12313 comm="webalizer" > scontext=user_u:system_r:webalizer_t:s0 > tcontext=user_u:system_r:webalizer_t:s0 tclass=netlink_route_socket -- Stephen J Smoogen. CSIRT/Linux System Administrator From knute at frazmtn.com Wed May 24 04:00:03 2006 From: knute at frazmtn.com (Knute Johnson) Date: Tue, 23 May 2006 21:00:03 -0700 Subject: Stuff I found in my log? In-Reply-To: <80d7e4090605231900p518a085aq83d660963060c875@mail.gmail.com> References: <44734285.13828.5D7877@knute.frazmtn.com> Message-ID: <447377D3.5444.2A32DB@knute.frazmtn.com> >On 5/23/06, Knute Johnson wrote: >> I found some interesting things in my 'messages' log today. I'm not >> sure what they mean and would appreciate any information. >> >> This one is the most bothersome. It appears that 'useradd' was >> prevented from running this morning only I didn't run it. Would any >> other programs run 'useradd' and what would cause it to be denied? >> >> May 23 05:11:49 rabbitbrush kernel: audit(1148386309.877:556): avc: >> denied { write } for pid=13906 comm="useradd" name="[1708464]" >> dev=pipefs ino=1708464 scontext=user_u:system_r:useradd_t:s0 >> tcontext=user_u:system_r:unconfined_t:s0 tclass=fifo_file >> > >Need some more information to help on this: > >What is your OS and its version? >What is your selinux set to? >When was the last time you updated your system to? FC5. Kernel 2.6.16-1.2111_FC5. I assume you mean by to, is it enforcing and targeted? It is. May 15 04:18:39 Updated: selinux-policy.noarch 2.2.38-1.fc5 May 15 04:20:24 Updated: selinux-policy-targeted.noarch 2.2.38-1.fc5 /etc/selinux/conf # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - SELinux is fully disabled. SELINUX=enforcing # SELINUXTYPE= type of policy in use. Possible values are: # targeted - Only targeted network daemons are protected. # strict - Full SELinux protection. SELINUXTYPE=targeted # SETLOCALDEFS= Check local definition changes SETLOCALDEFS=0 Thanks very much, -- Knute Johnson Molon Labe... From paul at city-fan.org Wed May 24 06:33:55 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 24 May 2006 07:33:55 +0100 Subject: faied update a module In-Reply-To: <1148424636.1931.23.camel@papa.intrajp-yokosuka.co.jp> References: <1148424636.1931.23.camel@papa.intrajp-yokosuka.co.jp> Message-ID: <1148452436.5228.91.camel@laurel.intra.city-fan.org> On Wed, 2006-05-24 at 07:50 +0900, Shintaro Fujiwara wrote: > I yum updated lately. > I edited .te file and made apache.pp > When I tried to update apache.pp > > [root at intrajp devel]# semodule -u apache.pp > libsepol.class_copy_callback: apache: Modules may not yet declare new > classes. > libsemanage.semanage_link_sandbox: Link packages failed > semodule: Failed! > > Why and how shoul I do ? I got the same message last week when I tried installing a .pp file that had been built against an older selinux-policy package. Did you make the module on the same machine you're trying to install it on? Does "semodule -i apache.pp" give the same error? Do you get the same error if you first remove the apache module? Paul. From tmz at pobox.com Wed May 24 06:43:29 2006 From: tmz at pobox.com (Todd Zullinger) Date: Wed, 24 May 2006 02:43:29 -0400 Subject: Mailman/Postfix execute_no_trans denial In-Reply-To: <1148368136.29091.21.camel@laurel.intra.city-fan.org> References: <20060521205817.GC18213@psilocybe.teonanacatl.org> <1148283602.7586.57.camel@laurel.intra.city-fan.org> <20060522205432.GM10533@psilocybe.teonanacatl.org> <20060523001741.GA12063@psilocybe.teonanacatl.org> <1148368136.29091.21.camel@laurel.intra.city-fan.org> Message-ID: <20060524064329.GA23402@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Howarth wrote: > On Mon, 2006-05-22 at 20:17 -0400, Todd Zullinger wrote: >> May 22 20:06:36 localhost kernel: audit(1148342796.578:36): avc: denied { search } for pid=9382 comm="python" name="log" dev=sda2 ino=489147 scontext=user_u:system_r:postfix_local_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=dir > > Looks like mailman trying to read the log file directory. May need a > policy change for this - I needed something similar for procmail. Could you point me toward the policy change you had to make for procmail? The inode referred to is indeed /var/log. Since mailman is patched by RH/Fedora to use /var/log/mailman I imagine that being able to read the log dir should be allowed or if mailman is trying to read more than it needs to read that should then be patched in the RH/Fedora mailman package. >> May 22 20:06:36 localhost kernel: audit(1148342796.582:37): avc: denied { write } for pid=9382 comm="python" name="in" dev=sda2 ino=491751 scontext=user_u:system_r:postfix_local_t:s0 tcontext=user_u:object_r:mailman_data_t:s0 tclass=dir > > Failed trying to write new file to directory /var/spool/mailman/in. > > I wonder if the mailman policy was written specifically with sendmail in > mind rather than postfix? That's certainly possible, but the denials in reading the log dir and writing to /var/spool/mailman/in would seem to be problems even when used with sendmail. If I get some time I will re-install sendmail on this system and see how well the mailman policy fares there. (That'll be a first for me, intentionally installing sendmail. :) It's odd too, as most (if not all?) the redhat.com lists use mailman and postfix. So I would have guessed the combination would have been tested more. It sure seems to be non-functional with SELinux enabled. Hopefully with a little testing here the policy can get updated. I imagine Dan Walsh has his hands full for quite a while after a new FC release. >> I'm not sure whether it's worth trying to chase every denial down >> this path or if there is a better fix that can be applied. > > I'm not sure. Running in permissive mode for a while should show up > all the denials you'll come across, but they might not all need > allowing, and if something has the wrong label, as appears to be the > case with /usr/lib/mailman/mail/mailman, then the denials won't be > useful anyway. That makes sense. Thanks for the info Paul. I don't have any need to roll out mailman with SELinux on any production boxes, so I'm in no great hurry. I just figured that since I was testing mailman and FC5 I'd try to help work out the SELinux issues as well. There's a bugzilla entry for mailman and postfix, but it dealt with a different method for integrating mailman and postfix using an external script. I'm not sure why in the bug this is referred to as "the most common method of postfix/mailman integration" as I would think the built in Postfix integration is more common. :) - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== The state is the great fictitious entity by which everyone seeks to live at the expense of everyone else. -- Fredric Bastiat -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iG0EARECAC0FAkR0AJEmGGh0dHA6Ly93d3cucG9ib3guY29tL350bXovcGdwL3Rt ei5hc2MACgkQuv+09NZUB1qX1QCcCrRI8cI3jgQh2XyC/gulXmLA/LkAn09EEh90 D80Cdt8lEJbHfRIbMdhC =eUFv -----END PGP SIGNATURE----- From paul at city-fan.org Wed May 24 07:17:33 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 24 May 2006 08:17:33 +0100 Subject: Stuff I found in my log? In-Reply-To: <44734285.13828.5D7877@knute.frazmtn.com> References: <44734285.13828.5D7877@knute.frazmtn.com> Message-ID: <1148455053.5228.101.camel@laurel.intra.city-fan.org> On Tue, 2006-05-23 at 17:12 -0700, Knute Johnson wrote: > I found some interesting things in my 'messages' log today. I'm not > sure what they mean and would appreciate any information. > > This one is the most bothersome. It appears that 'useradd' was > prevented from running this morning only I didn't run it. Would any > other programs run 'useradd' and what would cause it to be denied? > > May 23 05:11:49 rabbitbrush kernel: audit(1148386309.877:556): avc: > denied { write } for pid=13906 comm="useradd" name="[1708464]" > dev=pipefs ino=1708464 scontext=user_u:system_r:useradd_t:s0 > tcontext=user_u:system_r:unconfined_t:s0 tclass=fifo_file useradd is often run in the pre-install scripts of rpm packages when the package provides something that runs as a service. You probably updated such a package (or yum did it automatically in the overnight run). For instance, I got one of these when avahi was updated recently. The pre-install script for the avahi package is: # Add the "avahi" user /usr/sbin/useradd -c 'Avahi daemon' -u 70 \ -s /sbin/nologin -r -d '/' avahi 2> /dev/null || : The denial is coming because useradd is trying to write its output to a pipe, which is not allowed by policy. Perhaps it should be? Anyway, I think this one's harmless. > There are a boatload of these messages. I know that 'webalizer' is a > statistics formatter for the web server but why would it be run > dozens of times and be denied? > > May 23 04:02:02 rabbitbrush kernel: audit(1148382121.861:514): avc: > denied { create } for pid=12313 comm="webalizer" > scontext=user_u:system_r:webalizer_t:s0 > tcontext=user_u:system_r:webalizer_t:s0 tclass=netlink_route_socket I get these too. I asked about it yesterday but no response yet. Looking at the policy for other packages, and bearing in mind that webalizer still seems to work despite the denials, I suspect that these can be dontaudit-ed, but I'd like to know what they are first. Paul. From dwalsh at redhat.com Wed May 24 13:33:49 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 24 May 2006 09:33:49 -0400 Subject: Stuff I found in my log? In-Reply-To: <1148455053.5228.101.camel@laurel.intra.city-fan.org> References: <44734285.13828.5D7877@knute.frazmtn.com> <1148455053.5228.101.camel@laurel.intra.city-fan.org> Message-ID: <447460BD.4050708@redhat.com> Paul Howarth wrote: > On Tue, 2006-05-23 at 17:12 -0700, Knute Johnson wrote: > >> I found some interesting things in my 'messages' log today. I'm not >> sure what they mean and would appreciate any information. >> >> This one is the most bothersome. It appears that 'useradd' was >> prevented from running this morning only I didn't run it. Would any >> other programs run 'useradd' and what would cause it to be denied? >> >> May 23 05:11:49 rabbitbrush kernel: audit(1148386309.877:556): avc: >> denied { write } for pid=13906 comm="useradd" name="[1708464]" >> dev=pipefs ino=1708464 scontext=user_u:system_r:useradd_t:s0 >> tcontext=user_u:system_r:unconfined_t:s0 tclass=fifo_file >> > > useradd is often run in the pre-install scripts of rpm packages when the > package provides something that runs as a service. You probably updated > such a package (or yum did it automatically in the overnight run). For > instance, I got one of these when avahi was updated recently. The > pre-install script for the avahi package is: > > # Add the "avahi" user > /usr/sbin/useradd -c 'Avahi daemon' -u 70 \ > -s /sbin/nologin -r -d '/' avahi 2> /dev/null || : > > The denial is coming because useradd is trying to write its output to a > pipe, which is not allowed by policy. Perhaps it should be? > > Anyway, I think this one's harmless. > > The problem with that theory is you would expect it to be talking to rpm_script_t or rpm_t. Probably a leaked descriptor that useradd does not need to talk to, but applications that are handed open descriptors some times check their access, which could cause an AVC. >> There are a boatload of these messages. I know that 'webalizer' is a >> statistics formatter for the web server but why would it be run >> dozens of times and be denied? >> >> May 23 04:02:02 rabbitbrush kernel: audit(1148382121.861:514): avc: >> denied { create } for pid=12313 comm="webalizer" >> scontext=user_u:system_r:webalizer_t:s0 >> tcontext=user_u:system_r:webalizer_t:s0 tclass=netlink_route_socket >> > > I get these too. I asked about it yesterday but no response yet. Looking > at the policy for other packages, and bearing in mind that webalizer > still seems to work despite the denials, I suspect that these can be > dontaudit-ed, but I'd like to know what they are first. > This means webalizer is trying to look at the routing table. Not sure whether it matters whether it can or can not. Not that valuable of information so I will probably allow. > Paul. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From dwalsh at redhat.com Wed May 24 13:40:55 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 24 May 2006 09:40:55 -0400 Subject: httpd can't execute bash? In-Reply-To: <59DFCC57-4C95-40B3-BB20-AEFCEC844CFB@silentmedia.com> References: <59DFCC57-4C95-40B3-BB20-AEFCEC844CFB@silentmedia.com> Message-ID: <44746267.6060804@redhat.com> Ben wrote: > Is it a new thing that httpd can't execute bash? After a recent policy > upgrade, I'm seeing a lot of these: > > audit(1147792088.616:148): avc: denied { execute } for pid=1262 > comm="httpd" name="bash" dev=dm-0 ino=3267269 > scontext=system_u:system_r:httpd_t:s0 > tcontext=system_u:object_r:shell_exec_t:s0 tclass=file How do you have your booleans set? What Policy package are you running? getsebool -a | grep http > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From dwalsh at redhat.com Wed May 24 13:45:26 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 24 May 2006 09:45:26 -0400 Subject: selinux prelink avc's (broken paths in policy?) In-Reply-To: <4473337A.9060802@feuerpokemon.de> References: <4469F575.30609@feuerpokemon.de> <446EFB0B.8030508@feuerpokemon.de> <44731C1D.609@feuerpokemon.de> <1148395359.5228.2.camel@laurel.intra.city-fan.org> <4473250C.4020401@feuerpokemon.de> <44732578.70403@feuerpokemon.de> <44732772.7090302@feuerpokemon.de> <1148398247.5228.26.camel@laurel.intra.city-fan.org> <44732BA3.9050707@feuerpokemon.de> <1148400182.5228.43.camel@laurel.intra.city-fan.org> <4473337A.9060802@feuerpokemon.de> Message-ID: <44746376.2050504@redhat.com> dragoran wrote: > Paul Howarth wrote: >> On Tue, 2006-05-23 at 17:34 +0200, dragoran wrote: >> >>> Paul Howarth wrote: >>> >>>> On Tue, 2006-05-23 at 17:17 +0200, dragoran wrote: >>>> >>>>> dragoran wrote: >>>>> >>>>>> dragoran wrote: >>>>>> >>>>>>> Paul Howarth wrote: >>>>>>> >>>>>>>> On Tue, 2006-05-23 at 16:28 +0200, dragoran wrote: >>>>>>>> >>>>>>>> >>>>>>>>> dragoran wrote: >>>>>>>>> >>>>>>>>>> dragoran wrote: >>>>>>>>>> >>>>>>>>>>> audit(1147793154.831:353): avc: denied { execute_no_trans >>>>>>>>>>> } for pid=5195 comm="prelink" name="ld-2.4.so" dev=md0 >>>>>>>>>>> ino=8061163 scontext=system_u:system_r:prelink_t:s0 >>>>>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>>>>>>>> audit(1147793154.831:354): avc: denied { execute_no_trans >>>>>>>>>>> } for pid=5196 comm="prelink" name="ld-2.4.so" dev=md0 >>>>>>>>>>> ino=8061163 scontext=system_u:system_r:prelink_t:s0 >>>>>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>>>>>>>> audit(1147793155.019:355): avc: denied { execute_no_trans >>>>>>>>>>> } for pid=5197 comm="prelink" name="ld-2.4.so" dev=md0 >>>>>>>>>>> ino=8061163 scontext=system_u:system_r:prelink_t:s0 >>>>>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>>>>>>>> audit(1147793155.447:356): avc: denied { execute_no_trans >>>>>>>>>>> } for pid=5198 comm="prelink" name="ld-2.4.so" dev=md0 >>>>>>>>>>> ino=8061163 scontext=system_u:system_r:prelink_t:s0 >>>>>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>>>>>>>> audit(1147793156.255:357): avc: denied { execute_no_trans >>>>>>>>>>> } for pid=5199 comm="prelink" name="ld-2.4.so" dev=md0 >>>>>>>>>>> ino=8061163 scontext=system_u:system_r:prelink_t:s0 >>>>>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>>>>>>>> I am using FC5 with selinux-policy-targeted-2.2.36-2.fc5 >>>>>>>>>>> whats gonig on? is a file misslabeled or is this a policy bug? >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> fedora-selinux-list mailing list >>>>>>>>>>> fedora-selinux-list at redhat.com >>>>>>>>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> hello? >>>>>>>>>> any solution for this problem? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> it happend again... >>>>>>>>> am I the only one seeing this? >>>>>>>>> audit(1148393411.538:2907): avc: denied { execute_no_trans } >>>>>>>>> for pid=16856 comm="prelink" name="ld-2.4.so" dev=md0 >>>>>>>>> ino=8060939 scontext=system_u:system_r:prelink_t:s0 >>>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file >>>>>>>>> audit(1148393411.794:2908): avc: denied { execmod } for >>>>>>>>> pid=16859 comm="ld-linux.so.2" name="libGLcore.so.1.0.8762" >>>>>>>>> dev=md0 ino=29797475 scontext=system_u:system_r:prelink_t:s0 >>>>>>>>> tcontext=root:object_r:lib_t:s0 tclass=file >>>>>>>>> audit(1148393411.814:2909): avc: denied { execmod } for >>>>>>>>> pid=16860 comm="ld-linux.so.2" >>>>>>>>> name="libnvidia-tls.so.1.0.8762" dev=md0 ino=30869146 >>>>>>>>> scontext=system_u:system_r:prelink_t:s0 >>>>>>>>> tcontext=root:object_r:lib_t:s0 tclass=file >>>>>>>>> audit(1148393412.438:2910): avc: denied { unlink } for >>>>>>>>> pid=13702 comm="prelink" name="prelink.cache" dev=md0 >>>>>>>>> ino=7012828 scontext=system_u:system_r:prelink_t:s0 >>>>>>>>> tcontext=user_u:object_r:etc_t:s0 tclass=file >>>>>>>>> prelink seems to be completly broken and nobody seems to >>>>>>>>> notice it? >>>>>>>>> >>>>>>>> I'm not seeing this anywhere. >>>>>>>> >>>>>>>> Perhaps it's because /lib/ld-2.4.so is lib_t rather than >>>>>>>> ld_so_t on your >>>>>>>> system? >>>>>>>> >>>>>>>> Paul. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> ls -Z /lib/ld-2.4.so >>>>>>> -rwxr-xr-x root root system_u:object_r:ld_so_t >>>>>>> /lib/ld-2.4.so >>>>>>> ls -Z /lib64/ld-2.4.so >>>>>>> -rwxr-xr-x root root system_u:object_r:lib_t >>>>>>> seems that you are correct lets hope that this wont happen again. >>>>>>> >>>>>>> -- >>>>>>> fedora-selinux-list mailing list >>>>>>> fedora-selinux-list at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>>>>>> >>>>>>> >>>>>>> >>>>>> this *is* a bug >>>>>> restorecon /lib64/ld-2.4.so >>>>>> does not change it to ld_so_t (had to do a chcon) >>>>>> >>>>>> >>>>>> >>>>>> >>>>> I did a complete relabel and the result is >>>>> ls -Z /lib64/ld-2.4.so >>>>> -rwxr-xr-x root root system_u:object_r:lib_t >>>>> /lib64/ld-2.4.so >>>>> >>>> The context line that *should* match this appears to be: >>>> /lib(64)?(/.*)?/ld-[^/]*\.so(\.[^/]*)* regular file >>>> system_u:object_r:ld_so_t:s0 >>>> >>>> But this appears to be overruled by one of these: >>>> /lib(/.*)? all files >>>> system_u:object_r:lib_t:s0 >>>> /lib64(/.*)? all files >>>> system_u:object_r:lib_t:s0 >>>> >>>> I'm not sure what it is that decides which is the best match. The top >>>> one is longer and appears to me to be more specific, but it does have >>>> more wildcards in it... >>>> >>>> >>>>> I also noticed this: >>>>> drwxr-xr-x root root system_u:object_r:bin_t bin >>>>> drwxr-xr-x root root system_u:object_r:boot_t boot >>>>> drwxr-xr-x root root system_u:object_r:device_t dev >>>>> drwxr-xr-x root root system_u:object_r:etc_t etc >>>>> drwxr-xr-x root root system_u:object_r:home_root_t home >>>>> drwxr-xr-x root root system_u:object_r:lib_t lib >>>>> drwxr-xr-x root root system_u:object_r:lib_t lib64 >>>>> drwx------ root root system_u:object_r:lost_found_t >>>>> lost+found >>>>> drwxr-xr-x root root system_u:object_r:mnt_t media >>>>> drwxr-xr-x root root system_u:object_r:mnt_t misc >>>>> drwxr-xr-x root root system_u:object_r:mnt_t mnt >>>>> dr-xr-xr-x root root system_u:object_r:mnt_t net >>>>> drwxr-xr-x root root system_u:object_r:usr_t opt >>>>> dr-xr-xr-x root root system_u:object_r:proc_t proc >>>>> drwxr-x--- root root root:object_r:user_home_dir_t root >>>>> drwxr-xr-x root root system_u:object_r:sbin_t sbin >>>>> drwxr-xr-x root root system_u:object_r:security_t >>>>> selinux >>>>> drwxr-xr-x root root system_u:object_r:var_t srv >>>>> drwxr-xr-x root root system_u:object_r:sysfs_t sys >>>>> drwxrwxrwt root root system_u:object_r:tmp_t tmp >>>>> drwxr-xr-x root root system_u:object_r:usr_t usr >>>>> drwxr-xr-x root root system_u:object_r:var_t var >>>>> looks incorrect too whats going on here? >>>>> >>>> Looks like mine. What do you think is wrong with this? Nothing stands >>>> out to me. >>>> >>>> Paul. >>>> >>>> >>>> >>>> >>> root:object_r:user_home_dir_t root should be /home and >>> system_u:object_r:home_root_t home should be /root something >>> weird is going on here... >>> >> >> I disagree. I think these are correct. >> >> /root is the home directory for user "root" and should be >> user_home_dir_t, just like any other user's home directory. >> >> /home is the root of the "home" directory tree, where most user home >> directories live, so home_root_t seems OK for that. >> >> > thx got it >> Perhaps it's just the names of the context types that are confusing? >> > yes >> Paul. >> >> >> >> > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Yes /lib64/ld-2.4.so has the wrong context. These new sorting algorithms are driving me nuts. I have fixed it in Rawhide, and a new test package for fc5 is about to go out. From sds at tycho.nsa.gov Wed May 24 13:53:34 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 24 May 2006 09:53:34 -0400 Subject: Stuff I found in my log? In-Reply-To: <447460BD.4050708@redhat.com> References: <44734285.13828.5D7877@knute.frazmtn.com> <1148455053.5228.101.camel@laurel.intra.city-fan.org> <447460BD.4050708@redhat.com> Message-ID: <1148478814.24463.383.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-05-24 at 09:33 -0400, Daniel J Walsh wrote: > > I get these too. I asked about it yesterday but no response yet. Looking > > at the policy for other packages, and bearing in mind that webalizer > > still seems to work despite the denials, I suspect that these can be > > dontaudit-ed, but I'd like to know what they are first. > > > This means webalizer is trying to look at the routing table. Not sure > whether it matters whether it can or can not. Not that > valuable of information so I will probably allow. It is a common access attempt due to library probing. We commonly dontaudit it, but you could allow the read-only form (i.e. create read write nlmsg_read) to get routing information without being able to modify it (which requires nlmsg_write). Note the distinction: read and write permission means the ability to communicate with the kernel over the socket which is required for any kind of operation, whereas nlmsg_read and nlmsg_write correspond to the actual reading and writing of the routing table info (or other netlink-provided data). -- Stephen Smalley National Security Agency From paul at city-fan.org Wed May 24 13:57:31 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 24 May 2006 14:57:31 +0100 Subject: Stuff I found in my log? In-Reply-To: <447460BD.4050708@redhat.com> References: <44734285.13828.5D7877@knute.frazmtn.com> <1148455053.5228.101.camel@laurel.intra.city-fan.org> <447460BD.4050708@redhat.com> Message-ID: <4474664B.2090104@city-fan.org> Daniel J Walsh wrote: > Paul Howarth wrote: >> On Tue, 2006-05-23 at 17:12 -0700, Knute Johnson wrote: >> >>> I found some interesting things in my 'messages' log today. I'm not >>> sure what they mean and would appreciate any information. >>> >>> This one is the most bothersome. It appears that 'useradd' was >>> prevented from running this morning only I didn't run it. Would any >>> other programs run 'useradd' and what would cause it to be denied? >>> >>> May 23 05:11:49 rabbitbrush kernel: audit(1148386309.877:556): avc: >>> denied { write } for pid=13906 comm="useradd" name="[1708464]" >>> dev=pipefs ino=1708464 scontext=user_u:system_r:useradd_t:s0 >>> tcontext=user_u:system_r:unconfined_t:s0 tclass=fifo_file >>> >> >> useradd is often run in the pre-install scripts of rpm packages when the >> package provides something that runs as a service. You probably updated >> such a package (or yum did it automatically in the overnight run). For >> instance, I got one of these when avahi was updated recently. The >> pre-install script for the avahi package is: >> >> # Add the "avahi" user >> /usr/sbin/useradd -c 'Avahi daemon' -u 70 \ >> -s /sbin/nologin -r -d '/' avahi 2> /dev/null || : >> >> The denial is coming because useradd is trying to write its output to a >> pipe, which is not allowed by policy. Perhaps it should be? >> >> Anyway, I think this one's harmless. >> >> > The problem with that theory is you would expect it to be talking to > rpm_script_t or rpm_t. Probably a leaked > descriptor that useradd does not need to talk to, but applications that > are handed open descriptors some times check their > access, which could cause an AVC. Are you sure? rpm.te has: usermanage_domtrans_useradd(rpm_script_t) at least in serefpolicy-2.2.23 (don't have an up to date one to hand) >>> There are a boatload of these messages. I know that 'webalizer' is a >>> statistics formatter for the web server but why would it be run >>> dozens of times and be denied? >>> >>> May 23 04:02:02 rabbitbrush kernel: audit(1148382121.861:514): avc: >>> denied { create } for pid=12313 comm="webalizer" >>> scontext=user_u:system_r:webalizer_t:s0 >>> tcontext=user_u:system_r:webalizer_t:s0 tclass=netlink_route_socket >>> >> >> I get these too. I asked about it yesterday but no response yet. Looking >> at the policy for other packages, and bearing in mind that webalizer >> still seems to work despite the denials, I suspect that these can be >> dontaudit-ed, but I'd like to know what they are first. >> > This means webalizer is trying to look at the routing table. Not sure > whether it matters whether it can or can not. Not that > valuable of information so I will probably allow. OK, I'll add it locally for now too, to make my audit logs a lot smaller :-) Paul. From paul at city-fan.org Wed May 24 14:03:22 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 24 May 2006 15:03:22 +0100 Subject: Stuff I found in my log? In-Reply-To: <1148478814.24463.383.camel@moss-spartans.epoch.ncsc.mil> References: <44734285.13828.5D7877@knute.frazmtn.com> <1148455053.5228.101.camel@laurel.intra.city-fan.org> <447460BD.4050708@redhat.com> <1148478814.24463.383.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <447467AA.4060308@city-fan.org> Stephen Smalley wrote: > On Wed, 2006-05-24 at 09:33 -0400, Daniel J Walsh wrote: >>> I get these too. I asked about it yesterday but no response yet. Looking >>> at the policy for other packages, and bearing in mind that webalizer >>> still seems to work despite the denials, I suspect that these can be >>> dontaudit-ed, but I'd like to know what they are first. >>> >> This means webalizer is trying to look at the routing table. Not sure >> whether it matters whether it can or can not. Not that >> valuable of information so I will probably allow. > > It is a common access attempt due to library probing. We commonly > dontaudit it, but you could allow the read-only form (i.e. create read > write nlmsg_read) to get routing information without being able to > modify it (which requires nlmsg_write). Note the distinction: read and > write permission means the ability to communicate with the kernel over > the socket which is required for any kind of operation, whereas > nlmsg_read and nlmsg_write correspond to the actual reading and writing > of the routing table info (or other netlink-provided data). Is there a macro shorthand form of this or do I need to do: # Allow webalizer to read the routing table allow webalizer_t self:netlink_route_socket { create read write nlmsg_read }; Paul. From sds at tycho.nsa.gov Wed May 24 14:10:50 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 24 May 2006 10:10:50 -0400 Subject: Stuff I found in my log? In-Reply-To: <447467AA.4060308@city-fan.org> References: <44734285.13828.5D7877@knute.frazmtn.com> <1148455053.5228.101.camel@laurel.intra.city-fan.org> <447460BD.4050708@redhat.com> <1148478814.24463.383.camel@moss-spartans.epoch.ncsc.mil> <447467AA.4060308@city-fan.org> Message-ID: <1148479850.24463.388.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-05-24 at 15:03 +0100, Paul Howarth wrote: > Stephen Smalley wrote: > > On Wed, 2006-05-24 at 09:33 -0400, Daniel J Walsh wrote: > >>> I get these too. I asked about it yesterday but no response yet. Looking > >>> at the policy for other packages, and bearing in mind that webalizer > >>> still seems to work despite the denials, I suspect that these can be > >>> dontaudit-ed, but I'd like to know what they are first. > >>> > >> This means webalizer is trying to look at the routing table. Not sure > >> whether it matters whether it can or can not. Not that > >> valuable of information so I will probably allow. > > > > It is a common access attempt due to library probing. We commonly > > dontaudit it, but you could allow the read-only form (i.e. create read > > write nlmsg_read) to get routing information without being able to > > modify it (which requires nlmsg_write). Note the distinction: read and > > write permission means the ability to communicate with the kernel over > > the socket which is required for any kind of operation, whereas > > nlmsg_read and nlmsg_write correspond to the actual reading and writing > > of the routing table info (or other netlink-provided data). > > Is there a macro shorthand form of this or do I need to do: > > # Allow webalizer to read the routing table > allow webalizer_t self:netlink_route_socket { create read write > nlmsg_read }; policy/support/obj_perm_sets.spt defines r_netlink_socket_perms for that purpose, and rw_netlink_socket_perms for read-and-modify access. -- Stephen Smalley National Security Agency From paul at city-fan.org Wed May 24 14:22:54 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 24 May 2006 15:22:54 +0100 Subject: selinux prelink avc's (broken paths in policy?) In-Reply-To: <44746376.2050504@redhat.com> References: <4469F575.30609@feuerpokemon.de> <446EFB0B.8030508@feuerpokemon.de> <44731C1D.609@feuerpokemon.de> <1148395359.5228.2.camel@laurel.intra.city-fan.org> <4473250C.4020401@feuerpokemon.de> <44732578.70403@feuerpokemon.de> <44732772.7090302@feuerpokemon.de> <1148398247.5228.26.camel@laurel.intra.city-fan.org> <44732BA3.9050707@feuerpokemon.de> <1148400182.5228.43.camel@laurel.intra.city-fan.org> <4473337A.9060802@feuerpokemon.de> <44746376.2050504@redhat.com> Message-ID: <44746C3E.2030002@city-fan.org> Daniel J Walsh wrote: > Yes /lib64/ld-2.4.so has the wrong context. These new sorting > algorithms are driving me nuts. I have fixed it in Rawhide, and > a new test package for fc5 is about to go out. Is the sorting algorithm documented somewhere (the wiki?)? Paul. From cashworth at tresys.com Wed May 24 14:39:30 2006 From: cashworth at tresys.com (Christopher Ashworth) Date: Wed, 24 May 2006 10:39:30 -0400 Subject: selinux prelink avc's (broken paths in policy?) In-Reply-To: <44746C3E.2030002@city-fan.org> References: <4469F575.30609@feuerpokemon.de> <446EFB0B.8030508@feuerpokemon.de> <44731C1D.609@feuerpokemon.de> <1148395359.5228.2.camel@laurel.intra.city-fan.org> <4473250C.4020401@feuerpokemon.de> <44732578.70403@feuerpokemon.de> <44732772.7090302@feuerpokemon.de> <1148398247.5228.26.camel@laurel.intra.city-fan.org> <44732BA3.9050707@feuerpokemon.de> <1148400182.5228.43.camel@laurel.intra.city-fan.org> <4473337A.9060802@feuerpokemon.de> <44746376.2050504@redhat.com> <44746C3E.2030002@city-fan.org> Message-ID: <1148481570.517.7.camel@popeye.columbia.tresys.com> On Wed, 2006-05-24 at 15:22 +0100, Paul Howarth wrote: > Is the sorting algorithm documented somewhere (the wiki?)? The sorting algorithm is based on the following heuristics, applied in this order: When comparing two file contexts A and B... - if A is a regular expression and B is not, A is less specific than B - if A's stem length (the number of characters before the first regular expression wildcard) is shorter than B's stem length, A is less specific than B - if A's string length (the entire length of the file context string) is shorter than B's string length, A is less specific than B - if A does not have a specified type and B does, A is less specific than B. - else, they are considered equally specific. These are the same heuristics applied to file contexts when building reference policy. The sort is implemented as a stable iterative mergesort. Christopher From cashworth at tresys.com Wed May 24 14:43:48 2006 From: cashworth at tresys.com (Christopher Ashworth) Date: Wed, 24 May 2006 10:43:48 -0400 Subject: selinux prelink avc's (broken paths in policy?) In-Reply-To: <1148481570.517.7.camel@popeye.columbia.tresys.com> References: <4469F575.30609@feuerpokemon.de> <446EFB0B.8030508@feuerpokemon.de> <44731C1D.609@feuerpokemon.de> <1148395359.5228.2.camel@laurel.intra.city-fan.org> <4473250C.4020401@feuerpokemon.de> <44732578.70403@feuerpokemon.de> <44732772.7090302@feuerpokemon.de> <1148398247.5228.26.camel@laurel.intra.city-fan.org> <44732BA3.9050707@feuerpokemon.de> <1148400182.5228.43.camel@laurel.intra.city-fan.org> <4473337A.9060802@feuerpokemon.de> <44746376.2050504@redhat.com> <44746C3E.2030002@city-fan.org> <1148481570.517.7.camel@popeye.columbia.tresys.com> Message-ID: <1148481828.517.11.camel@popeye.columbia.tresys.com> On Wed, 2006-05-24 at 10:39 -0400, Christopher Ashworth wrote: > - if A's stem length (the number of characters before the first > regular expression wildcard) is shorter than B's stem length, A is > less specific than B "Wildcard" isn't the best word to use here. "Meta character" is better. They include: . ^ $ ? * + | [ ( { Chris From paul at city-fan.org Wed May 24 15:06:32 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 24 May 2006 16:06:32 +0100 Subject: selinux prelink avc's (broken paths in policy?) In-Reply-To: <1148481570.517.7.camel@popeye.columbia.tresys.com> References: <4469F575.30609@feuerpokemon.de> <446EFB0B.8030508@feuerpokemon.de> <44731C1D.609@feuerpokemon.de> <1148395359.5228.2.camel@laurel.intra.city-fan.org> <4473250C.4020401@feuerpokemon.de> <44732578.70403@feuerpokemon.de> <44732772.7090302@feuerpokemon.de> <1148398247.5228.26.camel@laurel.intra.city-fan.org> <44732BA3.9050707@feuerpokemon.de> <1148400182.5228.43.camel@laurel.intra.city-fan.org> <4473337A.9060802@feuerpokemon.de> <44746376.2050504@redhat.com> <44746C3E.2030002@city-fan.org> <1148481570.517.7.camel@popeye.columbia.tresys.com> Message-ID: <44747678.2010505@city-fan.org> Christopher Ashworth wrote: > On Wed, 2006-05-24 at 15:22 +0100, Paul Howarth wrote: > >> Is the sorting algorithm documented somewhere (the wiki?)? > > The sorting algorithm is based on the following heuristics, applied in > this order: > > When comparing two file contexts A and B... > > - if A is a regular expression and B is not, A is less specific than B > - if A's stem length (the number of characters before the first regular > expression wildcard) is shorter than B's stem length, A is less specific > than B > - if A's string length (the entire length of the file context string) is > shorter than B's string length, A is less specific than B > - if A does not have a specified type and B does, A is less specific > than B. > - else, they are considered equally specific. If there are two or more equally specific matches, is one picked at random? Paul. From cashworth at tresys.com Wed May 24 15:12:36 2006 From: cashworth at tresys.com (Christopher Ashworth) Date: Wed, 24 May 2006 11:12:36 -0400 Subject: selinux prelink avc's (broken paths in policy?) In-Reply-To: <44747678.2010505@city-fan.org> References: <4469F575.30609@feuerpokemon.de> <446EFB0B.8030508@feuerpokemon.de> <44731C1D.609@feuerpokemon.de> <1148395359.5228.2.camel@laurel.intra.city-fan.org> <4473250C.4020401@feuerpokemon.de> <44732578.70403@feuerpokemon.de> <44732772.7090302@feuerpokemon.de> <1148398247.5228.26.camel@laurel.intra.city-fan.org> <44732BA3.9050707@feuerpokemon.de> <1148400182.5228.43.camel@laurel.intra.city-fan.org> <4473337A.9060802@feuerpokemon.de> <44746376.2050504@redhat.com> <44746C3E.2030002@city-fan.org> <1148481570.517.7.camel@popeye.columbia.tresys.com> <44747678.2010505@city-fan.org> Message-ID: <1148483556.517.16.camel@popeye.columbia.tresys.com> On Wed, 2006-05-24 at 16:06 +0100, Paul Howarth wrote: > Christopher Ashworth wrote: > > On Wed, 2006-05-24 at 15:22 +0100, Paul Howarth wrote: > > > >> Is the sorting algorithm documented somewhere (the wiki?)? > > > > The sorting algorithm is based on the following heuristics, applied in > > this order: > > > > When comparing two file contexts A and B... > > > > - if A is a regular expression and B is not, A is less specific than B > > - if A's stem length (the number of characters before the first regular > > expression wildcard) is shorter than B's stem length, A is less specific > > than B > > - if A's string length (the entire length of the file context string) is > > shorter than B's string length, A is less specific than B > > - if A does not have a specified type and B does, A is less specific > > than B. > > - else, they are considered equally specific. > > If there are two or more equally specific matches, is one picked at random? > > Paul. The sort is stable, so the order of the original file contexts is maintained. The result is a list of all the file contexts sorted from least specific to most specific. When assigning the file contexts, the list is consulted in order of most to least specific. The first match wins. If there were two contexts that are considered equally specific, the original order given by the author will determine which one wins. Chris From dwalsh at redhat.com Wed May 24 15:20:32 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 24 May 2006 11:20:32 -0400 Subject: selinux prelink avc's (broken paths in policy?) In-Reply-To: <1148483556.517.16.camel@popeye.columbia.tresys.com> References: <4469F575.30609@feuerpokemon.de> <446EFB0B.8030508@feuerpokemon.de> <44731C1D.609@feuerpokemon.de> <1148395359.5228.2.camel@laurel.intra.city-fan.org> <4473250C.4020401@feuerpokemon.de> <44732578.70403@feuerpokemon.de> <44732772.7090302@feuerpokemon.de> <1148398247.5228.26.camel@laurel.intra.city-fan.org> <44732BA3.9050707@feuerpokemon.de> <1148400182.5228.43.camel@laurel.intra.city-fan.org> <4473337A.9060802@feuerpokemon.de> <44746376.2050504@redhat.com> <44746C3E.2030002@city-fan.org> <1148481570.517.7.camel@popeye.columbia.tresys.com> <44747678.2010505@city-fan.org> <1148483556.517.16.camel@popeye.columbia.tresys.com> Message-ID: <447479C0.9080501@redhat.com> Christopher Ashworth wrote: > On Wed, 2006-05-24 at 16:06 +0100, Paul Howarth wrote: > >> Christopher Ashworth wrote: >> >>> On Wed, 2006-05-24 at 15:22 +0100, Paul Howarth wrote: >>> >>> >>>> Is the sorting algorithm documented somewhere (the wiki?)? >>>> >>> The sorting algorithm is based on the following heuristics, applied in >>> this order: >>> >>> When comparing two file contexts A and B... >>> >>> - if A is a regular expression and B is not, A is less specific than B >>> - if A's stem length (the number of characters before the first regular >>> expression wildcard) is shorter than B's stem length, A is less specific >>> than B >>> - if A's string length (the entire length of the file context string) is >>> shorter than B's string length, A is less specific than B >>> - if A does not have a specified type and B does, A is less specific >>> than B. >>> - else, they are considered equally specific. >>> >> If there are two or more equally specific matches, is one picked at random? >> >> Paul. >> > > The sort is stable, so the order of the original file contexts is > maintained. The result is a list of all the file contexts sorted from > least specific to most specific. > > When assigning the file contexts, the list is consulted in order of most > to least specific. The first match wins. If there were two contexts > that are considered equally specific, the original order given by the > author will determine which one wins. > > Chris > Chris I just put some of your comments on my Blog and out on http://fedoraproject.org/wiki/SELinux I have better understanding of this now. From paul at city-fan.org Wed May 24 15:20:33 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 24 May 2006 16:20:33 +0100 Subject: selinux prelink avc's (broken paths in policy?) In-Reply-To: <1148483556.517.16.camel@popeye.columbia.tresys.com> References: <4469F575.30609@feuerpokemon.de> <446EFB0B.8030508@feuerpokemon.de> <44731C1D.609@feuerpokemon.de> <1148395359.5228.2.camel@laurel.intra.city-fan.org> <4473250C.4020401@feuerpokemon.de> <44732578.70403@feuerpokemon.de> <44732772.7090302@feuerpokemon.de> <1148398247.5228.26.camel@laurel.intra.city-fan.org> <44732BA3.9050707@feuerpokemon.de> <1148400182.5228.43.camel@laurel.intra.city-fan.org> <4473337A.9060802@feuerpokemon.de> <44746376.2050504@redhat.com> <44746C3E.2030002@city-fan.org> <1148481570.517.7.camel@popeye.columbia.tresys.com> <44747678.2010505@city-fan.org> <1148483556.517.16.camel@popeye.columbia.tresys.com> Message-ID: <447479C1.3080404@city-fan.org> Christopher Ashworth wrote: > On Wed, 2006-05-24 at 16:06 +0100, Paul Howarth wrote: >> Christopher Ashworth wrote: >>> On Wed, 2006-05-24 at 15:22 +0100, Paul Howarth wrote: >>> >>>> Is the sorting algorithm documented somewhere (the wiki?)? >>> The sorting algorithm is based on the following heuristics, applied in >>> this order: >>> >>> When comparing two file contexts A and B... >>> >>> - if A is a regular expression and B is not, A is less specific than B >>> - if A's stem length (the number of characters before the first regular >>> expression wildcard) is shorter than B's stem length, A is less specific >>> than B >>> - if A's string length (the entire length of the file context string) is >>> shorter than B's string length, A is less specific than B >>> - if A does not have a specified type and B does, A is less specific >>> than B. >>> - else, they are considered equally specific. >> If there are two or more equally specific matches, is one picked at random? >> >> Paul. > > The sort is stable, so the order of the original file contexts is > maintained. The result is a list of all the file contexts sorted from > least specific to most specific. > > When assigning the file contexts, the list is consulted in order of most > to least specific. The first match wins. If there were two contexts > that are considered equally specific, the original order given by the > author will determine which one wins. So in other words, in the event of a tie, the one nearest the bottom of the list (in the file_contexts file or the output of "semanage fcontext -l") is determined to be the most specific and that one wins. Is that right? Paul. From paul at city-fan.org Wed May 24 15:23:38 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 24 May 2006 16:23:38 +0100 Subject: selinux prelink avc's (broken paths in policy?) In-Reply-To: <1148481570.517.7.camel@popeye.columbia.tresys.com> References: <4469F575.30609@feuerpokemon.de> <446EFB0B.8030508@feuerpokemon.de> <44731C1D.609@feuerpokemon.de> <1148395359.5228.2.camel@laurel.intra.city-fan.org> <4473250C.4020401@feuerpokemon.de> <44732578.70403@feuerpokemon.de> <44732772.7090302@feuerpokemon.de> <1148398247.5228.26.camel@laurel.intra.city-fan.org> <44732BA3.9050707@feuerpokemon.de> <1148400182.5228.43.camel@laurel.intra.city-fan.org> <4473337A.9060802@feuerpokemon.de> <44746376.2050504@redhat.com> <44746C3E.2030002@city-fan.org> <1148481570.517.7.camel@popeye.columbia.tresys.com> Message-ID: <44747A7A.7040700@city-fan.org> Christopher Ashworth wrote: > On Wed, 2006-05-24 at 15:22 +0100, Paul Howarth wrote: > >> Is the sorting algorithm documented somewhere (the wiki?)? > > The sorting algorithm is based on the following heuristics, applied in > this order: > > When comparing two file contexts A and B... > > - if A is a regular expression and B is not, A is less specific than B > - if A's stem length (the number of characters before the first regular > expression wildcard) is shorter than B's stem length, A is less specific > than B > - if A's string length (the entire length of the file context string) is > shorter than B's string length, A is less specific than B > - if A does not have a specified type and B does, A is less specific > than B. > - else, they are considered equally specific. > > These are the same heuristics applied to file contexts when building > reference policy. > > The sort is implemented as a stable iterative mergesort. Thanks - I added this to the wiki: http://fedoraproject.org/wiki/SELinux/ManagingFileContext I suspect that Dan is currently writing a new page: http://fedoraproject.org/wiki/SELinux/FileContext Paul. From dwalsh at redhat.com Wed May 24 15:26:41 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 24 May 2006 11:26:41 -0400 Subject: need help for local.te In-Reply-To: <1866.128.252.85.103.1148058795.squirrel@morpheus.wustl.edu> References: <3584.128.252.85.103.1148050690.squirrel@morpheus.wustl.edu> <1148051687.25168.140.camel@moss-spartans.epoch.ncsc.mil> <1866.128.252.85.103.1148058795.squirrel@morpheus.wustl.edu> Message-ID: <44747B31.3040501@redhat.com> Hongwei Li wrote: >> On Fri, 2006-05-19 at 09:58 -0500, Hongwei Li wrote: >> >>> Hi, >>> >>> I need help about local.te. My system: >>> >>> kernel: 2.6.16-1.2111_FC5smp >>> selinux-policy-targeted: 2.2.38-1.fc5 >>> audit: 1.1.5-1 >>> sendmail: 8.13.6-0.FC5.1 >>> squirrelmail: 1.4.6-5.fc5 >>> >>> When I try to create an email folder in squirrelmail, I got Error. So, I >>> run >>> the following to create my local.te and add my module. Here are what I run >>> and get: >>> >>> # audit2allow -M local < /var/log/audit/audit.log >>> Generating type enforcment file: local.te >>> Compiling policy >>> checkmodule -M -m -o local.mod local.te >>> semodule_package -o local.pp -m local.mod >>> >>> ******************** IMPORTANT *********************** >>> >>> In order to load this newly created policy package into the kernel, >>> you are required to execute >>> >>> semodule -i local.pp >>> >>> # ls -l >>> total 40 >>> -rw-r--r-- 1 root root 2448 May 19 09:46 local.mod >>> -rw-r--r-- 1 root root 2464 May 19 09:46 local.pp >>> -rw-r--r-- 1 root root 733 May 19 09:46 local.te >>> >>> # semodule -i local.pp >>> libsepol.check_assertion_helper: assertion on line 0 violated by allow >>> httpd_t >>> shadow_t:file { read }; >>> libsepol.check_assertions: 1 assertion violations occured >>> libsemanage.semanage_expand_sandbox: Expand module failed >>> semodule: Failed! >>> >>> How to solve the problem? >>> >>> Thanks! >>> >> This means that your local.te file includes a rule that allows httpd to >> read your /etc/shadow file, and this violates an assertion in the base >> policy. Review your local.te file, prune entries that are not >> legitimate, and rebuild the .mod and .pp files, e.g. >> # vi local.te # edit out bogus entries or replace them with dontaudit rules >> # checkmodule -m -M -o local.mod local.te >> # semodule_package -o local.pp -m local.mod >> # semodule -i local.pp >> >> -- >> Stephen Smalley >> National Security Agency >> > > The problem is I need to re-do for local.te from time to time, and whenver I > run (after rebooting) > # audit2allow -M local < /var/log/audit/audit.log > the line > > allow httpd_t shadow_t:file { getattr read write }; > > is automatically added to local.te -- this time, it added more, not just read. > I believe that this is because I need to run change_password plugin in > squirrelmail. It is not a problem in fc4 selinux -- I run audit2allow to add > entry into local.te and run make load, then everything is working. But, in > fc5, it is a problem. If I remove that line, then whenever I run the above > command, it is automatically added. > > How to fix the problem? > If this is not causing a problem for squirrelmail, how about dontaudit httpd_t shadow_t:file { getattr read write }; Also you can create more than one pp file. So you could create local1.pp and local2.pp ... You should always edit make sure you only have the rules in your pp file that you want. If these are legitimate problems with policy or some package, are you submitting bugzillas? Dan > Thanks! > > Hongwei > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From dwalsh at redhat.com Wed May 24 15:30:35 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 24 May 2006 11:30:35 -0400 Subject: printer AVCs.... In-Reply-To: <4c4ba1530605190902q5c981798m31d36366654f159@mail.gmail.com> References: <4c4ba1530605190902q5c981798m31d36366654f159@mail.gmail.com> Message-ID: <44747C1B.5030704@redhat.com> Tom London wrote: > Running latest Rawhide, targeted/enforcing. > > I get the following when 'deactivating/activating' a USB printer (and > printing fails): > > type=AVC msg=audit(1148052935.119:30): avc: denied { create } for > pid=1902 comm="python" scontext=system_u:system_r:hplip_t:s0 > tcontext=system_u:system_r:hplip_t:s0 tclass=netlink_route_socket > type=SYSCALL msg=audit(1148052935.119:30): arch=40000003 syscall=102 > success=no exit=-13 a0=1 a1=bffa4878 a2=49ebaff4 a3=bffa4e69 items=0 > pid=1902 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=(none) comm="python" exe="/usr/bin/python" > subj=system_u:system_r:hplip_t:s0 > type=SOCKETCALL msg=audit(1148052935.119:30): nargs=3 a0=10 a1=3 a2=0 > > type=USER_AVC msg=audit(1148053114.333:32): user pid=1735 uid=81 > auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0 msg='avc: > denied { send_msg } for msgtype=signal > interface=com.redhat.PrinterSpooler member=JobQueuedLocal > dest=org.freedesktop.DBus spid=1913 tpid=2748 > scontext=system_u:system_r:cupsd_t:SystemLow-SystemHigh > tcontext=user_u:system_r:unconfined_execmem_t tclass=dbus : exe="?" > (sauid=81, hostname=?, addr=?, terminal=?)' > What is the unconfined_execmem_t application? > The following messages were in /var/log/messages: > > May 19 08:35:33 localhost dbus: Can't send to audit system: USER_AVC > avc: denied { send_msg } for msgtype=signal > interface=com.redhat.PrinterSpooler member=JobQueuedLocal > dest=org.freedesktop.DBus spid=1913 tpid=2748 > scontext=system_u:system_r:cupsd_t:SystemLow-SystemHigh > tcontext=user_u:system_r:unconfined_execmem_t tclass=dbus : exe="?" > (sauid=81, hostname=?, addr=?, terminal=?) > May 19 08:35:33 localhost dbus: Can't send to audit system: USER_AVC > avc: denied { send_msg } for msgtype=signal > interface=com.redhat.PrinterSpooler member=QueueChanged > dest=org.freedesktop.DBus spid=1913 tpid=2748 > scontext=system_u:system_r:cupsd_t:SystemLow-SystemHigh > tcontext=user_u:system_r:unconfined_execmem_t tclass=dbus : exe="?" > (sauid=81, hostname=?, addr=?, terminal=?) > May 19 08:35:33 localhost dbus: Can't send to audit system: USER_AVC > avc: denied { send_msg } for msgtype=signal > interface=com.redhat.PrinterSpooler member=JobStartedLocal > dest=org.freedesktop.DBus spid=1913 tpid=2748 > scontext=system_u:system_r:cupsd_t:SystemLow-SystemHigh > tcontext=user_u:system_r:unconfined_execmem_t tclass=dbus : exe="?" > (sauid=81, hostname=?, addr=?, terminal=?) > May 19 08:35:35 localhost hpiod: invalid product id string: Broken > pipe io/hpiod/device.cpp 623 > May 19 08:35:35 localhost hpiod: unable to Device::Open > hp:/usb/hp_LaserJet_1300?serial=00CNCB954325 io/hpiod/device.cpp 862 > May 19 08:35:35 localhost hp_LaserJet_1300?serial=00CNCB954325: INFO: > open device failed; will retry in 30 seconds... > May 19 08:36:05 localhost hpiod: invalid product id string: Broken > pipe io/hpiod/device.cpp 623 > > tom From cashworth at tresys.com Wed May 24 15:32:32 2006 From: cashworth at tresys.com (Christopher Ashworth) Date: Wed, 24 May 2006 11:32:32 -0400 Subject: selinux prelink avc's (broken paths in policy?) In-Reply-To: <447479C1.3080404@city-fan.org> References: <4469F575.30609@feuerpokemon.de> <446EFB0B.8030508@feuerpokemon.de> <44731C1D.609@feuerpokemon.de> <1148395359.5228.2.camel@laurel.intra.city-fan.org> <4473250C.4020401@feuerpokemon.de> <44732578.70403@feuerpokemon.de> <44732772.7090302@feuerpokemon.de> <1148398247.5228.26.camel@laurel.intra.city-fan.org> <44732BA3.9050707@feuerpokemon.de> <1148400182.5228.43.camel@laurel.intra.city-fan.org> <4473337A.9060802@feuerpokemon.de> <44746376.2050504@redhat.com> <44746C3E.2030002@city-fan.org> <1148481570.517.7.camel@popeye.columbia.tresys.com> <44747678.2010505@city-fan.org> <1148483556.517.16.camel@popeye.columbia.tresys.com> <447479C1.3080404@city-fan.org> Message-ID: <1148484753.517.23.camel@popeye.columbia.tresys.com> On Wed, 2006-05-24 at 16:20 +0100, Paul Howarth wrote: > So in other words, in the event of a tie, the one nearest the bottom of > the list (in the file_contexts file or the output of "semanage fcontext > -l") is determined to be the most specific and that one wins. Is that right? When I do "semanage fcontext -l" I don't get an ordered listing (so this does not appear to be correct in that case), but yes, this is correct for the file_contexts file. It would be ideal to make the algorithm do a proper sort based on strict regular expression subsets, but this is non-trivial and these heuristics work pretty well. Chris From dwalsh at redhat.com Wed May 24 15:35:30 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 24 May 2006 11:35:30 -0400 Subject: denied execheap, for httpd with zend optimizer (fc5) In-Reply-To: <4472C435.9060308@firm.ee> References: <446F65DD.3070600@firm.ee> <446F77A4.2000908@firm.ee> <4472C435.9060308@firm.ee> Message-ID: <44747D42.8010109@redhat.com> Jaak Simm wrote: > Hi again, > > Can anyone verify that Zend Optimizer generates a execheap denial in > FC5? Or is it just my problem? Zend Optimizer is needed to run binary > php code, which is common for commercial php projects. > > Simple steps to install Zend Optimizer and verify the problem: > 0. you have to have httpd and php installed (yum install httpd php) > > 1. Download and unpack Zend Optimizer 3 > http://www.zend.com/products/zend_optimizer > (requires a zend.com user, which can be created for free at the > download site) > > 2. Run ./install in the unpacked dir of Zend Optimizer > It will ask few questions, but defaults should be fine. > > 3. Allow execheap, give zend files correct security context, and > remove their execstack requirement: > setsebool allow_execheap 1 > chcon -t httpd_modules_t -u system_u `find /usr/local/Zend/lib/ > -name \*.so` > execstack -c `find /usr/local/Zend/lib/ -name \*.so` allow_execheap only effects "unconfined processes. If you want this rule for httpd you will need to build a policy module. grep execheap /var/log/messages | audit2allow -m Zend semodule -i Zend.pp Should add this rule. You might want to read up on execheap on the following http://people.redhat.com/~drepper/selinux-mem.html And report this as a bug to the Zend people. > > 4. restart httpd: > service httpd restart > > 5. check /var/log/messages (whether an avc execheap denial occured, > when httpd restarted) > > Send an e-mail to the list or to me with your results. If it is a > common problem, then I'll report a bug. > > Regards, > Jaak > > Jaak Simm wrote: >> One additional comment. The command line version of php works with >> zend optimizer, no selinux troubles there. >> Only httpd with php and zend optimizer creates the execheap problem. >> >> The context of Zend Optimizer's .so files is: >> system_u:object_r:httpd_modules_t >> >> Is execheap allowed in some contexts and disabled in others? >> >> Regards, >> Jaak >> >> Jaak Simm wrote: >>> Hi all, >>> >>> I'm installing Zend Optimizer 3.0 for httpd in FC5. After giving >>> correct security context with chcon and removing execstack >>> requirement from its .so files I'm still stuck with "denied >>> {execheap}" error in the /var/log/messages, when the httpd starts: >>> May 20 21:33:26 web2 kernel: audit(1148150006.772:751): avc: >>> denied { execheap } for pid=2584 comm="httpd" >>> scontext=root:system_r:httpd_t:s0 tcontext=root:system_r:httpd_t:s0 >>> tclass=process >>> >>> I have enabled allow_execheap: >>> # getsebool allow_execheap >>> allow_execheap --> on >>> >>> Also restarted the computer, but "denied {execheap}" message is >>> present and Zend Optimizer does not work. >>> >>> Any comments and hints from selinux gurus, besides disabling selinux? >>> >>> Thanks, >>> Jaak >>> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From paul at city-fan.org Wed May 24 15:38:30 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 24 May 2006 16:38:30 +0100 Subject: selinux prelink avc's (broken paths in policy?) In-Reply-To: <1148484753.517.23.camel@popeye.columbia.tresys.com> References: <4469F575.30609@feuerpokemon.de> <446EFB0B.8030508@feuerpokemon.de> <44731C1D.609@feuerpokemon.de> <1148395359.5228.2.camel@laurel.intra.city-fan.org> <4473250C.4020401@feuerpokemon.de> <44732578.70403@feuerpokemon.de> <44732772.7090302@feuerpokemon.de> <1148398247.5228.26.camel@laurel.intra.city-fan.org> <44732BA3.9050707@feuerpokemon.de> <1148400182.5228.43.camel@laurel.intra.city-fan.org> <4473337A.9060802@feuerpokemon.de> <44746376.2050504@redhat.com> <44746C3E.2030002@city-fan.org> <1148481570.517.7.camel@popeye.columbia.tresys.com> <44747678.2010505@city-fan.org> <1148483556.517.16.camel@popeye.columbia.tresys.com> <447479C1.3080404@city-fan.org> <1148484753.517.23.camel@popeye.columbia.tresys.com> Message-ID: <44747DF6.6090001@city-fan.org> Christopher Ashworth wrote: > On Wed, 2006-05-24 at 16:20 +0100, Paul Howarth wrote: > >> So in other words, in the event of a tie, the one nearest the bottom of >> the list (in the file_contexts file or the output of "semanage fcontext >> -l") is determined to be the most specific and that one wins. Is that right? > > When I do "semanage fcontext -l" I don't get an ordered listing (so this > does not appear to be correct in that case), but yes, this is correct > for the file_contexts file. > > It would be ideal to make the algorithm do a proper sort based on strict > regular expression subsets, but this is non-trivial and these heuristics > work pretty well. So if "semanage fcontext -l" doesn't produce an ordered listing, is there any way from userland to get one, one that encompasses both the base policy and any added modules or context objects added using semanage? I take it as read that semanage-added objects and the file contexts from policy module packages (.pp files) are seen as "later" in the list than the base file_contexts file, but which has precedence for semanage/semodule? Last one in? Does it make a difference whether "semodule -i" or "semodule -u" are used? Paul. From cashworth at tresys.com Wed May 24 16:56:31 2006 From: cashworth at tresys.com (Christopher Ashworth) Date: Wed, 24 May 2006 12:56:31 -0400 Subject: selinux prelink avc's (broken paths in policy?) In-Reply-To: <44747DF6.6090001@city-fan.org> References: <4469F575.30609@feuerpokemon.de> <446EFB0B.8030508@feuerpokemon.de> <44731C1D.609@feuerpokemon.de> <1148395359.5228.2.camel@laurel.intra.city-fan.org> <4473250C.4020401@feuerpokemon.de> <44732578.70403@feuerpokemon.de> <44732772.7090302@feuerpokemon.de> <1148398247.5228.26.camel@laurel.intra.city-fan.org> <44732BA3.9050707@feuerpokemon.de> <1148400182.5228.43.camel@laurel.intra.city-fan.org> <4473337A.9060802@feuerpokemon.de> <44746376.2050504@redhat.com> <44746C3E.2030002@city-fan.org> <1148481570.517.7.camel@popeye.columbia.tresys.com> <44747678.2010505@city-fan.org> <1148483556.517.16.camel@popeye.columbia.tresys.com> <447479C1.3080404@city-fan.org> <1148484753.517.23.camel@popeye.columbia.tresys.com> <44747DF6.6090001@city-fan.org> Message-ID: <1148489791.517.46.camel@popeye.columbia.tresys.com> On Wed, 2006-05-24 at 16:38 +0100, Paul Howarth wrote: > So if "semanage fcontext -l" doesn't produce an ordered listing, is > there any way from userland to get one, one that encompasses both the > base policy and any added modules or context objects added using semanage? I don't know the definitive answer on a userland tool. semanage fcontext -l appears to just be calling libsemanage, which is in turn using Ivan's database functions to list the objects (in this case, the fcontext objects). I'll try to track down what happens between the file_contexts file and the listing. > I take it as read that semanage-added objects and the file contexts from > policy module packages (.pp files) are seen as "later" in the list than > the base file_contexts file, but which has precedence for > semanage/semodule? Last one in? Does it make a difference whether > "semodule -i" or "semodule -u" are used? When semanage_direct_commit is invoked in libsemanage, the following things happen: - any modules are linked to the base module - the file contexts in the linked base are sorted - the file contexts are split into the file_contexts file and the other template files, and written to disk (well, to the sandbox, which is then loaded in a separate step) - any semanage-added "database" objects are then merged Thus, all fcontexts in the linked base (i.e. any fcontext associated with a module) are sorted together. The semanage-added objects are done last, outside of the module sorting, and so would have precedence, as I understand it. The database code is a little opaque and not well documented, so there may be some subtlety I'm missing as to how the database objects are merged, but this is my current understanding. Chris From paul at city-fan.org Wed May 24 17:04:10 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 24 May 2006 18:04:10 +0100 Subject: selinux prelink avc's (broken paths in policy?) In-Reply-To: <1148489791.517.46.camel@popeye.columbia.tresys.com> References: <4469F575.30609@feuerpokemon.de> <446EFB0B.8030508@feuerpokemon.de> <44731C1D.609@feuerpokemon.de> <1148395359.5228.2.camel@laurel.intra.city-fan.org> <4473250C.4020401@feuerpokemon.de> <44732578.70403@feuerpokemon.de> <44732772.7090302@feuerpokemon.de> <1148398247.5228.26.camel@laurel.intra.city-fan.org> <44732BA3.9050707@feuerpokemon.de> <1148400182.5228.43.camel@laurel.intra.city-fan.org> <4473337A.9060802@feuerpokemon.de> <44746376.2050504@redhat.com> <44746C3E.2030002@city-fan.org> <1148481570.517.7.camel@popeye.columbia.tresys.com> <44747678.2010505@city-fan.org> <1148483556.517.16.camel@popeye.columbia.tresys.com> <447479C1.3080404@city-fan.org> <1148484753.517.23.camel@popeye.columbia.tresys.com> <44747DF6.6090001@city-fan.org> <1148489791.517.46.camel@popeye.columbia.tresys.com> Message-ID: <4474920A.4050801@city-fan.org> Christopher Ashworth wrote: > On Wed, 2006-05-24 at 16:38 +0100, Paul Howarth wrote: >> So if "semanage fcontext -l" doesn't produce an ordered listing, is >> there any way from userland to get one, one that encompasses both the >> base policy and any added modules or context objects added using semanage? > > I don't know the definitive answer on a userland tool. semanage > fcontext -l appears to just be calling libsemanage, which is in turn > using Ivan's database functions to list the objects (in this case, the > fcontext objects). I'll try to track down what happens between the > file_contexts file and the listing. > >> I take it as read that semanage-added objects and the file contexts from >> policy module packages (.pp files) are seen as "later" in the list than >> the base file_contexts file, but which has precedence for >> semanage/semodule? Last one in? Does it make a difference whether >> "semodule -i" or "semodule -u" are used? > > When semanage_direct_commit is invoked in libsemanage, the following > things happen: > > - any modules are linked to the base module > - the file contexts in the linked base are sorted > - the file contexts are split into the file_contexts file and the other > template files, and written to disk (well, to the sandbox, which is then > loaded in a separate step) > - any semanage-added "database" objects are then merged > > Thus, all fcontexts in the linked base (i.e. any fcontext associated > with a module) are sorted together. The semanage-added objects are done > last, outside of the module sorting, and so would have precedence, as I > understand it. The database code is a little opaque and not well > documented, so there may be some subtlety I'm missing as to how the > database objects are merged, but this is my current understanding. I think the best policy, for the avoidance of confusion for people writing policy modules or calling semanage in rpm post-install scripts, is to encourage them to use strings that will sort as "more specific", i.e. avoid metacharacters if possible, and if not, use as long a stem as possible. This probably means having two separate entries for things that will go under /lib or /lib64, rather than the current idiom of /lib(64)?, which has a metacharacter very early in the string. Paul. From sds at tycho.nsa.gov Wed May 24 17:10:42 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 24 May 2006 13:10:42 -0400 Subject: selinux prelink avc's (broken paths in policy?) In-Reply-To: <4474920A.4050801@city-fan.org> References: <4469F575.30609@feuerpokemon.de> <446EFB0B.8030508@feuerpokemon.de> <44731C1D.609@feuerpokemon.de> <1148395359.5228.2.camel@laurel.intra.city-fan.org> <4473250C.4020401@feuerpokemon.de> <44732578.70403@feuerpokemon.de> <44732772.7090302@feuerpokemon.de> <1148398247.5228.26.camel@laurel.intra.city-fan.org> <44732BA3.9050707@feuerpokemon.de> <1148400182.5228.43.camel@laurel.intra.city-fan.org> <4473337A.9060802@feuerpokemon.de> <44746376.2050504@redhat.com> <44746C3E.2030002@city-fan.org> <1148481570.517.7.camel@popeye.columbia.tresys.com> <44747678.2010505@city-fan.org> <1148483556.517.16.camel@popeye.columbia.tresys.com> <447479C1.3080404@city-fan.org> <1148484753.517.23.camel@popeye.columbia.tresys.com> <44747DF6.6090001@city-fan.org> <1148489791.517.46.camel@popeye.columbia.tresys.com> <4474920A.4050801@city-fan.org> Message-ID: <1148490642.24463.460.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-05-24 at 18:04 +0100, Paul Howarth wrote: > I think the best policy, for the avoidance of confusion for people > writing policy modules or calling semanage in rpm post-install scripts, > is to encourage them to use strings that will sort as "more specific", > i.e. avoid metacharacters if possible, and if not, use as long a stem as > possible. This probably means having two separate entries for things > that will go under /lib or /lib64, rather than the current idiom of > /lib(64)?, which has a metacharacter very early in the string. Yes, this would be desirable even in the base policy module. -- Stephen Smalley National Security Agency From paul at city-fan.org Wed May 24 17:35:08 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 24 May 2006 18:35:08 +0100 Subject: selinux prelink avc's (broken paths in policy?) In-Reply-To: <1148490642.24463.460.camel@moss-spartans.epoch.ncsc.mil> References: <4469F575.30609@feuerpokemon.de> <446EFB0B.8030508@feuerpokemon.de> <44731C1D.609@feuerpokemon.de> <1148395359.5228.2.camel@laurel.intra.city-fan.org> <4473250C.4020401@feuerpokemon.de> <44732578.70403@feuerpokemon.de> <44732772.7090302@feuerpokemon.de> <1148398247.5228.26.camel@laurel.intra.city-fan.org> <44732BA3.9050707@feuerpokemon.de> <1148400182.5228.43.camel@laurel.intra.city-fan.org> <4473337A.9060802@feuerpokemon.de> <44746376.2050504@redhat.com> <44746C3E.2030002@city-fan.org> <1148481570.517.7.camel@popeye.columbia.tresys.com> <44747678.2010505@city-fan.org> <1148483556.517.16.camel@popeye.columbia.tresys.com> <447479C1.3080404@city-fan.org> <1148484753.517.23.camel@popeye.columbia.tresys.com> <44747DF6.6090001@city-fan.org> <1148489791.517.46.camel@popeye.columbia.tresys.com> <4474920A.4050801@city-fan.org> <1148490642.24463.460.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4474994C.4010002@city-fan.org> Stephen Smalley wrote: > On Wed, 2006-05-24 at 18:04 +0100, Paul Howarth wrote: >> I think the best policy, for the avoidance of confusion for people >> writing policy modules or calling semanage in rpm post-install scripts, >> is to encourage them to use strings that will sort as "more specific", >> i.e. avoid metacharacters if possible, and if not, use as long a stem as >> possible. This probably means having two separate entries for things >> that will go under /lib or /lib64, rather than the current idiom of >> /lib(64)?, which has a metacharacter very early in the string. > > Yes, this would be desirable even in the base policy module. Yes, and it explains why in the earlier thread "Re: unconfined_execmem_t for /usr/lib/jvm/java-1.5.0-sun-1.5.0.06/jre/bin/java ?" we had /usr/lib/jvm/java-1.5.0-sun-1.5.0.06/jre/bin/java labelled as bin_t rather than java_exec_t with the following file context entries in the base policy: /usr/lib(.*/)?bin/java([^/]*)? regular file system_u:object_r:java_exec_t:s0 /usr/lib/jvm/java.*/bin/.* all files system_u:object_r:bin_t:s0 Paul. From shin216 at xf7.so-net.ne.jp Thu May 25 09:28:46 2006 From: shin216 at xf7.so-net.ne.jp (Shintaro Fujiwara) Date: Thu, 25 May 2006 18:28:46 +0900 Subject: faied update a module In-Reply-To: <1148452436.5228.91.camel@laurel.intra.city-fan.org> References: <1148424636.1931.23.camel@papa.intrajp-yokosuka.co.jp> <1148452436.5228.91.camel@laurel.intra.city-fan.org> Message-ID: <1148549326.2443.5.camel@papa.intrajp-yokosuka.co.jp> Thank you for your advice paul. There were two different rpm versions in my system. So, I rpm -e ed altogether after disabled SELiunx first. Then I rpm -ivh ed same version as others and made it O.K. sorry for my mis-spelling... 2006-05-24 07:33 +0100 Paul Howarth wrote: > On Wed, 2006-05-24 at 07:50 +0900, Shintaro Fujiwara wrote: > > I yum updated lately. > > I edited .te file and made apache.pp > > When I tried to update apache.pp > > > > [root at intrajp devel]# semodule -u apache.pp > > libsepol.class_copy_callback: apache: Modules may not yet declare new > > classes. > > libsemanage.semanage_link_sandbox: Link packages failed > > semodule: Failed! > > > > Why and how shoul I do ? > > I got the same message last week when I tried installing a .pp file that > had been built against an older selinux-policy package. > > Did you make the module on the same machine you're trying to install it > on? > > Does "semodule -i apache.pp" give the same error? > > Do you get the same error if you first remove the apache module? > > Paul. > From mcolef at nyit.edu Thu May 25 12:18:32 2006 From: mcolef at nyit.edu (Michael Colef) Date: Thu, 25 May 2006 08:18:32 -0400 Subject: Fedora Core +SELinux +VMware GSX server Message-ID: <1148559512.2511.9.camel@michaelc.nyit.edu> I am wondering if anyone has any information about setting up SELinux policies or sample policy files for a Fedora Core host running VMware GSX server. I am presently looking at both FC4 and FC5. Any help is highly appreciated. Michael Colef NYIT From cashworth at tresys.com Thu May 25 15:49:22 2006 From: cashworth at tresys.com (Christopher Ashworth) Date: Thu, 25 May 2006 11:49:22 -0400 Subject: selinux prelink avc's (broken paths in policy?) In-Reply-To: <1148489791.517.46.camel@popeye.columbia.tresys.com> References: <4469F575.30609@feuerpokemon.de> <446EFB0B.8030508@feuerpokemon.de> <44731C1D.609@feuerpokemon.de> <1148395359.5228.2.camel@laurel.intra.city-fan.org> <4473250C.4020401@feuerpokemon.de> <44732578.70403@feuerpokemon.de> <44732772.7090302@feuerpokemon.de> <1148398247.5228.26.camel@laurel.intra.city-fan.org> <44732BA3.9050707@feuerpokemon.de> <1148400182.5228.43.camel@laurel.intra.city-fan.org> <4473337A.9060802@feuerpokemon.de> <44746376.2050504@redhat.com> <44746C3E.2030002@city-fan.org> <1148481570.517.7.camel@popeye.columbia.tresys.com> <44747678.2010505@city-fan.org> <1148483556.517.16.camel@popeye.columbia.tresys.com> <447479C1.3080404@city-fan.org> <1148484753.517.23.camel@popeye.columbia.tresys.com> <44747DF6.6090001@city-fan.org> <1148489791.517.46.camel@popeye.columbia.tresys.com> Message-ID: <1148572162.13769.5.camel@popeye.columbia.tresys.com> On Wed, 2006-05-24 at 12:56 -0400, Christopher Ashworth wrote: > On Wed, 2006-05-24 at 16:38 +0100, Paul Howarth wrote: > > So if "semanage fcontext -l" doesn't produce an ordered listing, is > > there any way from userland to get one, one that encompasses both the > > base policy and any added modules or context objects added using semanage? > > I don't know the definitive answer on a userland tool. semanage > fcontext -l appears to just be calling libsemanage, which is in turn > using Ivan's database functions to list the objects (in this case, the > fcontext objects). I'll try to track down what happens between the > file_contexts file and the listing. I had a chance to take another look at this this morning. In semanage (seobject.py, specifically), the list of file contexts being retrieved via semanage_fcontext_list is in the correct order. However, it is transfered to a dictionary and printed out by iterating over the keys of the dictionary. Changing this will allow semanage to report the file contexts in the original order. Christopher From jochen.wiedmann at gmail.com Fri May 26 06:03:59 2006 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Fri, 26 May 2006 08:03:59 +0200 Subject: CGI Script permissions Message-ID: <44769A4F.1060807@gmail.com> Hi, I have a CGI script which ought to have some special permissions. In particular, it ought to invoke a certain command as a certain user. To achieve that, I have created an entry in the sudoers file, which allows the httpd user to invoke the command without a password. Now my CGI script does a sudo -u mp /u2/mp/mpbin/mpfak 001 where mp is the special user, mpfak is the necessary command and the remaining part is the mp programs argument. However, when the program is invoked, then I see the following message in syslog: May 26 07:49:21 fibudbserver kernel: audit(1148622561.696:14): avc: denied { setrlimit } for pid=31749 comm="sudo" scontext=root:system_r:httpd_sys_script_t tcontext=root:system_r:httpd_sys_script_t tclass=process May 26 07:49:21 fibudbserver kernel: audit(1148622561.699:15): avc: denied { setgid } for pid=31749 comm="sudo" capability=6 scontext=root:system_r:httpd_sys_script_t tcontext=root:system_r:httpd_sys_script_t tclass=capability May 26 07:49:21 fibudbserver kernel: audit(1148622561.699:16): avc: denied { setuid } for pid=31749 comm="sudo" capability=7 scontext=root:system_r:httpd_sys_script_t tcontext=root:system_r:httpd_sys_script_t tclass=capability May 26 07:49:21 fibudbserver kernel: audit(1148622561.700:17): avc: denied { search } for pid=31749 comm="sudo" name="/" dev=sda5 ino=2 scontext=root:system_r:httpd_sys_script_t tcontext=system_u:object_r:file_t tclass=dir May 26 07:49:21 fibudbserver kernel: audit(1148622561.700:18): avc: denied { setgid } for pid=31749 comm="sudo" capability=6 scontext=root:system_r:httpd_sys_script_t tcontext=root:system_r:httpd_sys_script_t tclass=capability May 26 07:49:21 fibudbserver kernel: audit(1148622561.700:19): avc: denied { setuid } for pid=31749 comm="sudo" capability=7 scontext=root:system_r:httpd_sys_script_t tcontext=root:system_r:httpd_sys_script_t tclass=capability I must admit, that I do not even understand whether I ought to change my scripts permissions or the "sudo" programs. I do hesitate to do either. Can anyone please advice me how to continue? For example, I might as well invoke sudo from a wrapper script and change that scripts permissions. Question is: How would I do that? Regards, Jochen From paul at city-fan.org Fri May 26 06:50:49 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 26 May 2006 07:50:49 +0100 Subject: CGI Script permissions In-Reply-To: <44769A4F.1060807@gmail.com> References: <44769A4F.1060807@gmail.com> Message-ID: <1148626250.8185.39.camel@laurel.intra.city-fan.org> On Fri, 2006-05-26 at 08:03 +0200, Jochen Wiedmann wrote: > Hi, > > I have a CGI script which ought to have some special permissions. In > particular, it ought to invoke a certain command as a certain user. To > achieve that, I have created an entry in the sudoers file, which allows > the httpd user to invoke the command without a password. Now my CGI > script does a > > sudo -u mp /u2/mp/mpbin/mpfak 001 > > where mp is the special user, mpfak is the necessary command and the > remaining part is the mp programs argument. > > However, when the program is invoked, then I see the following message > in syslog: > > May 26 07:49:21 fibudbserver kernel: audit(1148622561.696:14): avc: > denied { setrlimit } for pid=31749 comm="sudo" > scontext=root:system_r:httpd_sys_script_t > tcontext=root:system_r:httpd_sys_script_t tclass=process > May 26 07:49:21 fibudbserver kernel: audit(1148622561.699:15): avc: > denied { setgid } for pid=31749 comm="sudo" capability=6 > scontext=root:system_r:httpd_sys_script_t > tcontext=root:system_r:httpd_sys_script_t tclass=capability > May 26 07:49:21 fibudbserver kernel: audit(1148622561.699:16): avc: > denied { setuid } for pid=31749 comm="sudo" capability=7 > scontext=root:system_r:httpd_sys_script_t > tcontext=root:system_r:httpd_sys_script_t tclass=capability > May 26 07:49:21 fibudbserver kernel: audit(1148622561.700:17): avc: > denied { search } for pid=31749 comm="sudo" name="/" dev=sda5 ino=2 > scontext=root:system_r:httpd_sys_script_t > tcontext=system_u:object_r:file_t tclass=dir > May 26 07:49:21 fibudbserver kernel: audit(1148622561.700:18): avc: > denied { setgid } for pid=31749 comm="sudo" capability=6 > scontext=root:system_r:httpd_sys_script_t > tcontext=root:system_r:httpd_sys_script_t tclass=capability > May 26 07:49:21 fibudbserver kernel: audit(1148622561.700:19): avc: > denied { setuid } for pid=31749 comm="sudo" capability=7 > scontext=root:system_r:httpd_sys_script_t > tcontext=root:system_r:httpd_sys_script_t tclass=capability > > I must admit, that I do not even understand whether I ought to change my > scripts permissions or the "sudo" programs. I do hesitate to do either. > > Can anyone please advice me how to continue? For example, I might as > well invoke sudo from a wrapper script and change that scripts > permissions. Question is: How would I do that? The simplest fix might be to change the file context of this particular CGI script to httpd_unconfined_script_exec_t instead of httpd_sys_script_t. That would effectively turn off SELinux protection for that particular script. The alternative approach of using audit2allow to create a local policy to allow these capabilities would turn on these capabilities for *all* of your CGI scripts, which IMHO would be worse than turning off protection for just that one script (particularly if that script was well-audited for security issues). Ideally it would be easy to create a subclass of CGI scripts and assign special capabilities to those (I have a similar issue with FastCGI scripts that need slightly more capabilities than regular CGI scripts), but that's beyond me at this moment. Paul. From jochen.wiedmann at gmail.com Fri May 26 08:46:24 2006 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Fri, 26 May 2006 10:46:24 +0200 Subject: CGI Script permissions Message-ID: <4476C060.7040306@gmail.com> Paul Howarth wrote: > The simplest fix might be to change the file context of this particular > CGI script to httpd_unconfined_script_exec_t instead of > httpd_sys_script_t. That would effectively turn off SELinux protection > for that particular script. > The alternative approach of using audit2allow to create a local policy > to allow these capabilities would turn on these capabilities for *all* > of your CGI scripts, which IMHO would be worse than turning off > protection for just that one script (particularly if that script was > well-audited for security issues). > Ideally it would be easy to create a subclass of CGI scripts and assign > special capabilities to those (I have a similar issue with FastCGI > scripts that need slightly more capabilities than regular CGI scripts), > but that's beyond me at this moment. As the script in question can indeed be called well-audited (basically, it just allows to trigger a certain action by calling another script with fixed attributes), I have decided to go with httpd_unconfined_script_exec_t. That did the trick neatly. Thanks very much, Jochen From dwalsh at redhat.com Fri May 26 10:27:25 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 26 May 2006 06:27:25 -0400 Subject: CGI Script permissions In-Reply-To: <4476C060.7040306@gmail.com> References: <4476C060.7040306@gmail.com> Message-ID: <4476D80D.8090600@redhat.com> Jochen Wiedmann wrote: > Paul Howarth wrote: > > >> The simplest fix might be to change the file context of this particular >> CGI script to httpd_unconfined_script_exec_t instead of >> httpd_sys_script_t. That would effectively turn off SELinux protection >> for that particular script. >> > > >> The alternative approach of using audit2allow to create a local policy >> to allow these capabilities would turn on these capabilities for *all* >> of your CGI scripts, which IMHO would be worse than turning off >> protection for just that one script (particularly if that script was >> well-audited for security issues). >> > > >> Ideally it would be easy to create a subclass of CGI scripts and assign >> special capabilities to those (I have a similar issue with FastCGI >> scripts that need slightly more capabilities than regular CGI scripts), >> but that's beyond me at this moment. >> > > As the script in question can indeed be called well-audited (basically, it > just allows to trigger a certain action by calling another script with > fixed attributes), I have decided to go with httpd_unconfined_script_exec_t. > That did the trick neatly. > > Thanks very much, > > Jochen > Another alternative might be to write your own module Create three files # cat >> myapache.te << _EOF policy_module(myapache,1.0.0) apache_content_template(myapache) allow httpd_myapache_script_t self:capability setuid; allow httpd_myapache_script_t self:process setrlimit; _EOF echo > myapache.if # cat >> myapache.te << _EOF /var/www/cgi-bin/myapache_script -- gen_context(system_u:object_r:httpd_myapache_script_exec_t,s0) _EOF Then build a policy module. make -f /usr/share/selinux/devel/Makefile semodule -i myapache.pp restorecon -F -v /var/www/cgi-bin/myapache_script Then try it out. Of course you might need additional rules. > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From paul at city-fan.org Fri May 26 12:59:44 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 26 May 2006 13:59:44 +0100 Subject: SELinux Module Packaging in FC5 In-Reply-To: <1148044323.25168.81.camel@moss-spartans.epoch.ncsc.mil> References: <44169B09.3050508@city-fan.org> <1142341123.3713.36.camel@moss-spartans.epoch.ncsc.mil> <4469DCF1.2080406@city-fan.org> <80d7e4090605160834r1efc0d6ata7ee23d9ea67d6f9@mail.gmail.com> <4469F629.4010803@city-fan.org> <1147797025.30789.180.camel@moss-spartans.epoch.ncsc.mil> <4469FEEE.5090403@city-fan.org> <1147798738.30789.200.camel@moss-spartans.epoch.ncsc.mil> <446A0783.1010503@city-fan.org> <446C6B16.4060709@city-fan.org> <446C740E.4090706@city-fan.org> <1148044323.25168.81.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4476FBC0.30000@city-fan.org> Stephen Smalley wrote: > On Thu, 2006-05-18 at 14:18 +0100, Paul Howarth wrote: >> Another query regarding policy module packages in RPMs: >> >> Supposing a package is installed when the system has SELinux disabled. >> >> What would happen if semodule was called to install a policy module? >> >> If the result is that nothing happens (or semodule bombs out with an >> error of some sort), what would then happen if the system subsequently >> had SELinux enabled and the system was relabelled? Would the package >> containing the policy module have to be reinstalled? >> >> I'd try it myself but I can't bring myself to disable SELinux on any of >> my boxes and go through the whole relabelling process. > > If policy is installed on the system, then semodule (actually > libsemanage) will install the module and rebuild the generated files, > but will not try to load policy into the kernel since SELinux is > disabled. Then, if you enable SELinux, the module will already be > included in the policy. > > If policy is not installed on the system, then semodule will abort with > an error like this: > semodule: SELinux policy is not managed or store cannot be accessed. > > Note also that one should generally use semodule -s as in > the selinux-policy .spec file to indicate which kind of policy your > module is built for (targeted, strict, mls). Then, if the system is > running a different kind of policy, semodule will know to install the > module to the proper location (not the active policy) and to not try to > load it. OK, just to recap where I think we're up to. Here are the relevant parts of my current spec file for the application "contagged", which will have a policy module package included: *** Top of spec, so that FC4/FC5 packages can build from same SRPM: # FC5 and later include SELinux policy module packages %if 0%{?fedora} < 5 %define selinux_module 0 %define selinux_variants %{nil} %else %define selinux_module 1 %define selinux_variants mls strict targeted %endif *** Buildreq needed for building .pp files: %if %{selinux_module} # selinux-policy >= 2.2.40 needed because of #190561 BuildRequires: checkpolicy, selinux-policy >= 2.2.40 %endif *** Build .pp file for each base policy (SELinux directory contains te/fc/if files): %build %if %{selinux_module} cd SELinux for selinuxvariant in %{selinux_variants} do %{__make} NAME=${selinuxvariant} verbose=@ \ -f /usr/share/selinux/devel/Makefile %{__mv} SELinux/contagged.pp contagged.pp.${selinuxvariant} %{__make} NAME=${selinuxvariant} \ -f /usr/share/selinux/devel/Makefile clean done cd - %endif *** Install .pp files %install ... usual stuff ... # Install SELinux policy modules %if %{selinux_module} for selinuxvariant in %{selinux_variants} do %{__install} -d %{buildroot}%{_datadir}/selinux/${selinuxvariant} %{__install} -p -m 644 contagged.pp.${selinuxvariant} \ %{buildroot}%{_datadir}/selinux/${selinuxvariant}/contagged.pp done %endif *** post-install scriptlet installs policy modules and fixes contexts: %if %{selinux_module} %post # Install SELinux policy modules if [ -x /usr/sbin/semodule ]; then for selinuxvariant in %{selinux_variants} do /usr/sbin/semodule -s ${selinuxvariant} -i \ %{_datadir}/selinux/${selinuxvariant}/contagged.pp \ &> /dev/null || : done fi # Fix up non-standard directory context [ -x /sbin/restorecon ] && /sbin/restorecon \ %{_localstatedir}/cache/contagged || : %endif *** pre-uninstall script removes policy modules (and removes app's cache, not SELinux-related)): %postun # Clean up after package removal if [ $1 -eq 0 ]; then # Clean out the cache %{__rm} -f %{_localstatedir}/cache/contagged/*.tpl.php /bin/rmdir %{_localstatedir}/cache/contagged &> /dev/null || : %if %{selinux_module} # Remove SELinux policy modules if [ -x /usr/sbin/semodule ]; then for selinuxvariant in %{selinux_variants} do /usr/sbin/semodule -s ${selinuxvariant} -r contagged || : done fi %endif fi *** %files section includes policy module packages: %files ... usual stuff ... %if %{selinux_module} %dir %{_datadir}/selinux/* %{_datadir}/selinux/*/contagged.pp %endif Now Dan tells me in #190561 that one .pp file should be OK for all base policies if there is no MLS-specific stuff in the policy. So: * If there was MLS-specific stuff in the policy module, would the approach above be correct? * As there is no MLS-specific stuff in my package, I'd be inclined to make a single .pp file, put it in %{_datadir}/selinux/share/contagged.pp and just load that one .pp file for each base policy in %post Dan also comments in #190561 that "ou only need to install it with semodule, you do not need to intall the pp file"; I don't get this, as how will semodule be able to access the .pp file if it isn't installed with the package... I'm also considering adding some horrible hack like this: %if %{selinux_module} %define selinux_policyver %(sed -e 's,.*selinux-policy-\\([^/]*\\)/.*,\\1,' /usr/share/selinux/devel/policyhelp) Conflicts: selinux-policy < %{selinux_policyver} %endif to avoid problems like this: http://www.redhat.com/archives/fedora-selinux-list/2006-May/msg00102.html My overall plan for this package is: 1. In conjuction with fedora-selinux-list, make this as clean a package as possible SELinux-wise, such that it can form a good example for others wishing to include policy module packages in their RPM packages. 2. In conjuction with fedora-extras-list, do the same from the point of view of a PHP web application (the usual difficulty with these is that upstream writes them in such a way that they're designed to be untarred somewhere under /var/www and then just work, but that's not FHS-compliant and not a good example). 3. Get the package accepted into Fedora Extras. 4. Include documentation on the wiki at http://fedoraproject.org/wiki/Packaging/SELinux explaining why things in the package are done the way they are, as a guide for other packagers. Paul. From dwalsh at redhat.com Fri May 26 13:17:39 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 26 May 2006 09:17:39 -0400 Subject: SELinux Module Packaging in FC5 In-Reply-To: <4476FBC0.30000@city-fan.org> References: <44169B09.3050508@city-fan.org> <1142341123.3713.36.camel@moss-spartans.epoch.ncsc.mil> <4469DCF1.2080406@city-fan.org> <80d7e4090605160834r1efc0d6ata7ee23d9ea67d6f9@mail.gmail.com> <4469F629.4010803@city-fan.org> <1147797025.30789.180.camel@moss-spartans.epoch.ncsc.mil> <4469FEEE.5090403@city-fan.org> <1147798738.30789.200.camel@moss-spartans.epoch.ncsc.mil> <446A0783.1010503@city-fan.org> <446C6B16.4060709@city-fan.org> <446C740E.4090706@city-fan.org> <1148044323.25168.81.camel@moss-spartans.epoch.ncsc.mil> <4476FBC0.30000@city-fan.org> Message-ID: <4476FFF3.7020707@redhat.com> Paul Howarth wrote: > Stephen Smalley wrote: >> On Thu, 2006-05-18 at 14:18 +0100, Paul Howarth wrote: >>> Another query regarding policy module packages in RPMs: >>> >>> Supposing a package is installed when the system has SELinux disabled. >>> >>> What would happen if semodule was called to install a policy module? >>> >>> If the result is that nothing happens (or semodule bombs out with an >>> error of some sort), what would then happen if the system >>> subsequently had SELinux enabled and the system was relabelled? >>> Would the package containing the policy module have to be reinstalled? >>> >>> I'd try it myself but I can't bring myself to disable SELinux on any >>> of my boxes and go through the whole relabelling process. >> >> If policy is installed on the system, then semodule (actually >> libsemanage) will install the module and rebuild the generated files, >> but will not try to load policy into the kernel since SELinux is >> disabled. Then, if you enable SELinux, the module will already be >> included in the policy. >> >> If policy is not installed on the system, then semodule will abort with >> an error like this: >> semodule: SELinux policy is not managed or store cannot be accessed. >> >> Note also that one should generally use semodule -s as in >> the selinux-policy .spec file to indicate which kind of policy your >> module is built for (targeted, strict, mls). Then, if the system is >> running a different kind of policy, semodule will know to install the >> module to the proper location (not the active policy) and to not try to >> load it. > > OK, just to recap where I think we're up to. Here are the relevant > parts of my current spec file for the application "contagged", which > will have a policy module package included: > > *** Top of spec, so that FC4/FC5 packages can build from same SRPM: > > # FC5 and later include SELinux policy module packages > %if 0%{?fedora} < 5 > %define selinux_module 0 > %define selinux_variants %{nil} > %else > %define selinux_module 1 > %define selinux_variants mls strict targeted > %endif > > *** Buildreq needed for building .pp files: > > %if %{selinux_module} > # selinux-policy >= 2.2.40 needed because of #190561 > BuildRequires: checkpolicy, selinux-policy >= 2.2.40 > %endif > > *** Build .pp file for each base policy (SELinux directory contains > te/fc/if files): > > %build > %if %{selinux_module} > cd SELinux > for selinuxvariant in %{selinux_variants} > do > %{__make} NAME=${selinuxvariant} verbose=@ \ > -f /usr/share/selinux/devel/Makefile > %{__mv} SELinux/contagged.pp contagged.pp.${selinuxvariant} > %{__make} NAME=${selinuxvariant} \ > -f /usr/share/selinux/devel/Makefile clean > done > cd - > %endif > > *** Install .pp files > > %install > ... usual stuff ... > # Install SELinux policy modules > %if %{selinux_module} > for selinuxvariant in %{selinux_variants} > do > %{__install} -d %{buildroot}%{_datadir}/selinux/${selinuxvariant} > %{__install} -p -m 644 contagged.pp.${selinuxvariant} \ > %{buildroot}%{_datadir}/selinux/${selinuxvariant}/contagged.pp > done > %endif > > *** post-install scriptlet installs policy modules and fixes contexts: > > %if %{selinux_module} > %post > # Install SELinux policy modules > if [ -x /usr/sbin/semodule ]; then > for selinuxvariant in %{selinux_variants} > do > /usr/sbin/semodule -s ${selinuxvariant} -i \ > %{_datadir}/selinux/${selinuxvariant}/contagged.pp \ > &> /dev/null || : > done > fi Does this fail silently if the policy package is not installed? > # Fix up non-standard directory context > [ -x /sbin/restorecon ] && /sbin/restorecon \ > %{_localstatedir}/cache/contagged || : > %endif > > > *** pre-uninstall script removes policy modules (and removes app's > cache, not SELinux-related)): > > %postun > # Clean up after package removal > if [ $1 -eq 0 ]; then > # Clean out the cache > %{__rm} -f %{_localstatedir}/cache/contagged/*.tpl.php > /bin/rmdir %{_localstatedir}/cache/contagged &> /dev/null || : > %if %{selinux_module} > # Remove SELinux policy modules > if [ -x /usr/sbin/semodule ]; then > for selinuxvariant in %{selinux_variants} > do > /usr/sbin/semodule -s ${selinuxvariant} -r contagged || : > done > fi You might need to fixup contexts here also, if you leave anything behind. > > %endif > fi > > *** %files section includes policy module packages: > > %files > ... usual stuff ... > %if %{selinux_module} > %dir %{_datadir}/selinux/* > %{_datadir}/selinux/*/contagged.pp > %endif > > > > > Now Dan tells me in #190561 that one .pp file should be OK for all > base policies if there is no MLS-specific stuff in the policy. So: > > * If there was MLS-specific stuff in the policy module, would the > approach above be correct? > > * As there is no MLS-specific stuff in my package, I'd be inclined to > make a single .pp file, put it in > %{_datadir}/selinux/share/contagged.pp and just load that one .pp file > for each base policy in %post > > Dan also comments in #190561 that "ou only need to install it with > semodule, you do not need to intall the pp file"; I don't get this, as > how will semodule be able to access the .pp file if it isn't installed > with the package... Sorry you are right. The only thing is you should not put the pp file in /usr/share/selinux/VARIANT, as the current policy package does a semodule -i of all pp files in that directory. (Which I should really change) So if someone does a semodule -r later, the policy upgrade will reinstall. My point about the pp file, is that you do not need to leave it on disk or even use it again after it has been installed. As a matter of fact semodule copies the pp file to /etc/selinux/VARIANT/modules/active/modules/ > > I'm also considering adding some horrible hack like this: > > %if %{selinux_module} > %define selinux_policyver %(sed -e > 's,.*selinux-policy-\\([^/]*\\)/.*,\\1,' > /usr/share/selinux/devel/policyhelp) > Conflicts: selinux-policy < %{selinux_policyver} > %endif > > to avoid problems like this: > http://www.redhat.com/archives/fedora-selinux-list/2006-May/msg00102.html > > > My overall plan for this package is: > 1. In conjuction with fedora-selinux-list, make this as clean a > package as possible SELinux-wise, such that it can form a good example > for others wishing to include policy module packages in their RPM > packages. > 2. In conjuction with fedora-extras-list, do the same from the point > of view of a PHP web application (the usual difficulty with these is > that upstream writes them in such a way that they're designed to be > untarred somewhere under /var/www and then just work, but that's not > FHS-compliant and not a good example). > 3. Get the package accepted into Fedora Extras. > 4. Include documentation on the wiki at > http://fedoraproject.org/wiki/Packaging/SELinux explaining why things > in the package are done the way they are, as a guide for other packagers. > > Paul. > From paul at city-fan.org Fri May 26 13:29:27 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 26 May 2006 14:29:27 +0100 Subject: SELinux Module Packaging in FC5 In-Reply-To: <4476FFF3.7020707@redhat.com> References: <44169B09.3050508@city-fan.org> <1142341123.3713.36.camel@moss-spartans.epoch.ncsc.mil> <4469DCF1.2080406@city-fan.org> <80d7e4090605160834r1efc0d6ata7ee23d9ea67d6f9@mail.gmail.com> <4469F629.4010803@city-fan.org> <1147797025.30789.180.camel@moss-spartans.epoch.ncsc.mil> <4469FEEE.5090403@city-fan.org> <1147798738.30789.200.camel@moss-spartans.epoch.ncsc.mil> <446A0783.1010503@city-fan.org> <446C6B16.4060709@city-fan.org> <446C740E.4090706@city-fan.org> <1148044323.25168.81.camel@moss-spartans.epoch.ncsc.mil> <4476FBC0.30000@city-fan.org> <4476FFF3.7020707@redhat.com> Message-ID: <447702B7.10007@city-fan.org> Daniel J Walsh wrote: > Paul Howarth wrote: >> *** post-install scriptlet installs policy modules and fixes contexts: >> >> %if %{selinux_module} >> %post >> # Install SELinux policy modules >> if [ -x /usr/sbin/semodule ]; then >> for selinuxvariant in %{selinux_variants} >> do >> /usr/sbin/semodule -s ${selinuxvariant} -i \ >> %{_datadir}/selinux/${selinuxvariant}/contagged.pp \ >> &> /dev/null || : >> done >> fi > Does this fail silently if the policy package is not installed? I believe semodule will output "semodule: SELinux policy is not managed or store cannot be accessed.", hence the redirection of all output to /dev/null and the "|| :" to ignore the semodule exit code. >> # Fix up non-standard directory context >> [ -x /sbin/restorecon ] && /sbin/restorecon \ >> %{_localstatedir}/cache/contagged || : >> %endif >> >> >> *** pre-uninstall script removes policy modules (and removes app's >> cache, not SELinux-related)): >> >> %postun >> # Clean up after package removal >> if [ $1 -eq 0 ]; then >> # Clean out the cache >> %{__rm} -f %{_localstatedir}/cache/contagged/*.tpl.php >> /bin/rmdir %{_localstatedir}/cache/contagged &> /dev/null || : >> %if %{selinux_module} >> # Remove SELinux policy modules >> if [ -x /usr/sbin/semodule ]; then >> for selinuxvariant in %{selinux_variants} >> do >> /usr/sbin/semodule -s ${selinuxvariant} -r contagged || : >> done >> fi > You might need to fixup contexts here also, if you leave anything behind. Good point. So in this case I'd need: /sbin/restorecon -Rh %{_localstatedir}/cache/contagged || : >> Dan also comments in #190561 that "ou only need to install it with >> semodule, you do not need to intall the pp file"; I don't get this, as >> how will semodule be able to access the .pp file if it isn't installed >> with the package... > Sorry you are right. The only thing is you should not put the pp file > in /usr/share/selinux/VARIANT, as the current policy package does a > semodule -i of all pp files in that directory. (Which I should really > change) So if someone does a semodule -r later, the policy upgrade will > reinstall. Ah, I saw the clamav.pp in there and assumed it was from an Extras package but it's not. There probably needs to be a separate hierarchy for package modules then, perhaps: /usr/share/selinux/packages/VARIANT/ and the .pp files go in there. And if it's the same .pp file for all variants, it would go in /usr/share/selinux/packages/share/ instead. > My point about the pp file, is that you do not need to leave it on disk > or even use it again after it has been installed. As a matter of fact > semodule copies the pp file to > /etc/selinux/VARIANT/modules/active/modules/ From a package management point of view, it's probably best (and certainly easiest) to just install it as a regular file and then it'll get removed if the package is removed. It's not as if it's saving a huge amount of disk space. Paul. From selinux at gmail.com Fri May 26 13:49:46 2006 From: selinux at gmail.com (Tom London) Date: Fri, 26 May 2006 06:49:46 -0700 Subject: printer AVCs.... In-Reply-To: <44747C1B.5030704@redhat.com> References: <4c4ba1530605190902q5c981798m31d36366654f159@mail.gmail.com> <44747C1B.5030704@redhat.com> Message-ID: <4c4ba1530605260649k12e23a41gf25ed8f00848001a@mail.gmail.com> On 5/24/06, Daniel J Walsh wrote: > Tom London wrote: > > Running latest Rawhide, targeted/enforcing. > > > > I get the following when 'deactivating/activating' a USB printer (and > > printing fails): > > > > type=AVC msg=audit(1148052935.119:30): avc: denied { create } for > > pid=1902 comm="python" scontext=system_u:system_r:hplip_t:s0 > > tcontext=system_u:system_r:hplip_t:s0 tclass=netlink_route_socket > > type=SYSCALL msg=audit(1148052935.119:30): arch=40000003 syscall=102 > > success=no exit=-13 a0=1 a1=bffa4878 a2=49ebaff4 a3=bffa4e69 items=0 > > pid=1902 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > > sgid=0 fsgid=0 tty=(none) comm="python" exe="/usr/bin/python" > > subj=system_u:system_r:hplip_t:s0 > > type=SOCKETCALL msg=audit(1148052935.119:30): nargs=3 a0=10 a1=3 a2=0 > > > > type=USER_AVC msg=audit(1148053114.333:32): user pid=1735 uid=81 > > auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0 msg='avc: > > denied { send_msg } for msgtype=signal > > interface=com.redhat.PrinterSpooler member=JobQueuedLocal > > dest=org.freedesktop.DBus spid=1913 tpid=2748 > > scontext=system_u:system_r:cupsd_t:SystemLow-SystemHigh > > tcontext=user_u:system_r:unconfined_execmem_t tclass=dbus : exe="?" > > (sauid=81, hostname=?, addr=?, terminal=?)' > > > What is the unconfined_execmem_t application? Uhh, probably vmware..... I can't seem to reproduce this now. > > The following messages were in /var/log/messages: > > > > May 19 08:35:33 localhost dbus: Can't send to audit system: USER_AVC > > avc: denied { send_msg } for msgtype=signal > > interface=com.redhat.PrinterSpooler member=JobQueuedLocal > > dest=org.freedesktop.DBus spid=1913 tpid=2748 > > scontext=system_u:system_r:cupsd_t:SystemLow-SystemHigh > > tcontext=user_u:system_r:unconfined_execmem_t tclass=dbus : exe="?" > > (sauid=81, hostname=?, addr=?, terminal=?) > > May 19 08:35:33 localhost dbus: Can't send to audit system: USER_AVC > > avc: denied { send_msg } for msgtype=signal > > interface=com.redhat.PrinterSpooler member=QueueChanged > > dest=org.freedesktop.DBus spid=1913 tpid=2748 > > scontext=system_u:system_r:cupsd_t:SystemLow-SystemHigh > > tcontext=user_u:system_r:unconfined_execmem_t tclass=dbus : exe="?" > > (sauid=81, hostname=?, addr=?, terminal=?) > > May 19 08:35:33 localhost dbus: Can't send to audit system: USER_AVC > > avc: denied { send_msg } for msgtype=signal > > interface=com.redhat.PrinterSpooler member=JobStartedLocal > > dest=org.freedesktop.DBus spid=1913 tpid=2748 > > scontext=system_u:system_r:cupsd_t:SystemLow-SystemHigh > > tcontext=user_u:system_r:unconfined_execmem_t tclass=dbus : exe="?" > > (sauid=81, hostname=?, addr=?, terminal=?) > > May 19 08:35:35 localhost hpiod: invalid product id string: Broken > > pipe io/hpiod/device.cpp 623 > > May 19 08:35:35 localhost hpiod: unable to Device::Open > > hp:/usb/hp_LaserJet_1300?serial=00CNCB954325 io/hpiod/device.cpp 862 > > May 19 08:35:35 localhost hp_LaserJet_1300?serial=00CNCB954325: INFO: > > open device failed; will retry in 30 seconds... > > May 19 08:36:05 localhost hpiod: invalid product id string: Broken > > pipe io/hpiod/device.cpp 623 > > > > tom > > -- Tom London From paul at city-fan.org Fri May 26 14:20:41 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 26 May 2006 15:20:41 +0100 Subject: CGI Script permissions In-Reply-To: <4476D80D.8090600@redhat.com> References: <4476C060.7040306@gmail.com> <4476D80D.8090600@redhat.com> Message-ID: <44770EB9.6080105@city-fan.org> Daniel J Walsh wrote: > Jochen Wiedmann wrote: >> Paul Howarth wrote: >> >> >>> The simplest fix might be to change the file context of this particular >>> CGI script to httpd_unconfined_script_exec_t instead of >>> httpd_sys_script_t. That would effectively turn off SELinux protection >>> for that particular script. >>> >> >> >>> The alternative approach of using audit2allow to create a local policy >>> to allow these capabilities would turn on these capabilities for *all* >>> of your CGI scripts, which IMHO would be worse than turning off >>> protection for just that one script (particularly if that script was >>> well-audited for security issues). >>> >> >> >>> Ideally it would be easy to create a subclass of CGI scripts and assign >>> special capabilities to those (I have a similar issue with FastCGI >>> scripts that need slightly more capabilities than regular CGI scripts), >>> but that's beyond me at this moment. >>> >> >> As the script in question can indeed be called well-audited >> (basically, it >> just allows to trigger a certain action by calling another script with >> fixed attributes), I have decided to go with >> httpd_unconfined_script_exec_t. >> That did the trick neatly. >> >> Thanks very much, >> >> Jochen >> > > Another alternative might be to write your own module > > Create three files > > # cat >> myapache.te << _EOF > policy_module(myapache,1.0.0) > apache_content_template(myapache) > allow httpd_myapache_script_t self:capability setuid; > allow httpd_myapache_script_t self:process setrlimit; > _EOF > > echo > myapache.if > > # cat >> myapache.te << _EOF That should be myapache.fc > /var/www/cgi-bin/myapache_script -- > gen_context(system_u:object_r:httpd_myapache_script_exec_t,s0) > _EOF > > Then build a policy module. > > make -f /usr/share/selinux/devel/Makefile > > semodule -i myapache.pp > > restorecon -F -v /var/www/cgi-bin/myapache_script > > Then try it out. > Of course you might need additional rules. I made something similar for my moin wiki running under mod_fcgid: te file: policy_module(apache, 0.2.1) require { type devpts_t; type httpd_t; type httpd_log_t; type httpd_sys_script_exec_t; type var_run_t; }; # ========================================================== # Create and use httpd_fastcgi_script_t for mod_fcgid apps # ========================================================== apache_content_template(fastcgi) kernel_read_kernel_sysctls(httpd_fastcgi_script_t) # Allow FastCGI applications to live alongside regular CGI apps allow httpd_fastcgi_script_t httpd_sys_script_exec_t:dir { search_dir_perms }; # Allow FastCGI applications to listen for FastCGI requests on their # sockets and respond to them allow httpd_fastcgi_script_t httpd_t:unix_stream_socket { rw_stream_socket_perms }; # FastCGI application doing something to the httpd error log dontaudit httpd_fastcgi_script_t httpd_log_t:file ioctl; # Not sure what this is doing (happens when fastcgi scripts start) dontaudit httpd_t devpts_t:chr_file ioctl; # mod_fcgid setting attr of its socket dir allow httpd_t var_run_t:dir setattr; fc file: /srv/www/tips/cgi-bin/moin.fcgi -- gen_context(system_u:object_r:httpd_fastcgi_script_exec_t,s0) /var/www/tips/cgi-bin/moin.fcgi -- gen_context(system_u:object_r:httpd_fastcgi_script_exec_t,s0) Paul. From dwalsh at redhat.com Fri May 26 14:21:07 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 26 May 2006 10:21:07 -0400 Subject: selinux prelink avc's (broken paths in policy?) In-Reply-To: <1148572162.13769.5.camel@popeye.columbia.tresys.com> References: <4469F575.30609@feuerpokemon.de> <446EFB0B.8030508@feuerpokemon.de> <44731C1D.609@feuerpokemon.de> <1148395359.5228.2.camel@laurel.intra.city-fan.org> <4473250C.4020401@feuerpokemon.de> <44732578.70403@feuerpokemon.de> <44732772.7090302@feuerpokemon.de> <1148398247.5228.26.camel@laurel.intra.city-fan.org> <44732BA3.9050707@feuerpokemon.de> <1148400182.5228.43.camel@laurel.intra.city-fan.org> <4473337A.9060802@feuerpokemon.de> <44746376.2050504@redhat.com> <44746C3E.2030002@city-fan.org> <1148481570.517.7.camel@popeye.columbia.tresys.com> <44747678.2010505@city-fan.org> <1148483556.517.16.camel@popeye.columbia.tresys.com> <447479C1.3080404@city-fan.org> <1148484753.517.23.camel@popeye.columbia.tresys.com> <44747DF6.6090001@city-fan.org> <1148489791.517.46.camel@popeye.columbia.tresys.com> <1148572162.13769.5.camel@popeye.columbia.tresys.com> Message-ID: <44770ED3.8020202@redhat.com> Christopher Ashworth wrote: > On Wed, 2006-05-24 at 12:56 -0400, Christopher Ashworth wrote: > >> On Wed, 2006-05-24 at 16:38 +0100, Paul Howarth wrote: >> >>> So if "semanage fcontext -l" doesn't produce an ordered listing, is >>> there any way from userland to get one, one that encompasses both the >>> base policy and any added modules or context objects added using semanage? >>> >> I don't know the definitive answer on a userland tool. semanage >> fcontext -l appears to just be calling libsemanage, which is in turn >> using Ivan's database functions to list the objects (in this case, the >> fcontext objects). I'll try to track down what happens between the >> file_contexts file and the listing. >> > > I had a chance to take another look at this this morning. > > In semanage (seobject.py, specifically), the list of file contexts being > retrieved via semanage_fcontext_list is in the correct order. However, > it is transfered to a dictionary and printed out by iterating over the > keys of the dictionary. > > Changing this will allow semanage to report the file contexts in the > original order. > > Christopher > Ok I updated policycoreutils to use a list instead of a dictionary so the order is maintained. From Valdis.Kletnieks at vt.edu Fri May 26 17:17:20 2006 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 26 May 2006 13:17:20 -0400 Subject: Really wierd 'more' interaction with 'newrole' and stderr... Message-ID: <200605261717.k4QHHKnG013648@turing-police.cc.vt.edu> OK.. .running Rawhide as of this morning, strict policy in permissive mode - so selinux *shouldn't* kill anything off. I start off as a user, and then 'su' to root. I'm running with: # id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=valdis:staff_r:staff_t # ls -lZ `tty` crw------- valdis valdis valdis:object_r:staff_devpts_t /dev/pts/0 If I do 'more /etc/passwd /etc/group', it works fine (any two files is OK, or any single file over 1 screen long). Then I 'newrole -r sysadm_r'.. # id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=valdis:sysadm_r:sysadm_t # ls -lZ `tty` crw------- valdis valdis valdis:object_r:sysadm_devpts_t /dev/pts/0 Now if I try to 'more' anything that's more than one screen, it just silently exits after the first screen/file/etc. Some poking with strace indicates that when it fails, we have this: getcwd("/home/valdis", 4098) = 13 write(1, "\33[7m--More--(Next file: /etc/gro"..., 40)) = 40 read(2, 0xbfa266c7, 1) = -1 EBADF (Bad file descriptor) ioctl(2, SNDCTL_TMR_START or TCSETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0) = 4 exit_group(0) = ? while the working case has: getcwd("/home/valdis", 4098) = 13 write(1, "\33[7m--More--(Next file: /etc/gro"..., 40)) = 40 read(2, "\n", 1) = 1 The problem is in newrole.c, where we do this: fd = open(ttyn,O_WRONLY); to open fd2. Now, should this be fixed to O_RDWR, or should 'more' be fixed to read off stdin rather than stderr? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From sds at tycho.nsa.gov Fri May 26 17:27:56 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 26 May 2006 13:27:56 -0400 Subject: Really wierd 'more' interaction with 'newrole' and stderr... In-Reply-To: <200605261717.k4QHHKnG013648@turing-police.cc.vt.edu> References: <200605261717.k4QHHKnG013648@turing-police.cc.vt.edu> Message-ID: <1148664476.20976.248.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2006-05-26 at 13:17 -0400, Valdis.Kletnieks at vt.edu wrote: > OK.. .running Rawhide as of this morning, strict policy in permissive > mode - so selinux *shouldn't* kill anything off. > > I start off as a user, and then 'su' to root. I'm running with: > > # id > uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=valdis:staff_r:staff_t > # ls -lZ `tty` > crw------- valdis valdis valdis:object_r:staff_devpts_t /dev/pts/0 > > If I do 'more /etc/passwd /etc/group', it works fine (any two files is OK, > or any single file over 1 screen long). > > Then I 'newrole -r sysadm_r'.. > > # id > uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=valdis:sysadm_r:sysadm_t > # ls -lZ `tty` > crw------- valdis valdis valdis:object_r:sysadm_devpts_t /dev/pts/0 > > Now if I try to 'more' anything that's more than one screen, it just silently > exits after the first screen/file/etc. > > Some poking with strace indicates that when it fails, we have this: > > getcwd("/home/valdis", 4098) = 13 > write(1, "\33[7m--More--(Next file: /etc/gro"..., 40)) = 40 > read(2, 0xbfa266c7, 1) = -1 EBADF (Bad file descriptor) > ioctl(2, SNDCTL_TMR_START or TCSETS, {B38400 opost isig icanon echo ...}) = 0 > ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0) = 4 > exit_group(0) = ? > > while the working case has: > > getcwd("/home/valdis", 4098) = 13 > write(1, "\33[7m--More--(Next file: /etc/gro"..., 40)) = 40 > read(2, "\n", 1) = 1 > > The problem is in newrole.c, where we do this: > > fd = open(ttyn,O_WRONLY); > > to open fd2. Now, should this be fixed to O_RDWR, or should 'more' > be fixed to read off stdin rather than stderr? Hmm...they used to be O_RDWR, but Steve Grubb submitted a patch that changed them a while back as part of a general cleanup of newrole. If programs expect stdout and stderr to be rw, then I suppose newrole needs to open them that way, although it does seem odd to read from your error stream. -- Stephen Smalley National Security Agency From Valdis.Kletnieks at vt.edu Fri May 26 17:43:41 2006 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 26 May 2006 13:43:41 -0400 Subject: Really wierd 'more' interaction with 'newrole' and stderr... In-Reply-To: Your message of "Fri, 26 May 2006 13:27:56 EDT." <1148664476.20976.248.camel@moss-spartans.epoch.ncsc.mil> References: <200605261717.k4QHHKnG013648@turing-police.cc.vt.edu> <1148664476.20976.248.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200605261743.k4QHhfsp014667@turing-police.cc.vt.edu> On Fri, 26 May 2006 13:27:56 EDT, Stephen Smalley said: > Hmm...they used to be O_RDWR, but Steve Grubb submitted a patch that > changed them a while back as part of a general cleanup of newrole. If > programs expect stdout and stderr to be rw, then I suppose newrole needs > to open them that way, although it does seem odd to read from your error > stream. It can't read from stdin, because that might be in use: grep foo bar* | more And most shells open stderr as R/W, so reading from that works. One can certainly argue that stderr *should* be write-only, and programs using stderr for reading should probably be fixed to open /dev/tty and use that instead. But not knowing whether it's just this one odd program, or lots of them, I can't really say. I suppose Fedora could just do the equivalent change in /bin/bash and see how many bug reports come in. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From mike at easysw.com Fri May 26 17:53:47 2006 From: mike at easysw.com (Michael Sweet) Date: Fri, 26 May 2006 13:53:47 -0400 Subject: Really wierd 'more' interaction with 'newrole' and stderr... In-Reply-To: <200605261743.k4QHhfsp014667@turing-police.cc.vt.edu> References: <200605261717.k4QHHKnG013648@turing-police.cc.vt.edu> <1148664476.20976.248.camel@moss-spartans.epoch.ncsc.mil> <200605261743.k4QHhfsp014667@turing-police.cc.vt.edu> Message-ID: <447740AB.5060204@easysw.com> Valdis.Kletnieks at vt.edu wrote: > On Fri, 26 May 2006 13:27:56 EDT, Stephen Smalley said: > >> Hmm...they used to be O_RDWR, but Steve Grubb submitted a patch that >> changed them a while back as part of a general cleanup of newrole. If >> programs expect stdout and stderr to be rw, then I suppose newrole needs >> to open them that way, although it does seem odd to read from your error >> stream. > > It can't read from stdin, because that might be in use: > > grep foo bar* | more > > And most shells open stderr as R/W, so reading from that works. > > One can certainly argue that stderr *should* be write-only, and programs > using stderr for reading should probably be fixed to open /dev/tty and use > that instead. But not knowing whether it's just this one odd program, > or lots of them, I can't really say. > ... But don't programs like "more" open /dev/tty? -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Internet Printing and Document Software http://www.easysw.com From Valdis.Kletnieks at vt.edu Fri May 26 18:08:47 2006 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 26 May 2006 14:08:47 -0400 Subject: Really wierd 'more' interaction with 'newrole' and stderr... In-Reply-To: Your message of "Fri, 26 May 2006 13:53:47 EDT." <447740AB.5060204@easysw.com> References: <200605261717.k4QHHKnG013648@turing-police.cc.vt.edu> <1148664476.20976.248.camel@moss-spartans.epoch.ncsc.mil> <200605261743.k4QHhfsp014667@turing-police.cc.vt.edu> <447740AB.5060204@easysw.com> Message-ID: <200605261808.k4QI8lMW015683@turing-police.cc.vt.edu> On Fri, 26 May 2006 13:53:47 EDT, Michael Sweet said: > But don't programs like "more" open /dev/tty? What 'more' uses: int readch () { unsigned char c; errno = 0; if (read (fileno(stderr), &c, 1) <= 0) { if (errno != EINTR) end_it(0); else c = otty.c_cc[VKILL]; } return (c); } There's only one reference to /dev/tty, and it's re-opening stdin to /dev/tty when spawning a 'vi'. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From dwalsh at redhat.com Fri May 26 18:18:59 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 26 May 2006 14:18:59 -0400 Subject: CGI Script permissions In-Reply-To: <44770EB9.6080105@city-fan.org> References: <4476C060.7040306@gmail.com> <4476D80D.8090600@redhat.com> <44770EB9.6080105@city-fan.org> Message-ID: <44774693.3070401@redhat.com> Paul Howarth wrote: > Daniel J Walsh wrote: >> Jochen Wiedmann wrote: >>> Paul Howarth wrote: >>> >>> >>>> The simplest fix might be to change the file context of this >>>> particular >>>> CGI script to httpd_unconfined_script_exec_t instead of >>>> httpd_sys_script_t. That would effectively turn off SELinux protection >>>> for that particular script. >>>> >>> >>> >>>> The alternative approach of using audit2allow to create a local policy >>>> to allow these capabilities would turn on these capabilities for *all* >>>> of your CGI scripts, which IMHO would be worse than turning off >>>> protection for just that one script (particularly if that script was >>>> well-audited for security issues). >>>> >>> >>> >>>> Ideally it would be easy to create a subclass of CGI scripts and >>>> assign >>>> special capabilities to those (I have a similar issue with FastCGI >>>> scripts that need slightly more capabilities than regular CGI >>>> scripts), >>>> but that's beyond me at this moment. >>>> >>> >>> As the script in question can indeed be called well-audited >>> (basically, it >>> just allows to trigger a certain action by calling another script with >>> fixed attributes), I have decided to go with >>> httpd_unconfined_script_exec_t. >>> That did the trick neatly. >>> >>> Thanks very much, >>> >>> Jochen >>> >> >> Another alternative might be to write your own module >> >> Create three files >> >> # cat >> myapache.te << _EOF >> policy_module(myapache,1.0.0) >> apache_content_template(myapache) >> allow httpd_myapache_script_t self:capability setuid; >> allow httpd_myapache_script_t self:process setrlimit; >> _EOF >> >> echo > myapache.if >> >> # cat >> myapache.te << _EOF > > That should be myapache.fc > >> /var/www/cgi-bin/myapache_script -- >> gen_context(system_u:object_r:httpd_myapache_script_exec_t,s0) >> _EOF >> >> Then build a policy module. >> >> make -f /usr/share/selinux/devel/Makefile >> >> semodule -i myapache.pp >> >> restorecon -F -v /var/www/cgi-bin/myapache_script >> >> Then try it out. Of course you might need additional rules. > > I made something similar for my moin wiki running under mod_fcgid: > > te file: > > policy_module(apache, 0.2.1) > > require { > type devpts_t; > type httpd_t; > type httpd_log_t; > type httpd_sys_script_exec_t; > type var_run_t; > }; > > # ========================================================== > # Create and use httpd_fastcgi_script_t for mod_fcgid apps > # ========================================================== > > apache_content_template(fastcgi) > kernel_read_kernel_sysctls(httpd_fastcgi_script_t) > > # Allow FastCGI applications to live alongside regular CGI apps > allow httpd_fastcgi_script_t httpd_sys_script_exec_t:dir { > search_dir_perms }; > > # Allow FastCGI applications to listen for FastCGI requests on their > # sockets and respond to them > allow httpd_fastcgi_script_t httpd_t:unix_stream_socket { > rw_stream_socket_perms }; > > # FastCGI application doing something to the httpd error log > dontaudit httpd_fastcgi_script_t httpd_log_t:file ioctl; > > # Not sure what this is doing (happens when fastcgi scripts start) > dontaudit httpd_t devpts_t:chr_file ioctl; > > # mod_fcgid setting attr of its socket dir > allow httpd_t var_run_t:dir setattr; Why not create a context for its socket dir so you don't need this for var_run? > > > fc file: > > /srv/www/tips/cgi-bin/moin.fcgi -- > gen_context(system_u:object_r:httpd_fastcgi_script_exec_t,s0) > /var/www/tips/cgi-bin/moin.fcgi -- > gen_context(system_u:object_r:httpd_fastcgi_script_exec_t,s0) > > Paul. I think it might be a good idea to add this (fastcgi that is) policy to base. Have you tried to submit it upstream? From paul at city-fan.org Fri May 26 19:30:17 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 26 May 2006 20:30:17 +0100 Subject: CGI Script permissions In-Reply-To: <44774693.3070401@redhat.com> References: <4476C060.7040306@gmail.com> <4476D80D.8090600@redhat.com> <44770EB9.6080105@city-fan.org> <44774693.3070401@redhat.com> Message-ID: <1148671818.13674.2.camel@laurel.intra.city-fan.org> On Fri, 2006-05-26 at 14:18 -0400, Daniel J Walsh wrote: > Paul Howarth wrote: > > I made something similar for my moin wiki running under mod_fcgid: > > > > te file: > > > > policy_module(apache, 0.2.1) > > > > require { > > type devpts_t; > > type httpd_t; > > type httpd_log_t; > > type httpd_sys_script_exec_t; > > type var_run_t; > > }; > > > > # ========================================================== > > # Create and use httpd_fastcgi_script_t for mod_fcgid apps > > # ========================================================== > > > > apache_content_template(fastcgi) > > kernel_read_kernel_sysctls(httpd_fastcgi_script_t) > > > > # Allow FastCGI applications to live alongside regular CGI apps > > allow httpd_fastcgi_script_t httpd_sys_script_exec_t:dir { > > search_dir_perms }; > > > > # Allow FastCGI applications to listen for FastCGI requests on their > > # sockets and respond to them > > allow httpd_fastcgi_script_t httpd_t:unix_stream_socket { > > rw_stream_socket_perms }; > > > > # FastCGI application doing something to the httpd error log > > dontaudit httpd_fastcgi_script_t httpd_log_t:file ioctl; > > > > # Not sure what this is doing (happens when fastcgi scripts start) > > dontaudit httpd_t devpts_t:chr_file ioctl; > > > > # mod_fcgid setting attr of its socket dir > > allow httpd_t var_run_t:dir setattr; > Why not create a context for its socket dir so you don't need this for > var_run? The obvious type to use would really be httpd_var_run_t rather than creating a new type (comparing with other users of /var/run). In fact I think I tried that but it seemed worse than leaving it the default var_run_t and adding the one allow rule. What would you suggest? > > fc file: > > > > /srv/www/tips/cgi-bin/moin.fcgi -- > > gen_context(system_u:object_r:httpd_fastcgi_script_exec_t,s0) > > /var/www/tips/cgi-bin/moin.fcgi -- > > gen_context(system_u:object_r:httpd_fastcgi_script_exec_t,s0) > > > > Paul. > > I think it might be a good idea to add this (fastcgi that is) policy to > base. Have you tried to submit it upstream? Not yet; it probably needs more work to add further capabilities, as I've only use one application with FastCGI myself, and I can see that httpd_sys_script_t has far more capabilities that I've so far allowed to httpd_fastcgi_script_t. Perhaps there should be a interface that goes further than apache_content_template and adds capabilities needed by most server-side scripts (e.g. the kernel_read_kernel_sysctls from above), for use in developing custom types like httpd_fastcgi_script_t? Paul. From bench at silentmedia.com Sat May 27 15:06:45 2006 From: bench at silentmedia.com (Ben) Date: Sat, 27 May 2006 08:06:45 -0700 Subject: postgresql AVC errors Message-ID: <66817B3D-86AF-4DCD-B534-0E6D0B4CC2F4@silentmedia.com> I get this a LOT on my fedora postgres server: kernel: audit(1148742297.318:91630): avc: denied { create } for pid=29176 comm="postmaster" scontext=system_u:system_r:postgresql_t:s0 tcontext=system_u:system_r:postgresql_t:s0 tclass=netlink_route_socket It doesn't seem to harm anything, but it hardly seems like it should be there, either. Ideas? From shin216 at xf7.so-net.ne.jp Sat May 27 15:31:04 2006 From: shin216 at xf7.so-net.ne.jp (Shintaro Fujiwara) Date: Sun, 28 May 2006 00:31:04 +0900 Subject: postgresql AVC errors In-Reply-To: <66817B3D-86AF-4DCD-B534-0E6D0B4CC2F4@silentmedia.com> References: <66817B3D-86AF-4DCD-B534-0E6D0B4CC2F4@silentmedia.com> Message-ID: <1148743865.1775.40.camel@papa.intrajp-yokosuka.co.jp> I have exactly the same error messages a lot. I made my own module named postgresql_by_me,but it's exactly the same as yours. Have no idea why,either. I have not yet permitted this,because I don't understand. Postgresql works fine without this I guess. type=AVC msg=audit(1148623281.334:13): avc: denied { create } for pid=1588 comm="postmaster" scontext=system_u:system_r:postgresql_by_me_t:s0 tcontext=system_u:system_r:postgresql_by_me_t:s0 tclass=netlink_route_socket 2006-05-27 08:06 -0700 Ben wrote: > I get this a LOT on my fedora postgres server: > > kernel: audit(1148742297.318:91630): avc: denied { create } for > pid=29176 comm="postmaster" > scontext=system_u:system_r:postgresql_t:s0 > tcontext=system_u:system_r:postgresql_t:s0 tclass=netlink_route_socket > > > It doesn't seem to harm anything, but it hardly seems like it > should be there, either. Ideas? > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From selinux at gmail.com Sat May 27 17:46:29 2006 From: selinux at gmail.com (Tom London) Date: Sat, 27 May 2006 10:46:29 -0700 Subject: automount borked ... Message-ID: <4c4ba1530605271046s3ca3b410wbb57d283b7be1e7@mail.gmail.com> Running latest rawhide, targeted/enforcing. Lots of AVC from automount: type=AVC msg=audit(1148751437.978:7): avc: denied { search } for pid=2042 comm="automount" name="irq" dev=proc ino=-268435217 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:object_r:sysctl_irq_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.978:7): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.978:7): cwd="/" type=PATH msg=audit(1148751437.978:7): item=0 name="/proc/irq/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.982:8): avc: denied { search } for pid=2042 comm="automount" name="net" dev=proc ino=-268435432 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:object_r:proc_net_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.982:8): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.982:8): cwd="/" type=PATH msg=audit(1148751437.982:8): item=0 name="/proc/net/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.982:9): avc: denied { search } for pid=2042 comm="automount" name="1" dev=proc ino=65538 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.982:9): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.982:9): cwd="/" type=PATH msg=audit(1148751437.982:9): item=0 name="/proc/1/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.982:10): avc: denied { search } for pid=2042 comm="automount" name="2" dev=proc ino=131074 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.982:10): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.982:10): cwd="/" type=PATH msg=audit(1148751437.982:10): item=0 name="/proc/2/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.986:11): avc: denied { search } for pid=2042 comm="automount" name="3" dev=proc ino=196610 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.986:11): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.986:11): cwd="/" type=PATH msg=audit(1148751437.986:11): item=0 name="/proc/3/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.986:12): avc: denied { search } for pid=2042 comm="automount" name="4" dev=proc ino=262146 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.986:12): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.986:12): cwd="/" type=PATH msg=audit(1148751437.986:12): item=0 name="/proc/4/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.986:13): avc: denied { search } for pid=2042 comm="automount" name="5" dev=proc ino=327682 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.986:13): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.986:13): cwd="/" type=PATH msg=audit(1148751437.986:13): item=0 name="/proc/5/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.986:14): avc: denied { search } for pid=2042 comm="automount" name="6" dev=proc ino=393218 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.986:14): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.986:14): cwd="/" type=PATH msg=audit(1148751437.986:14): item=0 name="/proc/6/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.986:15): avc: denied { search } for pid=2042 comm="automount" name="7" dev=proc ino=458754 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.986:15): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.986:15): cwd="/" type=PATH msg=audit(1148751437.986:15): item=0 name="/proc/7/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.986:16): avc: denied { search } for pid=2042 comm="automount" name="9" dev=proc ino=589826 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.986:16): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.986:16): cwd="/" type=PATH msg=audit(1148751437.986:16): item=0 name="/proc/9/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.986:17): avc: denied { search } for pid=2042 comm="automount" name="10" dev=proc ino=655362 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.986:17): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.986:17): cwd="/" type=PATH msg=audit(1148751437.986:17): item=0 name="/proc/10/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.986:18): avc: denied { search } for pid=2042 comm="automount" name="118" dev=proc ino=7733250 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.986:18): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.986:18): cwd="/" type=PATH msg=audit(1148751437.986:18): item=0 name="/proc/118/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.990:19): avc: denied { search } for pid=2042 comm="automount" name="120" dev=proc ino=7864322 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.990:19): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.990:19): cwd="/" type=PATH msg=audit(1148751437.990:19): item=0 name="/proc/120/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.990:20): avc: denied { search } for pid=2042 comm="automount" name="174" dev=proc ino=11403266 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.990:20): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.990:20): cwd="/" type=PATH msg=audit(1148751437.990:20): item=0 name="/proc/174/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.990:21): avc: denied { search } for pid=2042 comm="automount" name="175" dev=proc ino=11468802 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.990:21): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.990:21): cwd="/" type=PATH msg=audit(1148751437.990:21): item=0 name="/proc/175/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.990:22): avc: denied { search } for pid=2042 comm="automount" name="176" dev=proc ino=11534338 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.990:22): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.990:22): cwd="/" type=PATH msg=audit(1148751437.990:22): item=0 name="/proc/176/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.990:23): avc: denied { search } for pid=2042 comm="automount" name="177" dev=proc ino=11599874 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.990:23): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.990:23): cwd="/" type=PATH msg=audit(1148751437.990:23): item=0 name="/proc/177/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.990:24): avc: denied { search } for pid=2042 comm="automount" name="323" dev=proc ino=21168130 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.990:24): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.990:24): cwd="/" type=PATH msg=audit(1148751437.990:24): item=0 name="/proc/323/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.990:25): avc: denied { search } for pid=2042 comm="automount" name="334" dev=proc ino=21889026 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.990:25): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.990:25): cwd="/" type=PATH msg=audit(1148751437.990:25): item=0 name="/proc/334/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.990:26): avc: denied { search } for pid=2042 comm="automount" name="355" dev=proc ino=23265282 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.990:26): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.990:26): cwd="/" type=PATH msg=audit(1148751437.990:26): item=0 name="/proc/355/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.990:27): avc: denied { search } for pid=2042 comm="automount" name="360" dev=proc ino=23592962 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.990:27): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.990:27): cwd="/" type=PATH msg=audit(1148751437.990:27): item=0 name="/proc/360/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.994:28): avc: denied { search } for pid=2042 comm="automount" name="374" dev=proc ino=24510466 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.994:28): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.994:28): cwd="/" type=PATH msg=audit(1148751437.994:28): item=0 name="/proc/374/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.994:29): avc: denied { search } for pid=2042 comm="automount" name="393" dev=proc ino=25755650 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.994:29): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.994:29): cwd="/" type=PATH msg=audit(1148751437.994:29): item=0 name="/proc/393/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.994:30): avc: denied { search } for pid=2042 comm="automount" name="403" dev=proc ino=26411010 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.994:30): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.994:30): cwd="/" type=PATH msg=audit(1148751437.994:30): item=0 name="/proc/403/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.994:31): avc: denied { search } for pid=2042 comm="automount" name="474" dev=proc ino=31064066 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:udev_t:s0-s0:c0.c255 tclass=dir type=SYSCALL msg=audit(1148751437.994:31): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.994:31): cwd="/" type=PATH msg=audit(1148751437.994:31): item=0 name="/proc/474/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.994:32): avc: denied { search } for pid=2042 comm="automount" name="852" dev=proc ino=55836674 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.994:32): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.994:32): cwd="/" type=PATH msg=audit(1148751437.994:32): item=0 name="/proc/852/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.994:33): avc: denied { search } for pid=2042 comm="automount" name="1358" dev=proc ino=88997890 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.994:33): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.994:33): cwd="/" type=PATH msg=audit(1148751437.994:33): item=0 name="/proc/1358/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.994:34): avc: denied { search } for pid=2042 comm="automount" name="1420" dev=proc ino=93061122 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.994:34): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.994:34): cwd="/" type=PATH msg=audit(1148751437.994:34): item=0 name="/proc/1420/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.994:35): avc: denied { search } for pid=2042 comm="automount" name="1455" dev=proc ino=95354882 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:readahead_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.994:35): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.994:35): cwd="/" type=PATH msg=audit(1148751437.994:35): item=0 name="/proc/1455/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.994:36): avc: denied { search } for pid=2042 comm="automount" name="1474" dev=proc ino=96600066 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:cpuspeed_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.994:36): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.994:36): cwd="/" type=PATH msg=audit(1148751437.994:36): item=0 name="/proc/1474/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.998:37): avc: denied { search } for pid=2042 comm="automount" name="1769" dev=proc ino=115933186 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:dhcpc_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.998:37): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.998:37): cwd="/" type=PATH msg=audit(1148751437.998:37): item=0 name="/proc/1769/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.998:38): avc: denied { search } for pid=2042 comm="automount" name="1816" dev=proc ino=119013378 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:auditd_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.998:38): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.998:38): cwd="/" type=PATH msg=audit(1148751437.998:38): item=0 name="/proc/1816/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.998:39): avc: denied { search } for pid=2042 comm="automount" name="1818" dev=proc ino=119144450 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.998:39): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.998:39): cwd="/" type=PATH msg=audit(1148751437.998:39): item=0 name="/proc/1818/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.998:40): avc: denied { search } for pid=2042 comm="automount" name="1831" dev=proc ino=119996418 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:setrans_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.998:40): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.998:40): cwd="/" type=PATH msg=audit(1148751437.998:40): item=0 name="/proc/1831/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.998:41): avc: denied { search } for pid=2042 comm="automount" name="1840" dev=proc ino=120586242 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:syslogd_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.998:41): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.998:41): cwd="/" type=PATH msg=audit(1148751437.998:41): item=0 name="/proc/1840/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.998:42): avc: denied { search } for pid=2042 comm="automount" name="1843" dev=proc ino=120782850 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:klogd_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.998:42): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.998:42): cwd="/" type=PATH msg=audit(1148751437.998:42): item=0 name="/proc/1843/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.998:43): avc: denied { search } for pid=2042 comm="automount" name="1867" dev=proc ino=122355714 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:portmap_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.998:43): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.998:43): cwd="/" type=PATH msg=audit(1148751437.998:43): item=0 name="/proc/1867/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.998:44): avc: denied { search } for pid=2042 comm="automount" name="1886" dev=proc ino=123600898 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:rpcd_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.998:44): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.998:44): cwd="/" type=PATH msg=audit(1148751437.998:44): item=0 name="/proc/1886/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751437.998:45): avc: denied { search } for pid=2042 comm="automount" name="1915" dev=proc ino=125501442 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:rpcd_t:s0 tclass=dir type=SYSCALL msg=audit(1148751437.998:45): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751437.998:45): cwd="/" type=PATH msg=audit(1148751437.998:45): item=0 name="/proc/1915/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751438.002:46): avc: denied { search } for pid=2042 comm="automount" name="1954" dev=proc ino=128057346 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=dir type=SYSCALL msg=audit(1148751438.002:46): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751438.002:46): cwd="/" type=PATH msg=audit(1148751438.002:46): item=0 name="/proc/1954/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751438.002:47): avc: denied { search } for pid=2042 comm="automount" name="1955" dev=proc ino=128122882 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=dir type=SYSCALL msg=audit(1148751438.002:47): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751438.002:47): cwd="/" type=PATH msg=audit(1148751438.002:47): item=0 name="/proc/1955/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751438.002:48): avc: denied { search } for pid=2042 comm="automount" name="1956" dev=proc ino=128188418 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=dir type=SYSCALL msg=audit(1148751438.002:48): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751438.002:48): cwd="/" type=PATH msg=audit(1148751438.002:48): item=0 name="/proc/1956/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751438.002:49): avc: denied { search } for pid=2042 comm="automount" name="1967" dev=proc ino=128909314 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=dir type=SYSCALL msg=audit(1148751438.002:49): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751438.002:49): cwd="/" type=PATH msg=audit(1148751438.002:49): item=0 name="/proc/1967/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751438.002:50): avc: denied { search } for pid=2042 comm="automount" name="1968" dev=proc ino=128974850 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=dir type=SYSCALL msg=audit(1148751438.002:50): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751438.002:50): cwd="/" type=PATH msg=audit(1148751438.002:50): item=0 name="/proc/1968/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751438.002:51): avc: denied { search } for pid=2042 comm="automount" name="1969" dev=proc ino=129040386 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=dir type=SYSCALL msg=audit(1148751438.002:51): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751438.002:51): cwd="/" type=PATH msg=audit(1148751438.002:51): item=0 name="/proc/1969/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751438.002:52): avc: denied { search } for pid=2042 comm="automount" name="1989" dev=proc ino=130351106 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:system_dbusd_t:s0 tclass=dir type=SYSCALL msg=audit(1148751438.002:52): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751438.002:52): cwd="/" type=PATH msg=audit(1148751438.002:52): item=0 name="/proc/1989/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751438.002:53): avc: denied { search } for pid=2042 comm="automount" name="2030" dev=proc ino=133038082 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:bluetooth_t:s0 tclass=dir type=SYSCALL msg=audit(1148751438.002:53): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751438.002:53): cwd="/" type=PATH msg=audit(1148751438.002:53): item=0 name="/proc/2030/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751438.002:54): avc: denied { search } for pid=2042 comm="automount" name="2038" dev=proc ino=133562370 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=dir type=SYSCALL msg=audit(1148751438.002:54): arch=40000003 syscall=5 success=no exit=-13 a0=bffb4fe8 a1=0 a2=1b6 a3=848f290 items=1 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751438.002:54): cwd="/" type=PATH msg=audit(1148751438.002:54): item=0 name="/proc/2038/cmdline" obj=system_u:object_r:proc_t:s0 type=AVC msg=audit(1148751438.006:55): avc: denied { setrlimit } for pid=2042 comm="automount" scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:automount_t:s0 tclass=process type=SYSCALL msg=audit(1148751438.006:55): arch=40000003 syscall=75 success=no exit=-13 a0=7 a1=bffb3fd8 a2=23fff4 a3=bffb3fd8 items=0 pid=2042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=AVC msg=audit(1148751438.006:56): avc: denied { execute } for pid=2047 comm="automount" name="modprobe" dev=dm-0 ino=2687107 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:object_r:insmod_exec_t:s0 tclass=file type=SYSCALL msg=audit(1148751438.006:56): arch=40000003 syscall=11 success=no exit=-13 a0=dc1fdf a1=bffb2e80 a2=848d1e8 a3=dc1fdf items=1 pid=2047 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="automount" exe="/usr/sbin/automount" subj=system_u:system_r:automount_t:s0 type=CWD msg=audit(1148751438.006:56): cwd="/" type=PATH msg=audit(1148751438.006:56): item=0 name="/sbin/modprobe" inode=2687107 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:insmod_exec_t:s0 -- Tom London From yukku19752000 at yahoo.com Sun May 28 08:20:07 2006 From: yukku19752000 at yahoo.com (yukku yukkoooooo) Date: Sun, 28 May 2006 01:20:07 -0700 (PDT) Subject: Cisco VPNClient does not work with SELinux enabled in FC4 In-Reply-To: <20060525160018.6BA90734DE@hormel.redhat.com> Message-ID: <20060528082007.94385.qmail@web34205.mail.mud.yahoo.com> Hi, I am running on FC4 and I installed Cisco VPN client software, however when I run vpnclient I am getting the error message : "vpnclient: error while loading shared libraries: /opt/cisco-vpnclient/lib/libvpnapi.so: cannot restore segment prot after reloc: Permission denied" Friendly neighbourhood Paul Howarth correctly guessed it to be related to SELinux. I am able to run the vpnclient by disabling the SELinux using setenforce 0 The chcon command did not work (apparently it is not supposed to work in FC4) I get a error message "type=AVC msg=audit(1147460693.437:11955217): avc: denied { execmod } " if I disable selinux and run the vpnclient command. > Paul Howarth wrote : > > The memory checks are present in FC4 but disabled by default. It > > appears > > that they have somehow been enabled on your system. This should fix it: > > # setsebool -P allow_execmod 1 > > I gave this command and it still does not work with > SELinux. So digged a littlebit and gave the command > # getsebool -a | less > and I got a long output of which I took the ones that might > make sense to you - > allow_execmem --> active > allow_execmod --> active > allow_execstack --> active > allow_kerberos --> active > allow_write_xshm --> active > allow_ypbind --> active >> There's something very weird going on there. allow_execmod should do >> what it says. I'd try asking about this on fedora-selinux-list, setsebool with execmod is not working either. I have attached the relevant files as well. Any ideas ? This should give you an idea of the SELinux version > selinux-doc-1.19.5-1.noarch.rpm > selinux-policy-strict-1.23.16-6.noarch.rpm > selinux-policy-targeted-1.23.16-6.noarch.rpm Thanks Newbie Yukku --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: audit.log Type: text/x-log Size: 1070 bytes Desc: 1329256320-audit.log URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sestatus.txt URL: From jouni at viikarit.com Sun May 28 09:43:42 2006 From: jouni at viikarit.com (Jouni Viikari) Date: Sun, 28 May 2006 12:43:42 +0300 Subject: httpd can't execute bash? Message-ID: <1148809422.19653.3.camel@pappa.viikarit.com> I have the same problem: type=AVC msg=audit(1148808793.986:30189): avc: denied { execute } for pid=18644 comm="httpd" name="bash" dev=dm-0 ino=3440979 scontext=user_u:system_r:httpd_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file Not sure which update started it. Script complaining now used to work before on FC5. # getsebool -a | grep http allow_httpd_anon_write --> off allow_httpd_sys_script_anon_write --> off httpd_builtin_scripting --> on httpd_can_network_connect --> on httpd_can_network_connect_db --> off httpd_can_network_relay --> off httpd_disable_trans --> off httpd_enable_cgi --> on httpd_enable_ftp_server --> off httpd_enable_homedirs --> on httpd_ssi_exec --> off httpd_suexec_disable_trans --> off httpd_tty_comm --> off httpd_unified --> off # rpm -qa | grep -i policy selinux-policy-targeted-2.2.40-1.fc5 checkpolicy-1.30.3-1.fc5 policycoreutils-1.30.8-1.fc5 selinux-policy-2.2.40-1.fc5 -Jouni From paul at city-fan.org Sun May 28 09:58:49 2006 From: paul at city-fan.org (Paul Howarth) Date: Sun, 28 May 2006 10:58:49 +0100 Subject: httpd can't execute bash? In-Reply-To: <1148809422.19653.3.camel@pappa.viikarit.com> References: <1148809422.19653.3.camel@pappa.viikarit.com> Message-ID: <1148810330.25423.13.camel@laurel.intra.city-fan.org> On Sun, 2006-05-28 at 12:43 +0300, Jouni Viikari wrote: > I have the same problem: > > type=AVC msg=audit(1148808793.986:30189): avc: denied { execute } for > pid=18644 comm="httpd" name="bash" dev=dm-0 ino=3440979 > scontext=user_u:system_r:httpd_t:s0 > tcontext=system_u:object_r:shell_exec_t:s0 tclass=file > > > Not sure which update started it. Script complaining now used to work > before on FC5. > > # getsebool -a | grep http > allow_httpd_anon_write --> off > allow_httpd_sys_script_anon_write --> off > httpd_builtin_scripting --> on > httpd_can_network_connect --> on > httpd_can_network_connect_db --> off > httpd_can_network_relay --> off > httpd_disable_trans --> off > httpd_enable_cgi --> on > httpd_enable_ftp_server --> off > httpd_enable_homedirs --> on > httpd_ssi_exec --> off > httpd_suexec_disable_trans --> off > httpd_tty_comm --> off > httpd_unified --> off > > # rpm -qa | grep -i policy > selinux-policy-targeted-2.2.40-1.fc5 > checkpolicy-1.30.3-1.fc5 > policycoreutils-1.30.8-1.fc5 > selinux-policy-2.2.40-1.fc5 What's the context of the actual script? Paul. From dwalsh at redhat.com Sun May 28 11:04:56 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sun, 28 May 2006 07:04:56 -0400 Subject: Cisco VPNClient does not work with SELinux enabled in FC4 In-Reply-To: <20060528082007.94385.qmail@web34205.mail.mud.yahoo.com> References: <20060528082007.94385.qmail@web34205.mail.mud.yahoo.com> Message-ID: <447983D8.3070400@redhat.com> yukku yukkoooooo wrote: > Hi, > I am running on FC4 and I installed Cisco VPN client software, > however when I run vpnclient I am getting the error message : > "vpnclient: error while loading shared libraries: /opt/cisco-vpnclient/lib/libvpnapi.so: cannot restore segment prot after reloc: Permission denied" This is strange. Have you tried chcon -t textrel_shlib_t /opt/cisco-vpnclient/lib/libvpnapi.so > Friendly neighbourhood Paul Howarth correctly guessed it to be related > to SELinux. > I am able to run the vpnclient by disabling the SELinux using > setenforce 0 > The chcon command did not work (apparently it is not supposed to work > in FC4) > I get a error message "type=AVC msg=audit(1147460693.437:11955217): > avc: denied { execmod } " > if I disable selinux and run the vpnclient command. > > Paul Howarth wrote : > > > The memory checks are present in FC4 but disabled by default. It > > > appears > > > that they have somehow been enabled on your system. > This should fix > it: > > > # setsebool -P allow_execmod 1 > > > > I gave this command and it still does not work with > > SELinux. So digged a littlebit and gave the command > > # getsebool -a | less > > and I got a long output of which I took the ones that might > > make sense to you - > > allow_execmem --> active > > allow_execmod --> active > > allow_execstack --> active > > allow_kerberos --> active > > allow_write_xshm --> active > > allow_ypbind --> active > >> There's something very weird going on there. allow_execmod should do > >> what it says. I'd try asking about this on fedora-selinux-list, > > setsebool with execmod is not working either. > I have attached the relevant files as well. Any ideas ? > This should give you an idea of the SELinux version > > selinux-doc-1.19.5-1.noarch.rpm > > > selinux-policy-strict-1.23.16-6.noarch.rpm > > selinux-policy-targeted-1.23.16-6.noarch.rpm > > Thanks > Newbie Yukku > > > > ------------------------------------------------------------------------ > New Yahoo! Messenger with Voice. Call regular phones from your PC > > and save big. > ------------------------------------------------------------------------ > > type=SYSCALL msg=audit(1147715609.949:3621791): arch=40000003 syscall=4 success=yes exit=1 a0=3 a1=bfc7b7b8 a2=1 a3=bfc7b7b8 items=0 pid=4330 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="setenforce" exe="/usr/sbin/setenforce" > type=AVC msg=audit(1147715609.949:3621791): avc: granted { setenforce } for pid=4330 comm="setenforce" scontext=root:system_r:unconfined_t tcontext=system_u:object_r:security_t tclass=security > type=AVC_PATH msg=audit(1147715612.195:3634219): path="/opt/cisco-vpnclient/lib/libvpnapi.so" > type=SYSCALL msg=audit(1147715612.195:3634219): arch=40000003 syscall=125 per=400000 success=yes exit=0 a0=9be000 a1=41000 a2=5 a3=bfd74540 items=0 pid=4332 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="vpnclient" exe="/opt/cisco-vpnclient/bin/vpnclient" > type=AVC msg=audit(1147715612.195:3634219): avc: denied { execmod } for pid=4332 comm="vpnclient" name=libvpnapi.so dev=hda3 ino=32474 scontext=user_u:system_r:unconfined_t tcontext=root:object_r:usr_t tclass=file > > ------------------------------------------------------------------------ > > SELinux status: enabled > SELinuxfs mount: /selinux > Current mode: enforcing > Mode from config file: enforcing > Policy version: 19 > Policy from config file: targeted > > Policy booleans: > NetworkManager_disable_trans inactive > allow_execmem active > allow_execmod active > allow_execstack active > allow_kerberos active > allow_write_xshm inactive > allow_ypbind inactive > apmd_disable_trans inactive > arpwatch_disable_trans inactive > auditd_disable_trans inactive > bluetooth_disable_trans inactive > canna_disable_trans inactive > cardmgr_disable_trans inactive > comsat_disable_trans inactive > cupsd_config_disable_trans inactive > cupsd_disable_trans inactive > cvs_disable_trans inactive > cyrus_disable_trans inactive > dbskkd_disable_trans inactive > dhcpc_disable_trans inactive > dhcpd_disable_trans inactive > dovecot_disable_trans inactive > fingerd_disable_trans inactive > ftp_home_dir active > ftpd_disable_trans inactive > ftpd_is_daemon active > hald_disable_trans inactive > hotplug_disable_trans inactive > howl_disable_trans inactive > httpd_builtin_scripting active > httpd_can_network_connect inactive > httpd_disable_trans inactive > httpd_enable_cgi active > httpd_enable_homedirs active > httpd_ssi_exec active > httpd_suexec_disable_trans inactive > httpd_tty_comm inactive > httpd_unified active > i18n_input_disable_trans inactive > inetd_child_disable_trans inactive > inetd_disable_trans inactive > innd_disable_trans inactive > kadmind_disable_trans inactive > klogd_disable_trans inactive > krb5kdc_disable_trans inactive > ktalkd_disable_trans inactive > lpd_disable_trans inactive > mysqld_disable_trans inactive > named_disable_trans inactive > named_write_master_zones inactive > nfs_export_all_ro active > nfs_export_all_rw active > nmbd_disable_trans inactive > nscd_disable_trans inactive > ntpd_disable_trans inactive > portmap_disable_trans inactive > postgresql_disable_trans inactive > pppd_disable_trans inactive > pppd_for_user inactive > privoxy_disable_trans inactive > ptal_disable_trans inactive > radiusd_disable_trans inactive > radvd_disable_trans inactive > read_default_t active > rlogind_disable_trans inactive > rsync_disable_trans inactive > samba_enable_home_dirs inactive > saslauthd_disable_trans inactive > slapd_disable_trans inactive > smbd_disable_trans inactive > snmpd_disable_trans inactive > squid_connect_any inactive > squid_disable_trans inactive > stunnel_disable_trans inactive > stunnel_is_daemon inactive > syslogd_disable_trans inactive > system_dbusd_disable_trans inactive > telnetd_disable_trans inactive > tftpd_disable_trans inactive > udev_disable_trans inactive > use_nfs_home_dirs inactive > use_samba_home_dirs inactive > uucpd_disable_trans inactive > winbind_disable_trans inactive > ypbind_disable_trans inactive > ypserv_disable_trans inactive > zebra_disable_trans inactive > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From paul at city-fan.org Sun May 28 12:21:48 2006 From: paul at city-fan.org (Paul Howarth) Date: Sun, 28 May 2006 13:21:48 +0100 Subject: Cisco VPNClient does not work with SELinux enabled in FC4 In-Reply-To: <447983D8.3070400@redhat.com> References: <20060528082007.94385.qmail@web34205.mail.mud.yahoo.com> <447983D8.3070400@redhat.com> Message-ID: <1148818908.25423.29.camel@laurel.intra.city-fan.org> On Sun, 2006-05-28 at 07:04 -0400, Daniel J Walsh wrote: > yukku yukkoooooo wrote: > > Hi, > > I am running on FC4 and I installed Cisco VPN client software, > > however when I run vpnclient I am getting the error message : > > "vpnclient: error while loading shared libraries: /opt/cisco-vpnclient/lib/libvpnapi.so: cannot restore segment prot after reloc: Permission denied" > This is strange. > > Have you tried > > chcon -t textrel_shlib_t /opt/cisco-vpnclient/lib/libvpnapi.so I recall suggesting this to the OP when it was reported on fedora-list, but this is FC4 and that type didn't seem to be available. Paul. From gajownik at gmail.com Sun May 28 12:27:13 2006 From: gajownik at gmail.com (Dawid Gajownik) Date: Sun, 28 May 2006 14:27:13 +0200 Subject: Cisco VPNClient does not work with SELinux enabled in FC4 In-Reply-To: <1148818908.25423.29.camel@laurel.intra.city-fan.org> References: <20060528082007.94385.qmail@web34205.mail.mud.yahoo.com> <447983D8.3070400@redhat.com> <1148818908.25423.29.camel@laurel.intra.city-fan.org> Message-ID: <44799721.6020804@gmail.com> Dnia 05/28/2006 02:22 PM, U?ytkownik Paul Howarth napisa?: >> chcon -t textrel_shlib_t /opt/cisco-vpnclient/lib/libvpnapi.so > > I recall suggesting this to the OP when it was reported on fedora-list, > but this is FC4 and that type didn't seem to be available. IIRC, texrel_shlib_t should work in FC-4. -- ^_* From yukku19752000 at yahoo.com Sun May 28 17:41:17 2006 From: yukku19752000 at yahoo.com (yukku yukkoooooo) Date: Sun, 28 May 2006 10:41:17 -0700 (PDT) Subject: Cisco VPNClient does not work with SELinux enabled in FC4 In-Reply-To: <447983D8.3070400@redhat.com> Message-ID: <20060528174118.61027.qmail@web34204.mail.mud.yahoo.com> I tried that command and it came out with an error - >[root at host ~]# chcon -t textrel_shlib_t /opt/cisco-vpnclient/lib/libvpnapi.so > chcon: failed to change context of >/opt/cisco-vpnclient/lib/libvpnapi.so to root:object_r:textrel_shlib_t: Invalid argument and later agian on Pauls adivice I aso ran the command # setsebool -P allow_execmod 1 which did not work either. Thanks shyam Daniel J Walsh wrote: yukku yukkoooooo wrote: > Hi, > I am running on FC4 and I installed Cisco VPN client software, > however when I run vpnclient I am getting the error message : > "vpnclient: error while loading shared libraries: /opt/cisco-vpnclient/lib/libvpnapi.so: cannot restore segment prot after reloc: Permission denied" This is strange. Have you tried chcon -t textrel_shlib_t /opt/cisco-vpnclient/lib/libvpnapi.so > Friendly neighbourhood Paul Howarth correctly guessed it to be related > to SELinux. > I am able to run the vpnclient by disabling the SELinux using > setenforce 0 > The chcon command did not work (apparently it is not supposed to work > in FC4) > I get a error message "type=AVC msg=audit(1147460693.437:11955217): > avc: denied { execmod } " > if I disable selinux and run the vpnclient command. > > Paul Howarth wrote : > > > The memory checks are present in FC4 but disabled by default. It > > > appears > > > that they have somehow been enabled on your system. > This should fix > it: > > > # setsebool -P allow_execmod 1 > > > > I gave this command and it still does not work with > > SELinux. So digged a littlebit and gave the command > > # getsebool -a | less > > and I got a long output of which I took the ones that might > > make sense to you - > > allow_execmem --> active > > allow_execmod --> active > > allow_execstack --> active > > allow_kerberos --> active > > allow_write_xshm --> active > > allow_ypbind --> active > >> There's something very weird going on there. allow_execmod should do > >> what it says. I'd try asking about this on fedora-selinux-list, > > setsebool with execmod is not working either. > I have attached the relevant files as well. Any ideas ? > This should give you an idea of the SELinux version > > selinux-doc-1.19.5-1.noarch.rpm > > > selinux-policy-strict-1.23.16-6.noarch.rpm > > selinux-policy-targeted-1.23.16-6.noarch.rpm > > Thanks > Newbie Yukku > > > > ------------------------------------------------------------------------ > New Yahoo! Messenger with Voice. Call regular phones from your PC > > and save big. > ------------------------------------------------------------------------ > > type=SYSCALL msg=audit(1147715609.949:3621791): arch=40000003 syscall=4 success=yes exit=1 a0=3 a1=bfc7b7b8 a2=1 a3=bfc7b7b8 items=0 pid=4330 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="setenforce" exe="/usr/sbin/setenforce" > type=AVC msg=audit(1147715609.949:3621791): avc: granted { setenforce } for pid=4330 comm="setenforce" scontext=root:system_r:unconfined_t tcontext=system_u:object_r:security_t tclass=security > type=AVC_PATH msg=audit(1147715612.195:3634219): path="/opt/cisco-vpnclient/lib/libvpnapi.so" > type=SYSCALL msg=audit(1147715612.195:3634219): arch=40000003 syscall=125 per=400000 success=yes exit=0 a0=9be000 a1=41000 a2=5 a3=bfd74540 items=0 pid=4332 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="vpnclient" exe="/opt/cisco-vpnclient/bin/vpnclient" > type=AVC msg=audit(1147715612.195:3634219): avc: denied { execmod } for pid=4332 comm="vpnclient" name=libvpnapi.so dev=hda3 ino=32474 scontext=user_u:system_r:unconfined_t tcontext=root:object_r:usr_t tclass=file > > ------------------------------------------------------------------------ > > SELinux status: enabled > SELinuxfs mount: /selinux > Current mode: enforcing > Mode from config file: enforcing > Policy version: 19 > Policy from config file: targeted > > Policy booleans: > NetworkManager_disable_trans inactive > allow_execmem active > allow_execmod active > allow_execstack active > allow_kerberos active > allow_write_xshm inactive > allow_ypbind inactive > apmd_disable_trans inactive > arpwatch_disable_trans inactive > auditd_disable_trans inactive > bluetooth_disable_trans inactive > canna_disable_trans inactive > cardmgr_disable_trans inactive > comsat_disable_trans inactive > cupsd_config_disable_trans inactive > cupsd_disable_trans inactive > cvs_disable_trans inactive > cyrus_disable_trans inactive > dbskkd_disable_trans inactive > dhcpc_disable_trans inactive > dhcpd_disable_trans inactive > dovecot_disable_trans inactive > fingerd_disable_trans inactive > ftp_home_dir active > ftpd_disable_trans inactive > ftpd_is_daemon active > hald_disable_trans inactive > hotplug_disable_trans inactive > howl_disable_trans inactive > httpd_builtin_scripting active > httpd_can_network_connect inactive > httpd_disable_trans inactive > httpd_enable_cgi active > httpd_enable_homedirs active > httpd_ssi_exec active > httpd_suexec_disable_trans inactive > httpd_tty_comm inactive > httpd_unified active > i18n_input_disable_trans inactive > inetd_child_disable_trans inactive > inetd_disable_trans inactive > innd_disable_trans inactive > kadmind_disable_trans inactive > klogd_disable_trans inactive > krb5kdc_disable_trans inactive > ktalkd_disable_trans inactive > lpd_disable_trans inactive > mysqld_disable_trans inactive > named_disable_trans inactive > named_write_master_zones inactive > nfs_export_all_ro active > nfs_export_all_rw active > nmbd_disable_trans inactive > nscd_disable_trans inactive > ntpd_disable_trans inactive > portmap_disable_trans inactive > postgresql_disable_trans inactive > pppd_disable_trans inactive > pppd_for_user inactive > privoxy_disable_trans inactive > ptal_disable_trans inactive > radiusd_disable_trans inactive > radvd_disable_trans inactive > read_default_t active > rlogind_disable_trans inactive > rsync_disable_trans inactive > samba_enable_home_dirs inactive > saslauthd_disable_trans inactive > slapd_disable_trans inactive > smbd_disable_trans inactive > snmpd_disable_trans inactive > squid_connect_any inactive > squid_disable_trans inactive > stunnel_disable_trans inactive > stunnel_is_daemon inactive > syslogd_disable_trans inactive > system_dbusd_disable_trans inactive > telnetd_disable_trans inactive > tftpd_disable_trans inactive > udev_disable_trans inactive > use_nfs_home_dirs inactive > use_samba_home_dirs inactive > uucpd_disable_trans inactive > winbind_disable_trans inactive > ypbind_disable_trans inactive > ypserv_disable_trans inactive > zebra_disable_trans inactive > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list --------------------------------- Love cheap thrills? Enjoy PC-to-Phone calls to 30+ countries for just 2?/min with Yahoo! Messenger with Voice. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gajownik at gmail.com Sun May 28 17:53:18 2006 From: gajownik at gmail.com (Dawid Gajownik) Date: Sun, 28 May 2006 19:53:18 +0200 Subject: Cisco VPNClient does not work with SELinux enabled in FC4 In-Reply-To: <20060528174118.61027.qmail@web34204.mail.mud.yahoo.com> References: <20060528174118.61027.qmail@web34204.mail.mud.yahoo.com> Message-ID: <4479E38E.4010100@gmail.com> Dnia 05/28/2006 07:41 PM, U?ytkownik yukku yukkoooooo napisa?: > root:object_r:textrel_shlib_t: Invalid argument Did you try texrel_shlib_t (texrel not textrel)? -- ^_* From MDecker at tesis.de Mon May 29 13:23:49 2006 From: MDecker at tesis.de (Michael Decker) Date: Mon, 29 May 2006 15:23:49 +0200 Subject: FC5/SELinux: Possibilty to enforce an "second set of eyes" method for admins? Message-ID: <447AF5E5.1060509@tesis.de> Hi! I wonder, if I can setup this kind of scenario: An admin has to change e.g. some SELinux policies. But if an admin can change all SELinux policies, he could change his own or others in a way, so he can do anything. So a second admin/user has to allow that action. Is there a way to setup that? Thanks... -- Michael Decker Michael.Decker at tesis.de TESIS SYSware GmbH http://www.tesis.de Baierbrunnerstr. 15 * 81379 Muenchen * Tel. +49 89 747377-0 From yukku19752000 at yahoo.com Mon May 29 13:31:34 2006 From: yukku19752000 at yahoo.com (yukku yukkoooooo) Date: Mon, 29 May 2006 06:31:34 -0700 (PDT) Subject: Cisco VPNClient does not work with SELinux enabled in FC4 (Resolved) In-Reply-To: <4479E38E.4010100@gmail.com> Message-ID: <20060529133134.41189.qmail@web34207.mail.mud.yahoo.com> Dawid, texrel worked ! (now I am able to execute the vpnclient command) So thats the subtle difference between SELinux on FC4 and FC5. BTW what is this command trying to do ? Thanks yukku Dawid Gajownik wrote: Dnia 05/28/2006 07:41 PM, Użytkownik yukku yukkoooooo napisał: > root:object_r:textrel_shlib_t: Invalid argument Did you try texrel_shlib_t (texrel not textrel)? -- ^_* --------------------------------- Do you Yahoo!? Next-gen email? Have it all with the all-new Yahoo! Mail Beta. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragoran at feuerpokemon.de Mon May 29 13:58:33 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Mon, 29 May 2006 15:58:33 +0200 Subject: webalizer avcs in dmesg (FC5 targeted) Message-ID: <447AFE09.3020403@feuerpokemon.de> I found tons of such errors in my logs: audit(1148908532.047:300): avc: denied { create } for pid=3924 comm="webalizer" scontext=system_u:system_r:webalizer_t:s0 tcontext=system_u:system_r:webalizer_t:s0 tclass=netlink_route_socket audit(1148908532.047:301): avc: denied { create } for pid=3924 comm="webalizer" scontext=system_u:system_r:webalizer_t:s0 tcontext=system_u:system_r:webalizer_t:s0 tclass=netlink_route_socket audit(1148908532.047:302): avc: denied { create } for pid=3924 comm="webalizer" scontext=system_u:system_r:webalizer_t:s0 tcontext=system_u:system_r:webalizer_t:s0 tclass=netlink_route_socket audit(1148908532.047:303): avc: denied { create } for pid=3924 comm="webalizer" scontext=system_u:system_r:webalizer_t:s0 tcontext=system_u:system_r:webalizer_t:s0 tclass=netlink_route_socket audit(1148908532.047:304): avc: denied { create } for pid=3924 comm="webalizer" scontext=system_u:system_r:webalizer_t:s0 tcontext=system_u:system_r:webalizer_t:s0 tclass=netlink_route_socket audit(1148908532.047:305): avc: denied { create } for pid=3924 comm="webalizer" scontext=system_u:system_r:webalizer_t:s0 tcontext=system_u:system_r:webalizer_t:s0 tclass=netlink_route_socket audit(1148908532.047:306): avc: denied { create } for pid=3924 comm="webalizer" scontext=system_u:system_r:webalizer_t:s0 tcontext=system_u:system_r:webalizer_t:s0 tclass=netlink_route_socket audit(1148908532.047:307): avc: denied { create } for pid=3924 comm="webalizer" scontext=system_u:system_r:webalizer_t:s0 tcontext=system_u:system_r:webalizer_t:s0 tclass=netlink_route_socket audit(1148908532.047:308): avc: denied { create } for pid=3924 comm="webalizer" scontext=system_u:system_r:webalizer_t:s0 tcontext=system_u:system_r:webalizer_t:s0 tclass=netlink_route_socket audit(1148908532.047:309): avc: denied { create } for pid=3924 comm="webalizer" scontext=system_u:system_r:webalizer_t:s0 tcontext=system_u:system_r:webalizer_t:s0 tclass=netlink_route_socket audit(1148908532.047:310): avc: denied { create } for pid=3924 comm="webalizer" scontext=system_u:system_r:webalizer_t:s0 tcontext=system_u:system_r:webalizer_t:s0 tclass=netlink_route_socket audit(1148908532.047:311): avc: denied { create } for pid=3924 comm="webalizer" scontext=system_u:system_r:webalizer_t:s0 tcontext=system_u:system_r:webalizer_t:s0 tclass=netlink_route_socket audit(1148908532.047:312): avc: denied { create } for pid=3924 comm="webalizer" scontext=system_u:system_r:webalizer_t:s0 tcontext=system_u:system_r:webalizer_t:s0 tclass=netlink_route_socket audit(1148908532.047:313): avc: denied { create } for pid=3924 comm="webalizer" scontext=system_u:system_r:webalizer_t:s0 tcontext=system_u:system_r:webalizer_t:s0 tclass=netlink_route_socket whats wrong here? known bug or new one? should I fill it in bugzilla? I am using selinux-policy-targeted-2.2.40-1.fc5 on FC5 x86_64. From paul at city-fan.org Mon May 29 15:02:10 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 29 May 2006 16:02:10 +0100 Subject: webalizer avcs in dmesg (FC5 targeted) In-Reply-To: <447AFE09.3020403@feuerpokemon.de> References: <447AFE09.3020403@feuerpokemon.de> Message-ID: <1148914930.2876.49.camel@laurel.intra.city-fan.org> On Mon, 2006-05-29 at 15:58 +0200, dragoran wrote: > I found tons of such errors in my logs: > audit(1148908532.047:300): avc: denied { create } for pid=3924 > comm="webalizer" scontext=system_u:system_r:webalizer_t:s0 > tcontext=system_u:system_r:webalizer_t:s0 tclass=netlink_route_socket > audit(1148908532.047:301): avc: denied { create } for pid=3924 > comm="webalizer" scontext=system_u:system_r:webalizer_t:s0 > tcontext=system_u:system_r:webalizer_t:s0 tclass=netlink_route_socket > audit(1148908532.047:302): avc: denied { create } for pid=3924 > comm="webalizer" scontext=system_u:system_r:webalizer_t:s0 > tcontext=system_u:system_r:webalizer_t:s0 tclass=netlink_route_socket > audit(1148908532.047:303): avc: denied { create } for pid=3924 > comm="webalizer" scontext=system_u:system_r:webalizer_t:s0 > tcontext=system_u:system_r:webalizer_t:s0 tclass=netlink_route_socket > audit(1148908532.047:304): avc: denied { create } for pid=3924 > comm="webalizer" scontext=system_u:system_r:webalizer_t:s0 > tcontext=system_u:system_r:webalizer_t:s0 tclass=netlink_route_socket > audit(1148908532.047:305): avc: denied { create } for pid=3924 > comm="webalizer" scontext=system_u:system_r:webalizer_t:s0 > tcontext=system_u:system_r:webalizer_t:s0 tclass=netlink_route_socket > audit(1148908532.047:306): avc: denied { create } for pid=3924 > comm="webalizer" scontext=system_u:system_r:webalizer_t:s0 > tcontext=system_u:system_r:webalizer_t:s0 tclass=netlink_route_socket > audit(1148908532.047:307): avc: denied { create } for pid=3924 > comm="webalizer" scontext=system_u:system_r:webalizer_t:s0 > tcontext=system_u:system_r:webalizer_t:s0 tclass=netlink_route_socket > audit(1148908532.047:308): avc: denied { create } for pid=3924 > comm="webalizer" scontext=system_u:system_r:webalizer_t:s0 > tcontext=system_u:system_r:webalizer_t:s0 tclass=netlink_route_socket > audit(1148908532.047:309): avc: denied { create } for pid=3924 > comm="webalizer" scontext=system_u:system_r:webalizer_t:s0 > tcontext=system_u:system_r:webalizer_t:s0 tclass=netlink_route_socket > audit(1148908532.047:310): avc: denied { create } for pid=3924 > comm="webalizer" scontext=system_u:system_r:webalizer_t:s0 > tcontext=system_u:system_r:webalizer_t:s0 tclass=netlink_route_socket > audit(1148908532.047:311): avc: denied { create } for pid=3924 > comm="webalizer" scontext=system_u:system_r:webalizer_t:s0 > tcontext=system_u:system_r:webalizer_t:s0 tclass=netlink_route_socket > audit(1148908532.047:312): avc: denied { create } for pid=3924 > comm="webalizer" scontext=system_u:system_r:webalizer_t:s0 > tcontext=system_u:system_r:webalizer_t:s0 tclass=netlink_route_socket > audit(1148908532.047:313): avc: denied { create } for pid=3924 > comm="webalizer" scontext=system_u:system_r:webalizer_t:s0 > tcontext=system_u:system_r:webalizer_t:s0 tclass=netlink_route_socket > whats wrong here? > known bug or new one? > should I fill it in bugzilla? > I am using selinux-policy-targeted-2.2.40-1.fc5 on FC5 x86_64. Known issue, already fixed in selinux-policy-2.2.42-3 onwards, which is currently in rawhide. I'm sure a fix for FC5 will appear eventually, though this one seems harmless enough apart from filling up logs. Paul. From jouni at viikarit.com Mon May 29 16:47:18 2006 From: jouni at viikarit.com (Jouni Viikari) Date: Mon, 29 May 2006 19:47:18 +0300 Subject: httpd can't execute bash? In-Reply-To: <1148810330.25423.13.camel@laurel.intra.city-fan.org> References: <1148809422.19653.3.camel@pappa.viikarit.com> <1148810330.25423.13.camel@laurel.intra.city-fan.org> Message-ID: <1148921238.22476.8.camel@pappa.viikarit.com> On Sun, 2006-05-28 at 10:58 +0100, Paul Howarth wrote: > On Sun, 2006-05-28 at 12:43 +0300, Jouni Viikari wrote: > > I have the same problem: > > > > type=AVC msg=audit(1148808793.986:30189): avc: denied { execute } for > > pid=18644 comm="httpd" name="bash" dev=dm-0 ino=3440979 > > scontext=user_u:system_r:httpd_t:s0 > > tcontext=system_u:object_r:shell_exec_t:s0 tclass=file > > > > > > Not sure which update started it. Script complaining now used to work > > before on FC5. > > > > # getsebool -a | grep http > > allow_httpd_anon_write --> off > > allow_httpd_sys_script_anon_write --> off > > httpd_builtin_scripting --> on > > httpd_can_network_connect --> on > > httpd_can_network_connect_db --> off > > httpd_can_network_relay --> off > > httpd_disable_trans --> off > > httpd_enable_cgi --> on > > httpd_enable_ftp_server --> off > > httpd_enable_homedirs --> on > > httpd_ssi_exec --> off > > httpd_suexec_disable_trans --> off > > httpd_tty_comm --> off > > httpd_unified --> off > > > > # rpm -qa | grep -i policy > > selinux-policy-targeted-2.2.40-1.fc5 > > checkpolicy-1.30.3-1.fc5 > > policycoreutils-1.30.8-1.fc5 > > selinux-policy-2.2.40-1.fc5 > > What's the context of the actual script? > > Paul. It is a php-script doing basically ugly 'system("cat xyz");' #ls -Z system_u:object_r:httpd_sys_content_t This is just a testing_something.php where I happened to notice a change in a behavior. Jouni From sundaram at fedoraproject.org Mon May 29 17:39:38 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 29 May 2006 23:09:38 +0530 Subject: Cisco VPNClient does not work with SELinux enabled in FC4 (Resolved) In-Reply-To: <20060529133134.41189.qmail@web34207.mail.mud.yahoo.com> References: <20060529133134.41189.qmail@web34207.mail.mud.yahoo.com> Message-ID: <1148924379.4310.831.camel@sundaram.pnq.redhat.com> On Mon, 2006-05-29 at 06:31 -0700, yukku yukkoooooo wrote: > Dawid, > texrel worked ! > (now I am able to execute the vpnclient command) > So thats the subtle difference between SELinux on FC4 and FC5. > BTW what is this command trying to do ? > > Thanks > yukku http://fedora.redhat.com/docs/selinux-faq-fc5/#faq-entry-unconfined_t http://people.redhat.com/drepper/selinux-mem.html Rahul From fedora at greatoasis.com Tue May 30 04:47:21 2006 From: fedora at greatoasis.com (Don) Date: Mon, 29 May 2006 21:47:21 -0700 Subject: Cannot FTP to /var/www/don/html with SELinux enabled Message-ID: <7.0.1.0.2.20060529155445.089ac4d8@greatoasis.com> Hi, I have two problems which I think they are similar. 1) I have a directory /var/www/don/html which is owned by don. I want to ftp some web pages, but I cannot cd to /var/www/don/html when SELinux is enabled. When I turn SELinux off it works. What do I need to set to allow this. 2) If I ftp the html files to my home dir the and copy them to /var/www/don/html they cannot we read by the browser while SELinux is enabled. Thanks in advance, Don From paul at city-fan.org Tue May 30 07:21:40 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 30 May 2006 08:21:40 +0100 Subject: Cannot FTP to /var/www/don/html with SELinux enabled In-Reply-To: <7.0.1.0.2.20060529155445.089ac4d8@greatoasis.com> References: <7.0.1.0.2.20060529155445.089ac4d8@greatoasis.com> Message-ID: <1148973701.2876.82.camel@laurel.intra.city-fan.org> On Mon, 2006-05-29 at 21:47 -0700, Don wrote: > Hi, > I have two problems which I think they are similar. > > 1) I have a directory /var/www/don/html which is owned by don. I > want to ftp some web pages, but I cannot cd to /var/www/don/html when > SELinux is enabled. When I turn SELinux off it works. What do I > need to set to allow this. You'll need to allow this area to be writable by your ftp server as far as SELinux is concerned. It might be enough to do: # chcon -R -t public_content_rw_t /var/www/don/html # setsebool -P allow_ftpd_anon_write 1 but I suspect you'll also need a local policy tweak to allow the ftp server to access /var/www/don in the first place. If the above commands don't work, look in /var/log/messages for lines containing "avc: denied" after the time you made these changes, and post what you find here. > 2) If I ftp the html files to my home dir the and copy them to > /var/www/don/html they cannot we read by the browser while SELinux is enabled. You'll need to change the security context of the files after copying them if you do it this way. $ chcon -R -t httpd_sys_content_t /var/www/don/html Paul. From MSchwartz at mn.rr.com Tue May 30 13:37:02 2006 From: MSchwartz at mn.rr.com (Marc Schwartz) Date: Tue, 30 May 2006 08:37:02 -0500 Subject: postfix, procmail and SELinux - No Go Message-ID: Hi all, I took advantage of the long weekend here in the States to finally update to FC5. All went well in general, however it has become apparent that procmail is problematic with SELinux enabled. fetchmail and postfix work fine in terms of getting my e-mail from multiple POP3 accounts. However local (~/.procmailrc) procmail filtering does not. My FC4 configuration files, with a few edits to reflect some path changes for postfix, now work fine with SELinux disabled. I was not running SELinux on FC4 and all worked fine there. I found other FC5/SELinux posts where others have had similar problems and disabling SELinux solved them. This is on a fully updated FC5 system as of the writing of this post. Is there a policy update pending to resolve this issue or some temporary steps that can be used in the interim, short of disabling SELinux entirely? Thanks, Marc Schwartz From paul at city-fan.org Tue May 30 15:32:17 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 30 May 2006 16:32:17 +0100 Subject: postfix, procmail and SELinux - No Go In-Reply-To: References: Message-ID: <447C6581.6050306@city-fan.org> Marc Schwartz wrote: > Hi all, > > I took advantage of the long weekend here in the States to finally > update to FC5. All went well in general, however it has become apparent > that procmail is problematic with SELinux enabled. > > fetchmail and postfix work fine in terms of getting my e-mail from > multiple POP3 accounts. However local (~/.procmailrc) procmail filtering > does not. > > My FC4 configuration files, with a few edits to reflect some path > changes for postfix, now work fine with SELinux disabled. I was not > running SELinux on FC4 and all worked fine there. > > I found other FC5/SELinux posts where others have had similar problems > and disabling SELinux solved them. > > This is on a fully updated FC5 system as of the writing of this post. > > Is there a policy update pending to resolve this issue or some temporary > steps that can be used in the interim, short of disabling SELinux entirely? I'm using procmail with sendmail on FC5. and whilst there were significant problems getting it to work with the out-of-the-box policy, it's mostly fixed now. The only local tweaks I do to policy are to add the ability to write a log file to /var/log (probably peculiar to me), to allow it to forward mail by calling sendmail (I think policy still doesn't allow reading of the /usr/sbin/sendmail -> /etc/alternatives/mta symlink, which pretty much most procmail users will need), and to allow programs called from procmail to create temporary files. If you run SELinux in permissive mode and post the AVCs that get logged when procmail is running, it should be possible to get this fixed. Paul. From mschwartz at mn.rr.com Tue May 30 18:41:50 2006 From: mschwartz at mn.rr.com (Marc Schwartz (via MN)) Date: Tue, 30 May 2006 13:41:50 -0500 Subject: postfix, procmail and SELinux - No Go In-Reply-To: <447C6581.6050306@city-fan.org> References: <447C6581.6050306@city-fan.org> Message-ID: <1149014510.4915.9.camel@localhost.localdomain> On Tue, 2006-05-30 at 16:32 +0100, Paul Howarth wrote: > Marc Schwartz wrote: > > Hi all, > > > > I took advantage of the long weekend here in the States to finally > > update to FC5. All went well in general, however it has become apparent > > that procmail is problematic with SELinux enabled. > > > > fetchmail and postfix work fine in terms of getting my e-mail from > > multiple POP3 accounts. However local (~/.procmailrc) procmail filtering > > does not. > > > > My FC4 configuration files, with a few edits to reflect some path > > changes for postfix, now work fine with SELinux disabled. I was not > > running SELinux on FC4 and all worked fine there. > > > > I found other FC5/SELinux posts where others have had similar problems > > and disabling SELinux solved them. > > > > This is on a fully updated FC5 system as of the writing of this post. > > > > Is there a policy update pending to resolve this issue or some temporary > > steps that can be used in the interim, short of disabling SELinux entirely? > > I'm using procmail with sendmail on FC5. and whilst there were > significant problems getting it to work with the out-of-the-box policy, > it's mostly fixed now. The only local tweaks I do to policy are to add > the ability to write a log file to /var/log (probably peculiar to me), > to allow it to forward mail by calling sendmail (I think policy still > doesn't allow reading of the /usr/sbin/sendmail -> /etc/alternatives/mta > symlink, which pretty much most procmail users will need), and to allow > programs called from procmail to create temporary files. > > If you run SELinux in permissive mode and post the AVCs that get logged > when procmail is running, it should be possible to get this fixed. Paul, Thanks for the reply. I have re-booted with SELinux in Permissive Mode. However, while procmail is working still, I see no avc messages at all in /var/log/messages that would seemingly be related here. There are other avc's there, most of which appear to be related to the boot process and the relabelling of files subsequent to having disabled SELinux earlier. Is this something more subtle or is there someplace else that I should be looking? I did not note this earlier, but this was a clean install of FC5, not an upgrade over FC4. BTW, on a separate and possible SELinux related issue, I had noted that the Evolution Data Server was crashing after I first installed FC5 with SELinux enabled. For the time this morning that I had SELinux disabled, I was not getting the crash. Didn't make the association initially, but now that I have it re-enabled in Permissive Mode, it's crashing again. No avc's in the log here either. Thanks, Marc From nicolas.mailhot at laposte.net Tue May 30 18:56:23 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 30 May 2006 20:56:23 +0200 Subject: postfix, procmail and SELinux - No Go In-Reply-To: <1149014510.4915.9.camel@localhost.localdomain> References: <447C6581.6050306@city-fan.org> <1149014510.4915.9.camel@localhost.localdomain> Message-ID: <1149015386.7262.13.camel@rousalka.dyndns.org> Getting postfix + procmail + selinux to work is hard as : - the postfix bits are exposed to the external world so they have tight permissions - procmail is essentially a script multiplexer, not good at all from a security perspective every action added to the procmailrc needs to have been predicted, audited and authorized by the policy authors - procmailrc is in /home, default policy dontaudits a lot of the stuff happening there - selinux policy authors don't seem to run or test this combo I spent weeks reporting bugs on this before FC5 - every selinux update seemed to break procmail + postfix in new mysterious ways. If you find the time to get the Fedora Devel policy ironed out for postfix + procmail and manage somewhat to convince policy authors to check they don't break it every other release I'll be very grateful. I don't have too much time nowadays so I've stopped testing for a few months -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From paul at city-fan.org Tue May 30 19:05:08 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 30 May 2006 20:05:08 +0100 Subject: postfix, procmail and SELinux - No Go In-Reply-To: <1149014510.4915.9.camel@localhost.localdomain> References: <447C6581.6050306@city-fan.org> <1149014510.4915.9.camel@localhost.localdomain> Message-ID: <1149015909.5247.1.camel@laurel.intra.city-fan.org> On Tue, 2006-05-30 at 13:41 -0500, Marc Schwartz (via MN) wrote: > On Tue, 2006-05-30 at 16:32 +0100, Paul Howarth wrote: > > Marc Schwartz wrote: > > > Hi all, > > > > > > I took advantage of the long weekend here in the States to finally > > > update to FC5. All went well in general, however it has become apparent > > > that procmail is problematic with SELinux enabled. > > > > > > fetchmail and postfix work fine in terms of getting my e-mail from > > > multiple POP3 accounts. However local (~/.procmailrc) procmail filtering > > > does not. > > > > > > My FC4 configuration files, with a few edits to reflect some path > > > changes for postfix, now work fine with SELinux disabled. I was not > > > running SELinux on FC4 and all worked fine there. > > > > > > I found other FC5/SELinux posts where others have had similar problems > > > and disabling SELinux solved them. > > > > > > This is on a fully updated FC5 system as of the writing of this post. > > > > > > Is there a policy update pending to resolve this issue or some temporary > > > steps that can be used in the interim, short of disabling SELinux entirely? > > > > I'm using procmail with sendmail on FC5. and whilst there were > > significant problems getting it to work with the out-of-the-box policy, > > it's mostly fixed now. The only local tweaks I do to policy are to add > > the ability to write a log file to /var/log (probably peculiar to me), > > to allow it to forward mail by calling sendmail (I think policy still > > doesn't allow reading of the /usr/sbin/sendmail -> /etc/alternatives/mta > > symlink, which pretty much most procmail users will need), and to allow > > programs called from procmail to create temporary files. > > > > If you run SELinux in permissive mode and post the AVCs that get logged > > when procmail is running, it should be possible to get this fixed. > > Paul, > > Thanks for the reply. > > I have re-booted with SELinux in Permissive Mode. > > However, while procmail is working still, I see no avc messages at all > in /var/log/messages that would seemingly be related here. There are > other avc's there, most of which appear to be related to the boot > process and the relabelling of files subsequent to having disabled > SELinux earlier. > > Is this something more subtle or is there someplace else that I should > be looking? Perhaps you have auditd running, and have AVCs logged to /var/log/audit/audit.log instead? > BTW, on a separate and possible SELinux related issue, I had noted that > the Evolution Data Server was crashing after I first installed FC5 with > SELinux enabled. For the time this morning that I had SELinux disabled, > I was not getting the crash. Didn't make the association initially, but > now that I have it re-enabled in Permissive Mode, it's crashing again. > No avc's in the log here either. Don't know what's happening with that. Having SELinux in permissive mode should behave almost identically to disabled mode really. Paul. From paul at city-fan.org Tue May 30 19:09:23 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 30 May 2006 20:09:23 +0100 Subject: postfix, procmail and SELinux - No Go In-Reply-To: <1149015386.7262.13.camel@rousalka.dyndns.org> References: <447C6581.6050306@city-fan.org> <1149014510.4915.9.camel@localhost.localdomain> <1149015386.7262.13.camel@rousalka.dyndns.org> Message-ID: <1149016164.5247.7.camel@laurel.intra.city-fan.org> On Tue, 2006-05-30 at 20:56 +0200, Nicolas Mailhot wrote: > Getting postfix + procmail + selinux to work is hard as : > - the postfix bits are exposed to the external world so they have tight > permissions > - procmail is essentially a script multiplexer, not good at all from a > security perspective every action added to the procmailrc needs to have > been predicted, audited and authorized by the policy authors This conflict is resolved, at least for the sendmail/procmail combination, by having a domain transition to procmail_t when sendmail calls procmail. So sendmail remains more restricted than procmail. > - procmailrc is in /home, default policy dontaudits a lot of the stuff > happening there You can get the dontaudit rules removed by changing the base policy: # semodule -b /usr/share/selinux/targeted/enableaudit.pp The dontaudit rules can be restored using: # semodule -b /usr/share/selinux/targeted/base.pp > - selinux policy authors don't seem to run or test this combo Can't help there; I use sendmail myself. > I spent weeks reporting bugs on this before FC5 - every selinux update > seemed to break procmail + postfix in new mysterious ways. If you find > the time to get the Fedora Devel policy ironed out for postfix + > procmail and manage somewhat to convince policy authors to check they > don't break it every other release I'll be very grateful. I had a lot of trouble with FC4 too and gave up reporting issues. It's much easier to do fixes with FC5 and the modular policy IMO. The things I'm reporting now are getting fixed too :-) Paul. From mschwartz at mn.rr.com Tue May 30 19:47:38 2006 From: mschwartz at mn.rr.com (Marc Schwartz (via MN)) Date: Tue, 30 May 2006 14:47:38 -0500 Subject: postfix, procmail and SELinux - No Go In-Reply-To: <1149015909.5247.1.camel@laurel.intra.city-fan.org> References: <447C6581.6050306@city-fan.org> <1149014510.4915.9.camel@localhost.localdomain> <1149015909.5247.1.camel@laurel.intra.city-fan.org> Message-ID: <1149018459.4915.49.camel@localhost.localdomain> On Tue, 2006-05-30 at 20:05 +0100, Paul Howarth wrote: > On Tue, 2006-05-30 at 13:41 -0500, Marc Schwartz (via MN) wrote: > > On Tue, 2006-05-30 at 16:32 +0100, Paul Howarth wrote: > > > If you run SELinux in permissive mode and post the AVCs that get logged > > > when procmail is running, it should be possible to get this fixed. > > > > Paul, > > > > Thanks for the reply. > > > > I have re-booted with SELinux in Permissive Mode. > > > > However, while procmail is working still, I see no avc messages at all > > in /var/log/messages that would seemingly be related here. There are > > other avc's there, most of which appear to be related to the boot > > process and the relabelling of files subsequent to having disabled > > SELinux earlier. > > > > Is this something more subtle or is there someplace else that I should > > be looking? > > Perhaps you have auditd running, and have AVCs logged > to /var/log/audit/audit.log instead? Yep. That's it. Thanks to Tom also for pointing this out. For reference, here is my ~/.procmailrc: # Scan for viruses using ClamAV + clamassassin :0 fw | /usr/local/bin/clamassassin # Scan with SpamAssasin (+ razor, pyzor and dcc) :0 fw | /usr/bin/spamc -s 256000 I'm not sure how much you might need/want, but here is a sampling. I tried to catch what appear to be complete "cycles" in each case. Here are some using grep 'procmail': type=AVC_PATH msg=audit(1149015973.940:563): path="/home/marcs/.procmailrc" type=PATH msg=audit(1149015973.940:563): item=0 name="/home/marcs/.procmailrc" flags=1 inode=426353 dev=fd:00 mode=0100664 ouid=500 ogid=500 rdev=00:00 type=AVC msg=audit(1149015973.940:564): avc: denied { read } for pid=11095 comm="procmail" name=".procmailrc" dev=dm-0 ino=426353 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file type=SYSCALL msg=audit(1149015973.940:564): arch=40000003 syscall=5 success=yes exit=4 a0=9337d60 a1=8000 a2=0 a3=8000 items=1 pid=11095 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="procmail" exe="/usr/bin/procmail" type=PATH msg=audit(1149015973.940:564): item=0 name="/home/marcs/.procmailrc" flags=101 inode=426353 dev=fd:00 mode=0100664 ouid=500 ogid=500 rdev=00:00 type=AVC msg=audit(1149015973.956:565): avc: denied { execute } for pid=11101 comm="clamassassin" name="clamscan" dev=hdc7 ino=3123838 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:clamscan_exec_t:s0 tclass=file type=AVC msg=audit(1149015973.956:565): avc: denied { execute_no_trans } for pid=11101 comm="clamassassin" name="clamscan" dev=hdc7 ino=3123838 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:clamscan_exec_t:s0 tclass=file type=AVC msg=audit(1149015973.956:565): avc: denied { read } for pid=11101 comm="clamassassin" name="clamscan" dev=hdc7 ino=3123838 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:clamscan_exec_t:s0 tclass=file type=AVC msg=audit(1149015973.960:566): avc: denied { search } for pid=11101 comm="clamscan" name="clamav" dev=hdc5 ino=30881 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:clamd_var_lib_t:s0 tclass=dir type=AVC msg=audit(1149015973.960:566): avc: denied { read } for pid=11101 comm="clamscan" name="daily.cvd" dev=hdc5 ino=29403 scontext=system_u:system_r:procmail_t:s0 tcontext=user_u:object_r:clamd_var_lib_t:s0 tclass=file type=AVC msg=audit(1149015973.960:567): avc: denied { getattr } for pid=11101 comm="clamscan" name="daily.cvd" dev=hdc5 ino=29403 scontext=system_u:system_r:procmail_t:s0 tcontext=user_u:object_r:clamd_var_lib_t:s0 tclass=file type=AVC msg=audit(1149015973.972:568): avc: denied { read } for pid=11105 comm="clamscan" name="clamav" dev=hdc5 ino=30881 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:clamd_var_lib_t:s0 tclass=dir type=AVC msg=audit(1149015973.972:569): avc: denied { getattr } for pid=11105 comm="clamscan" name="clamav" dev=hdc5 ino=30881 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:clamd_var_lib_t:s0 tclass=dir type=AVC msg=audit(1149015973.972:570): avc: denied { read } for pid=11105 comm="clamscan" name="main.cvd" dev=hdc5 ino=30890 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:clamd_var_lib_t:s0 tclass=file type=AVC msg=audit(1149015973.972:571): avc: denied { getattr } for pid=11105 comm="clamscan" name="main.cvd" dev=hdc5 ino=30890 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:clamd_var_lib_t:s0 tclass=file type=AVC msg=audit(1149015974.368:572): avc: denied { write } for pid=11105 comm="clamscan" name="main.ndb" dev=hdc6 ino=146248 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file type=AVC msg=audit(1149015974.368:573): avc: denied { read } for pid=11105 comm="clamscan" name="clamav-5f6ea15f5332ca86" dev=hdc6 ino=30 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file type=AVC msg=audit(1149015974.532:574): avc: denied { create } for pid=11105 comm="clamscan" name="main.zmd" scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file type=AVC msg=audit(1149015974.532:575): avc: denied { getattr } for pid=11105 comm="clamscan" name="main.zmd" dev=hdc6 ino=146249 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file type=AVC msg=audit(1149015974.532:576): avc: denied { unlink } for pid=11105 comm="clamscan" name="clamav-5f6ea15f5332ca86" dev=hdc6 ino=30 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file type=AVC msg=audit(1149015974.992:577): avc: denied { search } for pid=11105 comm="clamscan" name="/" dev=hdc6 ino=2 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir type=AVC msg=audit(1149015975.444:578): avc: denied { read } for pid=11105 comm="clamscan" name="clamav-a0ba2088c392494c" dev=hdc6 ino=146243 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir type=AVC msg=audit(1149015975.444:579): avc: denied { setattr } for pid=11105 comm="clamscan" name="clamav-a0ba2088c392494c" dev=hdc6 ino=146243 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir type=AVC msg=audit(1149015975.444:580): avc: denied { write } for pid=11105 comm="clamscan" name="/" dev=hdc6 ino=2 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir type=AVC msg=audit(1149015975.444:580): avc: denied { remove_name } for pid=11105 comm="clamscan" name="clamav-a0ba2088c392494c" dev=hdc6 ino=146243 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir type=AVC msg=audit(1149015975.444:580): avc: denied { rmdir } for pid=11105 comm="clamscan" name="clamav-a0ba2088c392494c" dev=hdc6 ino=146243 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir type=AVC msg=audit(1149015975.452:581): avc: denied { add_name } for pid=11105 comm="clamscan" name="clamav-c8c20a1e39aef1bc" scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir type=AVC msg=audit(1149015975.452:581): avc: denied { create } for pid=11105 comm="clamscan" name="clamav-c8c20a1e39aef1bc" scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir Here are some using grep 'postfix': type=SYSCALL msg=audit(1149014661.600:328): arch=40000003 syscall=196 success=no exit=-2 a0=9769930 a1=bf8a4b80 a2=580ff4 a3=3 items=1 pid=8367 auid=500 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 comm="local" exe="/usr/libexec/postfix/local" type=CWD msg=audit(1149014661.600:328): cwd="/var/spool/postfix" type=CWD msg=audit(1149014661.604:329): cwd="/var/spool/postfix" type=CWD msg=audit(1149014661.604:330): cwd="/var/spool/postfix" type=AVC msg=audit(1149014770.075:378): avc: denied { search } for pid=8646 comm="local" name="/" dev=dm-0 ino=2 scontext=system_u:system_r:postfix_local_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=dir Some using grep 'pyzor'. Note that neither 'razor' nor 'dcc' are showing up curiously: type=AVC_PATH msg=audit(1149015851.011:541): path="/home/marcs/.pyzor" type=PATH msg=audit(1149015851.011:541): item=0 name="/home/marcs/.pyzor" flags=1 inode=427255 dev=fd:00 mode=040755 ouid=500 ogid=5 00 rdev=00:00 type=AVC msg=audit(1149015851.015:542): avc: denied { getattr } for pid=10802 comm="pyzor" name="servers" dev=dm-0 ino=427256 scon text=system_u:system_r:pyzor_t:s0 tcontext=user_u:object_r:user_home_t:s0 tclass=file type=SYSCALL msg=audit(1149015851.015:542): arch=40000003 syscall=195 success=yes exit=0 a0=86c1fb0 a1=bf9b8da8 a2=4891eff4 a3=868e1b 0 items=1 pid=10802 auid=4294967295 uid=500 gid=0 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="pyzor" exe="/usr/bin/ python" type=AVC_PATH msg=audit(1149015851.015:542): path="/home/marcs/.pyzor/servers" type=PATH msg=audit(1149015851.015:542): item=0 name="/home/marcs/.pyzor/servers" flags=1 inode=427256 dev=fd:00 mode=0100664 ouid=5 00 ogid=500 rdev=00:00 type=AVC msg=audit(1149015851.015:543): avc: denied { search } for pid=10802 comm="pyzor" name="marcs" dev=dm-0 ino=425153 scontex t=system_u:system_r:pyzor_t:s0 tcontext=user_u:object_r:user_home_dir_t:s0 tclass=dir type=AVC msg=audit(1149015851.015:543): avc: denied { read } for pid=10802 comm="pyzor" name="servers" dev=dm-0 ino=427256 scontex t=system_u:system_r:pyzor_t:s0 tcontext=user_u:object_r:user_home_t:s0 tclass=file type=SYSCALL msg=audit(1149015851.015:543): arch=40000003 syscall=5 success=yes exit=3 a0=87273d0 a1=8000 a2=1b6 a3=86e0b90 items=1 p id=10802 auid=4294967295 uid=500 gid=0 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="pyzor" exe="/usr/bin/python" type=PATH msg=audit(1149015851.015:543): item=0 name="/home/marcs/.pyzor/servers" flags=101 inode=427256 dev=fd:00 mode=0100664 ouid =500 ogid=500 rdev=00:00 type=AVC msg=audit(1149015851.027:544): avc: denied { search } for pid=10802 comm="pyzor" name="/" dev=hdc6 ino=2 scontext=system_ u:system_r:pyzor_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir type=AVC msg=audit(1149015851.027:544): avc: denied { write } for pid=10802 comm="pyzor" name="/" dev=hdc6 ino=2 scontext=system_u :system_r:pyzor_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir type=AVC msg=audit(1149015851.027:544): avc: denied { add_name } for pid=10802 comm="pyzor" name="bBOXo3" scontext=system_u:system _r:pyzor_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir type=AVC msg=audit(1149015851.027:544): avc: denied { create } for pid=10802 comm="pyzor" name="bBOXo3" scontext=system_u:system_r :pyzor_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file More with grep 'spamd': type=AVC msg=audit(1149017045.372:768): avc: denied { search } for pid=1949 comm="spamd" name="/" dev=dm-0 ino=2 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=dir type=SYSCALL msg=audit(1149017045.372:768): arch=40000003 syscall=195 success=yes exit=0 a0=a3a19c0 a1=9ffa0c8 a2=4891eff4 a3=a3a19c0 items=1 pid=1949 auid=4294967295 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 comm="spamd" exe="/usr/bin/perl" type=PATH msg=audit(1149017045.372:768): item=0 name="/home/marcs/.spamassassin/user_prefs" flags=1 inode=1193881 dev=fd:00 mode=0100664 ouid=500 ogid=500 rdev=00:00 type=AVC msg=audit(1149017045.380:769): avc: denied { getattr } for pid=1949 comm="spamd" name="bayes_toks" dev=dm-0 ino=1193882 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file type=SYSCALL msg=audit(1149017045.380:769): arch=40000003 syscall=195 success=yes exit=0 a0=a3a19c0 a1=9ffa0c8 a2=4891eff4 a3=a3a19c0 items=1 pid=1949 auid=4294967295 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 comm="spamd" exe="/usr/bin/perl" type=AVC_PATH msg=audit(1149017045.380:769): path="/home/marcs/.spamassassin/bayes_toks" type=PATH msg=audit(1149017045.380:769): item=0 name="/home/marcs/.spamassassin/bayes_toks" flags=1 inode=1193882 dev=fd:00 mode=0100600 ouid=500 ogid=500 rdev=00:00 type=AVC msg=audit(1149017045.380:770): avc: denied { read } for pid=1949 comm="spamd" name="bayes_toks" dev=dm-0 ino=1193882 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file type=SYSCALL msg=audit(1149017045.380:770): arch=40000003 syscall=5 success=yes exit=8 a0=b1db3b8 a1=8000 a2=0 a3=8000 items=1 pid=1949 auid=4294967295 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 comm="spamd" exe="/usr/bin/perl" type=PATH msg=audit(1149017045.380:770): item=0 name="/home/marcs/.spamassassin/bayes_toks" flags=101 inode=1193882 dev=fd:00 mode=0100600 ouid=500 ogid=500 rdev=00:00 type=AVC msg=audit(1149017047.188:771): avc: denied { append } for pid=1949 comm="spamd" name="bayes_journal" dev=dm-0 ino=2338489 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file type=SYSCALL msg=audit(1149017047.188:771): arch=40000003 syscall=5 success=yes exit=10 a0=b8211d8 a1=8441 a2=1b6 a3=8441 items=1 pid=1949 auid=4294967295 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 comm="spamd" exe="/usr/bin/perl" type=PATH msg=audit(1149017047.188:771): item=0 name="/home/marcs/.spamassassin/bayes_journal" flags=310 inode=1193874 dev=fd:00 mode=040755 ouid=500 ogid=500 rdev=00:00 type=AVC msg=audit(1149017047.188:772): avc: denied { ioctl } for pid=1949 comm="spamd" name="bayes_journal" dev=dm-0 ino=2338489 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file type=SYSCALL msg=audit(1149017047.188:772): arch=40000003 syscall=54 success=no exit=-25 a0=a a1=5401 a2=bf84f5d8 a3=bf84f618 items=0 pid=1949 auid=4294967295 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 comm="spamd" exe="/usr/bin/perl" type=AVC_PATH msg=audit(1149017047.188:772): path="/home/marcs/.spamassassin/bayes_journal" type=AVC msg=audit(1149017047.828:791): avc: denied { write } for pid=1949 comm="spamd" name="bayes_toks" dev=dm-0 ino=1193882 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file Finally with grep "clamassassin": type=SYSCALL msg=audit(1149016209.330:652): arch=40000003 syscall=5 success=yes exit=3 a0=99e48c0 a1=8241 a2=1b6 a3=8241 items=1 pid=11646 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="clamassassin" exe="/bin/bash" type=PATH msg=audit(1149016209.330:652): item=0 name="/tmp/clamassassinmsg.jSBOI11644" flags=310 inode=2 dev=16:06 mode=041777 ouid=0 ogid=0 rdev=00:00 type=AVC msg=audit(1149016209.330:653): avc: denied { getattr } for pid=11646 comm="cat" name="clamassassinmsg.jSBOI11644" dev=hdc6 ino=28 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file type=AVC_PATH msg=audit(1149016209.330:653): path="/tmp/clamassassinmsg.jSBOI11644" type=AVC msg=audit(1149016209.334:654): avc: denied { execute } for pid=11647 comm="clamassassin" name="clamscan" dev=hdc7 ino=3123838 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:clamscan_exec_t:s0 tclass=file type=AVC msg=audit(1149016209.334:654): avc: denied { execute_no_trans } for pid=11647 comm="clamassassin" name="clamscan" dev=hdc7 ino=3123838 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:clamscan_exec_t:s0 tclass=file type=AVC msg=audit(1149016209.334:654): avc: denied { read } for pid=11647 comm="clamassassin" name="clamscan" dev=hdc7 ino=3123838 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:clamscan_exec_t:s0 tclass=file type=AVC msg=audit(1149016209.346:657): avc: denied { read } for pid=11651 comm="clamassassin" name="clamassassinmsg.jSBOI11644" dev=hdc6 ino=28 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file type=SYSCALL msg=audit(1149016209.346:657): arch=40000003 syscall=5 success=yes exit=3 a0=99e1190 a1=8000 a2=0 a3=8000 items=1 pid=11651 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="clamassassin" exe="/bin/bash" type=PATH msg=audit(1149016209.346:657): item=0 name="/tmp/clamassassinmsg.jSBOI11644" flags=101 inode=28 dev=16:06 mode=0100600 ouid=500 ogid=500 rdev=00:00 type=AVC msg=audit(1149017043.144:752): avc: denied { add_name } for pid=13192 comm="mktemp" name="clamassassinmsg.QRJvd13192" scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir type=AVC msg=audit(1149017043.144:752): avc: denied { create } for pid=13192 comm="mktemp" name="clamassassinmsg.QRJvd13192" scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file type=PATH msg=audit(1149017043.144:752): item=0 name="/tmp/clamassassinmsg.QRJvd13192" flags=310 inode=2 dev=16:06 mode=041777 ouid=0 ogid=0 rdev=00:00 type=AVC msg=audit(1149017043.152:753): avc: denied { write } for pid=13194 comm="clamassassin" name="clamassassinmsg.QRJvd13192" dev=hdc6 ino=28 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file > > BTW, on a separate and possible SELinux related issue, I had noted that > > the Evolution Data Server was crashing after I first installed FC5 with > > SELinux enabled. For the time this morning that I had SELinux disabled, > > I was not getting the crash. Didn't make the association initially, but > > now that I have it re-enabled in Permissive Mode, it's crashing again. > > No avc's in the log here either. > > Don't know what's happening with that. Having SELinux in permissive mode > should behave almost identically to disabled mode really. No avc's in /var/log/audit/audit.log, now that I am searching that. Yeah, this is curious. I'll pay attention to it and post back with any further data. Thanks, Marc From paul at city-fan.org Tue May 30 20:36:56 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 30 May 2006 21:36:56 +0100 Subject: postfix, procmail and SELinux - No Go In-Reply-To: <1149018459.4915.49.camel@localhost.localdomain> References: <447C6581.6050306@city-fan.org> <1149014510.4915.9.camel@localhost.localdomain> <1149015909.5247.1.camel@laurel.intra.city-fan.org> <1149018459.4915.49.camel@localhost.localdomain> Message-ID: <1149021417.5247.17.camel@laurel.intra.city-fan.org> On Tue, 2006-05-30 at 14:47 -0500, Marc Schwartz (via MN) wrote: > > > On Tue, 2006-05-30 at 20:05 +0100, Paul Howarth wrote: > > On Tue, 2006-05-30 at 13:41 -0500, Marc Schwartz (via MN) wrote: > > > On Tue, 2006-05-30 at 16:32 +0100, Paul Howarth wrote: > > > > If you run SELinux in permissive mode and post the AVCs that get logged > > > > when procmail is running, it should be possible to get this fixed. > > > > > > Paul, > > > > > > Thanks for the reply. > > > > > > I have re-booted with SELinux in Permissive Mode. > > > > > > However, while procmail is working still, I see no avc messages at all > > > in /var/log/messages that would seemingly be related here. There are > > > other avc's there, most of which appear to be related to the boot > > > process and the relabelling of files subsequent to having disabled > > > SELinux earlier. > > > > > > Is this something more subtle or is there someplace else that I should > > > be looking? > > > > Perhaps you have auditd running, and have AVCs logged > > to /var/log/audit/audit.log instead? > > Yep. That's it. > > Thanks to Tom also for pointing this out. > > > For reference, here is my ~/.procmailrc: > > # Scan for viruses using ClamAV + clamassassin > :0 fw > | /usr/local/bin/clamassassin > > # Scan with SpamAssasin (+ razor, pyzor and dcc) > :0 fw > | /usr/bin/spamc -s 256000 > > > > I'm not sure how much you might need/want, but here is a sampling. I > tried to catch what appear to be complete "cycles" in each case. > > Here are some using grep 'procmail': > > type=AVC_PATH msg=audit(1149015973.940:563): path="/home/marcs/.procmailrc" > type=PATH msg=audit(1149015973.940:563): item=0 name="/home/marcs/.procmailrc" flags=1 inode=426353 dev=fd:00 mode=0100664 ouid=500 ogid=500 rdev=00:00 > type=AVC msg=audit(1149015973.940:564): avc: denied { read } for pid=11095 comm="procmail" name=".procmailrc" dev=dm-0 ino=426353 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file > type=SYSCALL msg=audit(1149015973.940:564): arch=40000003 syscall=5 success=yes exit=4 a0=9337d60 a1=8000 a2=0 a3=8000 items=1 pid=11095 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="procmail" exe="/usr/bin/procmail" > type=PATH msg=audit(1149015973.940:564): item=0 name="/home/marcs/.procmailrc" flags=101 inode=426353 dev=fd:00 mode=0100664 ouid=500 ogid=500 rdev=00:00 This one's a labelling prpblem. I don;t think you should have anything labelled file_t on the system. Try changing the context of ~/.procmailrc to user_home_t. > type=AVC msg=audit(1149015973.956:565): avc: denied { execute } for pid=11101 comm="clamassassin" name="clamscan" dev=hdc7 ino=3123838 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:clamscan_exec_t:s0 tclass=file > type=AVC msg=audit(1149015973.956:565): avc: denied { execute_no_trans } for pid=11101 comm="clamassassin" name="clamscan" dev=hdc7 ino=3123838 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:clamscan_exec_t:s0 tclass=file This needs a policy change. There needs to be a domain transition from procmail_t to (I think) clamscan_exec_t. This could be done with a policy module in the short term, and when it's working properly, publish the fix one fedora-selinux-list and it should get included in the main policy. > type=AVC msg=audit(1149015973.956:565): avc: denied { read } for pid=11101 comm="clamassassin" name="clamscan" dev=hdc7 ino=3123838 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:clamscan_exec_t:s0 tclass=file > type=AVC msg=audit(1149015973.960:566): avc: denied { search } for pid=11101 comm="clamscan" name="clamav" dev=hdc5 ino=30881 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:clamd_var_lib_t:s0 tclass=dir > type=AVC msg=audit(1149015973.960:566): avc: denied { read } for pid=11101 comm="clamscan" name="daily.cvd" dev=hdc5 ino=29403 scontext=system_u:system_r:procmail_t:s0 tcontext=user_u:object_r:clamd_var_lib_t:s0 tclass=file > type=AVC msg=audit(1149015973.960:567): avc: denied { getattr } for pid=11101 comm="clamscan" name="daily.cvd" dev=hdc5 ino=29403 scontext=system_u:system_r:procmail_t:s0 tcontext=user_u:object_r:clamd_var_lib_t:s0 tclass=file > type=AVC msg=audit(1149015973.972:568): avc: denied { read } for pid=11105 comm="clamscan" name="clamav" dev=hdc5 ino=30881 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:clamd_var_lib_t:s0 tclass=dir > type=AVC msg=audit(1149015973.972:569): avc: denied { getattr } for pid=11105 comm="clamscan" name="clamav" dev=hdc5 ino=30881 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:clamd_var_lib_t:s0 tclass=dir > type=AVC msg=audit(1149015973.972:570): avc: denied { read } for pid=11105 comm="clamscan" name="main.cvd" dev=hdc5 ino=30890 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:clamd_var_lib_t:s0 tclass=file > type=AVC msg=audit(1149015973.972:571): avc: denied { getattr } for pid=11105 comm="clamscan" name="main.cvd" dev=hdc5 ino=30890 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:clamd_var_lib_t:s0 tclass=file > type=AVC msg=audit(1149015974.368:572): avc: denied { write } for pid=11105 comm="clamscan" name="main.ndb" dev=hdc6 ino=146248 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file > type=AVC msg=audit(1149015974.368:573): avc: denied { read } for pid=11105 comm="clamscan" name="clamav-5f6ea15f5332ca86" dev=hdc6 ino=30 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file > type=AVC msg=audit(1149015974.532:574): avc: denied { create } for pid=11105 comm="clamscan" name="main.zmd" scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file > type=AVC msg=audit(1149015974.532:575): avc: denied { getattr } for pid=11105 comm="clamscan" name="main.zmd" dev=hdc6 ino=146249 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file > type=AVC msg=audit(1149015974.532:576): avc: denied { unlink } for pid=11105 comm="clamscan" name="clamav-5f6ea15f5332ca86" dev=hdc6 ino=30 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file > type=AVC msg=audit(1149015974.992:577): avc: denied { search } for pid=11105 comm="clamscan" name="/" dev=hdc6 ino=2 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir > type=AVC msg=audit(1149015975.444:578): avc: denied { read } for pid=11105 comm="clamscan" name="clamav-a0ba2088c392494c" dev=hdc6 ino=146243 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir > type=AVC msg=audit(1149015975.444:579): avc: denied { setattr } for pid=11105 comm="clamscan" name="clamav-a0ba2088c392494c" dev=hdc6 ino=146243 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir > type=AVC msg=audit(1149015975.444:580): avc: denied { write } for pid=11105 comm="clamscan" name="/" dev=hdc6 ino=2 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir > type=AVC msg=audit(1149015975.444:580): avc: denied { remove_name } for pid=11105 comm="clamscan" name="clamav-a0ba2088c392494c" dev=hdc6 ino=146243 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir > type=AVC msg=audit(1149015975.444:580): avc: denied { rmdir } for pid=11105 comm="clamscan" name="clamav-a0ba2088c392494c" dev=hdc6 ino=146243 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir > type=AVC msg=audit(1149015975.452:581): avc: denied { add_name } for pid=11105 comm="clamscan" name="clamav-c8c20a1e39aef1bc" scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir > type=AVC msg=audit(1149015975.452:581): avc: denied { create } for pid=11105 comm="clamscan" name="clamav-c8c20a1e39aef1bc" scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir I bet the domain transition would fix all of these. > Here are some using grep 'postfix': > > type=SYSCALL msg=audit(1149014661.600:328): arch=40000003 syscall=196 success=no exit=-2 a0=9769930 a1=bf8a4b80 a2=580ff4 a3=3 items=1 pid=8367 auid=500 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 comm="local" exe="/usr/libexec/postfix/local" > type=CWD msg=audit(1149014661.600:328): cwd="/var/spool/postfix" > type=CWD msg=audit(1149014661.604:329): cwd="/var/spool/postfix" > type=CWD msg=audit(1149014661.604:330): cwd="/var/spool/postfix" > type=AVC msg=audit(1149014770.075:378): avc: denied { search } for pid=8646 comm="local" name="/" dev=dm-0 ino=2 scontext=system_u:system_r:postfix_local_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=dir That looks like a mis-labelled directory. > Some using grep 'pyzor'. Note that neither 'razor' nor 'dcc' are showing > up curiously: > > type=AVC_PATH msg=audit(1149015851.011:541): path="/home/marcs/.pyzor" > type=PATH msg=audit(1149015851.011:541): item=0 name="/home/marcs/.pyzor" flags=1 inode=427255 dev=fd:00 mode=040755 ouid=500 ogid=5 00 rdev=00:00 > type=AVC msg=audit(1149015851.015:542): avc: denied { getattr } for pid=10802 comm="pyzor" name="servers" dev=dm-0 ino=427256 scon text=system_u:system_r:pyzor_t:s0 tcontext=user_u:object_r:user_home_t:s0 tclass=file > type=SYSCALL msg=audit(1149015851.015:542): arch=40000003 syscall=195 success=yes exit=0 a0=86c1fb0 a1=bf9b8da8 a2=4891eff4 a3=868e1b 0 items=1 pid=10802 auid=4294967295 uid=500 gid=0 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="pyzor" exe="/usr/bin/ python" > type=AVC_PATH msg=audit(1149015851.015:542): path="/home/marcs/.pyzor/servers" > type=PATH msg=audit(1149015851.015:542): item=0 name="/home/marcs/.pyzor/servers" flags=1 inode=427256 dev=fd:00 mode=0100664 ouid=5 00 ogid=500 rdev=00:00 > type=AVC msg=audit(1149015851.015:543): avc: denied { search } for pid=10802 comm="pyzor" name="marcs" dev=dm-0 ino=425153 scontex t=system_u:system_r:pyzor_t:s0 tcontext=user_u:object_r:user_home_dir_t:s0 tclass=dir > type=AVC msg=audit(1149015851.015:543): avc: denied { read } for pid=10802 comm="pyzor" name="servers" dev=dm-0 ino=427256 scontex t=system_u:system_r:pyzor_t:s0 tcontext=user_u:object_r:user_home_t:s0 tclass=file > type=SYSCALL msg=audit(1149015851.015:543): arch=40000003 syscall=5 success=yes exit=3 a0=87273d0 a1=8000 a2=1b6 a3=86e0b90 items=1 p id=10802 auid=4294967295 uid=500 gid=0 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="pyzor" exe="/usr/bin/python" > type=PATH msg=audit(1149015851.015:543): item=0 name="/home/marcs/.pyzor/servers" flags=101 inode=427256 dev=fd:00 mode=0100664 ouid =500 ogid=500 rdev=00:00 > type=AVC msg=audit(1149015851.027:544): avc: denied { search } for pid=10802 comm="pyzor" name="/" dev=hdc6 ino=2 scontext=system_ u:system_r:pyzor_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir > type=AVC msg=audit(1149015851.027:544): avc: denied { write } for pid=10802 comm="pyzor" name="/" dev=hdc6 ino=2 scontext=system_u :system_r:pyzor_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir > type=AVC msg=audit(1149015851.027:544): avc: denied { add_name } for pid=10802 comm="pyzor" name="bBOXo3" scontext=system_u:system _r:pyzor_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir > type=AVC msg=audit(1149015851.027:544): avc: denied { create } for pid=10802 comm="pyzor" name="bBOXo3" scontext=system_u:system_r :pyzor_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file Those look to me like things that should be allowed but I don't know anything about pyzor so maybe it can be used differently? > More with grep 'spamd': > > type=AVC msg=audit(1149017045.372:768): avc: denied { search } for pid=1949 comm="spamd" name="/" dev=dm-0 ino=2 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=dir > type=SYSCALL msg=audit(1149017045.372:768): arch=40000003 syscall=195 success=yes exit=0 a0=a3a19c0 a1=9ffa0c8 a2=4891eff4 a3=a3a19c0 items=1 pid=1949 auid=4294967295 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 comm="spamd" exe="/usr/bin/perl" > type=PATH msg=audit(1149017045.372:768): item=0 name="/home/marcs/.spamassassin/user_prefs" flags=1 inode=1193881 dev=fd:00 mode=0100664 ouid=500 ogid=500 rdev=00:00 > type=AVC msg=audit(1149017045.380:769): avc: denied { getattr } for pid=1949 comm="spamd" name="bayes_toks" dev=dm-0 ino=1193882 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file > type=SYSCALL msg=audit(1149017045.380:769): arch=40000003 syscall=195 success=yes exit=0 a0=a3a19c0 a1=9ffa0c8 a2=4891eff4 a3=a3a19c0 items=1 pid=1949 auid=4294967295 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 comm="spamd" exe="/usr/bin/perl" > type=AVC_PATH msg=audit(1149017045.380:769): path="/home/marcs/.spamassassin/bayes_toks" > type=PATH msg=audit(1149017045.380:769): item=0 name="/home/marcs/.spamassassin/bayes_toks" flags=1 inode=1193882 dev=fd:00 mode=0100600 ouid=500 ogid=500 rdev=00:00 > type=AVC msg=audit(1149017045.380:770): avc: denied { read } for pid=1949 comm="spamd" name="bayes_toks" dev=dm-0 ino=1193882 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file > type=SYSCALL msg=audit(1149017045.380:770): arch=40000003 syscall=5 success=yes exit=8 a0=b1db3b8 a1=8000 a2=0 a3=8000 items=1 pid=1949 auid=4294967295 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 comm="spamd" exe="/usr/bin/perl" > type=PATH msg=audit(1149017045.380:770): item=0 name="/home/marcs/.spamassassin/bayes_toks" flags=101 inode=1193882 dev=fd:00 mode=0100600 ouid=500 ogid=500 rdev=00:00 > type=AVC msg=audit(1149017047.188:771): avc: denied { append } for pid=1949 comm="spamd" name="bayes_journal" dev=dm-0 ino=2338489 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file > type=SYSCALL msg=audit(1149017047.188:771): arch=40000003 syscall=5 success=yes exit=10 a0=b8211d8 a1=8441 a2=1b6 a3=8441 items=1 pid=1949 auid=4294967295 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 comm="spamd" exe="/usr/bin/perl" > type=PATH msg=audit(1149017047.188:771): item=0 name="/home/marcs/.spamassassin/bayes_journal" flags=310 inode=1193874 dev=fd:00 mode=040755 ouid=500 ogid=500 rdev=00:00 > type=AVC msg=audit(1149017047.188:772): avc: denied { ioctl } for pid=1949 comm="spamd" name="bayes_journal" dev=dm-0 ino=2338489 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file > type=SYSCALL msg=audit(1149017047.188:772): arch=40000003 syscall=54 success=no exit=-25 a0=a a1=5401 a2=bf84f5d8 a3=bf84f618 items=0 pid=1949 auid=4294967295 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 comm="spamd" exe="/usr/bin/perl" > type=AVC_PATH msg=audit(1149017047.188:772): path="/home/marcs/.spamassassin/bayes_journal" > type=AVC msg=audit(1149017047.828:791): avc: denied { write } for pid=1949 comm="spamd" name="bayes_toks" dev=dm-0 ino=1193882 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file More mislabelled files. I think you need to relabel the system. > Finally with grep "clamassassin": > > type=SYSCALL msg=audit(1149016209.330:652): arch=40000003 syscall=5 success=yes exit=3 a0=99e48c0 a1=8241 a2=1b6 a3=8241 items=1 pid=11646 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="clamassassin" exe="/bin/bash" > type=PATH msg=audit(1149016209.330:652): item=0 name="/tmp/clamassassinmsg.jSBOI11644" flags=310 inode=2 dev=16:06 mode=041777 ouid=0 ogid=0 rdev=00:00 > type=AVC msg=audit(1149016209.330:653): avc: denied { getattr } for pid=11646 comm="cat" name="clamassassinmsg.jSBOI11644" dev=hdc6 ino=28 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file > type=AVC_PATH msg=audit(1149016209.330:653): path="/tmp/clamassassinmsg.jSBOI11644" > type=AVC msg=audit(1149016209.334:654): avc: denied { execute } for pid=11647 comm="clamassassin" name="clamscan" dev=hdc7 ino=3123838 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:clamscan_exec_t:s0 tclass=file > type=AVC msg=audit(1149016209.334:654): avc: denied { execute_no_trans } for pid=11647 comm="clamassassin" name="clamscan" dev=hdc7 ino=3123838 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:clamscan_exec_t:s0 tclass=file > type=AVC msg=audit(1149016209.334:654): avc: denied { read } for pid=11647 comm="clamassassin" name="clamscan" dev=hdc7 ino=3123838 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:clamscan_exec_t:s0 tclass=file > type=AVC msg=audit(1149016209.346:657): avc: denied { read } for pid=11651 comm="clamassassin" name="clamassassinmsg.jSBOI11644" dev=hdc6 ino=28 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file > type=SYSCALL msg=audit(1149016209.346:657): arch=40000003 syscall=5 success=yes exit=3 a0=99e1190 a1=8000 a2=0 a3=8000 items=1 pid=11651 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="clamassassin" exe="/bin/bash" > type=PATH msg=audit(1149016209.346:657): item=0 name="/tmp/clamassassinmsg.jSBOI11644" flags=101 inode=28 dev=16:06 mode=0100600 ouid=500 ogid=500 rdev=00:00 > type=AVC msg=audit(1149017043.144:752): avc: denied { add_name } for pid=13192 comm="mktemp" name="clamassassinmsg.QRJvd13192" scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir > type=AVC msg=audit(1149017043.144:752): avc: denied { create } for pid=13192 comm="mktemp" name="clamassassinmsg.QRJvd13192" scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file > type=PATH msg=audit(1149017043.144:752): item=0 name="/tmp/clamassassinmsg.QRJvd13192" flags=310 inode=2 dev=16:06 mode=041777 ouid=0 ogid=0 rdev=00:00 > type=AVC msg=audit(1149017043.152:753): avc: denied { write } for pid=13194 comm="clamassassin" name="clamassassinmsg.QRJvd13192" dev=hdc6 ino=28 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file These are clamassassin running in the procmail domain. I think the domain transition mentioned above would probably fix these. Paul. From mschwartz at mn.rr.com Tue May 30 20:58:01 2006 From: mschwartz at mn.rr.com (Marc Schwartz (via MN)) Date: Tue, 30 May 2006 15:58:01 -0500 Subject: postfix, procmail and SELinux - No Go In-Reply-To: <1149021417.5247.17.camel@laurel.intra.city-fan.org> References: <447C6581.6050306@city-fan.org> <1149014510.4915.9.camel@localhost.localdomain> <1149015909.5247.1.camel@laurel.intra.city-fan.org> <1149018459.4915.49.camel@localhost.localdomain> <1149021417.5247.17.camel@laurel.intra.city-fan.org> Message-ID: <1149022681.4915.78.camel@localhost.localdomain> Paul, Thanks for your assistance. Give me a bit of time, with everything else (ie. work) going on, to implement and test your recommendations (and to review some documentation). I'll post back as soon as I have something definitive. On your query on pyzor, much like razor and dcc, it is called as part of the spamassassin checks when present. These constitute the 'remote' checks that one can perform when using SA. This is why I find it curious that there were no avc messages for razor and dcc. All of these were installed when SELinux was enabled initially. Thanks again for your insights. Marc From nicolas.mailhot at laposte.net Wed May 31 06:48:20 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 31 May 2006 08:48:20 +0200 Subject: postfix, procmail and SELinux - No Go In-Reply-To: <1149022681.4915.78.camel@localhost.localdomain> References: <447C6581.6050306@city-fan.org> <1149014510.4915.9.camel@localhost.localdomain> <1149015909.5247.1.camel@laurel.intra.city-fan.org> <1149018459.4915.49.camel@localhost.localdomain> <1149021417.5247.17.camel@laurel.intra.city-fan.org> <1149022681.4915.78.camel@localhost.localdomain> Message-ID: <1149058107.5163.1.camel@rousalka.dyndns.org> Le mardi 30 mai 2006 ? 15:58 -0500, Marc Schwartz (via MN) a ?crit : > > > Paul, > > Thanks for your assistance. > > Give me a bit of time, with everything else (ie. work) going on, to > implement and test your recommendations (and to review some > documentation). > > I'll post back as soon as I have something definitive. > > On your query on pyzor, much like razor and dcc, it is called as part of > the spamassassin checks when present. These constitute the 'remote' > checks that one can perform when using SA. This is why I find it curious > that there were no avc messages for razor and dcc. are you sure razor and dcc are used ? Last I looked the FC version of SA disabled the razor check because of licensing problems As for pyzor, I've reported it in the past, you need the policy to allow reading its config file, then connecting to pyzor servers, etc -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From paul at city-fan.org Wed May 31 14:15:13 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 31 May 2006 15:15:13 +0100 Subject: postfix, procmail and SELinux - No Go In-Reply-To: <1149021417.5247.17.camel@laurel.intra.city-fan.org> References: <447C6581.6050306@city-fan.org> <1149014510.4915.9.camel@localhost.localdomain> <1149015909.5247.1.camel@laurel.intra.city-fan.org> <1149018459.4915.49.camel@localhost.localdomain> <1149021417.5247.17.camel@laurel.intra.city-fan.org> Message-ID: <447DA4F1.4070300@city-fan.org> Paul Howarth wrote: > On Tue, 2006-05-30 at 14:47 -0500, Marc Schwartz (via MN) wrote: >> For reference, here is my ~/.procmailrc: >> >> # Scan for viruses using ClamAV + clamassassin >> :0 fw >> | /usr/local/bin/clamassassin >> >> # Scan with SpamAssasin (+ razor, pyzor and dcc) >> :0 fw >> | /usr/bin/spamc -s 256000 Could you also try adding a recipe for forwarding mail somewhere off your system? I suspect that may also fail with postfix as your MTA, and we might as well fix that whilst we're here. Something like this ought to do: # Test forwarding :0 * Subject: forwarding test ! myaccount at hotmail.com >> I'm not sure how much you might need/want, but here is a sampling. I >> tried to catch what appear to be complete "cycles" in each case. >> >> Here are some using grep 'procmail': >> >> type=AVC_PATH msg=audit(1149015973.940:563): path="/home/marcs/.procmailrc" >> type=PATH msg=audit(1149015973.940:563): item=0 name="/home/marcs/.procmailrc" flags=1 inode=426353 dev=fd:00 mode=0100664 ouid=500 ogid=500 rdev=00:00 >> type=AVC msg=audit(1149015973.940:564): avc: denied { read } for pid=11095 comm="procmail" name=".procmailrc" dev=dm-0 ino=426353 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file >> type=SYSCALL msg=audit(1149015973.940:564): arch=40000003 syscall=5 success=yes exit=4 a0=9337d60 a1=8000 a2=0 a3=8000 items=1 pid=11095 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="procmail" exe="/usr/bin/procmail" >> type=PATH msg=audit(1149015973.940:564): item=0 name="/home/marcs/.procmailrc" flags=101 inode=426353 dev=fd:00 mode=0100664 ouid=500 ogid=500 rdev=00:00 > > This one's a labelling prpblem. I don;t think you should have anything > labelled file_t on the system. Try changing the context of ~/.procmailrc > to user_home_t. In fact you should relabel your entire home directory: $ restorecon -Rv /home/marcs That should do until such time as you can do a full relabel of the system. >> type=AVC msg=audit(1149015973.956:565): avc: denied { execute } for pid=11101 comm="clamassassin" name="clamscan" dev=hdc7 ino=3123838 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:clamscan_exec_t:s0 tclass=file >> type=AVC msg=audit(1149015973.956:565): avc: denied { execute_no_trans } for pid=11101 comm="clamassassin" name="clamscan" dev=hdc7 ino=3123838 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:clamscan_exec_t:s0 tclass=file > > This needs a policy change. There needs to be a domain transition from > procmail_t to (I think) clamscan_exec_t. This could be done with a > policy module in the short term, and when it's working properly, publish > the fix one fedora-selinux-list and it should get included in the main > policy. I shall address this in a policy module (see below). >> Here are some using grep 'postfix': >> >> type=SYSCALL msg=audit(1149014661.600:328): arch=40000003 syscall=196 success=no exit=-2 a0=9769930 a1=bf8a4b80 a2=580ff4 a3=3 items=1 pid=8367 auid=500 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 comm="local" exe="/usr/libexec/postfix/local" >> type=CWD msg=audit(1149014661.600:328): cwd="/var/spool/postfix" >> type=CWD msg=audit(1149014661.604:329): cwd="/var/spool/postfix" >> type=CWD msg=audit(1149014661.604:330): cwd="/var/spool/postfix" >> type=AVC msg=audit(1149014770.075:378): avc: denied { search } for pid=8646 comm="local" name="/" dev=dm-0 ino=2 scontext=system_u:system_r:postfix_local_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=dir > > That looks like a mis-labelled directory. You'll need to figure out which directory this refers to (grep for 1149014770.075:378 in the log file) and use restorecon to fix the label. >> Some using grep 'pyzor'. Note that neither 'razor' nor 'dcc' are showing >> up curiously: >> >> type=AVC_PATH msg=audit(1149015851.011:541): path="/home/marcs/.pyzor" >> type=PATH msg=audit(1149015851.011:541): item=0 name="/home/marcs/.pyzor" flags=1 inode=427255 dev=fd:00 mode=040755 ouid=500 ogid=5 00 rdev=00:00 >> type=AVC msg=audit(1149015851.015:542): avc: denied { getattr } for pid=10802 comm="pyzor" name="servers" dev=dm-0 ino=427256 scon text=system_u:system_r:pyzor_t:s0 tcontext=user_u:object_r:user_home_t:s0 tclass=file >> type=SYSCALL msg=audit(1149015851.015:542): arch=40000003 syscall=195 success=yes exit=0 a0=86c1fb0 a1=bf9b8da8 a2=4891eff4 a3=868e1b 0 items=1 pid=10802 auid=4294967295 uid=500 gid=0 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="pyzor" exe="/usr/bin/ python" >> type=AVC_PATH msg=audit(1149015851.015:542): path="/home/marcs/.pyzor/servers" >> type=PATH msg=audit(1149015851.015:542): item=0 name="/home/marcs/.pyzor/servers" flags=1 inode=427256 dev=fd:00 mode=0100664 ouid=5 00 ogid=500 rdev=00:00 >> type=AVC msg=audit(1149015851.015:543): avc: denied { search } for pid=10802 comm="pyzor" name="marcs" dev=dm-0 ino=425153 scontex t=system_u:system_r:pyzor_t:s0 tcontext=user_u:object_r:user_home_dir_t:s0 tclass=dir >> type=AVC msg=audit(1149015851.015:543): avc: denied { read } for pid=10802 comm="pyzor" name="servers" dev=dm-0 ino=427256 scontex t=system_u:system_r:pyzor_t:s0 tcontext=user_u:object_r:user_home_t:s0 tclass=file >> type=SYSCALL msg=audit(1149015851.015:543): arch=40000003 syscall=5 success=yes exit=3 a0=87273d0 a1=8000 a2=1b6 a3=86e0b90 items=1 p id=10802 auid=4294967295 uid=500 gid=0 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="pyzor" exe="/usr/bin/python" >> type=PATH msg=audit(1149015851.015:543): item=0 name="/home/marcs/.pyzor/servers" flags=101 inode=427256 dev=fd:00 mode=0100664 ouid =500 ogid=500 rdev=00:00 >> type=AVC msg=audit(1149015851.027:544): avc: denied { search } for pid=10802 comm="pyzor" name="/" dev=hdc6 ino=2 scontext=system_ u:system_r:pyzor_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir >> type=AVC msg=audit(1149015851.027:544): avc: denied { write } for pid=10802 comm="pyzor" name="/" dev=hdc6 ino=2 scontext=system_u :system_r:pyzor_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir >> type=AVC msg=audit(1149015851.027:544): avc: denied { add_name } for pid=10802 comm="pyzor" name="bBOXo3" scontext=system_u:system _r:pyzor_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir >> type=AVC msg=audit(1149015851.027:544): avc: denied { create } for pid=10802 comm="pyzor" name="bBOXo3" scontext=system_u:system_r :pyzor_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file > > Those look to me like things that should be allowed but I don't know > anything about pyzor so maybe it can be used differently? This appears to be doing two things that it's not currently allowed to do: 1. Read configs from the user's home directory 2. Create and use temp files. These can probably be addressed by a separate policy module for pyzor but I'd rather fix the other issues first as there's a small chance that these might go away after doing that. >> More with grep 'spamd': >> >> type=AVC msg=audit(1149017045.372:768): avc: denied { search } for pid=1949 comm="spamd" name="/" dev=dm-0 ino=2 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=dir >> type=SYSCALL msg=audit(1149017045.372:768): arch=40000003 syscall=195 success=yes exit=0 a0=a3a19c0 a1=9ffa0c8 a2=4891eff4 a3=a3a19c0 items=1 pid=1949 auid=4294967295 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 comm="spamd" exe="/usr/bin/perl" >> type=PATH msg=audit(1149017045.372:768): item=0 name="/home/marcs/.spamassassin/user_prefs" flags=1 inode=1193881 dev=fd:00 mode=0100664 ouid=500 ogid=500 rdev=00:00 >> type=AVC msg=audit(1149017045.380:769): avc: denied { getattr } for pid=1949 comm="spamd" name="bayes_toks" dev=dm-0 ino=1193882 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file >> type=SYSCALL msg=audit(1149017045.380:769): arch=40000003 syscall=195 success=yes exit=0 a0=a3a19c0 a1=9ffa0c8 a2=4891eff4 a3=a3a19c0 items=1 pid=1949 auid=4294967295 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 comm="spamd" exe="/usr/bin/perl" >> type=AVC_PATH msg=audit(1149017045.380:769): path="/home/marcs/.spamassassin/bayes_toks" >> type=PATH msg=audit(1149017045.380:769): item=0 name="/home/marcs/.spamassassin/bayes_toks" flags=1 inode=1193882 dev=fd:00 mode=0100600 ouid=500 ogid=500 rdev=00:00 >> type=AVC msg=audit(1149017045.380:770): avc: denied { read } for pid=1949 comm="spamd" name="bayes_toks" dev=dm-0 ino=1193882 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file >> type=SYSCALL msg=audit(1149017045.380:770): arch=40000003 syscall=5 success=yes exit=8 a0=b1db3b8 a1=8000 a2=0 a3=8000 items=1 pid=1949 auid=4294967295 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 comm="spamd" exe="/usr/bin/perl" >> type=PATH msg=audit(1149017045.380:770): item=0 name="/home/marcs/.spamassassin/bayes_toks" flags=101 inode=1193882 dev=fd:00 mode=0100600 ouid=500 ogid=500 rdev=00:00 >> type=AVC msg=audit(1149017047.188:771): avc: denied { append } for pid=1949 comm="spamd" name="bayes_journal" dev=dm-0 ino=2338489 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file >> type=SYSCALL msg=audit(1149017047.188:771): arch=40000003 syscall=5 success=yes exit=10 a0=b8211d8 a1=8441 a2=1b6 a3=8441 items=1 pid=1949 auid=4294967295 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 comm="spamd" exe="/usr/bin/perl" >> type=PATH msg=audit(1149017047.188:771): item=0 name="/home/marcs/.spamassassin/bayes_journal" flags=310 inode=1193874 dev=fd:00 mode=040755 ouid=500 ogid=500 rdev=00:00 >> type=AVC msg=audit(1149017047.188:772): avc: denied { ioctl } for pid=1949 comm="spamd" name="bayes_journal" dev=dm-0 ino=2338489 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file >> type=SYSCALL msg=audit(1149017047.188:772): arch=40000003 syscall=54 success=no exit=-25 a0=a a1=5401 a2=bf84f5d8 a3=bf84f618 items=0 pid=1949 auid=4294967295 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 comm="spamd" exe="/usr/bin/perl" >> type=AVC_PATH msg=audit(1149017047.188:772): path="/home/marcs/.spamassassin/bayes_journal" >> type=AVC msg=audit(1149017047.828:791): avc: denied { write } for pid=1949 comm="spamd" name="bayes_toks" dev=dm-0 ino=1193882 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file > > More mislabelled files. I think you need to relabel the system. These should all be fixed if you've run restorecon on your home directory. Right now, time for the local policy module. Set yourself up for making local policy modules: # yum install checkpolicy # cd /root # mkdir selinux.local # cd selinux.local # chcon -R -t usr_t . # ln -s /usr/share/selinux/devel/Makefile . Make a local policy module for this issue, in this directory: 1. Create a file procmail.te with this content: policy_module(procmail, 0.5.0) require { type procmail_t; }; # temp files type procmail_tmp_t; files_tmp_file(procmail_tmp_t) # log files type procmail_var_log_t; logging_log_file(procmail_var_log_t) # Write log to /var/log/procmail.log allow procmail_t procmail_var_log_t:file create_file_perms; allow procmail_t procmail_var_log_t:dir { rw_dir_perms setattr }; logging_log_filetrans(procmail_t,procmail_var_log_t, { file dir }) # Allow programs called from procmail to read/write temp files and dirs allow procmail_t procmail_tmp_t:dir create_dir_perms; allow procmail_t procmail_tmp_t:file create_file_perms; files_type(procmail_tmp_t) files_tmp_filetrans(procmail_t, procmail_tmp_t, { file dir }) # ============================================== # Procmail needs to call sendmail for forwarding # ============================================== # Read alternatives link (still not in policy) corecmd_read_sbin_symlinks(procmail_t) # Allow transition to sendmail # This is in selinux-policy-2.2.34-2 onwards # (may need similar code for other MTAs that can replace sendmail) # sendmail_domtrans(procmail_t) # ============================================== # Procmail needs to be able to call clamassassin # ============================================== clamscan_domtrans(procmail_t) 2. Create a file procmail.fc with this content: /var/log/procmail\.log -- gen_context(system_u:object_r:procmail_var_log_t,s0) (that's one long line) 3. Create an empty procmail.if file: # touch procmail.if 4. Build the policy module # make Finally, install your new policy module: # semodule -i procmail.pp Keep running in permissive mode and test out a few things. You should get significantly fewer denials. Please report back whatever you get. Paul. From paul at city-fan.org Wed May 31 15:07:43 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 31 May 2006 16:07:43 +0100 Subject: File contexts again Message-ID: <447DB13F.7060508@city-fan.org> Having trouble with default file contexts again. I have a policy module with the following .fc file: /home/pgsql -d gen_context(system_u:object_r:var_lib_t,s0) /home/pgsql/data -d gen_context(system_u:object_r:postgresql_db_t,s0) /home/pgsql/data/.* -d gen_context(system_u:object_r:postgresql_db_t,s0) /home/pgsql/data/.* -- gen_context(system_u:object_r:postgresql_db_t,s0) /home/pgsql/pgstartup\.log -- gen_context(system_u:object_r:postgresql_log_t,s0) The entries that are not regexes work OK, but as soon as I use a regex, the type I'm specifying gets overridden by user_home_t when I do a restorecon. For instance, if I have a file /home/pgsql/data/test.db, restorecon labels it user_home_t rather than postgresql_db_t. /home/pgsql is not the home directory of any user. Why is this happening? It appears that some further tweaking to the file contexts sort order that I put on the wiki (http://fedoraproject.org/wiki/SELinux/ManagingFileContext) after the last discussion is needed. Paul. From cashworth at tresys.com Wed May 31 15:52:23 2006 From: cashworth at tresys.com (Christopher Ashworth) Date: Wed, 31 May 2006 11:52:23 -0400 Subject: File contexts again In-Reply-To: <447DB13F.7060508@city-fan.org> References: <447DB13F.7060508@city-fan.org> Message-ID: <1149090743.30503.19.camel@popeye.columbia.tresys.com> On Wed, 2006-05-31 at 16:07 +0100, Paul Howarth wrote: > Having trouble with default file contexts again. > > I have a policy module with the following .fc file: > > /home/pgsql -d > gen_context(system_u:object_r:var_lib_t,s0) > /home/pgsql/data -d > gen_context(system_u:object_r:postgresql_db_t,s0) > /home/pgsql/data/.* -d > gen_context(system_u:object_r:postgresql_db_t,s0) > /home/pgsql/data/.* -- > gen_context(system_u:object_r:postgresql_db_t,s0) > /home/pgsql/pgstartup\.log -- > gen_context(system_u:object_r:postgresql_log_t,s0) > The entries that are not regexes work OK, but as soon as I use a regex, > the type I'm specifying gets overridden by user_home_t when I do a > restorecon. > > For instance, if I have a file /home/pgsql/data/test.db, restorecon > labels it user_home_t rather than postgresql_db_t. > > /home/pgsql is not the home directory of any user. > > Why is this happening? When the file contexts are sorted, we need a way to split out some in a per-user way. If a path has the prefix keyword HOME_DIR, HOME_ROOT, or ROLE, the context specification is split out into the homedir.template file. Example: HOME_DIR/.+ user_u:object_r:user_home_t:s0 (I briefly mentioned this split in a prior post, but I should have been more clear about it; sorry about that.) This template file is used to produce file contexts for each selinux user. These per-user file contexts are written to the file "file_contexts.homedirs", which lives in the same directory as "file_contexts". When matching file contexts, the file_contexts.homedirs contexts are appended to the main file_contexts contexts, so they have priority. The contexts for user user_u include: /home/[^/]*/.+ user_u:object_r:user_home_t:s0 /home/[^/]* -d user_u:object_r:user_home_dir_t:s0 which is why your file is getting that context, even though you do not have an actual user with the home directory /home/pgsql. You can prefix your file context path expression with a template keyword to place it in the file_context.homedirs file. Chris From paul at city-fan.org Wed May 31 16:00:12 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 31 May 2006 17:00:12 +0100 Subject: File contexts again In-Reply-To: <1149090743.30503.19.camel@popeye.columbia.tresys.com> References: <447DB13F.7060508@city-fan.org> <1149090743.30503.19.camel@popeye.columbia.tresys.com> Message-ID: <447DBD8C.8090900@city-fan.org> Christopher Ashworth wrote: > On Wed, 2006-05-31 at 16:07 +0100, Paul Howarth wrote: >> Having trouble with default file contexts again. >> >> I have a policy module with the following .fc file: >> >> /home/pgsql -d >> gen_context(system_u:object_r:var_lib_t,s0) >> /home/pgsql/data -d >> gen_context(system_u:object_r:postgresql_db_t,s0) >> /home/pgsql/data/.* -d >> gen_context(system_u:object_r:postgresql_db_t,s0) >> /home/pgsql/data/.* -- >> gen_context(system_u:object_r:postgresql_db_t,s0) >> /home/pgsql/pgstartup\.log -- >> gen_context(system_u:object_r:postgresql_log_t,s0) > >> The entries that are not regexes work OK, but as soon as I use a regex, >> the type I'm specifying gets overridden by user_home_t when I do a >> restorecon. >> >> For instance, if I have a file /home/pgsql/data/test.db, restorecon >> labels it user_home_t rather than postgresql_db_t. >> >> /home/pgsql is not the home directory of any user. >> >> Why is this happening? > > When the file contexts are sorted, we need a way to split out some in a > per-user way. If a path has the prefix keyword HOME_DIR, HOME_ROOT, or > ROLE, the context specification is split out into the homedir.template > file. > > Example: > > HOME_DIR/.+ user_u:object_r:user_home_t:s0 > > (I briefly mentioned this split in a prior post, but I should have been > more clear about it; sorry about that.) > > This template file is used to produce file contexts for each selinux > user. These per-user file contexts are written to the file > "file_contexts.homedirs", which lives in the same directory as > "file_contexts". Yes, I found that. > When matching file contexts, the file_contexts.homedirs contexts are > appended to the main file_contexts contexts, so they have priority. Is there some reason why "semanage fcontext -l" does not include these? > The contexts for user user_u include: > > /home/[^/]*/.+ user_u:object_r:user_home_t:s0 > /home/[^/]* -d user_u:object_r:user_home_dir_t:s0 > > which is why your file is getting that context, even though you do not > have an actual user with the home directory /home/pgsql. I thought they'd only have priority by means of their position at the end of the list if all other sorting criteria were equal? So the fact that /home/pgsql/data(/.*)? for instance has a longer stem than /home/[^/]*/.+ should have given it precedence? > You can prefix your file context path expression with a template keyword > to place it in the file_context.homedirs file. Wouldn't that result in all /home/*/data directories and everything underneath them being labelled postgresql_db_t, not just /home/pgsql/data? Paul. From cashworth at tresys.com Wed May 31 16:44:31 2006 From: cashworth at tresys.com (Christopher Ashworth) Date: Wed, 31 May 2006 12:44:31 -0400 Subject: File contexts again In-Reply-To: <447DBD8C.8090900@city-fan.org> References: <447DB13F.7060508@city-fan.org> <1149090743.30503.19.camel@popeye.columbia.tresys.com> <447DBD8C.8090900@city-fan.org> Message-ID: <1149093871.30503.35.camel@popeye.columbia.tresys.com> On Wed, 2006-05-31 at 17:00 +0100, Paul Howarth wrote: > > When matching file contexts, the file_contexts.homedirs contexts are > > appended to the main file_contexts contexts, so they have priority. > > Is there some reason why "semanage fcontext -l" does not include these? Hmmm...I don't know off the top of my head--it certainly doesn't sound like desirable behavior. Anyone who's been around longer than me know if this is desired or a bug? I'll look to see where the homedirs are omitted during the listing by libsemange. > > The contexts for user user_u include: > > > > /home/[^/]*/.+ user_u:object_r:user_home_t:s0 > > /home/[^/]* -d user_u:object_r:user_home_dir_t:s0 > > > > which is why your file is getting that context, even though you do not > > have an actual user with the home directory /home/pgsql. > > I thought they'd only have priority by means of their position at the > end of the list if all other sorting criteria were equal? So the fact > that /home/pgsql/data(/.*)? for instance has a longer stem than > /home/[^/]*/.+ should have given it precedence? Once the sort is done during the original generation of the files, and the files have been spit out, no additional sorting occurs. So sticking the homedirs contexts at the end of the list when looking for a match means that every homedir context is checked for a match first, before any other context is checked. > > You can prefix your file context path expression with a template keyword > > to place it in the file_context.homedirs file. > > Wouldn't that result in all /home/*/data directories and everything > underneath them being labelled postgresql_db_t, not just /home/pgsql/data? Yes, you are right. Unfortunately, I don't think there is any way around this at the moment. Anything with the "/home/" prefix will get caught by the per-user contexts, and so trying to label files below "/home/" in a non-per-user way (for lack of a better term), won't work. As I understand it, you'll have to move it to a different location. Chris From paul at city-fan.org Wed May 31 16:50:08 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 31 May 2006 17:50:08 +0100 Subject: File contexts again In-Reply-To: <1149093871.30503.35.camel@popeye.columbia.tresys.com> References: <447DB13F.7060508@city-fan.org> <1149090743.30503.19.camel@popeye.columbia.tresys.com> <447DBD8C.8090900@city-fan.org> <1149093871.30503.35.camel@popeye.columbia.tresys.com> Message-ID: <447DC940.4040209@city-fan.org> Christopher Ashworth wrote: > On Wed, 2006-05-31 at 17:00 +0100, Paul Howarth wrote: >>> When matching file contexts, the file_contexts.homedirs contexts are >>> appended to the main file_contexts contexts, so they have priority. >> Is there some reason why "semanage fcontext -l" does not include these? > > Hmmm...I don't know off the top of my head--it certainly doesn't sound > like desirable behavior. Anyone who's been around longer than me know > if this is desired or a bug? I'll look to see where the homedirs are > omitted during the listing by libsemange. Thanks. >>> The contexts for user user_u include: >>> >>> /home/[^/]*/.+ user_u:object_r:user_home_t:s0 >>> /home/[^/]* -d user_u:object_r:user_home_dir_t:s0 >>> >>> which is why your file is getting that context, even though you do not >>> have an actual user with the home directory /home/pgsql. >> I thought they'd only have priority by means of their position at the >> end of the list if all other sorting criteria were equal? So the fact >> that /home/pgsql/data(/.*)? for instance has a longer stem than >> /home/[^/]*/.+ should have given it precedence? > > Once the sort is done during the original generation of the files, and > the files have been spit out, no additional sorting occurs. So sticking > the homedirs contexts at the end of the list when looking for a match > means that every homedir context is checked for a match first, before > any other context is checked. Hmm, that doesn't explain why file contexts that aren't regexes do actually work. So if I have: /home/pgsql/pgstartup\.log -- gen_context(system_u:object_r:postgresql_log_t,s0) this actually works as expected, even though the /home/[^/]*/.+ homedir context also matches. >>> You can prefix your file context path expression with a template keyword >>> to place it in the file_context.homedirs file. >> Wouldn't that result in all /home/*/data directories and everything >> underneath them being labelled postgresql_db_t, not just /home/pgsql/data? > > Yes, you are right. Unfortunately, I don't think there is any way > around this at the moment. Anything with the "/home/" prefix will get > caught by the per-user contexts, and so trying to label files below > "/home/" in a non-per-user way (for lack of a better term), won't work. > As I understand it, you'll have to move it to a different location. Actually this isn't my problem - I'm trying to help someone else. If it was me I'd just bind mount /home/pgsql on /var/lib/pgsql and there wouldn't be an issue... Paul. From cashworth at tresys.com Wed May 31 16:54:31 2006 From: cashworth at tresys.com (Christopher Ashworth) Date: Wed, 31 May 2006 12:54:31 -0400 Subject: File contexts again In-Reply-To: <447DC940.4040209@city-fan.org> References: <447DB13F.7060508@city-fan.org> <1149090743.30503.19.camel@popeye.columbia.tresys.com> <447DBD8C.8090900@city-fan.org> <1149093871.30503.35.camel@popeye.columbia.tresys.com> <447DC940.4040209@city-fan.org> Message-ID: <1149094471.30503.38.camel@popeye.columbia.tresys.com> On Wed, 2006-05-31 at 17:50 +0100, Paul Howarth wrote: > Hmm, that doesn't explain why file contexts that aren't regexes do > actually work. So if I have: > > /home/pgsql/pgstartup\.log -- > gen_context(system_u:object_r:postgresql_log_t,s0) > > this actually works as expected, even though the /home/[^/]*/.+ > homedir context also matches. Ah, true. I forgot you had said that this behavior was occurring. It seems I have misremembered what is happening. Let me look again to confirm what's going on. Chris From sds at tycho.nsa.gov Wed May 31 17:05:47 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 31 May 2006 13:05:47 -0400 Subject: File contexts again In-Reply-To: <1149094471.30503.38.camel@popeye.columbia.tresys.com> References: <447DB13F.7060508@city-fan.org> <1149090743.30503.19.camel@popeye.columbia.tresys.com> <447DBD8C.8090900@city-fan.org> <1149093871.30503.35.camel@popeye.columbia.tresys.com> <447DC940.4040209@city-fan.org> <1149094471.30503.38.camel@popeye.columbia.tresys.com> Message-ID: <1149095147.524.217.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-05-31 at 12:54 -0400, Christopher Ashworth wrote: > On Wed, 2006-05-31 at 17:50 +0100, Paul Howarth wrote: > > Hmm, that doesn't explain why file contexts that aren't regexes do > > actually work. So if I have: > > > > /home/pgsql/pgstartup\.log -- > > gen_context(system_u:object_r:postgresql_log_t,s0) > > > > this actually works as expected, even though the /home/[^/]*/.+ > > homedir context also matches. > > Ah, true. I forgot you had said that this behavior was occurring. It > seems I have misremembered what is happening. Let me look again to > confirm what's going on. libselinux gives precedence to fully specified pathnames (no regex characters). Doesn't matter where they fall within the config files. -- Stephen Smalley National Security Agency From selinux at gmail.com Wed May 31 17:06:50 2006 From: selinux at gmail.com (Tom London) Date: Wed, 31 May 2006 10:06:50 -0700 Subject: home dir is default_t ? Message-ID: <4c4ba1530605311006s3bb4cb14hc58ae070ff73692d@mail.gmail.com> Running today's rawhide, targeted/enforcing. I did a 'restorecon -v -R' of my home directory (/home/tbl) and it relabeled almost everything as default_t. Did I miss a step in the upgrade? tom -- Tom London From selinux at gmail.com Wed May 31 17:17:07 2006 From: selinux at gmail.com (Tom London) Date: Wed, 31 May 2006 10:17:07 -0700 Subject: setsebool generates error message.... Message-ID: <4c4ba1530605311017i72e7267ej5632ff0e68556205@mail.gmail.com> Running today's rawhide, targeted/enforcing: [root at localhost files]# setsebool allow_execmem=1 libsemanage.semanage_install_active: setfiles returned error code 1. libsemanage.semanage_install_active: setfiles returned error code 1. Could not change policy booleans [root at localhost files]# Appears that boolean has changed: [root at localhost files]# getsebool -a | grep exec allow_execheap --> off allow_execmem --> on allow_execmod --> off allow_execstack --> on allow_java_execstack --> on httpd_ssi_exec --> off httpd_suexec_disable_trans --> off [root at localhost files]# tom -- Tom London From cashworth at tresys.com Wed May 31 17:58:40 2006 From: cashworth at tresys.com (Christopher Ashworth) Date: Wed, 31 May 2006 13:58:40 -0400 Subject: File contexts again In-Reply-To: <1149095147.524.217.camel@moss-spartans.epoch.ncsc.mil> References: <447DB13F.7060508@city-fan.org> <1149090743.30503.19.camel@popeye.columbia.tresys.com> <447DBD8C.8090900@city-fan.org> <1149093871.30503.35.camel@popeye.columbia.tresys.com> <447DC940.4040209@city-fan.org> <1149094471.30503.38.camel@popeye.columbia.tresys.com> <1149095147.524.217.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1149098320.30503.59.camel@popeye.columbia.tresys.com> On Wed, 2006-05-31 at 13:05 -0400, Stephen Smalley wrote: > On Wed, 2006-05-31 at 12:54 -0400, Christopher Ashworth wrote: > > On Wed, 2006-05-31 at 17:50 +0100, Paul Howarth wrote: > > > Hmm, that doesn't explain why file contexts that aren't regexes do > > > actually work. So if I have: > > > > > > /home/pgsql/pgstartup\.log -- > > > gen_context(system_u:object_r:postgresql_log_t,s0) > > > > > > this actually works as expected, even though the /home/[^/]*/.+ > > > homedir context also matches. > > > > Ah, true. I forgot you had said that this behavior was occurring. It > > seems I have misremembered what is happening. Let me look again to > > confirm what's going on. > > libselinux gives precedence to fully specified pathnames (no regex > characters). Doesn't matter where they fall within the config files. Ah, right; thanks. (As specified in libselinux/src/matchpathcon.c) So what I said before was true, modulo the fact that when the actual call to matchpathcon is made, one final sort is performed, to give fully specified pathnames precedence. Seems like the end-to-end process is a bit confusing, what with several layers of sorting going on, but I can't immediately suggest an improvement. I guess it's just a matter of documenting the life of file contexts as clearly as possible. Chris From sds at tycho.nsa.gov Wed May 31 18:19:10 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 31 May 2006 14:19:10 -0400 Subject: File contexts again In-Reply-To: <1149098320.30503.59.camel@popeye.columbia.tresys.com> References: <447DB13F.7060508@city-fan.org> <1149090743.30503.19.camel@popeye.columbia.tresys.com> <447DBD8C.8090900@city-fan.org> <1149093871.30503.35.camel@popeye.columbia.tresys.com> <447DC940.4040209@city-fan.org> <1149094471.30503.38.camel@popeye.columbia.tresys.com> <1149095147.524.217.camel@moss-spartans.epoch.ncsc.mil> <1149098320.30503.59.camel@popeye.columbia.tresys.com> Message-ID: <1149099550.524.252.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-05-31 at 13:58 -0400, Christopher Ashworth wrote: > On Wed, 2006-05-31 at 13:05 -0400, Stephen Smalley wrote: > > On Wed, 2006-05-31 at 12:54 -0400, Christopher Ashworth wrote: > > > On Wed, 2006-05-31 at 17:50 +0100, Paul Howarth wrote: > > > > Hmm, that doesn't explain why file contexts that aren't regexes do > > > > actually work. So if I have: > > > > > > > > /home/pgsql/pgstartup\.log -- > > > > gen_context(system_u:object_r:postgresql_log_t,s0) > > > > > > > > this actually works as expected, even though the /home/[^/]*/.+ > > > > homedir context also matches. > > > > > > Ah, true. I forgot you had said that this behavior was occurring. It > > > seems I have misremembered what is happening. Let me look again to > > > confirm what's going on. > > > > libselinux gives precedence to fully specified pathnames (no regex > > characters). Doesn't matter where they fall within the config files. > > Ah, right; thanks. (As specified in libselinux/src/matchpathcon.c) > > So what I said before was true, modulo the fact that when the actual > call to matchpathcon is made, one final sort is performed, to give fully > specified pathnames precedence. > > Seems like the end-to-end process is a bit confusing, what with several > layers of sorting going on, but I can't immediately suggest an > improvement. I guess it's just a matter of documenting the life of file > contexts as clearly as possible. Ultimately, we'd like to migrate all integration and ordering of the various file contexts sources into libsemanage and eliminate the need for it in libselinux. Mostly a legacy issue. -- Stephen Smalley National Security Agency From cashworth at tresys.com Wed May 31 18:32:35 2006 From: cashworth at tresys.com (Christopher Ashworth) Date: Wed, 31 May 2006 14:32:35 -0400 Subject: File contexts again In-Reply-To: <1149090743.30503.19.camel@popeye.columbia.tresys.com> References: <447DB13F.7060508@city-fan.org> <1149090743.30503.19.camel@popeye.columbia.tresys.com> Message-ID: <1149100355.30503.68.camel@popeye.columbia.tresys.com> On Wed, 2006-05-31 at 11:52 -0400, Christopher Ashworth wrote: > Example: > > HOME_DIR/.+ user_u:object_r:user_home_t:s0 Also, I need to correct the above example. It should read: HOME_DIR/.+ system_u:object_r:user_home_t:s0 because genhomedircon replaces "system_u" with the proper user while generating file_contexts.homedirs. Sorry for the typo. Chris From MSchwartz at mn.rr.com Wed May 31 20:04:04 2006 From: MSchwartz at mn.rr.com (Marc Schwartz) Date: Wed, 31 May 2006 15:04:04 -0500 Subject: postfix, procmail and SELinux - No Go In-Reply-To: <1149058107.5163.1.camel@rousalka.dyndns.org> References: <447C6581.6050306@city-fan.org> <1149014510.4915.9.camel@localhost.localdomain> <1149015909.5247.1.camel@laurel.intra.city-fan.org> <1149018459.4915.49.camel@localhost.localdomain> <1149021417.5247.17.camel@laurel.intra.city-fan.org> <1149022681.4915.78.camel@localhost.localdomain> <1149058107.5163.1.camel@rousalka.dyndns.org> Message-ID: <447DF6B4.5020602@mn.rr.com> Nicolas Mailhot wrote: > Le mardi 30 mai 2006 ? 15:58 -0500, Marc Schwartz (via MN) a ?crit : >> >> >> Paul, >> >> Thanks for your assistance. >> >> Give me a bit of time, with everything else (ie. work) going on, to >> implement and test your recommendations (and to review some >> documentation). >> >> I'll post back as soon as I have something definitive. >> >> On your query on pyzor, much like razor and dcc, it is called as part of >> the spamassassin checks when present. These constitute the 'remote' >> checks that one can perform when using SA. This is why I find it curious >> that there were no avc messages for razor and dcc. > > are you sure razor and dcc are used ? Last I looked the FC version of SA > disabled the razor check because of licensing problems > > As for pyzor, I've reported it in the past, you need the policy to allow > reading its config file, then connecting to pyzor servers, etc Nicolas, Thanks kindly for making note of this. In SA 3.1.x, which is new to FC5, these checks are indeed disabled. From some Googling, this appears to not be unique to FC, but to SA itself. In FC4, which used SA 3.0.x, these checks worked fine without adjustments to config files. I was not aware of the change. I have now edited: /etc/mail/spamassassin/v310pre to enable the checks. I also did some fine tuning to ~/.spamassassin/user.prefs to account for some setting changes as well. Sure enough, avc messages are now being logged. I have cc'd Paul to reference the additional info below: Now for grep "dcc": type=SYSCALL msg=audit(1149104051.041:8648): arch=40000003 syscall=197 success=yes exit=0 a0=4 a1=bfaad188 a2=4891eff4 a3=3 items=0 pi d=25104 auid=500 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 comm="dccproc" exe="/usr/local/bin/dccproc" type=AVC_PATH msg=audit(1149104051.041:8648): path="/var/dcc/map" type=AVC msg=audit(1149104051.041:8649): avc: denied { lock } for pid=25104 comm="dccproc" name="map" dev=hdc5 ino=87811 scontext=s ystem_u:system_r:spamd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file type=SYSCALL msg=audit(1149104051.041:8649): arch=40000003 syscall=221 success=yes exit=0 a0=4 a1=7 a2=bfaae304 a3=bfaae304 items=0 pi d=25104 auid=500 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 comm="dccproc" exe="/usr/local/bin/dccproc" type=AVC_PATH msg=audit(1149104051.041:8649): path="/var/dcc/map" type=AVC msg=audit(1149104167.275:8694): avc: denied { read write } for pid=25544 comm="dccproc" name="map" dev=hdc5 ino=87811 scon text=system_u:system_r:spamd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file type=SYSCALL msg=audit(1149104167.275:8694): arch=40000003 syscall=5 success=yes exit=4 a0=80ba6e0 a1=2 a2=180 a3=11 items=1 pid=25544 auid=500 uid=500 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=500 fsgid=0 comm="dccproc" exe="/usr/local/bin/dccproc" type=CWD msg=audit(1149104167.275:8694): cwd="/var/dcc" type=PATH msg=audit(1149104167.275:8694): item=0 name="/var/dcc/map" flags=101 inode=87811 dev=16:05 mode=0100600 ouid=0 ogid=0 rdev= 00:00 type=AVC msg=audit(1149104167.275:8695): avc: denied { getattr } for pid=25544 comm="dccproc" name="map" dev=hdc5 ino=87811 scontex t=system_u:system_r:spamd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file type=SYSCALL msg=audit(1149104167.275:8695): arch=40000003 syscall=197 success=yes exit=0 a0=4 a1=bfbf5cc8 a2=4891eff4 a3=3 items=0 pi d=25544 auid=500 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 comm="dccproc" exe="/usr/local/bin/dccproc" type=AVC_PATH msg=audit(1149104167.275:8695): path="/var/dcc/map" type=AVC msg=audit(1149104167.275:8696): avc: denied { lock } for pid=25544 comm="dccproc" name="map" dev=hdc5 ino=87811 scontext=s ystem_u:system_r:spamd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file type=SYSCALL msg=audit(1149104167.275:8696): arch=40000003 syscall=221 success=yes exit=0 a0=4 a1=7 a2=bfbf6e44 a3=bfbf6e44 items=0 pi d=25544 auid=500 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 comm="dccproc" exe="/usr/local/bin/dccproc" type=AVC_PATH msg=audit(1149104167.275:8696): path="/var/dcc/map" For grep "razor": type=AVC msg=audit(1149102177.498:8243): avc: denied { append } for pid=20136 comm="spamd" name="razor-agent.log" dev=hdc7 ino=98923 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file type=PATH msg=audit(1149102177.498:8243): item=0 name="razor-agent.log" flags=310 inode=2 dev=16:07 mode=040755 ouid=0 ogid=0 rdev=00:00 type=AVC msg=audit(1149102177.498:8244): avc: denied { ioctl } for pid=20136 comm="spamd" name="razor-agent.log" dev=hdc7 ino=98923 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file type=AVC_PATH msg=audit(1149102177.498:8244): path="/razor-agent.log" type=AVC msg=audit(1149102177.498:8245): avc: denied { getattr } for pid=20136 comm="spamd" name="razor-agent.log" dev=hdc7 ino=98923 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file type=AVC_PATH msg=audit(1149102177.498:8245): path="/razor-agent.log" type=AVC msg=audit(1149102177.530:8246): avc: denied { add_name } for pid=20136 comm="spamd" name=".razor" scontext=system_u:system_r:spamd_t:s0 tcontext=root:object_r:user_home_dir_t:s0 tclass=dir type=AVC msg=audit(1149102177.530:8246): avc: denied { create } for pid=20136 comm="spamd" name=".razor" scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:user_home_dir_t:s0 tclass=dir type=PATH msg=audit(1149102177.530:8246): item=0 name="/root/.razor" flags=10 inode=65537 dev=16:07 mode=040750 ouid=0 ogid=0 rdev=00:00 type=AVC msg=audit(1149102177.554:8247): avc: denied { read } for pid=20136 comm="spamd" name=".razor" dev=hdc7 ino=829589 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:user_home_dir_t:s0 tclass=dir type=PATH msg=audit(1149102177.554:8247): item=0 name="/root/.razor" flags=103 inode=829589 dev=16:07 mode=040755 ouid=0 ogid=0 rdev=00:00 type=AVC msg=audit(1149102178.058:8248): avc: denied { write } for pid=20136 comm="spamd" name=".razor" dev=hdc7 ino=829589 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:user_home_dir_t:s0 tclass=dir type=PATH msg=audit(1149102178.058:8248): item=0 name="/root/.razor/servers.discovery.lst.lock" flags=310 inode=829589 dev=16:07 mode=040755 ouid=0 ogid=0 rdev=00:00 type=AVC_PATH msg=audit(1149102178.058:8249): path="/root/.razor/servers.discovery.lst.lock" type=AVC_PATH msg=audit(1149102178.058:8250): path="/root/.razor/servers.discovery.lst.lock" type=AVC_PATH msg=audit(1149102178.058:8251): path="/root/.razor/servers.discovery.lst" type=PATH msg=audit(1149102178.058:8252): item=0 name="/root/.razor/servers.discovery.lst.lock" flags=10 inode=829589 dev=16:07 mode=040755 ouid=0 ogid=0 rdev=00:00 I think that the last few messages for razor have to do with server configuration for 'root', not actual calls to the razor checks via SA. I am now seeing razor check hits in incoming e-mail headers. Have not seen any for DCC yet. Paul, I will reply to your other post momentarily. Thanks to both of you. Marc From MSchwartz at mn.rr.com Wed May 31 20:12:47 2006 From: MSchwartz at mn.rr.com (Marc Schwartz) Date: Wed, 31 May 2006 15:12:47 -0500 Subject: postfix, procmail and SELinux - No Go In-Reply-To: <447DA4F1.4070300@city-fan.org> References: <447C6581.6050306@city-fan.org> <1149014510.4915.9.camel@localhost.localdomain> <1149015909.5247.1.camel@laurel.intra.city-fan.org> <1149018459.4915.49.camel@localhost.localdomain> <1149021417.5247.17.camel@laurel.intra.city-fan.org> <447DA4F1.4070300@city-fan.org> Message-ID: <1149106367.19798.56.camel@localhost.localdomain> Paul, Thanks for your assistance with this process. I will follow your instructions and implement the new policy for testing and get back with any questions/comments. Last night, after beginning this process, I had reviewed the FAQ and went ahead and did a complete relabelling of the entire system using: /sbin/fixfiles relabel and then re-booted. Hopefully that will take care of some of the issues that you referenced. Paul, I can't thank you enough for taking the time to make the detailed instructions available. It would have taken me several hours, I am sure, to review the requisite documentation to figure this out. If you see anything of note in the dcc/razor avc's that I posted in my other reply, please let me know. Thanks again. Regards, Marc Schwartz From i.pilcher at comcast.net Wed May 31 20:43:40 2006 From: i.pilcher at comcast.net (Ian Pilcher) Date: Wed, 31 May 2006 15:43:40 -0500 Subject: Fedora Core +SELinux +VMware GSX server In-Reply-To: <1148559512.2511.9.camel@michaelc.nyit.edu> References: <1148559512.2511.9.camel@michaelc.nyit.edu> Message-ID: Michael Colef wrote: > I am wondering if anyone has any information about setting up SELinux > policies or sample policy files for a Fedora Core host running VMware > GSX server. I am presently looking at both FC4 and FC5. I have VMware Server (successor to GSX server) running on Fedora Core 5. All I had to do was make sure that VmPerl.so and HConfig.so have their type set to textrel_shlib_t. -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ========================================================================