From hugomartinplug at yahoo.com Thu Feb 1 01:57:41 2007 From: hugomartinplug at yahoo.com (Hugo Martin Campos V.) Date: Thu, 1 Feb 2007 01:57:41 +0000 (GMT) Subject: making a user create files as "user_u:system_r:httpd_t" Message-ID: <19454.28171.qm@web39511.mail.mud.yahoo.com> Hello list, I am analyzing a HTTPd server working with SELinux in permissive mode before I enforce it. The problem I've seen so far begins when the .html .php files get uploaded by the person in charge and they are labeled as "system_u:object_r:default_t" and the label needs to be "user_u:system_r:httpd_t" The resulting error: avc: denied { getattr } for pid=8244 comm="httpd" name="/" dev=hda5 ino=2 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:default_t tclass=dir I added that folder to be labeled as "user_u:system_r:httpd_t" in "/etc/selinux/targeted/src/policy/file_contexts/file_contexts" to relabel it with "fixfiles restore" (and it works) but it's not practical to relabel everything everytime that user uploads a webpage. What should I do?? My knowledge goes as far as labeling, do I need to set roles? or should I follow audit2allow advice for now. It would just be cool to autolabel every file uploaded by that user as "user_u:system_r:httpd_t" Thanks, Hugo Martin --------------------------------- Pregunt?. Respond?. Descubr?. Todo lo que quer?as saber, y lo que ni imaginabas, est? en Yahoo! Respuestas (Beta). Probalo ya! -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at city-fan.org Thu Feb 1 07:41:09 2007 From: paul at city-fan.org (Paul Howarth) Date: Thu, 01 Feb 2007 07:41:09 +0000 Subject: making a user create files as "user_u:system_r:httpd_t" In-Reply-To: <19454.28171.qm@web39511.mail.mud.yahoo.com> References: <19454.28171.qm@web39511.mail.mud.yahoo.com> Message-ID: <1170315669.23374.2.camel@metropolis.intra.city-fan.org> On Thu, 2007-02-01 at 01:57 +0000, Hugo Martin Campos V. wrote: > Hello list, > > I am analyzing a HTTPd server working with SELinux in permissive mode > before I enforce it. The problem I've seen so far begins when > the .html .php files get uploaded by the person in charge and they are > labeled as "system_u:object_r:default_t" and the label needs to be > "user_u:system_r:httpd_t" > > The resulting error: > avc: denied { getattr } for pid=8244 comm="httpd" name="/" dev=hda5 > ino=2 scontext=user_u:system_r:httpd_t > tcontext=system_u:object_r:default_t tclass=dir > > I added that folder to be labeled as "user_u:system_r:httpd_t" in > "/etc/selinux/targeted/src/policy/file_contexts/file_contexts" to > relabel it with "fixfiles restore" (and it works) but it's not > practical to relabel everything everytime that user uploads a webpage. > > What should I do?? My knowledge goes as far as labeling, do I need to > set roles? or should I follow audit2allow advice for now. It would > just be cool to autolabel every file uploaded by that user as > "user_u:system_r:httpd_t" How is the person uploading the files and where in the directory hierarchy are they uploading them to? Paul. From sds at tycho.nsa.gov Thu Feb 1 12:25:51 2007 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 01 Feb 2007 07:25:51 -0500 Subject: making a user create files as "user_u:system_r:httpd_t" In-Reply-To: <1170315669.23374.2.camel@metropolis.intra.city-fan.org> References: <19454.28171.qm@web39511.mail.mud.yahoo.com> <1170315669.23374.2.camel@metropolis.intra.city-fan.org> Message-ID: <1170332751.12293.110.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2007-02-01 at 07:41 +0000, Paul Howarth wrote: > On Thu, 2007-02-01 at 01:57 +0000, Hugo Martin Campos V. wrote: > > Hello list, > > > > I am analyzing a HTTPd server working with SELinux in permissive mode > > before I enforce it. The problem I've seen so far begins when > > the .html .php files get uploaded by the person in charge and they are > > labeled as "system_u:object_r:default_t" and the label needs to be > > "user_u:system_r:httpd_t" > > > > The resulting error: > > avc: denied { getattr } for pid=8244 comm="httpd" name="/" dev=hda5 > > ino=2 scontext=user_u:system_r:httpd_t > > tcontext=system_u:object_r:default_t tclass=dir > > > > I added that folder to be labeled as "user_u:system_r:httpd_t" in > > "/etc/selinux/targeted/src/policy/file_contexts/file_contexts" to > > relabel it with "fixfiles restore" (and it works) but it's not > > practical to relabel everything everytime that user uploads a webpage. > > > > What should I do?? My knowledge goes as far as labeling, do I need to > > set roles? or should I follow audit2allow advice for now. It would > > just be cool to autolabel every file uploaded by that user as > > "user_u:system_r:httpd_t" > > How is the person uploading the files and where in the directory > hierarchy are they uploading them to? Note btw that user_u:system_r:httpd_t is a process context, not a context for files. You likely want user_u:object_r:httpd_sys_content_t instead. By default, files should inherit their type from the parent directory, so if you were copying files to /var/www/html, it should pick up the right context automatically. But if you upload to a different directory and then move the files into place, the file will inherit the context of the directory in which it was originally created and mv will seek to preserve the context. -- Stephen Smalley National Security Agency From ejtr at layer3.co.uk Thu Feb 1 18:46:36 2007 From: ejtr at layer3.co.uk (Ted Rule) Date: Thu, 01 Feb 2007 18:46:36 +0000 Subject: Java problems on FC6/strict Message-ID: <1170355597.3601.58.camel@topaz.bugfinder.co.uk> To begin at the beginning... I was trying to configure my FC6 machine so that I could run the OpenOffice SVG Import Filter here: http://www.ipd.uka.de/~hauma/svg-import/ I also wanted to be able to run Java as a plugin to Firefox-2.0.0.1. FFX2 runs Ok on FC6 - it just needs a few minor SELinux workrounds. The big problem with the SVG Import Filter is that it requires Java 1.5, so I've always assumed that the GNU Java 1.4.2 compatible RPMs won't support some of the more esoteric Java API functions. Hence the perceived need to install the latest Sun Java RPMs. I previously had both Sun-Java/Firefox and OpenOffice/SVG-Import working Ok on FC4 - again with a few minor policy patches. So I duly installed Sun's jre-1.5.0_10 RPM, and for good measure I manually adjusted the /etc/alternatives/java settings to make /usr/bin/java point to Sun. I also "execstack -l"'ed all the Sun Libraries so as to reduce the propensity for it to need exectack/execmem/execmod permissions. With all this in place, I ran up OpenOffice, going to Tools -> Options -> Java in an attempt to select Sun Java as the prefered JVM. Needless to say, avc's galore showed up in /var/log/messages. After quite a while trying to tweak SELinux policy to suit, I gave up the fight and decided that my next best option was to simply tweak file labels and policy so that Java was executed in user_t rather than user_javaplugin_t. I therefore gave bin/java bin/java_vm and bin/javaws in Sun-jre a "java_notrans_exec_t" label, and added can_exec(user_t, java_notrans_exec_t) The last hurdle was that Sun JRE is full of execstack/execmem/execmod problems - still - so I had to enable the global allow_execmem boolean - only. With all of this in place, and with NO relabel of the GNU Java binaries on the same box or any other policy changes to user_t permissions, I was finally able to see Sun Java as a valid JVM from inside OpenOffice. However, I noted that GNU Java was still throwing up lots of avc's when I opened OpenOffice -> Tools -> Options -> Java As an example of the avc's generated by staff_javaplugin_t trying to open GNU Java from OpenOffice, I have this log snippet: [root at topaz log]# grep gij messages| grep 14:26:47 | grep -v granted Feb 1 14:26:47 topaz kernel: audit(1170340007.573:4914): avc: denied { write } for pid=6774 comm="gij" name="[32609]" dev=pipefs ino=32609 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4915): avc: denied { write } for pid=6774 comm="gij" name="[32610]" dev=pipefs ino=32610 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4916): avc: denied { read } for pid=6774 comm="gij" name="[32525]" dev=pipefs ino=32525 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4917): avc: denied { write } for pid=6774 comm="gij" name="[32525]" dev=pipefs ino=32525 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4918): avc: denied { read } for pid=6774 comm="gij" name="[32528]" dev=pipefs ino=32528 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4919): avc: denied { write } for pid=6774 comm="gij" name="[32528]" dev=pipefs ino=32528 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4920): avc: denied { read } for pid=6774 comm="gij" name="[32529]" dev=pipefs ino=32529 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4921): avc: denied { write } for pid=6774 comm="gij" name="[32529]" dev=pipefs ino=32529 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4922): avc: denied { read } for pid=6774 comm="gij" name="ooo680en-US.res" dev=hda6 ino=1760867 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4923): avc: denied { read } for pid=6774 comm="gij" name="ofa680en-US.res" dev=hda6 ino=1760866 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4924): avc: denied { read } for pid=6774 comm="gij" name="ooo680en-US.res" dev=hda6 ino=1760867 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4925): avc: denied { read } for pid=6774 comm="gij" name="sfx680en-US.res" dev=hda6 ino=1760876 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4926): avc: denied { read } for pid=6774 comm="gij" name="vcl680en-US.res" dev=hda6 ino=1760888 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4927): avc: denied { read } for pid=6774 comm="gij" name="sw680en-US.res" dev=hda6 ino=1760881 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4928): avc: denied { read } for pid=6774 comm="gij" name="svx680en-US.res" dev=hda6 ino=1760880 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4929): avc: denied { read } for pid=6774 comm="gij" name="svt680en-US.res" dev=hda6 ino=1760879 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4930): avc: denied { read write } for pid=6774 comm="gij" name="svdb.tmp" dev=hda5 ino=219746 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=staff_u:object_r:staff_tmp_t:s0 tclass=file Feb 1 14:26:47 topaz kernel: audit(1170340007.826:4952): avc: denied { getattr } for pid=6774 comm="gij" name="JREProperties.class" dev=hda6 ino=1729341 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file Feb 1 14:26:47 topaz kernel: audit(1170340007.826:4953): avc: denied { getattr } for pid=6774 comm="gij" name="JREProperties.class" dev=hda6 ino=1729341 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file Feb 1 14:26:47 topaz kernel: audit(1170340007.827:4954): avc: denied { getattr } for pid=6774 comm="gij" name="JREProperties.class" dev=hda6 ino=1729341 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file Feb 1 14:26:47 topaz kernel: audit(1170340007.827:4955): avc: denied { read } for pid=6774 comm="gij" name="JREProperties.class" dev=hda6 ino=1729341 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file Feb 1 14:26:47 topaz kernel: audit(1170340007.847:4960): avc: denied { execute } for pid=6783 comm="gij" name="addr2line" dev=hda6 ino=359825 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file [root at topaz log]# Running up Sun Java inside Firefox I came across a similar set of problems, and was similarly forced to run Sun java in user_mozilla_t instead of user_javaplugin_t to get it to work. I haven't bothered to try and run GNU Java inside Firefox, as yet. As with user_t, I had to grant user_mozilla_t execmem permissions because of the broken Sun binaries. The Java "test page" I was using in Firefox is here, FWIW: http://www.java.com/en/download/help/testvm.xml Meanwhile, for historical background: Looking back at the FC4 policy, I seems that Java run from user_t has no corresponding javaplugin_domain() definition in base_user_macros.te and hence would always have run in user_t. Meanwhile, on FC4, Java run from user_mozilla_t would run in user_mozilla_javaplugin_t. By contrast, FC6 seems to run java in user_javaplugin_t irrespective of whether one starts from user_t or user_mozilla_t; this just seems a bit odd to me. To ease the problems associated with running Java from OpenOffice, could I therefore request that an extra boolean be added to policy, namely "disable_java_trans", which defaults OFF, and can be enabled to achieve the same effect as my manual relabel for both user_t and user_mozilla_t domains. I would also like to try and disable the execmem boolean, but obviously that requires a recompile of the entire Sun RPM from scratch. Does anyone on this list know who we might approach at Sun so as to get them to rebuild their JVM with a newer/cleaner compiler toolkit? As with previous postings, I'm currently running selinux-policy-strict-2.4.6-27 -- Ted Rule Director, Layer3 Systems Ltd W: http://www.layer3.co.uk/ From hugomartinplug at yahoo.com Fri Feb 2 03:49:28 2007 From: hugomartinplug at yahoo.com (Hugo Martin Campos V.) Date: Fri, 2 Feb 2007 03:49:28 +0000 (GMT) Subject: making a user create files as "user_u:system_r:httpd_t" In-Reply-To: <1170332751.12293.110.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <230304.24601.qm@web39504.mail.mud.yahoo.com> Stephen Smalley escribi?: [ snip ] > > How is the person uploading the files and where in the directory > hierarchy are they uploading them to? Note btw that user_u:system_r:httpd_t is a process context, not a context for files. You likely want user_u:object_r:httpd_sys_content_t instead. By default, files should inherit their type from the parent directory, so if you were copying files to /var/www/html, it should pick up the right context automatically. But if you upload to a different directory and then move the files into place, the file will inherit the context of the directory in which it was originally created and mv will seek to preserve the context. Thanks Stephen and Paul, The person uploads the files in "/home2/web/" as the user "web2" These errors were generated before your advice (I could only reproduce the 2nd): avc: denied { getattr } for pid=8244 comm="httpd" name="/" dev=hda5 ino=2 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:default_t tclass=dir avc: denied { read } for pid=8247 comm="httpd" name="index.php" dev=hda5 ino=701772 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:default_t tclass=file After your advice I labeled the files in "/etc/selinux/targeted/src/policy/file_contexts/file_contexts" as: ... /home2/web(/.*)? system_u:object_r:httpd_user_content_t /home/httpd/html(/.*)? system_u:object_r:httpd_user_content_t When I create a file (HM-TestFile-web2) in /home2/web/ as web2 (the web admin) it gets labeled as: -rw-r--r-- web2 users user_u:object_r:httpd_sys_content_t HM-TestFile-web2 drwxr-xr-x web2 users system_u:object_r:httpd_user_content_t images -rw-r--r-- web2 users system_u:object_r:httpd_user_content_t index.html ... which is weird because the parent "/home2/web/" has "system_u:object_r:httpd_user_content_t" I am assuming that labeling as "httpd_user_content_t" is more secure in this case than "httpd_sys_content_t", is that true? Anyway, with those labels no denials have appeared on the logs so far. Hugo Martin --------------------------------- Pregunt?. Respond?. Descubr?. Todo lo que quer?as saber, y lo que ni imaginabas, est? en Yahoo! Respuestas (Beta). Probalo ya! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dblistsub-fedora at yahoo.it Sat Feb 3 21:19:42 2007 From: dblistsub-fedora at yahoo.it (Davide Bolcioni) Date: Sat, 3 Feb 2007 22:19:42 +0100 Subject: audit message on shutdown Message-ID: <200702032219.42820.dblistsub-fedora@yahoo.it> Greetings, I have been seeing an elusive message on shutdown, along the lines of audit(...) user uid=0 auid=4294967295 subj=system_u:system_r:hwclock_t:s0 msg='changing system time ... res=success)' and apparently harmless, since the clock is running ok on subsequent boot (but I am using NTP). Is it safe to ignore this or should I dig deeper ? Thank you for your consideration, Davide Bolcioni -- There is no place like /home. From selinux at gmail.com Sun Feb 4 00:26:42 2007 From: selinux at gmail.com (Tom London) Date: Sat, 3 Feb 2007 16:26:42 -0800 Subject: prelink AVC Message-ID: <4c4ba1530702031626hc6ad177j6a8391017b4c8ead@mail.gmail.com> Latest rawhide, targeted/enforcing: type=AVC msg=audit(1170548651.391:53): avc: denied { read } for pid=7741 comm="prelink" name="ssh-agent" dev=dm-0 ino=5479875 context=system_u:system_r:prelink_t:s0-s0:c0.c1023 context=system_u:object_r:ssh_agent_exec_t:s0 tclass=file type=SYSCALL msg=audit(1170548651.391:53): arch=40000003 syscall=5 success=no exit=-13 a0=9022ce8 a1=8000 a2=0 a3=0 items=0 ppid=7732 pid=7741 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-s0:c0.c1023 key=(null) tom -- Tom London From linux_4ever at yahoo.com Sun Feb 4 14:30:24 2007 From: linux_4ever at yahoo.com (Steve G) Date: Sun, 4 Feb 2007 06:30:24 -0800 (PST) Subject: audit message on shutdown In-Reply-To: <200702032219.42820.dblistsub-fedora@yahoo.it> Message-ID: <20070204143024.20268.qmail@web51505.mail.yahoo.com> >and apparently harmless, since the clock is running ok on subsequent boot (but >I am using NTP). Is it safe to ignore this or should I dig deeper ? Yes this is safe to ignore. Not all audit messages are related SE Linux. There are a fair amount that are intended to meet CAPP/LSPP and other security standards. They say that changes to time settings should be audited. Since this action occurs after the audit daemon has exited, it winds up on the console. -Steve ____________________________________________________________________________________ It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail/ From dwalsh at redhat.com Tue Feb 6 15:57:02 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 06 Feb 2007 10:57:02 -0500 Subject: Crossover In-Reply-To: <17855.31040.653674.536727@mimmi.uddeborg.se> References: <17855.31040.653674.536727@mimmi.uddeborg.se> Message-ID: <45C8A54E.3030000@redhat.com> G?ran Uddeborg wrote: > Crossover installs under /opt/cxoffice by default. The rules for > wine-style programs does not seem to cover that hierarchy, and just > trying to run things gives a lot of denied execmods. > > I assume just mirroring the settings for regular wine is fine for > Crossover too: > > /opt/cxoffice/lib/wine/.+\.so system_u:object_r:textrel_shlib_t:s0 > /opt/cxoffice/bin/wine system_u:object_r:wine_exec_t:s0 > > I changed the files (only directly with chcon) and it appears to work. > At least so far, we have not used this too much yet. > > Does this make sense? Do you want a bugzilla about it? > > No I will add this to policy > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From dwalsh at redhat.com Tue Feb 6 16:54:52 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 06 Feb 2007 11:54:52 -0500 Subject: prelink AVC In-Reply-To: <4c4ba1530702031626hc6ad177j6a8391017b4c8ead@mail.gmail.com> References: <4c4ba1530702031626hc6ad177j6a8391017b4c8ead@mail.gmail.com> Message-ID: <45C8B2DC.8050001@redhat.com> Tom London wrote: > Latest rawhide, targeted/enforcing: > > type=AVC msg=audit(1170548651.391:53): avc: denied { read } for > pid=7741 comm="prelink" name="ssh-agent" dev=dm-0 ino=5479875 > context=system_u:system_r:prelink_t:s0-s0:c0.c1023 > context=system_u:object_r:ssh_agent_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1170548651.391:53): arch=40000003 syscall=5 > success=no exit=-13 a0=9022ce8 a1=8000 a2=0 a3=0 items=0 ppid=7732 > pid=7741 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-s0:c0.c1023 key=(null) > > tom Should be fixes in rawhide. From dwalsh at redhat.com Tue Feb 6 17:15:05 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 06 Feb 2007 12:15:05 -0500 Subject: Mail problems... In-Reply-To: References: Message-ID: <45C8B799.5090505@redhat.com> melaina at libero.it wrote: > Hello! > > I have just started playing a bit with SELinux in permissive mode on my system. I have qmail with spamassassin installed; the only AVC denied messages I get (after I relabeled the system and fixed domains on a couple of log files), is the following: > > Jan 30 20:23:13 drake kernel: audit(1170210193.998:8): avc: denied { read } for pid=11862 comm="sendmail" name="RsmVLSTr" dev=loop0 ino=20 scontext=user_u: system_r:system_mail_t tcontext=user_u:object_r:httpd_sys_script_rw_t tclass=fil e > Jan 30 20:23:13 drake kernel: audit(1170210193.998:9): avc: denied { read wr ite } for pid=11862 comm="sendmail" name="jk-runtime-status" dev=hda5 ino=49827 49 scontext=user_u:system_r:system_mail_t tcontext=system_u:object_r:httpd_log_t tclass=file > Jan 30 20:23:14 drake kernel: audit(1170210194.019:10): avc: denied { ioctl } for pid=11863 comm="qmail-scanner-q" name="error_log" dev=hda5 ino=4984894 sc ontext=user_u:system_r:system_mail_t tcontext=system_u:object_r:httpd_log_t tcla ss=file > Jan 30 20:23:14 drake kernel: audit(1170210194.026:11): avc: denied { read } for pid=11863 comm="sperl5.8.5" name="mounts" dev=proc ino=777453584 scontext= user_u:system_r:system_mail_t tcontext=user_u:system_r:system_mail_t tclass=file > Jan 30 20:23:14 drake kernel: audit(1170210194.026:12): avc: denied { getatt r } for pid=11863 comm="sperl5.8.5" name="mounts" dev=proc ino=777453584 sconte xt=user_u:system_r:system_mail_t tcontext=user_u:system_r:system_mail_t tclass=f ile > Jan 30 20:23:15 drake kernel: audit(1170210195.204:13): avc: denied { append } for pid=11863 comm="perl5.8.5" name="qmail-queue.log" dev=hda5 ino=5130271 s context=user_u:system_r:system_mail_t tcontext=system_u:object_r:var_spool_t tcl ass=file > Jan 30 20:23:15 drake kernel: audit(1170210195.204:14): avc: denied { ioctl } for pid=11863 comm="perl5.8.5" name="qmail-queue.log" dev=hda5 ino=5130271 sc ontext=user_u:system_r:system_mail_t tcontext=system_u:object_r:var_spool_t tcla ss=file > Jan 30 20:23:15 drake kernel: audit(1170210195.205:15): avc: denied { getatt r } for pid=11863 comm="perl5.8.5" name="qmail-queue.log" dev=hda5 ino=5130271 scontext=user_u:system_r:system_mail_t tcontext=system_u:object_r:var_spool_t tc lass=file > Jan 30 20:23:15 drake kernel: audit(1170210195.206:16): avc: denied { read } for pid=11863 comm="perl5.8.5" name="qmail-scanner-queue-version.txt" dev=hda5 ino=5130273 scontext=user_u:system_r:system_mail_t tcontext=system_u:object_r:v ar_spool_t tclass=file > Jan 30 20:23:15 drake kernel: audit(1170210195.208:17): avc: denied { write } for pid=11863 comm="perl5.8.5" name="tmp" dev=hda5 ino=5195094 scontext=user_ u:system_r:system_mail_t tcontext=system_u:object_r:var_spool_t tclass=dir > Jan 30 20:23:15 drake kernel: audit(1170210195.208:18): avc: denied { add_na me } for pid=11863 comm="perl5.8.5" name="drake.mydomain.com1170210195772118 63" scontext=user_u:system_r:system_mail_t tcontext=system_u:object_r:var_spool_ t tclass=dir > Jan 30 20:23:15 drake kernel: audit(1170210195.208:19): avc: denied { create } for pid=11863 comm="perl5.8.5" name="drake.mydomain.com117021019577211863 " scontext=user_u:system_r:system_mail_t tcontext=user_u:object_r:var_spool_t tc lass=dir > Jan 30 20:23:15 drake kernel: audit(1170210195.409:20): avc: denied { create } for pid=11863 comm="perl5.8.5" name="drake.mydomain.com117021019577211863 " scontext=user_u:system_r:system_mail_t tcontext=user_u:object_r:var_spool_t tc lass=file > Jan 30 20:23:15 drake kernel: audit(1170210195.410:21): avc: denied { ioctl } for pid=11863 comm="perl5.8.5" name="drake.mydomain.com117021019577211863" dev=hda5 ino=5276868 scontext=user_u:system_r:system_mail_t tcontext=user_u:obj ect_r:var_spool_t tclass=file > Jan 30 20:23:15 drake kernel: audit(1170210195.410:22): avc: denied { getatt r } for pid=11863 comm="perl5.8.5" name="drake.mydomain.com11702101957721186 3" dev=hda5 ino=5276868 scontext=user_u:system_r:system_mail_t tcontext=user_u:o bject_r:var_spool_t tclass=file > Jan 30 20:23:15 drake kernel: audit(1170210195.414:23): avc: denied { write } for pid=11863 comm="perl5.8.5" name="drake.mydomain.com117021019577211863" dev=hda5 ino=5276868 scontext=user_u:system_r:system_mail_t tcontext=user_u:obj ect_r:var_spool_t tclass=file > Jan 30 20:23:15 drake kernel: audit(1170210195.418:24): avc: denied { link } for pid=11863 comm="perl5.8.5" name="drake.mydomain.com117021019577211863" dev=hda5 ino=5276868 scontext=user_u:system_r:system_mail_t tcontext=user_u:obje ct_r:var_spool_t tclass=file > Jan 30 20:23:15 drake kernel: audit(1170210195.419:25): avc: denied { remove _name } for pid=11863 comm="perl5.8.5" name="drake.mydomain.com1170210195772 11863" dev=hda5 ino=5276868 scontext=user_u:system_r:system_mail_t tcontext=syst em_u:object_r:var_spool_t tclass=dir > Jan 30 20:23:15 drake kernel: audit(1170210195.419:26): avc: denied { unlink } for pid=11863 comm="perl5.8.5" name="drake.mydomain.com117021019577211863 " dev=hda5 ino=5276868 scontext=user_u:system_r:system_mail_t tcontext=user_u:ob ject_r:var_spool_t tclass=file > Jan 30 20:23:15 drake kernel: audit(1170210195.424:27): avc: denied { read w rite } for pid=11864 comm="sh" name="tty" dev=tmpfs ino=1804 scontext=user_u:sy stem_r:system_mail_t tcontext=system_u:object_r:devtty_t tclass=chr_file > Jan 30 20:23:15 drake kernel: audit(1170210195.431:28): avc: denied { read } for pid=11865 comm="sh" name="drake.mydomain.com117021019577211863" dev=hda 5 ino=5276868 scontext=user_u:system_r:system_mail_t tcontext=user_u:object_r:va r_spool_t tclass=file > Jan 30 20:23:15 drake kernel: audit(1170210195.434:29): avc: denied { write } for pid=11865 comm="reformime" name="drake.mydomain.com117021019577211863" dev=hda5 ino=5408221 scontext=user_u:system_r:system_mail_t tcontext=user_u:obj ect_r:var_spool_t tclass=dir > Jan 30 20:23:15 drake kernel: audit(1170210195.434:30): avc: denied { add_na me } for pid=11865 comm="reformime" name="1170210195.11865-0.drake.mydomain. com" scontext=user_u:system_r:system_mail_t tcontext=user_u:object_r:var_spool_t tclass=dir > Jan 30 20:23:15 drake kernel: audit(1170210195.739:31): avc: denied { read } for pid=11863 comm="perl5.8.5" name="drake.mydomain.com117021019577211863" dev=hda5 ino=5408221 scontext=user_u:system_r:system_mail_t tcontext=user_u:obje ct_r:var_spool_t tclass=dir > Jan 30 20:23:15 drake kernel: audit(1170210195.755:32): avc: denied { read } for pid=11863 comm="perl5.8.5" name="tmp" dev=hda5 ino=4980740 scontext=user_u :system_r:system_mail_t tcontext=system_u:object_r:var_t tclass=lnk_file > Jan 30 20:23:15 drake kernel: audit(1170210195.795:33): avc: denied { execut e } for pid=11867 comm="perl5.8.5" name="find" dev=hda5 ino=5297451 scontext=us er_u:system_r:system_mail_t tcontext=system_u:object_r:file_t tclass=file > Jan 30 20:23:15 drake kernel: audit(1170210195.796:34): avc: denied { execut e_no_trans } for pid=11867 comm="perl5.8.5" name="find" dev=hda5 ino=5297451 sc ontext=user_u:system_r:system_mail_t tcontext=system_u:object_r:file_t tclass=fi le > Jan 30 20:23:15 drake kernel: audit(1170210195.796:35): avc: denied { read } for pid=11867 comm="perl5.8.5" name="find" dev=hda5 ino=5297451 scontext=user_ u:system_r:system_mail_t tcontext=system_u:object_r:file_t tclass=file > Jan 30 20:23:15 drake kernel: audit(1170210195.798:36): avc: denied { search } for pid=11867 comm="find" name="selinux" dev=hda5 ino=557257 scontext=user_u :system_r:system_mail_t tcontext=system_u:object_r:selinux_config_t tclass=dir > Jan 30 20:23:15 drake kernel: audit(1170210195.798:37): avc: denied { read } for pid=11867 comm="find" name="config" dev=hda5 ino=557274 scontext=user_u:sy stem_r:system_mail_t tcontext=user_u:object_r:selinux_config_t tclass=file > Jan 30 20:23:15 drake kernel: audit(1170210195.798:38): avc: denied { getatt r } for pid=11867 comm="find" name="config" dev=hda5 ino=557274 scontext=user_u :system_r:system_mail_t tcontext=user_u:object_r:selinux_config_t tclass=file > Jan 30 20:23:15 drake kernel: audit(1170210195.860:39): avc: denied { read } for pid=11871 comm="rm" name="qscan" dev=hda5 ino=5130256 scontext=user_u:syst em_r:system_mail_t tcontext=system_u:object_r:var_spool_t tclass=dir > Jan 30 20:23:15 drake kernel: audit(1170210195.860:40): avc: denied { remove _name } for pid=11871 comm="rm" name="1170210195.11865-0.drake.mydomain.com" dev=hda5 ino=5408222 scontext=user_u:system_r:system_mail_t tcontext=user_u:obj ect_r:var_spool_t tclass=dir > Jan 30 20:23:15 drake kernel: audit(1170210195.861:41): avc: denied { rmdir } for pid=11871 comm="rm" name="drake.mydomain.com117021019577211863" dev=hd a5 ino=5408221 scontext=user_u:system_r:system_mail_t tcontext=user_u:object_r:v ar_spool_t tclass=dir > Jan 30 20:23:15 drake kernel: audit(1170210195.873:42): avc: denied { sigchl d } for pid=1 comm="init" scontext=user_u:system_r:system_mail_t tcontext=user_ u:system_r:unconfined_t tclass=process > > Any directions to fix this? > > Thanks! > This looks like qmail is doing a lot more stuff then a normal sendmail would do. Running this log file under audit2allow gives the following rules allow system_mail_t devtty_t:chr_file { read write }; > This probably can be ignored. allow system_mail_t file_t:file { execute execute_no_trans read }; > Indicates something is still mislabeled. allow system_mail_t httpd_log_t:file { ioctl read write }; > Why would mail be updating httpd_log_t allow system_mail_t httpd_sys_script_rw_t:file read; >Reading a script file? allow system_mail_t selinux_config_t:dir search; allow system_mail_t selinux_config_t:file { getattr read }; > These disappear in enforcing mode. allow system_mail_t self:file { getattr read }; > Qmail specific allow system_mail_t unconfined_t:process sigchld; > qmail is somehow execing init to send a sigchld to an unconfined process??? allow system_mail_t var_spool_t:dir { add_name create read remove_name rmdir write }; allow system_mail_t var_spool_t:file { append create getattr ioctl link read unlink write }; allow system_mail_t var_t:lnk_file read; > qmail is updating files in /var/spool? > > ------------------------------------------------------ > Mutuo da 200.000 ?? Tassi ridotti da 4.25%. Solo per richieste online. Mutuionline.it > http://click.libero.it/mutuionline31ge07 > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From dan.track at gmail.com Wed Feb 7 17:08:16 2007 From: dan.track at gmail.com (Dan Track) Date: Wed, 7 Feb 2007 17:08:16 +0000 Subject: Selinux error help - continued Message-ID: <9d5ddd1f0702070908i1f8f97c3td083e73b8f5fefdb@mail.gmail.com> On Wed, 2007-02-07 at 16:34 +0000, Dan Track wrote: > Hi Stephen > > Firstly apologies for sending to the wrong list. Ok, then take follow-ups to fedora-selinux-list please. > Thanks for the advice it was really an eye opener. I trawlled through > the assert.te file in my selinux src directory, however I can tell > which rule to remove, could you please guide to which rule it is. > Currently my file looks like this: > > neverallow { domain -unrestricted -snmpd_t -pegasus_t } > unconfined_t:process ~sigchld; The rule above. Rather than removing it entirely, you could adjust it to make a specific exception for this case. What do you truly need your process to be able to do? > # Confined domains must never see unconfined domain's /proc/pid entries. > neverallow { domain -unrestricted -snmpd_t -pegasus_t } > unconfined_t:dir { getattr search }; This one will also get in your process' way if it truly needs to operate on unconfined processes. Naturally, if you go too far in this direction, you are effectively removing any real restriction on httpd and might as well just disable its protection altogether (via the corresponding boolean). Hi Stephen. I've moved the conversation over to the selinux list. My program is actually Beltane which is a web front end for managing samhain ( a filesystem integrity checker). The point at which the problem arises is when a setuid binary (belatne_cp) wants to write to a file it creates in the /tmp directory and then it wants to move that file to the /var/lib/yule/profiles directory. Its at this point I get the selinux error: Feb 7 14:26:10 jupiter kernel: audit(1170858370.177:2547): avc: denied { getsession } for pid=555 comm="httpd" scontext=root:system_r:httpd_t tcontext=root:system_r:unconfined_t tclass=process Feb 7 14:26:27 jupiter kernel: audit(1170858387.985:2548): avc: denied { getattr } for pid=14295 comm="beltane_cp" name="TMPFILIyEqoa" dev=sda3 ino=147699 scontext=root:system_r:httpd_sys_script_t tcontext=root:object_r:httpd_var_lib_t tclass=file This beltane_cp file is called by apache. Hope this helps in making clear what I'm trying to do. Thanks again Dan From sds at tycho.nsa.gov Wed Feb 7 17:12:05 2007 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 07 Feb 2007 12:12:05 -0500 Subject: Selinux error help - continued In-Reply-To: <9d5ddd1f0702070908i1f8f97c3td083e73b8f5fefdb@mail.gmail.com> References: <9d5ddd1f0702070908i1f8f97c3td083e73b8f5fefdb@mail.gmail.com> Message-ID: <1170868325.11912.74.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2007-02-07 at 17:08 +0000, Dan Track wrote: > Hi Stephen. > > I've moved the conversation over to the selinux list. My program is > actually Beltane which is a web front end for managing samhain ( a > filesystem integrity checker). The point at which the problem arises > is when a setuid binary (belatne_cp) wants to write to a file it > creates in the /tmp directory and then it wants to move that file to > the /var/lib/yule/profiles directory. Sounds like you should have a separate domain for that binary, and a separate type on that directory, so that you can give it the right permissions without affecting anything else. > Its at this point I get the > selinux error: > > Feb 7 14:26:10 jupiter kernel: audit(1170858370.177:2547): avc: > denied { getsession } for pid=555 comm="httpd" > scontext=root:system_r:httpd_t tcontext=root:system_r:unconfined_t > tclass=process Question is what process is the target of this getsid(2) call? You can find out more information by enabling system call auditing and retrying. auditctl -e 1 or boot with audit=1 or run auditd. -- Stephen Smalley National Security Agency From selinux at lucullo.it Wed Feb 7 18:07:42 2007 From: selinux at lucullo.it (selinux at lucullo.it) Date: Wed, 07 Feb 2007 19:07:42 +0100 Subject: an easy way to edit security policies in fc6 Message-ID: <45ca156e.3c5.19a7.866652660@webmailh5.aruba.it> hi, i'm new to selinux and i need to know how can i easy modify a selinux targeted policy rule in fc6. my apache can't write in a /var subdir. my idea is to start looking in to logs and then edit the policy (or the files attributes) to avoid problems. is there an easy tool for editing policy source? is there a complete how to (for fc6 targeted selinux)? excuse me for my bad english. thank you in advance. From sds at tycho.nsa.gov Wed Feb 7 18:13:15 2007 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 07 Feb 2007 13:13:15 -0500 Subject: an easy way to edit security policies in fc6 In-Reply-To: <45ca156e.3c5.19a7.866652660@webmailh5.aruba.it> References: <45ca156e.3c5.19a7.866652660@webmailh5.aruba.it> Message-ID: <1170871995.11912.80.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2007-02-07 at 19:07 +0100, selinux at lucullo.it wrote: > hi, > > i'm new to selinux and i need to know how can i easy modify > a selinux targeted policy rule in fc6. > > my apache can't write in a /var subdir. > > my idea is to start looking in to logs and then edit the > policy (or the files attributes) to avoid problems. audit2allow will automatically turn audit logs into allow rules, but you shouldn't blindly take its results. In your particular case, if you labeled the files in that /var subdirectory with an appropriate type, then apache would be able to write to it. > is there an easy tool for editing policy source? > > is there a complete how to (for fc6 targeted selinux)? Read the Fedora SELinux FAQ and the Fedora SELinux wiki pages. -- Stephen Smalley National Security Agency From mayerf at tresys.com Wed Feb 7 21:36:52 2007 From: mayerf at tresys.com (Frank Mayer) Date: Wed, 07 Feb 2007 16:36:52 -0500 Subject: ANN: NSA Director of Information Assurance to be Keynote Speaker at SELinux Symposium Message-ID: All, we just announced that Richard Schaeffer, NSA Director of Information Assurance, will be a keynote speaker at the SELinux symposium this March (I've attached the press release below). He joins Daniel Frye of IBM as our two keynote speakers this year. As a reminder early registration ends February 23. After that date the conference rate goes up some, but as important, the block of reserved hotel rooms for the conference are no longer assured. So if you are planning to come to the symposium this year, I recommend you register by that date. Regards, Frank -=-=-=-=-=-=-=-=-=-=-=-=-=- FOR IMMEDIATE RELEASE CONTACT: info at selinux-symposium.org National Security Agency Director of Information Assurance to be Keynote Speaker at Third Security Enhanced Linux Symposium Baltimore, Maryland?February 7, 2007? Richard Schaeffer, Director of Information Assurance for the National Security Agency (NSA), will be a keynote speaker for the third annual Security Enhanced Linux (SELinux) Symposium (www.selinux-symposium.org), scheduled for March 12-16, 2007 in Baltimore, Maryland. The Information Assurance Directorate (IAD) is the NSA mission element charged with providing products and services critical to protecting the United States? national security systems. IAD is also responsible for defining and implementing the Information Assurance Strategy to protect the Department of Defense?s (DoD) Global Information Grid (GIG). Moreover, IAD supports ongoing military operations against terrorism by delivering solutions that allow the secure and dynamic sharing of information across security domains at multiple classification levels in today?s net-centric environment. Consistent with its national security mission, NSA originally developed and publicly released SELinux as a demonstration that high-end security access control features could be successfully integrated into mainstream open source technology. At this year?s symposium, Mr. Schaeffer will present a keynote address entitled ?SELinux: An Example of a Better Path to Information Assurance through Partnership.? In this address, Mr. Schaeffer will discuss the benefits to both Government and business organizations that can be gained by working with the open source community. About the SELinux Symposium The Security Enhanced Linux (SELinux) Symposium is an annual exchange of ideas, technology, and research involving SELinux. SELinux is emerging technology that adds flexible, strong mandatory access control security to Linux. The third annual symposium is scheduled for March 12-16, 2007 in Baltimore, Maryland, USA. This year's symposium is sponsored by Hewlett-Packard, IBM, Red Hat, and Tresys Technology. The event brings together experts from business, government, and academia to share research, development, and application experiences using SELinux. For information on registration and sponsorship opportunities, see www.selinux-symposium.org. From dan.track at gmail.com Thu Feb 8 10:35:57 2007 From: dan.track at gmail.com (Dan Track) Date: Thu, 8 Feb 2007 10:35:57 +0000 Subject: Selinux error help - continued In-Reply-To: <1170868325.11912.74.camel@moss-spartans.epoch.ncsc.mil> References: <9d5ddd1f0702070908i1f8f97c3td083e73b8f5fefdb@mail.gmail.com> <1170868325.11912.74.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <9d5ddd1f0702080235x3ffcb787kbf2f679467453596@mail.gmail.com> On 2/7/07, Stephen Smalley wrote: > On Wed, 2007-02-07 at 17:08 +0000, Dan Track wrote: > > Hi Stephen. > > > > I've moved the conversation over to the selinux list. My program is > > actually Beltane which is a web front end for managing samhain ( a > > filesystem integrity checker). The point at which the problem arises > > is when a setuid binary (belatne_cp) wants to write to a file it > > creates in the /tmp directory and then it wants to move that file to > > the /var/lib/yule/profiles directory. > > Sounds like you should have a separate domain for that binary, and a > separate type on that directory, so that you can give it the right > permissions without affecting anything else. > > > Its at this point I get the > > selinux error: > > > > Feb 7 14:26:10 jupiter kernel: audit(1170858370.177:2547): avc: > > denied { getsession } for pid=555 comm="httpd" > > scontext=root:system_r:httpd_t tcontext=root:system_r:unconfined_t > > tclass=process > > Question is what process is the target of this getsid(2) call? > You can find out more information by enabling system call auditing and > retrying. auditctl -e 1 or boot with audit=1 or run auditd. > > -- > Stephen Smalley > National Security Agency > > On 2/7/07, Stephen Smalley wrote: > On Wed, 2007-02-07 at 17:08 +0000, Dan Track wrote: > > Hi Stephen. > > > > I've moved the conversation over to the selinux list. My program is > > actually Beltane which is a web front end for managing samhain ( a > > filesystem integrity checker). The point at which the problem arises > > is when a setuid binary (belatne_cp) wants to write to a file it > > creates in the /tmp directory and then it wants to move that file to > > the /var/lib/yule/profiles directory. > > Sounds like you should have a separate domain for that binary, and a > separate type on that directory, so that you can give it the right > permissions without affecting anything else. > > > Its at this point I get the > > selinux error: > > > > Feb 7 14:26:10 jupiter kernel: audit(1170858370.177:2547): avc: > > denied { getsession } for pid=555 comm="httpd" > > scontext=root:system_r:httpd_t tcontext=root:system_r:unconfined_t > > tclass=process > > Question is what process is the target of this getsid(2) call? > You can find out more information by enabling system call auditing and > retrying. auditctl -e 1 or boot with audit=1 or run auditd. Hi Stephen Hope things are good. I enabled the auditctl and got the following in /var/log/messages Feb 8 10:26:51 jupiter kernel: audit(1170930411.956:2939): avc: denied { getattr } for pid=6992 comm="beltane_cp" name="TMPFILuB4KTI" dev=sda3 ino=147701 scontext=root:system_r:httpd_sys_script_t tcontext=root:object_r:httpd_var_lib_t tclass=file Feb 8 10:26:51 jupiter kernel: audit(1170930411.956:2939): arch=40000003 syscall=196 success=no exit=-13 a0=bff6ab9d a1=bfed575c a2=8a9ff4 a3=bfed575c items=1 pid=6992 auid=4294967295 uid=48 gid=48 euid=0 suid=0 fsuid=0 egid=48 sgid=48 fsgid=48 comm="beltane_cp" exe="/usr/local/bin/beltane_cp" Feb 8 10:26:51 jupiter kernel: audit(1170930411.956:2939): path="/var/lib/yule/profiles/TMPFILuB4KTI" Feb 8 10:26:51 jupiter kernel: audit(1170930411.956:2939): cwd="/opt/www/beltane/php" Feb 8 10:26:51 jupiter kernel: audit(1170930411.956:2939): name="/var/lib/yule/profiles/TMPFILuB4KTI" flags=0 Feb 8 10:26:51 jupiter kernel: inode=147701 dev=08:03 mode=0100600 ouid=48 ogid=48 rdev=00:00 Hope this helps to figure out what is going on. Many Thanks Dan From sds at tycho.nsa.gov Thu Feb 8 13:19:56 2007 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 08 Feb 2007 08:19:56 -0500 Subject: Selinux error help - continued In-Reply-To: <9d5ddd1f0702080235x3ffcb787kbf2f679467453596@mail.gmail.com> References: <9d5ddd1f0702070908i1f8f97c3td083e73b8f5fefdb@mail.gmail.com> <1170868325.11912.74.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080235x3ffcb787kbf2f679467453596@mail.gmail.com> Message-ID: <1170940796.11912.206.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2007-02-08 at 10:35 +0000, Dan Track wrote: > I enabled the auditctl and got the following in /var/log/messages > > Feb 8 10:26:51 jupiter kernel: audit(1170930411.956:2939): avc: > denied { getattr } for pid=6992 comm="beltane_cp" > name="TMPFILuB4KTI" dev=sda3 ino=147701 > scontext=root:system_r:httpd_sys_script_t > tcontext=root:object_r:httpd_var_lib_t tclass=file > Feb 8 10:26:51 jupiter kernel: audit(1170930411.956:2939): > arch=40000003 syscall=196 success=no exit=-13 a0=bff6ab9d a1=bfed575c > a2=8a9ff4 a3=bfed575c items=1 pid=6992 auid=4294967295 uid=48 gid=48 > euid=0 suid=0 fsuid=0 egid=48 sgid=48 fsgid=48 comm="beltane_cp" > exe="/usr/local/bin/beltane_cp" > Feb 8 10:26:51 jupiter kernel: audit(1170930411.956:2939): > path="/var/lib/yule/profiles/TMPFILuB4KTI" > Feb 8 10:26:51 jupiter kernel: audit(1170930411.956:2939): > cwd="/opt/www/beltane/php" > Feb 8 10:26:51 jupiter kernel: audit(1170930411.956:2939): > name="/var/lib/yule/profiles/TMPFILuB4KTI" flags=0 > Feb 8 10:26:51 jupiter kernel: inode=147701 dev=08:03 mode=0100600 > ouid=48 ogid=48 rdev=00:00 > > Hope this helps to figure out what is going on. That shows the full path information for the access to /var/lib/yule/profiles. Just need to select an appropriate type for that directory that allows your script to write to it as is, like httpd_sys_script_rw_t, and apply it to those files. In FC4 or earlier, that would be something like: chcon -R -t httpd_sys_script_rw_t /var/lib/yule/profiles But I was hoping to also see the audit information for the other denial (the getsession one) - can you reproduce it with audit enabled? And then when you get the output, take the first argument (a0) and check to see what process it corresponds to. -- Stephen Smalley National Security Agency From dan.track at gmail.com Thu Feb 8 14:48:13 2007 From: dan.track at gmail.com (Dan Track) Date: Thu, 8 Feb 2007 14:48:13 +0000 Subject: Selinux error help - continued In-Reply-To: <1170940796.11912.206.camel@moss-spartans.epoch.ncsc.mil> References: <9d5ddd1f0702070908i1f8f97c3td083e73b8f5fefdb@mail.gmail.com> <1170868325.11912.74.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080235x3ffcb787kbf2f679467453596@mail.gmail.com> <1170940796.11912.206.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <9d5ddd1f0702080648m50c194abq2e66d7d9c5646292@mail.gmail.com> On 2/8/07, Stephen Smalley wrote: > On Thu, 2007-02-08 at 10:35 +0000, Dan Track wrote: > > I enabled the auditctl and got the following in /var/log/messages > > > > Feb 8 10:26:51 jupiter kernel: audit(1170930411.956:2939): avc: > > denied { getattr } for pid=6992 comm="beltane_cp" > > name="TMPFILuB4KTI" dev=sda3 ino=147701 > > scontext=root:system_r:httpd_sys_script_t > > tcontext=root:object_r:httpd_var_lib_t tclass=file > > Feb 8 10:26:51 jupiter kernel: audit(1170930411.956:2939): > > arch=40000003 syscall=196 success=no exit=-13 a0=bff6ab9d a1=bfed575c > > a2=8a9ff4 a3=bfed575c items=1 pid=6992 auid=4294967295 uid=48 gid=48 > > euid=0 suid=0 fsuid=0 egid=48 sgid=48 fsgid=48 comm="beltane_cp" > > exe="/usr/local/bin/beltane_cp" > > Feb 8 10:26:51 jupiter kernel: audit(1170930411.956:2939): > > path="/var/lib/yule/profiles/TMPFILuB4KTI" > > Feb 8 10:26:51 jupiter kernel: audit(1170930411.956:2939): > > cwd="/opt/www/beltane/php" > > Feb 8 10:26:51 jupiter kernel: audit(1170930411.956:2939): > > name="/var/lib/yule/profiles/TMPFILuB4KTI" flags=0 > > Feb 8 10:26:51 jupiter kernel: inode=147701 dev=08:03 mode=0100600 > > ouid=48 ogid=48 rdev=00:00 > > > > Hope this helps to figure out what is going on. > > That shows the full path information for the access > to /var/lib/yule/profiles. Just need to select an appropriate type for > that directory that allows your script to write to it as is, like > httpd_sys_script_rw_t, and apply it to those files. In FC4 or earlier, > that would be something like: > chcon -R -t httpd_sys_script_rw_t /var/lib/yule/profiles > > But I was hoping to also see the audit information for the other denial > (the getsession one) - can you reproduce it with audit enabled? And > then when you get the output, take the first argument (a0) and check to > see what process it corresponds to. > > -- > Stephen Smalley > National Security Agency > > Hi Thanks for getting back. I started the audit daemon and I got the following come up when I tried to create a profile from the web page: ype=AVC msg=audit(1170945767.596:8934): avc: denied { getattr } for pid=18356 comm="beltane_cp" name="TMPFILvLYQ7Z" dev=sda3 ino=147703 scontext=root:system_r:httpd_sys_script_t tcontext=root:object_r:httpd_var_lib_t tclass=file type=SYSCALL msg=audit(1170945767.596:8934): arch=40000003 syscall=196 success=no exit=-13 a0=bffa1b9d a1=bff42cdc a2=8a9ff4 a3=bff42cdc items=1 pid=18356 auid=4294967295 uid=48 gid=48 euid=0 suid=0 fsuid=0 egid=48 sgid=48 fsgid=48 comm="beltane_cp" exe="/usr/local/bin/beltane_cp" type=AVC_PATH msg=audit(1170945767.596:8934): path="/var/lib/yule/profiles/TMPFILvLYQ7Z" type=CWD msg=audit(1170945767.596:8934): cwd="/opt/www/beltane/php" type=PATH msg=audit(1170945767.596:8934): name="/var/lib/yule/profiles/TMPFILvLYQ7Z" flags=0 inode=147703 dev=08:03 mode=0100600 ouid=48 ogid=48 rdev=00:00 type=AVC msg=audit(1170945774.915:8935): avc: denied { getsession } for pid=15500 comm="httpd" scontext=root:system_r:httpd_t tcontext=root:system_r:unconfined_t tclass=process type=AVC msg=audit(1170945805.142:8936): avc: denied { getsession } for pid=31207 comm="httpd" scontext=root:system_r:httpd_t tcontext=root:system_r:unconfined_t tclass=process type=AVC msg=audit(1170945835.202:8937): avc: denied { getsession } for pid=15498 comm="httpd" scontext=root:system_r:httpd_t tcontext=root:system_r:unconfined_t tclass=process I'm not sure what you meant by the "a0" argument. The exe in the above output shows "/usr/local/bin/beltane_cp" and the uid show 48 (apache). Is this what you meant? Thanks Dan From sds at tycho.nsa.gov Thu Feb 8 15:13:09 2007 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 08 Feb 2007 10:13:09 -0500 Subject: Selinux error help - continued In-Reply-To: <9d5ddd1f0702080648m50c194abq2e66d7d9c5646292@mail.gmail.com> References: <9d5ddd1f0702070908i1f8f97c3td083e73b8f5fefdb@mail.gmail.com> <1170868325.11912.74.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080235x3ffcb787kbf2f679467453596@mail.gmail.com> <1170940796.11912.206.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080648m50c194abq2e66d7d9c5646292@mail.gmail.com> Message-ID: <1170947589.11912.258.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2007-02-08 at 14:48 +0000, Dan Track wrote: > Thanks for getting back. > I started the audit daemon and I got the following come up when I > tried to create a profile from the web page: > ype=AVC msg=audit(1170945767.596:8934): avc: denied { getattr } for > pid=18356 comm="beltane_cp" name="TMPFILvLYQ7Z" dev=sda3 ino=147703 > scontext=root:system_r:httpd_sys_script_t > tcontext=root:object_r:httpd_var_lib_t tclass=file > type=SYSCALL msg=audit(1170945767.596:8934): arch=40000003 syscall=196 > success=no exit=-13 a0=bffa1b9d a1=bff42cdc a2=8a9ff4 a3=bff42cdc > items=1 pid=18356 auid=4294967295 uid=48 gid=48 euid=0 suid=0 fsuid=0 > egid=48 sgid=48 fsgid=48 comm="beltane_cp" > exe="/usr/local/bin/beltane_cp" > type=AVC_PATH msg=audit(1170945767.596:8934): > path="/var/lib/yule/profiles/TMPFILvLYQ7Z" > type=CWD msg=audit(1170945767.596:8934): cwd="/opt/www/beltane/php" > type=PATH msg=audit(1170945767.596:8934): > name="/var/lib/yule/profiles/TMPFILvLYQ7Z" flags=0 inode=147703 > dev=08:03 mode=0100600 ouid=48 ogid=48 rdev=00:00 > type=AVC msg=audit(1170945774.915:8935): avc: denied { getsession } > for pid=15500 comm="httpd" scontext=root:system_r:httpd_t > tcontext=root:system_r:unconfined_t tclass=process > type=AVC msg=audit(1170945805.142:8936): avc: denied { getsession } > for pid=31207 comm="httpd" scontext=root:system_r:httpd_t > tcontext=root:system_r:unconfined_t tclass=process > type=AVC msg=audit(1170945835.202:8937): avc: denied { getsession } > for pid=15498 comm="httpd" scontext=root:system_r:httpd_t > tcontext=root:system_r:unconfined_t tclass=process > > I'm not sure what you meant by the "a0" argument. The exe in the above > output shows "/usr/local/bin/beltane_cp" and the uid show 48 (apache). > Is this what you meant? I'm looking for the SYSCALL record that corresponds to the getsession AVC message. It should have the same audit event id as the AVC message. But I don't see one above. What I was interested in was what pid is being passed to the getsid() call, and what process corresponds to that pid - that is the unconfined process that httpd is trying to get information about. -- Stephen Smalley National Security Agency From dan.track at gmail.com Thu Feb 8 16:09:15 2007 From: dan.track at gmail.com (Dan Track) Date: Thu, 8 Feb 2007 16:09:15 +0000 Subject: Selinux error help - continued In-Reply-To: <1170947589.11912.258.camel@moss-spartans.epoch.ncsc.mil> References: <9d5ddd1f0702070908i1f8f97c3td083e73b8f5fefdb@mail.gmail.com> <1170868325.11912.74.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080235x3ffcb787kbf2f679467453596@mail.gmail.com> <1170940796.11912.206.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080648m50c194abq2e66d7d9c5646292@mail.gmail.com> <1170947589.11912.258.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <9d5ddd1f0702080809l23577664j549eff08ba5109c@mail.gmail.com> On 2/8/07, Stephen Smalley wrote: > On Thu, 2007-02-08 at 14:48 +0000, Dan Track wrote: > > Thanks for getting back. > > I started the audit daemon and I got the following come up when I > > tried to create a profile from the web page: > > ype=AVC msg=audit(1170945767.596:8934): avc: denied { getattr } for > > pid=18356 comm="beltane_cp" name="TMPFILvLYQ7Z" dev=sda3 ino=147703 > > scontext=root:system_r:httpd_sys_script_t > > tcontext=root:object_r:httpd_var_lib_t tclass=file > > type=SYSCALL msg=audit(1170945767.596:8934): arch=40000003 syscall=196 > > success=no exit=-13 a0=bffa1b9d a1=bff42cdc a2=8a9ff4 a3=bff42cdc > > items=1 pid=18356 auid=4294967295 uid=48 gid=48 euid=0 suid=0 fsuid=0 > > egid=48 sgid=48 fsgid=48 comm="beltane_cp" > > exe="/usr/local/bin/beltane_cp" > > type=AVC_PATH msg=audit(1170945767.596:8934): > > path="/var/lib/yule/profiles/TMPFILvLYQ7Z" > > type=CWD msg=audit(1170945767.596:8934): cwd="/opt/www/beltane/php" > > type=PATH msg=audit(1170945767.596:8934): > > name="/var/lib/yule/profiles/TMPFILvLYQ7Z" flags=0 inode=147703 > > dev=08:03 mode=0100600 ouid=48 ogid=48 rdev=00:00 > > type=AVC msg=audit(1170945774.915:8935): avc: denied { getsession } > > for pid=15500 comm="httpd" scontext=root:system_r:httpd_t > > tcontext=root:system_r:unconfined_t tclass=process > > type=AVC msg=audit(1170945805.142:8936): avc: denied { getsession } > > for pid=31207 comm="httpd" scontext=root:system_r:httpd_t > > tcontext=root:system_r:unconfined_t tclass=process > > type=AVC msg=audit(1170945835.202:8937): avc: denied { getsession } > > for pid=15498 comm="httpd" scontext=root:system_r:httpd_t > > tcontext=root:system_r:unconfined_t tclass=process > > > > I'm not sure what you meant by the "a0" argument. The exe in the above > > output shows "/usr/local/bin/beltane_cp" and the uid show 48 (apache). > > Is this what you meant? > > I'm looking for the SYSCALL record that corresponds to the getsession > AVC message. It should have the same audit event id as the AVC message. > But I don't see one above. What I was interested in was what pid is > being passed to the getsid() call, and what process corresponds to that > pid - that is the unconfined process that httpd is trying to get > information about. > Hi I've tried to capture the process information that is triggiring these alerts but so far I'm failing. Basically the web page is just a form which you submit as soon as you press the submit button the whole process is over in a second. I've tried running the following to capture what is causing it: tail -f /var/log/audit/audit.log| grep SYSCALL | grep beltane | awk -F' ' {'print $12'} | awk -F'=' {'print "/proc/"$2"/cmdline"'} | xargs cat $1 But I'm getting blanks when running with tail. Any ideas of another way to capture the info using the pid in the a0 line of the audit log. Thanks in advance Dan From sds at tycho.nsa.gov Thu Feb 8 16:12:21 2007 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 08 Feb 2007 11:12:21 -0500 Subject: Selinux error help - continued In-Reply-To: <9d5ddd1f0702080809l23577664j549eff08ba5109c@mail.gmail.com> References: <9d5ddd1f0702070908i1f8f97c3td083e73b8f5fefdb@mail.gmail.com> <1170868325.11912.74.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080235x3ffcb787kbf2f679467453596@mail.gmail.com> <1170940796.11912.206.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080648m50c194abq2e66d7d9c5646292@mail.gmail.com> <1170947589.11912.258.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080809l23577664j549eff08ba5109c@mail.gmail.com> Message-ID: <1170951141.11912.281.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2007-02-08 at 16:09 +0000, Dan Track wrote: > I've tried to capture the process information that is triggiring these > alerts but so far I'm failing. Basically the web page is just a form > which you submit as soon as you press the submit button the whole > process is over in a second. Well, you could just wrap the script under strace or autrace or something similar. Question: What happens if you don't allow the getsession permission but just fix up the file permissions by running chcon as I suggested? Does the getsession denial actually prevent it from working? -- Stephen Smalley National Security Agency From dan.track at gmail.com Thu Feb 8 16:31:34 2007 From: dan.track at gmail.com (Dan Track) Date: Thu, 8 Feb 2007 16:31:34 +0000 Subject: Selinux error help - continued In-Reply-To: <1170951141.11912.281.camel@moss-spartans.epoch.ncsc.mil> References: <9d5ddd1f0702070908i1f8f97c3td083e73b8f5fefdb@mail.gmail.com> <1170868325.11912.74.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080235x3ffcb787kbf2f679467453596@mail.gmail.com> <1170940796.11912.206.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080648m50c194abq2e66d7d9c5646292@mail.gmail.com> <1170947589.11912.258.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080809l23577664j549eff08ba5109c@mail.gmail.com> <1170951141.11912.281.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <9d5ddd1f0702080831r71d8e1ekf947f7892014e64f@mail.gmail.com> On 2/8/07, Stephen Smalley wrote: > On Thu, 2007-02-08 at 16:09 +0000, Dan Track wrote: > > I've tried to capture the process information that is triggiring these > > alerts but so far I'm failing. Basically the web page is just a form > > which you submit as soon as you press the submit button the whole > > process is over in a second. > > Well, you could just wrap the script under strace or autrace or > something similar. > > Question: What happens if you don't allow the getsession permission but > just fix up the file permissions by running chcon as I suggested? Does > the getsession denial actually prevent it from working? > > -- Hi I just ran the chcon command you gave and now the web page script works fine. So it seems to have fixed the problem. But I'm still intrigued by your investigation, and I'd like to continue it. Since this is a httpd process how would I run strace on any child process that may appear? Thanks in advance Dan From sds at tycho.nsa.gov Thu Feb 8 16:36:36 2007 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 08 Feb 2007 11:36:36 -0500 Subject: Selinux error help - continued In-Reply-To: <9d5ddd1f0702080831r71d8e1ekf947f7892014e64f@mail.gmail.com> References: <9d5ddd1f0702070908i1f8f97c3td083e73b8f5fefdb@mail.gmail.com> <1170868325.11912.74.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080235x3ffcb787kbf2f679467453596@mail.gmail.com> <1170940796.11912.206.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080648m50c194abq2e66d7d9c5646292@mail.gmail.com> <1170947589.11912.258.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080809l23577664j549eff08ba5109c@mail.gmail.com> <1170951141.11912.281.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080831r71d8e1ekf947f7892014e64f@mail.gmail.com> Message-ID: <1170952596.11912.289.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2007-02-08 at 16:31 +0000, Dan Track wrote: > On 2/8/07, Stephen Smalley wrote: > > On Thu, 2007-02-08 at 16:09 +0000, Dan Track wrote: > > > I've tried to capture the process information that is triggiring these > > > alerts but so far I'm failing. Basically the web page is just a form > > > which you submit as soon as you press the submit button the whole > > > process is over in a second. > > > > Well, you could just wrap the script under strace or autrace or > > something similar. > > > > Question: What happens if you don't allow the getsession permission but > > just fix up the file permissions by running chcon as I suggested? Does > > the getsession denial actually prevent it from working? > > > > -- > > Hi > > I just ran the chcon command you gave and now the web page script > works fine. So it seems to have fixed the problem. But I'm still > intrigued by your investigation, and I'd like to continue it. > > Since this is a httpd process how would I run strace on any child > process that may appear? You could wrap your current script with a script that invokes it with strace -f -ff -o /tmp/webtrace . Or, at a cost of tracing the entire apache process and all descendants, you could do: # /etc/init.d/httpd stop # strace -f -ff -o webtrace /usr/sbin/httpd Then you should see a webtrace. file for each process created by httpd with the trace information. In which you can grep for a call to getsid and see the pid that was passed to it (and possibly how it was obtained in the first place, from the preceding calls). -- Stephen Smalley National Security Agency From dan.track at gmail.com Thu Feb 8 17:11:45 2007 From: dan.track at gmail.com (Dan Track) Date: Thu, 8 Feb 2007 17:11:45 +0000 Subject: Selinux error help - continued In-Reply-To: <1170952596.11912.289.camel@moss-spartans.epoch.ncsc.mil> References: <9d5ddd1f0702070908i1f8f97c3td083e73b8f5fefdb@mail.gmail.com> <1170868325.11912.74.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080235x3ffcb787kbf2f679467453596@mail.gmail.com> <1170940796.11912.206.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080648m50c194abq2e66d7d9c5646292@mail.gmail.com> <1170947589.11912.258.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080809l23577664j549eff08ba5109c@mail.gmail.com> <1170951141.11912.281.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080831r71d8e1ekf947f7892014e64f@mail.gmail.com> <1170952596.11912.289.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <9d5ddd1f0702080911m3834a547s463883cc813c74db@mail.gmail.com> On 2/8/07, Stephen Smalley wrote: > On Thu, 2007-02-08 at 16:31 +0000, Dan Track wrote: > > On 2/8/07, Stephen Smalley wrote: > > > On Thu, 2007-02-08 at 16:09 +0000, Dan Track wrote: > > > > I've tried to capture the process information that is triggiring these > > > > alerts but so far I'm failing. Basically the web page is just a form > > > > which you submit as soon as you press the submit button the whole > > > > process is over in a second. > > > > > > Well, you could just wrap the script under strace or autrace or > > > something similar. > > > > > > Question: What happens if you don't allow the getsession permission but > > > just fix up the file permissions by running chcon as I suggested? Does > > > the getsession denial actually prevent it from working? > > > > > > -- > > > > Hi > > > > I just ran the chcon command you gave and now the web page script > > works fine. So it seems to have fixed the problem. But I'm still > > intrigued by your investigation, and I'd like to continue it. > > > > Since this is a httpd process how would I run strace on any child > > process that may appear? > > You could wrap your current script with a script that invokes it with > strace -f -ff -o /tmp/webtrace . Or, at a cost of > tracing the entire apache process and all descendants, you could do: > # /etc/init.d/httpd stop > # strace -f -ff -o webtrace /usr/sbin/httpd > > Then you should see a webtrace. file for each process created by > httpd with the trace information. In which you can grep for a call to > getsid and see the pid that was passed to it (and possibly how it was > obtained in the first place, from the preceding calls). > Hi Ok I just ran your strace and I got two files that contain the getsid call. Not sure how to read where the pid is so I'll past a portion of the file incase you can read it better than me. The other strange thing is that I'm not getting any more selinux notifications (SYSCALL) since issuing your chcon command. There are no httpd violations. Should I back out the chcon to get the errors back? webtrace.25428 lstat64("/opt/www/.beltanerc", {st_mode=S_IFREG|0600, st_size=751, ...}) = 0 open("/opt/www/.beltanerc", O_RDONLY) = 14 fstat64(14, {st_mode=S_IFREG|0600, st_size=751, ...}) = 0 lseek(14, 0, SEEK_CUR) = 0 lseek(14, 0, SEEK_SET) = 0 fstat64(14, {st_mode=S_IFREG|0600, st_size=751, ...}) = 0 mmap2(NULL, 751, PROT_READ, MAP_SHARED, 14, 0) = 0xb7bc1000 munmap(0xb7bc1000, 751) = 0 close(14) = 0 time(NULL) = 1170954121 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1323, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1323, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1323, ...}) = 0 access("/var/run/yule.pid", F_OK) = 0 getcwd("/opt/www/beltane/php", 4096) = 21 lstat64("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat64("/var/run", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat64("/var/run/yule.pid", {st_mode=S_IFREG|0644, st_size=6, ...}) = 0 open("/var/run/yule.pid", O_RDONLY) = 14 fstat64(14, {st_mode=S_IFREG|0644, st_size=6, ...}) = 0 lseek(14, 0, SEEK_CUR) = 0 lseek(14, 0, SEEK_SET) = 0 fstat64(14, {st_mode=S_IFREG|0644, st_size=6, ...}) = 0 mmap2(NULL, 6, PROT_READ, MAP_SHARED, 14, 0) = 0xb7bc1000 munmap(0xb7bc1000, 6) = 0 close(14) = 0 getsid(26060) = 26059 munmap(0xb7b85000, 86016) = 0 chdir("/") = 0 umask(022) = 022 pwrite64(13, "count|i:196;timestamp|i:11709541"..., 122, 0) = 122 close(13) = 0 webtrace.25429 lstat64("/opt/www/.beltanerc", {st_mode=S_IFREG|0600, st_size=751, ...}) = 0 open("/opt/www/.beltanerc", O_RDONLY) = 14 fstat64(14, {st_mode=S_IFREG|0600, st_size=751, ...}) = 0 lseek(14, 0, SEEK_CUR) = 0 lseek(14, 0, SEEK_SET) = 0 fstat64(14, {st_mode=S_IFREG|0600, st_size=751, ...}) = 0 mmap2(NULL, 751, PROT_READ, MAP_SHARED, 14, 0) = 0xb7bc1000 munmap(0xb7bc1000, 751) = 0 close(14) = 0 time(NULL) = 1170954151 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1323, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1323, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1323, ...}) = 0 access("/var/run/yule.pid", F_OK) = 0 getcwd("/opt/www/beltane/php", 4096) = 21 lstat64("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat64("/var/run", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat64("/var/run/yule.pid", {st_mode=S_IFREG|0644, st_size=6, ...}) = 0 open("/var/run/yule.pid", O_RDONLY) = 14 fstat64(14, {st_mode=S_IFREG|0644, st_size=6, ...}) = 0 lseek(14, 0, SEEK_CUR) = 0 lseek(14, 0, SEEK_SET) = 0 fstat64(14, {st_mode=S_IFREG|0644, st_size=6, ...}) = 0 mmap2(NULL, 6, PROT_READ, MAP_SHARED, 14, 0) = 0xb7bc1000 munmap(0xb7bc1000, 6) = 0 close(14) = 0 getsid(26060) = 26059 munmap(0xb7b85000, 86016) = 0 chdir("/") = 0 umask(022) = 022 pwrite64(13, "count|i:202;timestamp|i:11709541"..., 122, 0) = 122 close(13) = 0 Many Thanks Dan From cpebenito at tresys.com Thu Feb 8 18:21:55 2007 From: cpebenito at tresys.com (Christopher J. PeBenito) Date: Thu, 08 Feb 2007 18:21:55 +0000 Subject: ANN: SETools Release Message-ID: <1170958915.31164.45.camel@sgc.columbia.tresys.com> A new release of SETools is now available on the Tresys OSS site, from http://oss.tresys.com. The primary change in this release is the addition of support for loading sets of policy modules in all of the tools. This enables analysis of the policy with nearly all of the information available from the original source policy, such as original attribute names. The complete change log for this release follows. SETools 3.1: SETools: * All tools that open a policy now support loadable policy modules. Command line tools expect the first module to be a base module followed optionally by any other modules. Graphical tools have a new open policy dialog to select a base module and any number of additional modules. * Release of RPM packages that are compatible with Fedora Core 5 and 6. The spec and support files are in packages/rpm. libapol: * New class apol_policy_path_t to represent a base policy and any number of modules. Use this whenever referring to the file or files constituting a policy. libqpol: * Policy features such as attribute names or MLS can now be queried individally via qpol_policy_has_capability() rather than inferred by policy type and version. * New class qpol_module_t to represent a particular policy module prior to it being linked into a base policy (qpol_policy_t). libseaudit: * Rewrite of library to have proper namespaces. libseaudit is now fully documented and suitable for third-party users. seaudit: * Rewrite to use new libseaudit. * Numerous tweaks to the interface to be more user friendly. seaudit-report: * Rewrite to use new libseaudit. sediffx: * Numerous tweaks to the interface to be more user friendly. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 From sds at tycho.nsa.gov Thu Feb 8 18:55:15 2007 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 08 Feb 2007 13:55:15 -0500 Subject: Selinux error help - continued In-Reply-To: <9d5ddd1f0702080911m3834a547s463883cc813c74db@mail.gmail.com> References: <9d5ddd1f0702070908i1f8f97c3td083e73b8f5fefdb@mail.gmail.com> <1170868325.11912.74.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080235x3ffcb787kbf2f679467453596@mail.gmail.com> <1170940796.11912.206.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080648m50c194abq2e66d7d9c5646292@mail.gmail.com> <1170947589.11912.258.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080809l23577664j549eff08ba5109c@mail.gmail.com> <1170951141.11912.281.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080831r71d8e1ekf947f7892014e64f@mail.gmail.com> <1170952596.11912.289.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080911m3834a547s463883cc813c74db@mail.gmail.com> Message-ID: <1170960915.11912.328.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2007-02-08 at 17:11 +0000, Dan Track wrote: > Ok I just ran your strace and I got two files that contain the getsid > call. Not sure how to read where the pid is so I'll past a portion of > the file incase you can read it better than me. It is the argument to getsid, i.e. the number in parentheses. > The other strange thing is that I'm not getting any more selinux > notifications (SYSCALL) since issuing your chcon command. There are no > httpd violations. Should I back out the chcon to get the errors back? The selinux notifications are actually the AVC messages; the SYSCALL records are generated by the audit system if you have system call auditing enabled when a system call exits if any AVC messages were emitted during the system call. The SYSCALL records are helpful in providing more information, but aren't fundamental to SELinux. > getsid(26060) = 26059 So it tried to call getsid() on process 26060, and got 26059 as the session ID of that process. So look in the traces for 26059 and 26060 to see what those processes were. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Thu Feb 8 19:08:10 2007 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 08 Feb 2007 14:08:10 -0500 Subject: Selinux error help - continued In-Reply-To: <1170960915.11912.328.camel@moss-spartans.epoch.ncsc.mil> References: <9d5ddd1f0702070908i1f8f97c3td083e73b8f5fefdb@mail.gmail.com> <1170868325.11912.74.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080235x3ffcb787kbf2f679467453596@mail.gmail.com> <1170940796.11912.206.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080648m50c194abq2e66d7d9c5646292@mail.gmail.com> <1170947589.11912.258.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080809l23577664j549eff08ba5109c@mail.gmail.com> <1170951141.11912.281.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080831r71d8e1ekf947f7892014e64f@mail.gmail.com> <1170952596.11912.289.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080911m3834a547s463883cc813c74db@mail.gmail.com> <1170960915.11912.328.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1170961690.11912.334.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2007-02-08 at 13:55 -0500, Stephen Smalley wrote: > On Thu, 2007-02-08 at 17:11 +0000, Dan Track wrote: > > Ok I just ran your strace and I got two files that contain the getsid > > call. Not sure how to read where the pid is so I'll past a portion of > > the file incase you can read it better than me. > > It is the argument to getsid, i.e. the number in parentheses. > > > The other strange thing is that I'm not getting any more selinux > > notifications (SYSCALL) since issuing your chcon command. There are no > > httpd violations. Should I back out the chcon to get the errors back? > > The selinux notifications are actually the AVC messages; the SYSCALL > records are generated by the audit system if you have system call > auditing enabled when a system call exits if any AVC messages were > emitted during the system call. The SYSCALL records are helpful in > providing more information, but aren't fundamental to SELinux. > > > > getsid(26060) = 26059 > > So it tried to call getsid() on process 26060, and got 26059 as the > session ID of that process. So look in the traces for 26059 and 26060 > to see what those processes were. Actually, you won't have traces for those processes since they weren't descendants of httpd (since they were unconfined_t, thereby triggering this getsession avc message in the first place). But we can actually infer what the process was from the rest of your trace output - if you look at your trace, you'll see that it opened /var/run/yule.pid shortly before calling getsid. Thus, it is likely trying to check up on the separate yule daemon process. Which is likely running in unconfined_t on your machine. -- Stephen Smalley National Security Agency From dan.track at gmail.com Fri Feb 9 10:22:13 2007 From: dan.track at gmail.com (Dan Track) Date: Fri, 9 Feb 2007 10:22:13 +0000 Subject: Selinux error help - continued In-Reply-To: <1170961690.11912.334.camel@moss-spartans.epoch.ncsc.mil> References: <9d5ddd1f0702070908i1f8f97c3td083e73b8f5fefdb@mail.gmail.com> <9d5ddd1f0702080648m50c194abq2e66d7d9c5646292@mail.gmail.com> <1170947589.11912.258.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080809l23577664j549eff08ba5109c@mail.gmail.com> <1170951141.11912.281.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080831r71d8e1ekf947f7892014e64f@mail.gmail.com> <1170952596.11912.289.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080911m3834a547s463883cc813c74db@mail.gmail.com> <1170960915.11912.328.camel@moss-spartans.epoch.ncsc.mil> <1170961690.11912.334.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <9d5ddd1f0702090222i16f83cd4ud5aae7d2307c953f@mail.gmail.com> On 2/8/07, Stephen Smalley wrote: > On Thu, 2007-02-08 at 13:55 -0500, Stephen Smalley wrote: > > On Thu, 2007-02-08 at 17:11 +0000, Dan Track wrote: > > > Ok I just ran your strace and I got two files that contain the getsid > > > call. Not sure how to read where the pid is so I'll past a portion of > > > the file incase you can read it better than me. > > > > It is the argument to getsid, i.e. the number in parentheses. > > > > > The other strange thing is that I'm not getting any more selinux > > > notifications (SYSCALL) since issuing your chcon command. There are no > > > httpd violations. Should I back out the chcon to get the errors back? > > > > The selinux notifications are actually the AVC messages; the SYSCALL > > records are generated by the audit system if you have system call > > auditing enabled when a system call exits if any AVC messages were > > emitted during the system call. The SYSCALL records are helpful in > > providing more information, but aren't fundamental to SELinux. > > > > > > > getsid(26060) = 26059 > > > > So it tried to call getsid() on process 26060, and got 26059 as the > > session ID of that process. So look in the traces for 26059 and 26060 > > to see what those processes were. > > Actually, you won't have traces for those processes since they weren't > descendants of httpd (since they were unconfined_t, thereby triggering > this getsession avc message in the first place). But we can actually > infer what the process was from the rest of your trace output - if you > look at your trace, you'll see that it opened /var/run/yule.pid shortly > before calling getsid. Thus, it is likely trying to check up on the > separate yule daemon process. Which is likely running in unconfined_t > on your machine. > Hi Wow thats a lot info gleaned from the output. So to summarise the problem is with the httpd type interacting with a process running in unconfined_t. How would I go about resolving this? Dan From sds at tycho.nsa.gov Fri Feb 9 13:06:57 2007 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 09 Feb 2007 08:06:57 -0500 Subject: Selinux error help - continued In-Reply-To: <9d5ddd1f0702090222i16f83cd4ud5aae7d2307c953f@mail.gmail.com> References: <9d5ddd1f0702070908i1f8f97c3td083e73b8f5fefdb@mail.gmail.com> <9d5ddd1f0702080648m50c194abq2e66d7d9c5646292@mail.gmail.com> <1170947589.11912.258.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080809l23577664j549eff08ba5109c@mail.gmail.com> <1170951141.11912.281.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080831r71d8e1ekf947f7892014e64f@mail.gmail.com> <1170952596.11912.289.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080911m3834a547s463883cc813c74db@mail.gmail.com> <1170960915.11912.328.camel@moss-spartans.epoch.ncsc.mil> <1170961690.11912.334.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702090222i16f83cd4ud5aae7d2307c953f@mail.gmail.com> Message-ID: <1171026417.4975.2.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2007-02-09 at 10:22 +0000, Dan Track wrote: > On 2/8/07, Stephen Smalley wrote: > > On Thu, 2007-02-08 at 13:55 -0500, Stephen Smalley wrote: > > > On Thu, 2007-02-08 at 17:11 +0000, Dan Track wrote: > > > > Ok I just ran your strace and I got two files that contain the getsid > > > > call. Not sure how to read where the pid is so I'll past a portion of > > > > the file incase you can read it better than me. > > > > > > It is the argument to getsid, i.e. the number in parentheses. > > > > > > > The other strange thing is that I'm not getting any more selinux > > > > notifications (SYSCALL) since issuing your chcon command. There are no > > > > httpd violations. Should I back out the chcon to get the errors back? > > > > > > The selinux notifications are actually the AVC messages; the SYSCALL > > > records are generated by the audit system if you have system call > > > auditing enabled when a system call exits if any AVC messages were > > > emitted during the system call. The SYSCALL records are helpful in > > > providing more information, but aren't fundamental to SELinux. > > > > > > > > > > getsid(26060) = 26059 > > > > > > So it tried to call getsid() on process 26060, and got 26059 as the > > > session ID of that process. So look in the traces for 26059 and 26060 > > > to see what those processes were. > > > > Actually, you won't have traces for those processes since they weren't > > descendants of httpd (since they were unconfined_t, thereby triggering > > this getsession avc message in the first place). But we can actually > > infer what the process was from the rest of your trace output - if you > > look at your trace, you'll see that it opened /var/run/yule.pid shortly > > before calling getsid. Thus, it is likely trying to check up on the > > separate yule daemon process. Which is likely running in unconfined_t > > on your machine. > > > Hi > > Wow thats a lot info gleaned from the output. So to summarise the > problem is with the httpd type interacting with a process running in > unconfined_t. How would I go about resolving this? Your options are: 1) Ignore it - use dontaudit rules to suppress the avc message. This is suitable if it doesn't truly need to interact with the yule daemon. 2) Allow it - use allow rules and adjust the neverallow rule to avoid a conflict (e.g. change ~sigchld to ~{sigchld getsession}). This is suitable if it doesn't expose you to risk. 3) Put the yule daemon into its own domain (i.e. define policy for it), and then allow httpd_t to interact with that domain rather than with unconfined_t. -- Stephen Smalley National Security Agency From dan.track at gmail.com Fri Feb 9 14:59:11 2007 From: dan.track at gmail.com (Dan Track) Date: Fri, 9 Feb 2007 14:59:11 +0000 Subject: Selinux error help - continued In-Reply-To: <1171026417.4975.2.camel@moss-spartans.epoch.ncsc.mil> References: <9d5ddd1f0702070908i1f8f97c3td083e73b8f5fefdb@mail.gmail.com> <9d5ddd1f0702080809l23577664j549eff08ba5109c@mail.gmail.com> <1170951141.11912.281.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080831r71d8e1ekf947f7892014e64f@mail.gmail.com> <1170952596.11912.289.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702080911m3834a547s463883cc813c74db@mail.gmail.com> <1170960915.11912.328.camel@moss-spartans.epoch.ncsc.mil> <1170961690.11912.334.camel@moss-spartans.epoch.ncsc.mil> <9d5ddd1f0702090222i16f83cd4ud5aae7d2307c953f@mail.gmail.com> <1171026417.4975.2.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <9d5ddd1f0702090659x389e88d7p5c5bc0388f3e0eeb@mail.gmail.com> On 2/9/07, Stephen Smalley wrote: > On Fri, 2007-02-09 at 10:22 +0000, Dan Track wrote: > > On 2/8/07, Stephen Smalley wrote: > > > On Thu, 2007-02-08 at 13:55 -0500, Stephen Smalley wrote: > > > > On Thu, 2007-02-08 at 17:11 +0000, Dan Track wrote: > > > > > Ok I just ran your strace and I got two files that contain the getsid > > > > > call. Not sure how to read where the pid is so I'll past a portion of > > > > > the file incase you can read it better than me. > > > > > > > > It is the argument to getsid, i.e. the number in parentheses. > > > > > > > > > The other strange thing is that I'm not getting any more selinux > > > > > notifications (SYSCALL) since issuing your chcon command. There are no > > > > > httpd violations. Should I back out the chcon to get the errors back? > > > > > > > > The selinux notifications are actually the AVC messages; the SYSCALL > > > > records are generated by the audit system if you have system call > > > > auditing enabled when a system call exits if any AVC messages were > > > > emitted during the system call. The SYSCALL records are helpful in > > > > providing more information, but aren't fundamental to SELinux. > > > > > > > > > > > > > getsid(26060) = 26059 > > > > > > > > So it tried to call getsid() on process 26060, and got 26059 as the > > > > session ID of that process. So look in the traces for 26059 and 26060 > > > > to see what those processes were. > > > > > > Actually, you won't have traces for those processes since they weren't > > > descendants of httpd (since they were unconfined_t, thereby triggering > > > this getsession avc message in the first place). But we can actually > > > infer what the process was from the rest of your trace output - if you > > > look at your trace, you'll see that it opened /var/run/yule.pid shortly > > > before calling getsid. Thus, it is likely trying to check up on the > > > separate yule daemon process. Which is likely running in unconfined_t > > > on your machine. > > > > > Hi > > > > Wow thats a lot info gleaned from the output. So to summarise the > > problem is with the httpd type interacting with a process running in > > unconfined_t. How would I go about resolving this? > > Your options are: > 1) Ignore it - use dontaudit rules to suppress the avc message. This is > suitable if it doesn't truly need to interact with the yule daemon. > 2) Allow it - use allow rules and adjust the neverallow rule to avoid a > conflict (e.g. change ~sigchld to ~{sigchld getsession}). This is > suitable if it doesn't expose you to risk. > 3) Put the yule daemon into its own domain (i.e. define policy for it), > and then allow httpd_t to interact with that domain rather than with > unconfined_t. Hi Stephen, Many thanks for help with this. I've learnt a lot through this exercise and I think I can use this as a base to jump off from and work with selinux with a little more confidence. FYI I'm going to try option 3, as that seems like the preferred one with regards to security. Thanks again Dan From melaina at libero.it Sun Feb 11 04:17:07 2007 From: melaina at libero.it (melaina at libero.it) Date: Sun, 11 Feb 2007 05:17:07 +0100 Subject: Mail problems... Message-ID: Hello, a follow-up to my last e-mail. I fear part of the problem may be caused by the policy shipping with Plesk, contained in the file plesk.te. Could this transition be causing the issue? # qmail permissions # always enabled allow system_mail_t system_mail_t:fifo_file rw_file_perms; can_exec(system_mail_t, sendmail_exec_t) r_dir_file(system_mail_t, sendmail_exec_t) ifdef(`mta.te', ` domain_auto_trans(httpd_sys_script_t, sendmail_exec_t, system_mail_t) ') ---------- Initial Header ----------- From ejtr at layer3.co.uk Mon Feb 12 10:14:23 2007 From: ejtr at layer3.co.uk (Ted Rule) Date: Mon, 12 Feb 2007 10:14:23 +0000 Subject: Cron mail problem with FC6/strict In-Reply-To: <20070124101932.fzhiaqgdgow444ck@mail.sweetp.net> References: <1169420723.3503.10.camel@topaz.bugfinder.co.uk> <1169498867.15056.9.camel@sgc.columbia.tresys.com> <20070124101932.fzhiaqgdgow444ck@mail.sweetp.net> Message-ID: <1171275263.9806.49.camel@topaz.bugfinder.co.uk> Since my previous posting on this matter, I've performed a few more tests, slightly amended policy, and found a somewhat surprising result. Because earlier tests indicated that individual Jobs could initiate mail themselves from system_crond_t, but NOT crond itself, I reasoned that maybe there was perhaps something in one or all of policy / crond / libselinux / kernel which prevented crond - which had already performed a setexeccon - to exec another process which directly required a domain transition. Therefore, I made use of crond's "-m" option to provide a shell wrapper to sendmail itself employing the same command line params as crond invokes, as in: [root at topaz ~]# cat /usr/sbin/sendmail.sendmail.crond #!/bin/sh /usr/sbin/sendmail -FCronDaemon -i -odi -oem -oi -t [root at topaz ~]# I also labelled the wrapper as sendmail_exec_t: [root at topaz ~]# ls -lZ /usr/sbin/sendmail.sendmail* -rwxr-sr-x root smmsp system_u:object_r:sendmail_exec_t /usr/sbin/sendmail.sendmail -rwxr-xr-x root root staff_u:object_r:sendmail_exec_t /usr/sbin/sendmail.sendmail.crond [root at topaz ~]# Because of findings from previous tests, I added an entrypoint to SELinux policy which appears to be required: domain_entry_file(system_crond_t, sendmail_exec_t) And then I invoked the wrapper via /etc/sysconfig/crond: [root at topaz ~]# cat /etc/sysconfig/crond # Settings for the CRON daemon. # CRONDARGS= : any extra command-line startup arguments for crond # CRON_VALIDATE_MAILRCPTS=1:a non-empty value of this variable will # enable vixie-cron-4.1's validation of # mail recipient names, which would then be # restricted to contain only the chars # from this tr(1) set : [@!:%-_.,:alnum:] # otherwise mailing is not attempted. #CRONDARGS= CRONDARGS="-m/usr/sbin/sendmail.sendmail.crond" [root at topaz ~]# With all this in place, I found that Crond COULD launch the wrapper script, which in turn launched sendmail itself, and Cron mail WAS delivered. If I simply comment out the CRONDARGS setting to revert crond to "normal" operation, it succeeds in executing /usr/sbin/sendmail, but fails to transition to system_mail_t and no mail is delivered. As a next test, I further emulated /usr/sbin/sendmail itself by adding group membership, setgid flags and selinux ownership: [root at topaz ~]# ls -lZ /usr/sbin/sendmail.* -rwxr-sr-x root smmsp system_u:object_r:sendmail_exec_t /usr/sbin/sendmail.sendmail -rwxr-sr-x root smmsp system_u:object_r:sendmail_exec_t /usr/sbin/sendmail.sendmail.crond [root at topaz ~]# This still appears to work Ok. All in all, I appear to have a workround for the problem. It DOES seem to require one tweak to the existing policy - the extra domain_entry_file setting. However, I'm still very much in the dark as to why the wrapper script works and the binary copy of sendmail doesn't. Ted On Wed, 2007-01-24 at 10:19 +0000, Ted Rule wrote: > Quoting "Christopher J. PeBenito" : > > > On Sun, 2007-01-21 at 23:05 +0000, Ted Rule wrote: > >> A little while ago, I found that anacron wasn't running correctly under > >> FC6/strict, which led to me add a temporary fixup .te for its operation. > >> Once I had that in place, I finally received the cron.daily and logwatch > >> Emails every day shortly after bootup. > >> > >> With that in place, I recently took to leaving the machine powered > >> overnight, which of course led to all the Cron jobs running via crond > >> instead of anacron. > >> > >> Oddly, I noticed that the logwatch Email arrived, but NOT the cron.daily > >> summary Email. > >> > >> Looking further, I found this odd avc: > >> > >> Jan 21 21:29:51 topaz kernel: audit(1169414991.423:988): avc: denied > >> { entrypoint } for pid=4891 comm="crond" name="sendmail.sendmail" > >> dev=hda6 ino=1313020 > >> scontext=system_u:system_r:system_crond_t:s0-s0:c0.c1023 > >> tcontext=system_u:object_r:sendmail_exec_t:s0 tclass=file > >> > >> i.e. the crond child process running in system_crond_t was apparently > >> unable to run sendmail. > > > > Is this supposed to be cron emailing the output of the cron jobs or the > > cron job itself emailing something? > > The former: as mentioned above, my tests indicate that the latter seems > to work > Ok. > > As far as I can tell, what happens is that crond starts in > crond_t, forks a crond child, setexeccon's to system_crond_t to run the > Job, and > then forks a sendmail process to pick up the stdout/stderr from the > Job. Hence I > think you end up with something like this: > > 101 crond_t crond > 102 system_crond_t \ crond > 103 system_crond_t \ cron-job-script > 104 system_mail_t \ sendmail > > where stdout/stderr from the cron-job-script is routed into the > sendmail stdin, > with email subject line and similar parameters injected from pid 102. I also > believe that pid 104 is not created at all until some output is generated by > pid 103 - hence silent Cron Jobs don't create the avc denials for sendmail. > > sendmail directly or indirectly launched by pid 103 is Ok according to > my tests, > but seemingly sendmail launched by pid 102 itself gronks. > > > > > > -- > > Chris PeBenito > > Tresys Technology, LLC > > (410) 290-1411 x150 > > > > > -- Ted Rule Director, Layer3 Systems Ltd W: http://www.layer3.co.uk/ From dwalsh at redhat.com Mon Feb 12 16:37:35 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 12 Feb 2007 11:37:35 -0500 Subject: an easy way to edit security policies in fc6 In-Reply-To: <45ca156e.3c5.19a7.866652660@webmailh5.aruba.it> References: <45ca156e.3c5.19a7.866652660@webmailh5.aruba.it> Message-ID: <45D097CF.7090700@redhat.com> selinux at lucullo.it wrote: > hi, > > i'm new to selinux and i need to know how can i easy modify > a selinux targeted policy rule in fc6. > > my apache can't write in a /var subdir. > > my idea is to start looking in to logs and then edit the > policy (or the files attributes) to avoid problems. > > is there an easy tool for editing policy source? > > is there a complete how to (for fc6 targeted selinux)? > > excuse me for my bad english. > > thank you in advance. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Look at man httpd_selinux, it will give you some help on labeling. From dwalsh at redhat.com Tue Feb 13 21:21:19 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 13 Feb 2007 16:21:19 -0500 Subject: Mail problems... In-Reply-To: References: Message-ID: <45D22BCF.2020709@redhat.com> melaina at libero.it wrote: > Hello, > > a follow-up to my last e-mail. I fear part of the problem may be caused by the policy shipping with Plesk, contained in the file plesk.te. Could this transition be causing the issue? > > # qmail permissions > # always enabled > allow system_mail_t system_mail_t:fifo_file rw_file_perms; > can_exec(system_mail_t, sendmail_exec_t) > r_dir_file(system_mail_t, sendmail_exec_t) > ifdef(`mta.te', ` > domain_auto_trans(httpd_sys_script_t, sendmail_exec_t, system_mail_t) > ') > > THis says that if a cgi script comes upon a sendmail_exec_t it will transition to a system_mail_t, And it adds the ability for system_mail_t to exec sendmail_t files, AS well as talk to itself via a fifo_file. > > ---------- Initial Header ----------- > > From : "Daniel J Walsh" dwalsh at redhat.com > To : "melaina at libero.it" melaina at libero.it > Cc : "fedora-selinux-list" fedora-selinux-list at redhat.com > Date : Tue, 06 Feb 2007 12:15:05 -0500 > Subject : Re: Mail problems... > > > > > > > > >> melaina at libero.it wrote: >> >>> Hello! >>> >>> I have just started playing a bit with SELinux in permissive mode on my system. I have qmail with spamassassin installed; the only AVC denied messages I get (after I relabeled the system and fixed domains on a couple of log files), is the following: >>> >>> Jan 30 20:23:13 drake kernel: audit(1170210193.998:8): avc: denied { read } for pid=11862 comm="sendmail" name="RsmVLSTr" dev=loop0 ino=20 scontext=user_u: system_r:system_mail_t tcontext=user_u:object_r:httpd_sys_script_rw_t tclass=fil e >>> Jan 30 20:23:13 drake kernel: audit(1170210193.998:9): avc: denied { read wr ite } for pid=11862 comm="sendmail" name="jk-runtime-status" dev=hda5 ino=49827 49 scontext=user_u:system_r:system_mail_t tcontext=system_u:object_r:httpd_log_t tclass=file >>> Jan 30 20:23:14 drake kernel: audit(1170210194.019:10): avc: denied { ioctl } for pid=11863 comm="qmail-scanner-q" name="error_log" dev=hda5 ino=4984894 sc ontext=user_u:system_r:system_mail_t tcontext=system_u:object_r:httpd_log_t tcla ss=file >>> Jan 30 20:23:14 drake kernel: audit(1170210194.026:11): avc: denied { read } for pid=11863 comm="sperl5.8.5" name="mounts" dev=proc ino=777453584 scontext= user_u:system_r:system_mail_t tcontext=user_u:system_r:system_mail_t tclass=file >>> Jan 30 20:23:14 drake kernel: audit(1170210194.026:12): avc: denied { getatt r } for pid=11863 comm="sperl5.8.5" name="mounts" dev=proc ino=777453584 sconte xt=user_u:system_r:system_mail_t tcontext=user_u:system_r:system_mail_t tclass=f ile >>> Jan 30 20:23:15 drake kernel: audit(1170210195.204:13): avc: denied { append } for pid=11863 comm="perl5.8.5" name="qmail-queue.log" dev=hda5 ino=5130271 s context=user_u:system_r:system_mail_t tcontext=system_u:object_r:var_spool_t tcl ass=file >>> Jan 30 20:23:15 drake kernel: audit(1170210195.204:14): avc: denied { ioctl } for pid=11863 comm="perl5.8.5" name="qmail-queue.log" dev=hda5 ino=5130271 sc ontext=user_u:system_r:system_mail_t tcontext=system_u:object_r:var_spool_t tcla ss=file >>> Jan 30 20:23:15 drake kernel: audit(1170210195.205:15): avc: denied { getatt r } for pid=11863 comm="perl5.8.5" name="qmail-queue.log" dev=hda5 ino=5130271 scontext=user_u:system_r:system_mail_t tcontext=system_u:object_r:var_spool_t tc lass=file >>> Jan 30 20:23:15 drake kernel: audit(1170210195.206:16): avc: denied { read } for pid=11863 comm="perl5.8.5" name="qmail-scanner-queue-version.txt" dev=hda5 ino=5130273 scontext=user_u:system_r:system_mail_t tcontext=system_u:object_r:v ar_spool_t tclass=file >>> Jan 30 20:23:15 drake kernel: audit(1170210195.208:17): avc: denied { write } for pid=11863 comm="perl5.8.5" name="tmp" dev=hda5 ino=5195094 scontext=user_ u:system_r:system_mail_t tcontext=system_u:object_r:var_spool_t tclass=dir >>> Jan 30 20:23:15 drake kernel: audit(1170210195.208:18): avc: denied { add_na me } for pid=11863 comm="perl5.8.5" name="drake.mydomain.com1170210195772118 63" scontext=user_u:system_r:system_mail_t tcontext=system_u:object_r:var_spool_ t tclass=dir >>> Jan 30 20:23:15 drake kernel: audit(1170210195.208:19): avc: denied { create } for pid=11863 comm="perl5.8.5" name="drake.mydomain.com117021019577211863 " scontext=user_u:system_r:system_mail_t tcontext=user_u:object_r:var_spool_t tc lass=dir >>> Jan 30 20:23:15 drake kernel: audit(1170210195.409:20): avc: denied { create } for pid=11863 comm="perl5.8.5" name="drake.mydomain.com117021019577211863 " scontext=user_u:system_r:system_mail_t tcontext=user_u:object_r:var_spool_t tc lass=file >>> Jan 30 20:23:15 drake kernel: audit(1170210195.410:21): avc: denied { ioctl } for pid=11863 comm="perl5.8.5" name="drake.mydomain.com117021019577211863" dev=hda5 ino=5276868 scontext=user_u:system_r:system_mail_t tcontext=user_u:obj ect_r:var_spool_t tclass=file >>> Jan 30 20:23:15 drake kernel: audit(1170210195.410:22): avc: denied { getatt r } for pid=11863 comm="perl5.8.5" name="drake.mydomain.com11702101957721186 3" dev=hda5 ino=5276868 scontext=user_u:system_r:system_mail_t tcontext=user_u:o bject_r:var_spool_t tclass=file >>> Jan 30 20:23:15 drake kernel: audit(1170210195.414:23): avc: denied { write } for pid=11863 comm="perl5.8.5" name="drake.mydomain.com117021019577211863" dev=hda5 ino=5276868 scontext=user_u:system_r:system_mail_t tcontext=user_u:obj ect_r:var_spool_t tclass=file >>> Jan 30 20:23:15 drake kernel: audit(1170210195.418:24): avc: denied { link } for pid=11863 comm="perl5.8.5" name="drake.mydomain.com117021019577211863" dev=hda5 ino=5276868 scontext=user_u:system_r:system_mail_t tcontext=user_u:obje ct_r:var_spool_t tclass=file >>> Jan 30 20:23:15 drake kernel: audit(1170210195.419:25): avc: denied { remove _name } for pid=11863 comm="perl5.8.5" name="drake.mydomain.com1170210195772 11863" dev=hda5 ino=5276868 scontext=user_u:system_r:system_mail_t tcontext=syst em_u:object_r:var_spool_t tclass=dir >>> Jan 30 20:23:15 drake kernel: audit(1170210195.419:26): avc: denied { unlink } for pid=11863 comm="perl5.8.5" name="drake.mydomain.com117021019577211863 " dev=hda5 ino=5276868 scontext=user_u:system_r:system_mail_t tcontext=user_u:ob ject_r:var_spool_t tclass=file >>> Jan 30 20:23:15 drake kernel: audit(1170210195.424:27): avc: denied { read w rite } for pid=11864 comm="sh" name="tty" dev=tmpfs ino=1804 scontext=user_u:sy stem_r:system_mail_t tcontext=system_u:object_r:devtty_t tclass=chr_file >>> Jan 30 20:23:15 drake kernel: audit(1170210195.431:28): avc: denied { read } for pid=11865 comm="sh" name="drake.mydomain.com117021019577211863" dev=hda 5 ino=5276868 scontext=user_u:system_r:system_mail_t tcontext=user_u:object_r:va r_spool_t tclass=file >>> Jan 30 20:23:15 drake kernel: audit(1170210195.434:29): avc: denied { write } for pid=11865 comm="reformime" name="drake.mydomain.com117021019577211863" dev=hda5 ino=5408221 scontext=user_u:system_r:system_mail_t tcontext=user_u:obj ect_r:var_spool_t tclass=dir >>> Jan 30 20:23:15 drake kernel: audit(1170210195.434:30): avc: denied { add_na me } for pid=11865 comm="reformime" name="1170210195.11865-0.drake.mydomain. com" scontext=user_u:system_r:system_mail_t tcontext=user_u:object_r:var_spool_t tclass=dir >>> Jan 30 20:23:15 drake kernel: audit(1170210195.739:31): avc: denied { read } for pid=11863 comm="perl5.8.5" name="drake.mydomain.com117021019577211863" dev=hda5 ino=5408221 scontext=user_u:system_r:system_mail_t tcontext=user_u:obje ct_r:var_spool_t tclass=dir >>> Jan 30 20:23:15 drake kernel: audit(1170210195.755:32): avc: denied { read } for pid=11863 comm="perl5.8.5" name="tmp" dev=hda5 ino=4980740 scontext=user_u :system_r:system_mail_t tcontext=system_u:object_r:var_t tclass=lnk_file >>> Jan 30 20:23:15 drake kernel: audit(1170210195.795:33): avc: denied { execut e } for pid=11867 comm="perl5.8.5" name="find" dev=hda5 ino=5297451 scontext=us er_u:system_r:system_mail_t tcontext=system_u:object_r:file_t tclass=file >>> Jan 30 20:23:15 drake kernel: audit(1170210195.796:34): avc: denied { execut e_no_trans } for pid=11867 comm="perl5.8.5" name="find" dev=hda5 ino=5297451 sc ontext=user_u:system_r:system_mail_t tcontext=system_u:object_r:file_t tclass=fi le >>> Jan 30 20:23:15 drake kernel: audit(1170210195.796:35): avc: denied { read } for pid=11867 comm="perl5.8.5" name="find" dev=hda5 ino=5297451 scontext=user_ u:system_r:system_mail_t tcontext=system_u:object_r:file_t tclass=file >>> Jan 30 20:23:15 drake kernel: audit(1170210195.798:36): avc: denied { search } for pid=11867 comm="find" name="selinux" dev=hda5 ino=557257 scontext=user_u :system_r:system_mail_t tcontext=system_u:object_r:selinux_config_t tclass=dir >>> Jan 30 20:23:15 drake kernel: audit(1170210195.798:37): avc: denied { read } for pid=11867 comm="find" name="config" dev=hda5 ino=557274 scontext=user_u:sy stem_r:system_mail_t tcontext=user_u:object_r:selinux_config_t tclass=file >>> Jan 30 20:23:15 drake kernel: audit(1170210195.798:38): avc: denied { getatt r } for pid=11867 comm="find" name="config" dev=hda5 ino=557274 scontext=user_u :system_r:system_mail_t tcontext=user_u:object_r:selinux_config_t tclass=file >>> Jan 30 20:23:15 drake kernel: audit(1170210195.860:39): avc: denied { read } for pid=11871 comm="rm" name="qscan" dev=hda5 ino=5130256 scontext=user_u:syst em_r:system_mail_t tcontext=system_u:object_r:var_spool_t tclass=dir >>> Jan 30 20:23:15 drake kernel: audit(1170210195.860:40): avc: denied { remove _name } for pid=11871 comm="rm" name="1170210195.11865-0.drake.mydomain.com" dev=hda5 ino=5408222 scontext=user_u:system_r:system_mail_t tcontext=user_u:obj ect_r:var_spool_t tclass=dir >>> Jan 30 20:23:15 drake kernel: audit(1170210195.861:41): avc: denied { rmdir } for pid=11871 comm="rm" name="drake.mydomain.com117021019577211863" dev=hd a5 ino=5408221 scontext=user_u:system_r:system_mail_t tcontext=user_u:object_r:v ar_spool_t tclass=dir >>> Jan 30 20:23:15 drake kernel: audit(1170210195.873:42): avc: denied { sigchl d } for pid=1 comm="init" scontext=user_u:system_r:system_mail_t tcontext=user_ u:system_r:unconfined_t tclass=process >>> >>> Any directions to fix this? >>> >>> Thanks! >>> >>> >> This looks like qmail is doing a lot more stuff then a normal sendmail >> would do. >> >> Running this log file under audit2allow gives the following rules >> >> allow system_mail_t devtty_t:chr_file { read write }; >> > This probably can be ignored. >> allow system_mail_t file_t:file { execute execute_no_trans read }; >> > Indicates something is still mislabeled. >> allow system_mail_t httpd_log_t:file { ioctl read write }; >> > Why would mail be updating httpd_log_t >> allow system_mail_t httpd_sys_script_rw_t:file read; >> >Reading a script file? >> allow system_mail_t selinux_config_t:dir search; >> allow system_mail_t selinux_config_t:file { getattr read }; >> > These disappear in enforcing mode. >> allow system_mail_t self:file { getattr read }; >> > Qmail specific >> allow system_mail_t unconfined_t:process sigchld; >> > qmail is somehow execing init to send a sigchld to an unconfined >> process??? >> allow system_mail_t var_spool_t:dir { add_name create read remove_name >> rmdir write }; >> allow system_mail_t var_spool_t:file { append create getattr ioctl link >> read unlink write }; >> allow system_mail_t var_t:lnk_file read; >> > qmail is updating files in /var/spool? >> >> >> >>> ------------------------------------------------------ >>> Mutuo da 200.000 ?? Tassi ridotti da 4.25%. Solo per richieste online. Mutuionline.it >>> http://click.libero.it/mutuionline31ge07 >>> >>> >>> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>> >>> >> >> > > > ------------------------------------------------------ > Passa a Infostrada. ADSL e Telefono senza limiti e senza canone Telecom > http://click.libero.it/infostrada11feb07 > > > From bruce.therrien at wm-mw.org Tue Feb 13 23:05:35 2007 From: bruce.therrien at wm-mw.org (Bruce Therrien) Date: Tue, 13 Feb 2007 18:05:35 -0500 Subject: re-configuring PHP Message-ID: <20070213180109.AE85.BRUCE.THERRIEN@wm-mw.org> Hi, Go-daddy insists that I re-configure PHP to use GD. Can someone tell me where PHP is located on my server. All I can find is php.ini........ I'm running core 6, with PHP 5.0.4, but I need the GD support. I have the configure text ready to execute, but where? I use Putty for access. Here's the text: ./configure --build=i386-redhat-linux --host=i386-redhat-linux --target=i386-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --cache-file=../config.cache --with-libdir=lib --with-config-file-path=/etc --with-config-file-scan-dir=/etc/php.d --disable-debug --with-pic --disable-rpath --with-bz2 --with-curl --with-exec-dir=/usr/bin --with-freetype-dir=/usr --with-png-dir=/usr --enable-gd-native-ttf --with-gdbm --with-gd --with-gettext --with-gmp --with-iconv --with-jpeg-dir=/usr --with-openssl --with-png --with-pspell --with-expat-dir=/usr --with-pcre-regex=/usr --with-zlib --with-layout=GNU --enable-exif --enable-ftp --enable-magic-quotes --enable-sockets --enable-sysvsem --enable-sysvshm --enable-sysvmsg --enable-track-vars --enable-trans-sid --enable-yp --enable-wddx --with-pear=/usr/share/pear --with-kerberos --enable-ucd-snmp-hack --with-unixODBC=shared,/usr --enable-memory-limit --enable-shmop --enable-calendar --enable-dbx --enable-dio --with-mime-magic=/etc/httpd/conf/magic --without-sqlite --without-mysql --without-gd --without-odbc --disable-dom --disable-dba Together, Bruce Therrien Vice-president, Online systems WebMusic-MusiqueWeb The only on line international music network owned by all of its Affiliates... Together International Foundation 146 ch du Tour-du-Lac Lac-Beauport, Quebec G3B 0T3 Canada Quebec City Phone : 1.418.694.9700 New-York City Phone : 1.646.808.0236 Hartford IP Phone : 1.860.819.3723 Office IP Phone : 1.747.668.5625 Michel's Pager : 1.418.650.8494 Skype : musicweb http://wm-mw.org http://t-i-f.org "We are sharing a vision, and determined to share that vision with all who wish to be a part of it. Dedicated to promote and enhance the concept, and will do whatever it takes to ensure that people from around the world will no longer be taken in by false promises of security." - SID '98 This is the end of the internet. Please turn around and go back. From tmz at pobox.com Wed Feb 14 03:21:17 2007 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 13 Feb 2007 22:21:17 -0500 Subject: re-configuring PHP In-Reply-To: <20070213180109.AE85.BRUCE.THERRIEN@wm-mw.org> References: <20070213180109.AE85.BRUCE.THERRIEN@wm-mw.org> Message-ID: <20070214032117.GI23466@psilocybe.teonanacatl.org> Bruce Therrien wrote: > Go-daddy insists that I re-configure PHP to use GD. What do they have to do with configuring your FC6 server? And what does this have to do with SELinux? > Can someone tell me where PHP is located on my server. > All I can find is php.ini........ > I'm running core 6, with PHP 5.0.4, but I need the GD support. So you've compiled your own php already and done so with a lower version than FC6 ships with? 5.1.6 is what came with FC6. And if you used the stock setup all you'd have to do to enable GD support in php is yum install php-gd, then restart httpd. > I have the configure text ready to execute, but where? You need to run configure in the directory where you extract the php source. I couldn't tell you where that is on your server. Best to ask for help on another list, though I'm not sure what the most appropriate suggestion would be if you're rolling your own and not using the packages provided. Perhaps there's a proper php.net list? -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ====================================================================== User, n.: The word computer professionals use when they mean "idiot." -- Dave Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From mjs at ces.clemson.edu Wed Feb 14 19:16:35 2007 From: mjs at ces.clemson.edu (Matthew Saltzman) Date: Wed, 14 Feb 2007 14:16:35 -0500 (EST) Subject: re-configuring PHP In-Reply-To: <20070214032117.GI23466@psilocybe.teonanacatl.org> References: <20070213180109.AE85.BRUCE.THERRIEN@wm-mw.org> <20070214032117.GI23466@psilocybe.teonanacatl.org> Message-ID: On Tue, 13 Feb 2007, Todd Zullinger wrote: > Bruce Therrien wrote: >> Go-daddy insists that I re-configure PHP to use GD. > > What do they have to do with configuring your FC6 server? And what > does this have to do with SELinux? > >> Can someone tell me where PHP is located on my server. >> All I can find is php.ini........ >> I'm running core 6, with PHP 5.0.4, but I need the GD support. > > So you've compiled your own php already and done so with a lower > version than FC6 ships with? 5.1.6 is what came with FC6. And if you > used the stock setup all you'd have to do to enable GD support in php > is yum install php-gd, then restart httpd. > >> I have the configure text ready to execute, but where? > > You need to run configure in the directory where you extract the php > source. I couldn't tell you where that is on your server. > > Best to ask for help on another list, though I'm not sure what the > most appropriate suggestion would be if you're rolling your own and not > using the packages provided. Perhaps there's a proper php.net list? You probably want fedora-list at redhat.com. But if you have an RPM for your (non-stock) PHP, grab the SRPM, install it, edit the spec file, and rebuild with "rpmbuild -bb php.spec". I'd recommend installing rpmdevtools, which will allow you to setup a build tree in your home directory so you don't have to build as root. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From drago01 at gmail.com Wed Feb 14 19:44:38 2007 From: drago01 at gmail.com (dragoran) Date: Wed, 14 Feb 2007 20:44:38 +0100 Subject: re-configuring PHP In-Reply-To: <20070213180109.AE85.BRUCE.THERRIEN@wm-mw.org> References: <20070213180109.AE85.BRUCE.THERRIEN@wm-mw.org> Message-ID: <45D366A6.7000009@gmail.com> Bruce Therrien wrote: > Hi, > > Go-daddy insists that I re-configure PHP to use GD. > 1) wrong list 2)you don't need to do so yum install php-gd should enable gd support for you. (httpd restart mioght be required) From ejtr at layer3.co.uk Sat Feb 17 21:42:40 2007 From: ejtr at layer3.co.uk (Ted Rule) Date: Sat, 17 Feb 2007 21:42:40 +0000 Subject: Cron mail problem with FC6/strict In-Reply-To: <1171275263.9806.49.camel@topaz.bugfinder.co.uk> References: <1169420723.3503.10.camel@topaz.bugfinder.co.uk> <1169498867.15056.9.camel@sgc.columbia.tresys.com> <20070124101932.fzhiaqgdgow444ck@mail.sweetp.net> <1171275263.9806.49.camel@topaz.bugfinder.co.uk> Message-ID: <1171748560.5537.40.camel@topaz.bugfinder.co.uk> I think I may have a possible explanation for this issue, which seems to point the blame at the kernel. >From man setexeccon I see: "setexeccon sets the context used for the next execve call. NULL can be passed to setexeccon to reset to the default policy behavior. The exec context is automatically reset after the next execve, so a program doesn?t need to explicitly sanitize it upon startup. setexeccon can be applied prior to library functions that internally perform an execve, e.g. execl*, execv*, popen, in order to set an exec context for that operation." Reading the Cron source, I see the following sequence: crond[parent] runs as crond_t crond[[parent] reads /etc/crontab crond[parent] forks a worker child still in crond_t crond[child] setexeccon's to system_crond_t based on /etc/crontab crond[child] forks a grandchild to run the Job in system_crond_t crond[grandchild] execle()'s the actual job.itself, which now runs in system_crond_t because of setexeccon(). crond[child] still in crond_t(?) waits for STDOUT pipe from Job. crond[child] sees incoming STDOUT and fork()/evecvp()'s yet again to run the sendmail process. My reasoning has it that crond[child] forks sendmail as system_crond_t, because it still has the latest setexeccon() setting leftover from the creation of the grandchild. However, it NEEDS to have the setexeccon() status left in place because it needs to run sendmail in either system_mail_t or user_mail_t depending on whether it is a user Cron Job or a system Cron Job. Therefore, I reason, the bug is actually in the kernel which doesn't allow for an exec() to perform a double transition. In this case, it would need to jump from crond_t to system_crond_t ( because of setexeccon() ), and thereafter to system_mail_t ( because of domain_auto_trans in SELinux policy. ) all during the act of performing a single exec(). Is this a plausible explanation for the observed behaviour? If so, the workround is presumably for crond to double fork before invoking the Job. i.e inside crond, do_command() would call child_process(), which would then setexeccon(), then fork() AGAIN to drop into the new security context as set by setexeccon(), and only then build all the pipes and the greatgrandchild Job process and sendmail processes themselves. Ted On Mon, 2007-02-12 at 10:14 +0000, Ted Rule wrote: > Since my previous posting on this matter, I've performed a few more > tests, slightly amended policy, and found a somewhat surprising result. > > Because earlier tests indicated that individual Jobs could initiate mail > themselves from system_crond_t, but NOT crond itself, I reasoned that > maybe there was perhaps something in one or all of policy / crond / > libselinux / kernel which prevented crond - which had already performed > a setexeccon - to exec another process which directly required a domain > transition. > > Therefore, I made use of crond's "-m" option to provide a shell wrapper > to sendmail itself employing the same command line params as crond > invokes, as in: > > > [root at topaz ~]# cat /usr/sbin/sendmail.sendmail.crond > #!/bin/sh > > /usr/sbin/sendmail -FCronDaemon -i -odi -oem -oi -t > [root at topaz ~]# > > > I also labelled the wrapper as sendmail_exec_t: > > [root at topaz ~]# ls -lZ /usr/sbin/sendmail.sendmail* > -rwxr-sr-x root smmsp > system_u:object_r:sendmail_exec_t /usr/sbin/sendmail.sendmail > -rwxr-xr-x root root > staff_u:object_r:sendmail_exec_t /usr/sbin/sendmail.sendmail.crond > [root at topaz ~]# > > > Because of findings from previous tests, I added an entrypoint to > SELinux policy which appears to be required: > > > domain_entry_file(system_crond_t, sendmail_exec_t) > > > And then I invoked the wrapper via /etc/sysconfig/crond: > > [root at topaz ~]# cat /etc/sysconfig/crond > # Settings for the CRON daemon. > # CRONDARGS= : any extra command-line startup arguments for crond > # CRON_VALIDATE_MAILRCPTS=1:a non-empty value of this variable will > # enable vixie-cron-4.1's validation of > # mail recipient names, which would then be > # restricted to contain only the chars > # from this tr(1) set : [@!:%-_.,:alnum:] > # otherwise mailing is not attempted. > #CRONDARGS= > CRONDARGS="-m/usr/sbin/sendmail.sendmail.crond" > [root at topaz ~]# > > > With all this in place, I found that Crond COULD launch the wrapper > script, which in turn launched sendmail itself, and Cron mail WAS > delivered. > > If I simply comment out the CRONDARGS setting to revert crond to > "normal" operation, it succeeds in executing /usr/sbin/sendmail, but > fails to transition to system_mail_t and no mail is delivered. > > As a next test, I further emulated /usr/sbin/sendmail itself by adding > group membership, setgid flags and selinux ownership: > > [root at topaz ~]# ls -lZ /usr/sbin/sendmail.* > -rwxr-sr-x root smmsp > system_u:object_r:sendmail_exec_t /usr/sbin/sendmail.sendmail > -rwxr-sr-x root smmsp > system_u:object_r:sendmail_exec_t /usr/sbin/sendmail.sendmail.crond > [root at topaz ~]# > > > This still appears to work Ok. > > > All in all, I appear to have a workround for the problem. It DOES seem > to require one tweak to the existing policy - the extra > domain_entry_file setting. However, I'm still very much in the dark as > to why the wrapper script works and the binary copy of sendmail doesn't. > > > > Ted > > > > > On Wed, 2007-01-24 at 10:19 +0000, Ted Rule wrote: > > Quoting "Christopher J. PeBenito" : > > > > > On Sun, 2007-01-21 at 23:05 +0000, Ted Rule wrote: > > >> A little while ago, I found that anacron wasn't running correctly under > > >> FC6/strict, which led to me add a temporary fixup .te for its operation. > > >> Once I had that in place, I finally received the cron.daily and logwatch > > >> Emails every day shortly after bootup. > > >> > > >> With that in place, I recently took to leaving the machine powered > > >> overnight, which of course led to all the Cron jobs running via crond > > >> instead of anacron. > > >> > > >> Oddly, I noticed that the logwatch Email arrived, but NOT the cron.daily > > >> summary Email. > > >> > > >> Looking further, I found this odd avc: > > >> > > >> Jan 21 21:29:51 topaz kernel: audit(1169414991.423:988): avc: denied > > >> { entrypoint } for pid=4891 comm="crond" name="sendmail.sendmail" > > >> dev=hda6 ino=1313020 > > >> scontext=system_u:system_r:system_crond_t:s0-s0:c0.c1023 > > >> tcontext=system_u:object_r:sendmail_exec_t:s0 tclass=file > > >> > > >> i.e. the crond child process running in system_crond_t was apparently > > >> unable to run sendmail. > > > > > > Is this supposed to be cron emailing the output of the cron jobs or the > > > cron job itself emailing something? > > > > The former: as mentioned above, my tests indicate that the latter seems > > to work > > Ok. > > > > As far as I can tell, what happens is that crond starts in > > crond_t, forks a crond child, setexeccon's to system_crond_t to run the > > Job, and > > then forks a sendmail process to pick up the stdout/stderr from the > > Job. Hence I > > think you end up with something like this: > > > > 101 crond_t crond > > 102 system_crond_t \ crond > > 103 system_crond_t \ cron-job-script > > 104 system_mail_t \ sendmail > > > > where stdout/stderr from the cron-job-script is routed into the > > sendmail stdin, > > with email subject line and similar parameters injected from pid 102. I also > > believe that pid 104 is not created at all until some output is generated by > > pid 103 - hence silent Cron Jobs don't create the avc denials for sendmail. > > > > sendmail directly or indirectly launched by pid 103 is Ok according to > > my tests, > > but seemingly sendmail launched by pid 102 itself gronks. > > > > > > > > > > -- > > > Chris PeBenito > > > Tresys Technology, LLC > > > (410) 290-1411 x150 > > > > > > > > -- Ted Rule Director, Layer3 Systems Ltd W: http://www.layer3.co.uk/ From ejtr at layer3.co.uk Sun Feb 18 17:36:29 2007 From: ejtr at layer3.co.uk (Ted Rule) Date: Sun, 18 Feb 2007 17:36:29 +0000 Subject: Cron mail problem with FC6/strict In-Reply-To: <1171748560.5537.40.camel@topaz.bugfinder.co.uk> References: <1169420723.3503.10.camel@topaz.bugfinder.co.uk> <1169498867.15056.9.camel@sgc.columbia.tresys.com> <20070124101932.fzhiaqgdgow444ck@mail.sweetp.net> <1171275263.9806.49.camel@topaz.bugfinder.co.uk> <1171748560.5537.40.camel@topaz.bugfinder.co.uk> Message-ID: <1171820189.22395.42.camel@topaz.bugfinder.co.uk> On Sat, 2007-02-17 at 21:42 +0000, Ted Rule wrote: > If so, the workround is presumably for crond to double fork before > invoking the Job. i.e inside crond, do_command() would call > child_process(), which would then setexeccon(), then fork() AGAIN to > drop into the new security context as set by setexeccon(), and only then > build all the pipes and the greatgrandchild Job process and sendmail > processes themselves. Doh. Of course I now realise that a double fork won't help because the setexecon only affects exec() behaviour, not fork(). So I'm back to working round the problem with my wrapper script to indirectly launch sendmail. -- Ted Rule Director, Layer3 Systems Ltd W: http://www.layer3.co.uk/ From selinux at gmail.com Tue Feb 20 16:10:36 2007 From: selinux at gmail.com (Tom London) Date: Tue, 20 Feb 2007 08:10:36 -0800 Subject: more prelink AVCs Message-ID: <4c4ba1530702200810r2ed04918v5df2b003af2c4844@mail.gmail.com> Running latest rawhide, targeted/enforcing. Getting AVCs for prelink for sudo_exec_t type=AVC msg=audit(1171985725.828:47): avc: denied { read } for pid=32139 comm="prelink" name="sudoedit" dev=dm-0 ino=5474778 scontext=system_u:system_r:prelink_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file type=SYSCALL msg=audit(1171985725.828:47): arch=40000003 syscall=5 success=no exit=-13 a0=a02bcf8 a1=8000 a2=0 a3=0 items=0 ppid=32130 pid=32139 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-s0:c0.c1023 key=(null) type=AVC msg=audit(1171985739.772:48): avc: denied { read } for pid=32139 comm="prelink" name="sudo" dev=dm-0 ino=5474778 scontext=system_u:system_r:prelink_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file type=SYSCALL msg=audit(1171985739.772:48): arch=40000003 syscall=5 success=no exit=-13 a0=a02bcf8 a1=8000 a2=0 a3=0 items=0 ppid=32130 pid=32139 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-s0:c0.c1023 key=(null) tom -- Tom London From ejtr at layer3.co.uk Thu Feb 22 15:27:50 2007 From: ejtr at layer3.co.uk (Ted Rule) Date: Thu, 22 Feb 2007 15:27:50 +0000 Subject: SpamAssassin Log explosion issue following update Message-ID: <1172158070.14619.85.camel@topaz.bugfinder.co.uk> I recently updated SpamAssassin on my FC6/strict box to spamassassin-3.1.8-2.fc6. FWIW, the selinux-policy is currently on selinux-policy-strict-2.4.6-37.fc6 It seems that the installation may well have partially failed because I ran "yum update spamassassin" whilst still in enforcing mode. I erroneously assumed that spamd continued to run Ok, as I saw no error messages during the "yum update". Sadly, to my horror earlier today, I found that the /var partition was completely full of log messages from SELinux/spamd, viz: ... Feb 22 12:08:25 topaz kernel: audit(1172146105.931:9462050): avc: denied { search } for pid=10329 comm="spamd" name="/" dev=hda2 ino=2 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir Feb 22 12:08:25 topaz kernel: audit(1172146105.932:9462051): avc: denied { search } for pid=10329 comm="spamd" name="/" dev=hda2 ino=2 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir Feb 22 12:08:25 topaz kernel: audit(1172146105.932:9462052): avc: denied { search } for pid=10329 comm="spamd" name="/" dev=hda2 ino=2 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir Feb 22 12:08:25 topaz kernel: audit(1172146105.932:9462053): avc: denied { search } for pid=10329 comm="spamd" name="/" dev=hda2 ino=2 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir .... In other words, for some reason the "broken" update left the process running in the unlabeled_t domain, which is a little bizarre. In any event, I then got a continuous stream of these denials in the log which eventually filled the log within a few hours. Note to self: presumably using auditd instead of syslog-ng for storing these messages would have avoided the filesystem overload. Similarly, I have yet to check the manual pages for syslog-ng for a max-logfile-size option which might have avoided the ensuing embarrassment. After clearing out the massive log files to give spamd and syslog-ng room to manoeuvre, I then tried looking for the spamd[10329] in the process list, but found that it was invisible(!), presumably because it was running as unlabeled_t. I then tried temporarily enabling the "allow_ptrace" boolean to see if that helped make the process visible, to no avail. Finally, I was forced to drop into permissive mode to locate the rogue PID running in "unlabeled_t". So then I stopped spamd, went back to enforcing mode, and restarted spamd, which duly ran in its proper spamd_t domain. >From previous experiences I think the strict policy, and perhaps the targeted policy also, is missing several permissions which allow various init scripts to be called from within "yum update". To satisfy my own curiousity, can someone explain how spamd ended up running in unlabeled_t? Is it somehow related to a process continuing to run which has no corresponding executable binary? Following this experience, can I make some suggestions: a. Please test that rpm/yum update runs without error for any RPM update on both a strict/enforcing box and a targeted/enforcing box before the RPM is released to mirrors. b. Don't expect that yum update can be run in enforcing mode, especially on packages associated with running daemons. c. Please can we add a policy permission so that sysadm_t can seek and destroy unlabeled_t processes with extreme prejudice without recourse to permissive mode? Ted # ps axf | grep 103 14549 pts/1 S+ 0:00 \_ grep 103 # setsebool allow_ptrace=1 # getsebool -a| grep ptrace allow_ptrace --> on # ps axf | grep 103 14561 pts/1 S+ 0:00 \_ grep 103 # setenforce 0 # ps axf | grep 103 10329 ? Ss 12:44 /usr/bin/spamd -d -c -m5 -H -r /var/run/spamd.pid 10331 ? Z 1:23 \_ [spamd] 10332 ? Z 0:06 \_ [spamd] 14564 pts/1 S+ 0:00 \_ grep 103 # ps axfZ | grep 103 system_u:object_r:unlabeled_t 10329 ? Ss 12:44 /usr/bin/spamd -d -c -m5 -H -r /var/run/spamd.pid system_u:object_r:unlabeled_t 10331 ? Z 1:23 \_ [spamd] system_u:object_r:unlabeled_t 10332 ? Z 0:06 \_ [spamd] staff_u:sysadm_r:sysadm_t 14566 pts/1 S+ 0:00 \_ grep 103 # setenforce 1 # ps axfZ | grep 103 staff_u:sysadm_r:sysadm_t 14569 pts/1 S+ 0:00 \_ grep 103 # setenforce 0 # run_init service spamassassin stop Authenticating root. Password: Stopping spamd: [ OK ] # ps axf | grep spam 14591 pts/1 S+ 0:00 \_ grep spam # setenforce 1 # run_init service spamassassin start Authenticating root. Password: Starting spamd: [ OK ] # ps axfZ | grep spam staff_u:sysadm_r:sysadm_t 14617 pts/1 S+ 0:00 \_ grep spam system_u:system_r:spamd_t 14612 ? Ss 0:01 /usr/bin/spamd -d -c -m5 -H -r /var/run/spamd.pid system_u:system_r:spamd_t 14614 ? S 0:00 \_ spamd child system_u:system_r:spamd_t 14615 ? S 0:00 \_ spamd child # -- Ted Rule Director, Layer3 Systems Ltd W: http://www.layer3.co.uk/ From dblistsub-fedora at yahoo.it Thu Feb 22 17:48:54 2007 From: dblistsub-fedora at yahoo.it (Davide Bolcioni) Date: Thu, 22 Feb 2007 18:48:54 +0100 Subject: Posttinstall scriptlets failing ? Message-ID: <200702221848.55062.dblistsub-fedora@yahoo.it> Greeetings, I just tried the following: yum install kernel-devel.x86_64 and got Installing: kernel-devel ######################### [1/1] error: %post(kernel-devel-2.6.19-1.2911.fc6.x86_64) scriptlet failed, exit status 255 the failure seems to be related to the following in the audit log: type=AVC msg=audit(1172166288.763:92): avc: denied { transition } for pid=7023 comm="yum" name="bash" dev=dm-1 ino=409636 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:rpm_script_t:s0-s0:c0.c1023 tclass=process type=SYSCALL msg=audit(1172166288.763:92): arch=c000003e syscall=59 success=no exit=-13 a0=3b5afef a1=7fff58604730 a2=4112960 a3=5f74c70 items=0 ppid=6779 pid=7023 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="yum" exe="/usr/bin/python" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) type=AVC_PATH msg=audit(1172166288.763:92): path="/bin/bash" which I understand being a failure to exec() bash, correct ? Apparently, yum is running as system_u:system_r:xdm_t, which I find somewhat surprising, but still. Thank you for your consideration, Davide Bolcioni -- There is no place like /home. From dwalsh at redhat.com Thu Feb 22 18:35:44 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 22 Feb 2007 13:35:44 -0500 Subject: SpamAssassin Log explosion issue following update In-Reply-To: <1172158070.14619.85.camel@topaz.bugfinder.co.uk> References: <1172158070.14619.85.camel@topaz.bugfinder.co.uk> Message-ID: <45DDE280.6040902@redhat.com> Ted Rule wrote: > I recently updated SpamAssassin on my FC6/strict box to > spamassassin-3.1.8-2.fc6. > > FWIW, the selinux-policy is currently on > selinux-policy-strict-2.4.6-37.fc6 > > It seems that the installation may well have partially failed because > I ran "yum update spamassassin" whilst still in enforcing mode. > > I erroneously assumed that spamd continued to run Ok, as I saw no error > messages during the "yum update". > > Sadly, to my horror earlier today, I found that the /var partition was > completely full of log messages from SELinux/spamd, viz: > > ... > Feb 22 12:08:25 topaz kernel: audit(1172146105.931:9462050): avc: > denied { search } for pid=10329 comm="spamd" name="/" dev=hda2 ino=2 > scontext=system_u:object_r:unlabeled_t:s0 > tcontext=system_u:object_r:root_t:s0 tclass=dir > Feb 22 12:08:25 topaz kernel: audit(1172146105.932:9462051): avc: > denied { search } for pid=10329 comm="spamd" name="/" dev=hda2 ino=2 > scontext=system_u:object_r:unlabeled_t:s0 > tcontext=system_u:object_r:root_t:s0 tclass=dir > Feb 22 12:08:25 topaz kernel: audit(1172146105.932:9462052): avc: > denied { search } for pid=10329 comm="spamd" name="/" dev=hda2 ino=2 > scontext=system_u:object_r:unlabeled_t:s0 > tcontext=system_u:object_r:root_t:s0 tclass=dir > Feb 22 12:08:25 topaz kernel: audit(1172146105.932:9462053): avc: > denied { search } for pid=10329 comm="spamd" name="/" dev=hda2 ino=2 > scontext=system_u:object_r:unlabeled_t:s0 > tcontext=system_u:object_r:root_t:s0 tclass=dir > .... > > In other words, for some reason the "broken" update left the process > running in the unlabeled_t domain, which is a little bizarre. > > In any event, I then got a continuous stream of these denials in the log > which eventually filled the log within a few hours. > > Note to self: presumably using auditd instead of syslog-ng for storing > these messages would have avoided the filesystem overload. Similarly, I > have yet to check the manual pages for syslog-ng for a max-logfile-size > option which might have avoided the ensuing embarrassment. > > After clearing out the massive log files to give spamd and syslog-ng > room to manoeuvre, I then tried looking for the spamd[10329] in the > process list, but found that it was invisible(!), presumably because it > was running as unlabeled_t. > > I then tried temporarily enabling the "allow_ptrace" boolean to see if > that helped make the process visible, to no avail. > > Finally, I was forced to drop into permissive mode to locate the rogue > PID running in "unlabeled_t". > > So then I stopped spamd, went back to enforcing mode, and restarted > spamd, which duly ran in its proper spamd_t domain. > > >From previous experiences I think the strict policy, and perhaps the > targeted policy also, is missing several permissions which allow various > init scripts to be called from within "yum update". > > > To satisfy my own curiousity, can someone explain how spamd ended up > running in unlabeled_t? Is it somehow related to a process continuing to > run which has no corresponding executable binary? > > > > Following this experience, can I make some suggestions: > > a. Please test that rpm/yum update runs without error for any RPM update > on both a strict/enforcing box and a targeted/enforcing box before the > RPM is released to mirrors. > > I have no idea what caused this. The usually example would be that your program spamd was running in a context that was removed from the system. So say you had it running in a local policy myspamd_t and then you removed the policy, it would end up in unlabeled_t. Nothing in this update should have caused this. > b. Don't expect that yum update can be run in enforcing mode, especially > on packages associated with running daemons. > > It should be able to run in enforcing mode. The only thing I am aware of where this has been a problem was in MLS machines where you have to run run_init yum -y upgrade. > c. Please can we add a policy permission so that sysadm_t can seek and > destroy unlabeled_t processes with extreme prejudice without recourse to > permissive mode? > > > I agree this policy will be added. > > Ted > > > > > # ps axf | grep 103 > 14549 pts/1 S+ 0:00 \_ grep 103 > # setsebool allow_ptrace=1 > # getsebool -a| grep ptrace > allow_ptrace --> on > # ps axf | grep 103 > 14561 pts/1 S+ 0:00 \_ grep 103 > > # setenforce 0 > # ps axf | grep 103 > 10329 ? Ss 12:44 /usr/bin/spamd -d -c -m5 -H > -r /var/run/spamd.pid > 10331 ? Z 1:23 \_ [spamd] > 10332 ? Z 0:06 \_ [spamd] > 14564 pts/1 S+ 0:00 \_ grep 103 > # ps axfZ | grep 103 > system_u:object_r:unlabeled_t 10329 ? Ss > 12:44 /usr/bin/spamd -d -c -m5 -H -r /var/run/spamd.pid > system_u:object_r:unlabeled_t 10331 ? Z 1:23 \_ [spamd] > > system_u:object_r:unlabeled_t 10332 ? Z 0:06 \_ [spamd] > > staff_u:sysadm_r:sysadm_t 14566 pts/1 S+ 0:00 > \_ grep 103 > # setenforce 1 > # ps axfZ | grep 103 > staff_u:sysadm_r:sysadm_t 14569 pts/1 S+ 0:00 > \_ grep 103 > > # setenforce 0 > # run_init service spamassassin stop > Authenticating root. > Password: > Stopping spamd: [ OK ] > # ps axf | grep spam > 14591 pts/1 S+ 0:00 \_ grep spam > > # setenforce 1 > # run_init service spamassassin start > Authenticating root. > Password: > Starting spamd: [ OK ] > # ps axfZ | grep spam > staff_u:sysadm_r:sysadm_t 14617 pts/1 S+ 0:00 > \_ grep spam > system_u:system_r:spamd_t 14612 ? Ss > 0:01 /usr/bin/spamd -d -c -m5 -H -r /var/run/spamd.pid > system_u:system_r:spamd_t 14614 ? S 0:00 \_ spamd > child > system_u:system_r:spamd_t 14615 ? S 0:00 \_ spamd > child > # > > > > From dwalsh at redhat.com Thu Feb 22 18:56:03 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 22 Feb 2007 13:56:03 -0500 Subject: Posttinstall scriptlets failing ? In-Reply-To: <200702221848.55062.dblistsub-fedora@yahoo.it> References: <200702221848.55062.dblistsub-fedora@yahoo.it> Message-ID: <45DDE743.3080505@redhat.com> Davide Bolcioni wrote: > Greeetings, > I just tried the following: > > yum install kernel-devel.x86_64 > > and got > > Installing: kernel-devel ######################### [1/1] > error: %post(kernel-devel-2.6.19-1.2911.fc6.x86_64) scriptlet failed, exit > status 255 > > the failure seems to be related to the following in the audit log: > > type=AVC msg=audit(1172166288.763:92): avc: denied { transition } for > pid=7023 comm="yum" name="bash" dev=dm-1 ino=409636 > scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 > tcontext=system_u:system_r:rpm_script_t:s0-s0:c0.c1023 tclass=process > type=SYSCALL msg=audit(1172166288.763:92): arch=c000003e syscall=59 success=no > exit=-13 a0=3b5afef a1=7fff58604730 a2=4112960 a3=5f74c70 items=0 ppid=6779 > pid=7023 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 > tty=pts0 comm="yum" exe="/usr/bin/python" > subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) > type=AVC_PATH msg=audit(1172166288.763:92): path="/bin/bash" > > which I understand being a failure to exec() bash, correct ? > > Apparently, yum is running as system_u:system_r:xdm_t, which I find somewhat > surprising, but still. > > Thank you for your consideration, > Davide Bolcioni > There is a problem in the latest version of pam_selinux that is causing this problem. You can either revert to the previous version of pam or wait for the next update. From ejtr at layer3.co.uk Fri Feb 23 09:16:55 2007 From: ejtr at layer3.co.uk (Ted Rule) Date: Fri, 23 Feb 2007 09:16:55 +0000 Subject: SpamAssassin Log explosion issue following update In-Reply-To: <45DDE280.6040902@redhat.com> References: <1172158070.14619.85.camel@topaz.bugfinder.co.uk> <45DDE280.6040902@redhat.com> Message-ID: <1172222216.3537.23.camel@topaz.bugfinder.co.uk> I've had another dig through the remnants of logs following yesterday's log explosion. Fortunately, I hadn't completely eliminated the log history of the crash. It seems that Dan is quite right in saying that the RPM Upgrade didn't cause the issue. The logs show that it all started when I amended my localanacron policy some 2 minutes before the log explosion started. I see these two entries: ... Feb 22 11:19:10 topaz kernel: security: invalidating context staff_u:sysadm_r:initrc_t:s0 Feb 22 11:19:10 topaz kernel: security: invalidating context staff_u:system_r:spamd_t:s0 ... All I had done was to add these lines to localanacron.te, (part of debugging another issue arising out of running anacron instead of crond), increment the module version number, run "make localanacron.pp" and then "semodule -u localanacron.pp": ... # Odd setfscreate message when using Anacron but apparently not when using Crond #Feb 21 08:47:59 topaz kernel: audit(1172047679.147:93): avc: denied { setfscreate } for pid=5340 comm="cp" scontext=system_u:system_r:system_crond_t:s0 tcontext=system_u:system_r:system_crond_t:s0 tclass=process allow system_crond_t self:process setfscreate; # Attempt to debug the problem auditallow { crond_t system_crond_t } self:process setfscreate; ... Just for luck, I checked that the devel environment has the same version number as the overall policy: [root at topaz selinux.local]# rpm -q selinux-policy-strict selinux-policy-strict-2.4.6-37.fc6 [root at topaz selinux.local]# rpm -qf /usr/share/selinux/devel/Makefile selinux-policy-devel-2.4.6-37.fc6 [root at topaz selinux.local]# Presumably, there's something amiss with the way I'm adding local patches to the policy which is causing SELinux to invalidate contexts during a local module upgrade. None of my patches directly overwrite any of the default .pp modules; I try to use localxxxxxx.pp to tweak xxxxxx.pp policy. Some of my modules do admittedly add types, as well as refining file-labelling and overall policy. Is perhaps the problem related to the way RPM update to policy itself is performed? Maybe I should be following this general method instead of a plain yum update?? # semodule -r localxxxxxx.pp # yum update selinux-policy-strict # semodule -i localxxxxxx.pp .... Feb 22 11:15:43 topaz kernel: audit(1172142943.430:470): avc: denied { write } for pid=14039 comm="su" name="root" dev=hda2 ino=2 58817 scontext=staff_u:sysadm_r:sysadm_su_t:s0 tcontext=root:object_r:sysadm_home_dir_t:s0 tclass=dir Feb 22 11:18:31 topaz syslog-ng[2517]: STATS: dropped 0 Feb 22 11:19:10 topaz kernel: security: 5 users, 5 roles, 2081 types, 87 bools, 1 sens, 1024 cats Feb 22 11:19:10 topaz kernel: security: 59 classes, 158274 rules Feb 22 11:19:10 topaz kernel: security: invalidating context staff_u:sysadm_r:initrc_t:s0 Feb 22 11:19:10 topaz kernel: security: invalidating context staff_u:system_r:spamd_t:s0 Feb 22 11:19:10 topaz dbus: Can't send to audit system: USER_AVC avc: received policyload notice (seqno=2) : exe="?" (sauid=81, hos tname=?, addr=?, terminal=?) Feb 22 11:19:10 topaz dbus: Can't send to audit system: USER_AVC avc: received policyload notice (seqno=2) : exe="/bin/dbus-daemon" (sauid=500, hostname=?, addr=?, terminal=?) Feb 22 11:19:10 topaz kernel: audit(1172143150.903:471): policy loaded auid=4294967295 Feb 22 11:21:19 topaz kernel: 29 comm="spamd" name="/" dev=hda2 ino=2 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:ob ject_r:root_t:s0 tclass=dir Feb 22 11:21:19 topaz kernel: audit(1172143279.378:42740): avc: denied { search } for pid=10329 comm="spamd" name="/" dev=hda2 in o=2 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir Feb 22 11:21:19 topaz kernel: audit(1172143279.378:42741): avc: denied { search } for pid=10329 comm="spamd" name="/" dev=hda2 in o=2 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir Feb 22 11:21:19 topaz kernel: audit(1172143279.378:42742): avc: denied { search } for pid=10329 comm="spamd" name="/" dev=hda2 in o=2 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir ... [root at topaz ~]# ls -lrt selinux.local/*.pp -rw-r--r-- 1 root root 22394 Jan 17 19:52 selinux.local/localsysadm.pp -rw-r--r-- 1 root root 21743 Jan 26 17:21 selinux.local/localsudo.pp -rw-r--r-- 1 root root 24145 Feb 1 14:18 selinux.local/localjava.pp -rw-r--r-- 1 root root 370766 Feb 7 17:17 selinux.local/myevolution.pp -rw-r--r-- 1 root root 29649 Feb 17 18:25 selinux.local/localfirefox.pp -rw-r--r-- 1 root root 36556 Feb 17 18:25 selinux.local/localevolution.pp -rw-r--r-- 1 root root 35652 Feb 19 10:11 selinux.local/localmiscpolicy.pp -rw-r--r-- 1 root root 36000 Feb 22 11:18 selinux.local/localanacron.pp [root at topaz ~]# -- Ted Rule Director, Layer3 Systems Ltd W: http://www.layer3.co.uk/ From sds at tycho.nsa.gov Fri Feb 23 12:50:21 2007 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 23 Feb 2007 07:50:21 -0500 Subject: Posttinstall scriptlets failing ? In-Reply-To: <45DDE743.3080505@redhat.com> References: <200702221848.55062.dblistsub-fedora@yahoo.it> <45DDE743.3080505@redhat.com> Message-ID: <1172235021.19041.1.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2007-02-22 at 13:56 -0500, Daniel J Walsh wrote: > Davide Bolcioni wrote: > > Greeetings, > > I just tried the following: > > > > yum install kernel-devel.x86_64 > > > > and got > > > > Installing: kernel-devel ######################### [1/1] > > error: %post(kernel-devel-2.6.19-1.2911.fc6.x86_64) scriptlet failed, exit > > status 255 > > > > the failure seems to be related to the following in the audit log: > > > > type=AVC msg=audit(1172166288.763:92): avc: denied { transition } for > > pid=7023 comm="yum" name="bash" dev=dm-1 ino=409636 > > scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 > > tcontext=system_u:system_r:rpm_script_t:s0-s0:c0.c1023 tclass=process > > type=SYSCALL msg=audit(1172166288.763:92): arch=c000003e syscall=59 success=no > > exit=-13 a0=3b5afef a1=7fff58604730 a2=4112960 a3=5f74c70 items=0 ppid=6779 > > pid=7023 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 > > tty=pts0 comm="yum" exe="/usr/bin/python" > > subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) > > type=AVC_PATH msg=audit(1172166288.763:92): path="/bin/bash" > > > > which I understand being a failure to exec() bash, correct ? > > > > Apparently, yum is running as system_u:system_r:xdm_t, which I find somewhat > > surprising, but still. > > > > Thank you for your consideration, > > Davide Bolcioni > > > > There is a problem in the latest version of pam_selinux that is causing > this problem. > > You can either revert to the previous version of pam or wait for the > next update. gdm at least doesn't use pam_selinux AFAICS, so it wouldn't be affected by the pam_selinux bug. If you log out and log back in, is your session still running in xdm_t? That is definitely wrong. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Fri Feb 23 13:10:09 2007 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 23 Feb 2007 08:10:09 -0500 Subject: SpamAssassin Log explosion issue following update In-Reply-To: <1172222216.3537.23.camel@topaz.bugfinder.co.uk> References: <1172158070.14619.85.camel@topaz.bugfinder.co.uk> <45DDE280.6040902@redhat.com> <1172222216.3537.23.camel@topaz.bugfinder.co.uk> Message-ID: <1172236210.19041.8.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2007-02-23 at 09:16 +0000, Ted Rule wrote: > I've had another dig through the remnants of logs following yesterday's > log explosion. Fortunately, I hadn't completely eliminated the log > history of the crash. > > It seems that Dan is quite right in saying that the RPM Upgrade didn't > cause the issue. The logs show that it all started when I amended my > localanacron policy some 2 minutes before the log explosion started. > > I see these two entries: > > ... > Feb 22 11:19:10 topaz kernel: security: invalidating context > staff_u:sysadm_r:initrc_t:s0 > Feb 22 11:19:10 topaz kernel: security: invalidating context > staff_u:system_r:spamd_t:s0 This means that at an earlier point in time, while permissive, the system executed an init script and spamd and performed automatic domain transitions even though the resulting contexts weren't legal under policy (allowed when permissive) due to invalid combinations of role/type or user/role (e.g. initrc_t should be in system_r, not sysadm_r, and likely staff_u isn't authorized for system_r?). Then later you reloaded policy while enforcing, and the system invalidated those contexts and remapped them to unlabeled. run_init explicitly transitions to system_u:system_r:initrc_t for running init scripts. The role transition can be done automatically via policy (role_transition statements), but we don't presently have support for automatic user transitions in policy. -- Stephen Smalley National Security Agency From ejtr at layer3.co.uk Fri Feb 23 13:41:59 2007 From: ejtr at layer3.co.uk (Ted Rule) Date: Fri, 23 Feb 2007 13:41:59 +0000 Subject: SpamAssassin Log explosion issue following update In-Reply-To: <1172236210.19041.8.camel@moss-spartans.epoch.ncsc.mil> References: <1172158070.14619.85.camel@topaz.bugfinder.co.uk> <45DDE280.6040902@redhat.com> <1172222216.3537.23.camel@topaz.bugfinder.co.uk> <1172236210.19041.8.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1172238119.3462.21.camel@topaz.bugfinder.co.uk> Ah. So does that mean my current method for getting sysadm_t status is flawed? At the moment I login as staff_u, newrole into sysadm_r, and thence "su -" to sysadm_t. This leaves me in "staff_u:sysadm_r:sysadm_t", whereupon run_init seems to be perfectly capable of running init scripts whilst in enforcing mode. Perhaps the root of my problem is that I ran "yum update" whilst in permissive starting from "staff_u:sysadm_r:sysadm_t", but the policy failed to transition to system_u when some of the rpm postinstall scripts ran /etc/init.d/xxxxx? On Fri, 2007-02-23 at 08:10 -0500, Stephen Smalley wrote: > On Fri, 2007-02-23 at 09:16 +0000, Ted Rule wrote: > > I've had another dig through the remnants of logs following yesterday's > > log explosion. Fortunately, I hadn't completely eliminated the log > > history of the crash. > > > > It seems that Dan is quite right in saying that the RPM Upgrade didn't > > cause the issue. The logs show that it all started when I amended my > > localanacron policy some 2 minutes before the log explosion started. > > > > I see these two entries: > > > > ... > > Feb 22 11:19:10 topaz kernel: security: invalidating context > > staff_u:sysadm_r:initrc_t:s0 > > Feb 22 11:19:10 topaz kernel: security: invalidating context > > staff_u:system_r:spamd_t:s0 > > This means that at an earlier point in time, while permissive, the > system executed an init script and spamd and performed automatic domain > transitions even though the resulting contexts weren't legal under > policy (allowed when permissive) due to invalid combinations of > role/type or user/role (e.g. initrc_t should be in system_r, not > sysadm_r, and likely staff_u isn't authorized for system_r?). Then > later you reloaded policy while enforcing, and the system invalidated > those contexts and remapped them to unlabeled. > > run_init explicitly transitions to system_u:system_r:initrc_t for > running init scripts. The role transition can be done automatically via > policy (role_transition statements), but we don't presently have support > for automatic user transitions in policy. -- Ted Rule Director, Layer3 Systems Ltd W: http://www.layer3.co.uk/ From sds at tycho.nsa.gov Fri Feb 23 14:40:22 2007 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 23 Feb 2007 09:40:22 -0500 Subject: Posttinstall scriptlets failing ? In-Reply-To: <200702231533.33139.dblistsub-fedora@yahoo.it> References: <200702221848.55062.dblistsub-fedora@yahoo.it> <45DDE743.3080505@redhat.com> <1172235021.19041.1.camel@moss-spartans.epoch.ncsc.mil> <200702231533.33139.dblistsub-fedora@yahoo.it> Message-ID: <1172241622.19041.44.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2007-02-23 at 15:33 +0100, Davide Bolcioni wrote: > On Friday 23 February 2007 13:50:21 you wrote: > > On Thu, 2007-02-22 at 13:56 -0500, Daniel J Walsh wrote: > > > Davide Bolcioni wrote: > > > > Greeetings, > > > > I just tried the following: > > > > > > > > yum install kernel-devel.x86_64 > > > > > > > > and got > > > > > > > > Installing: kernel-devel ######################### > > > > [1/1] error: %post(kernel-devel-2.6.19-1.2911.fc6.x86_64) scriptlet > > > > failed, exit status 255 > > > > > > > > the failure seems to be related to the following in the audit log: > > > > > > > > type=AVC msg=audit(1172166288.763:92): avc: denied { transition } for > > > > pid=7023 comm="yum" name="bash" dev=dm-1 ino=409636 > > > > scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 > > > > tcontext=system_u:system_r:rpm_script_t:s0-s0:c0.c1023 tclass=process > > > > type=SYSCALL msg=audit(1172166288.763:92): arch=c000003e syscall=59 > > > > success=no exit=-13 a0=3b5afef a1=7fff58604730 a2=4112960 a3=5f74c70 > > > > items=0 ppid=6779 pid=7023 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 > > > > egid=0 sgid=0 fsgid=0 tty=pts0 comm="yum" exe="/usr/bin/python" > > > > subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) > > > > type=AVC_PATH msg=audit(1172166288.763:92): path="/bin/bash" > > > > > > > > which I understand being a failure to exec() bash, correct ? > > > > > > > > Apparently, yum is running as system_u:system_r:xdm_t, which I find > > > > somewhat surprising, but still. > > > > > > > > Thank you for your consideration, > > > > Davide Bolcioni > > > > > > There is a problem in the latest version of pam_selinux that is causing > > > this problem. > > > > > > You can either revert to the previous version of pam or wait for the > > > next update. > > > > gdm at least doesn't use pam_selinux AFAICS, so it wouldn't be affected > > by the pam_selinux bug. > > > > If you log out and log back in, is your session still running in xdm_t? > > That is definitely wrong. > > I am using kdm, which definitely includes pam_selinux.so in /etc/pam.d/kdm. > Why doesn't gdm use pam_selinux ? IIRC the point of PAM was to separate > authentication, was it ? gdm has direct selinux support integrated into it. IIRC, we tried using pam_selinux with it but it performs the pam_open_session() from a different process than the one that ultimately exec's the user shell, so it didn't work. pam_selinux isn't authentication; it is setting the security context for the user shell. Whether or not it belongs in pam is open to debate, e.g. setting of the uid for the shell doesn't happen in pam either. -- Stephen Smalley National Security Agency From joe at nall.com Fri Feb 23 19:50:54 2007 From: joe at nall.com (Joe Nall) Date: Fri, 23 Feb 2007 13:50:54 -0600 Subject: login role transition failing on mls livecd Message-ID: <6BB851EF-2F45-4093-9642-2080F98AF843@nall.com> I've been working on a fedora livecd that runs the mls policy. When I login as root via ssh [root at livecd ~]# id -Z root:staff_r:staff_t:SystemLow-SystemHigh but if I login via the console [root at livecd ~]# id -Z system_u:system_r:local_login_t:SystemLow-SystemHigh I'm not transitioning into the correct role/type on a console login. Any pointers on where to look/what I forgot to create would be appreciated. joe ls -Z `tty` crw--w---- root tty system_u:object_r:tty_device_t:SystemLow /dev/tty4 Audit from a login local login: type=USER_AUTH msg=audit(1172236367.222:134): user pid=2395 uid=0 auid=4294967295 subj=system_u:system_r:local_login_t:s0-s15:c0.c1023 msg='PAM: authentication acct=root : exe="/bin/login" (hostname=?, addr=?, terminal=tty1 res=success)' type=USER_ACCT msg=audit(1172236367.222:135): user pid=2395 uid=0 auid=4294967295 subj=system_u:system_r:local_login_t:s0-s15:c0.c1023 msg='PAM: accounting acct=root : exe="/bin/login" (hostname=?, addr=?, terminal=tty1 res=success)' type=LOGIN msg=audit(1172236367.228:136): login pid=2395 uid=0 old auid=4294967295 new auid=0 type=USER_ROLE_CHANGE msg=audit(1172236367.246:137): user pid=2395 uid=0 auid=0 subj=system_u:system_r:local_login_t:s0-s15:c0.c1023 msg='pam: default-context=root:sysadm_r:sysadm_t:s0-s15:c0.c1023 selected-context=?: exe="/bin/login" (hostname=?, addr=?, terminal=tty1 res=success)' type=USER_START msg=audit(1172236367.246:138): user pid=2395 uid=0 auid=0 subj=system_u:system_r:local_login_t:s0-s15:c0.c1023 msg='PAM: session open acct=root : exe="/bin/login" (hostname=?, addr=?, terminal=tty1 res=success)' type=USER_LOGIN msg=audit(1172236367.248:140): user pid=2395 uid=0 auid=0 subj=system_u:system_r:local_login_t:s0-s15:c0.c1023 msg='uid=0: exe="/bin/login" (hostname=?, addr=?, terminal=tty1 res=success)'type=AVC msg=audit(1172236367.248:141): avc: denied { execute_no_trans } for pid=2401 comm="login" name="bash" dev=dm-0 ino=32771 scontext=system_u:system_r:local_login_t:s0-s15:c0.c1023 tcontext=system_u:object_r:shell_exec_t:s0 tclass=filetype=SYSCALL msg=audit(1172236367.248:141): arch=40000003 syscall=11 success=yes exit=0 a0=91d56d0 a1=bfde41c0 a2=91d7978 a3=804d2e8 items=0 ppid=2395 pid=2401 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty1 comm="bash" exe="/bin/bash" subj=system_u:system_r:local_login_t:s0-s15:c0.c1023 key=(null) type=AVC_PATH msg=audit(1172236367.248:141): path="/bin/bash" type=AVC msg=audit(1172236367.301:142): avc: denied { execute } for pid=2411 comm="bash" name="hostname" dev=dm-0 ino=32832 scontext=system_u:system_r:local_login_t:s0-s15:c0.c1023 tcontext=system_u:object_r:hostname_exec_t:s0 tclass=file type=AVC msg=audit(1172236367.301:142): avc: denied { execute_no_trans } for pid=2411 comm="bash" name="hostname" dev=dm-0 ino=32832 scontext=system_u:system_r:local_login_t:s0- s15:c0.c1023 tcontext=system_u:object_r:hostname_exec_t:s0 tclass=file sestatus -v SELinux status: enabled SELinuxfs mount: /selinux Current mode: permissive Mode from config file: permissive Policy version: 21 Policy from config file: mls Process contexts: Current context: system_u:system_r:local_login_t:SystemLow-SystemHigh Init context: system_u:system_r:init_t:SystemLow- SystemHigh /sbin/mingetty system_u:system_r:getty_t:SystemLow- SystemHigh /usr/sbin/sshd system_u:system_r:sshd_t:SystemLow- SystemHigh File contexts: Controlling term: system_u:object_r:tty_device_t:SystemLow /etc/passwd system_u:object_r:etc_t:SystemLow /etc/shadow system_u:object_r:shadow_t:SystemLow /bin/bash system_u:object_r:shell_exec_t:SystemLow /bin/login system_u:object_r:login_exec_t:SystemLow /bin/sh system_u:object_r:bin_t:SystemLow -> system_u:object_r:shell_exec_t:SystemLow /sbin/agetty system_u:object_r:getty_exec_t:SystemLow /sbin/init system_u:object_r:init_exec_t:SystemLow /sbin/mingetty system_u:object_r:getty_exec_t:SystemLow /usr/sbin/sshd system_u:object_r:sshd_exec_t:SystemLow /lib/libc.so.6 system_u:object_r:lib_t:SystemLow -> system_u:object_r:shlib_t:SystemLow /lib/ld-linux.so.2 system_u:object_r:lib_t:SystemLow -> system_u:object_r:ld_so_t:SystemLow From sds at tycho.nsa.gov Fri Feb 23 19:49:27 2007 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 23 Feb 2007 14:49:27 -0500 Subject: login role transition failing on mls livecd In-Reply-To: <6BB851EF-2F45-4093-9642-2080F98AF843@nall.com> References: <6BB851EF-2F45-4093-9642-2080F98AF843@nall.com> Message-ID: <1172260167.19041.108.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2007-02-23 at 13:50 -0600, Joe Nall wrote: > I've been working on a fedora livecd that runs the mls policy. When I > login as root via ssh > > [root at livecd ~]# id -Z > root:staff_r:staff_t:SystemLow-SystemHigh > > but if I login via the console > > [root at livecd ~]# id -Z > system_u:system_r:local_login_t:SystemLow-SystemHigh > > I'm not transitioning into the correct role/type on a console login. > Any pointers on where to look/what I forgot to create would be > appreciated. Bug in pam_selinux - look for an update in rawhide and fc6. Only affects logins that use pam_selinux, so ssh and gdm are ok. -- Stephen Smalley National Security Agency From joe at nall.com Fri Feb 23 21:29:19 2007 From: joe at nall.com (Joe Nall) Date: Fri, 23 Feb 2007 15:29:19 -0600 Subject: login role transition failing on mls livecd In-Reply-To: <1172260167.19041.108.camel@moss-spartans.epoch.ncsc.mil> References: <6BB851EF-2F45-4093-9642-2080F98AF843@nall.com> <1172260167.19041.108.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4470A144-B3EC-4B53-BF14-7CBF766BF123@nall.com> On Feb 23, 2007, at 1:49 PM, Stephen Smalley wrote: >> I'm not transitioning into the correct role/type on a console login. >> Any pointers on where to look/what I forgot to create would be >> appreciated. > > Bug in pam_selinux - look for an update in rawhide and fc6. > Only affects logins that use pam_selinux, so ssh and gdm are ok. That was it. Thanks. joe From linux_4ever at yahoo.com Sun Feb 25 20:15:03 2007 From: linux_4ever at yahoo.com (Steve G) Date: Sun, 25 Feb 2007 12:15:03 -0800 (PST) Subject: selinux-policy-2.5.4 Message-ID: <57839.39145.qm@web51509.mail.yahoo.com> Hi, I am curious about the testing process for policy releases. Seems like everytime a new upstream policy is pulled in, we suddenly have a bunch of avcs. For the newest policy, 2.5.4, I have all these: allow avahi_t unlabeled_t : packet { recv send }; allow bluetooth_t lib_t : file execute_no_trans; allow mount_t security_t : filesystem getattr; allow postfix_local_t mail_spool_t : file append; allow postfix_local_t unlabeled_t : packet send; allow postfix_master_t security_t : filesystem getattr; allow restorecon_t security_t : filesystem getattr; allow setrans_t security_t : filesystem getattr; allow setroubleshootd_t mail_spool_t : lnk_file read; allow setroubleshootd_t security_t : filesystem getattr; allow vpnc_t security_t : filesystem getattr; allow vpnc_t unlabeled_t : packet { recv send }; These are simply from booting and connecting to the network. I haven't even tried to start X or do any serious work. -Steve ____________________________________________________________________________________ No need to miss a message. Get email on-the-go with Yahoo! Mail for Mobile. Get started. http://mobile.yahoo.com/mail From ynakam at hitachisoft.jp Mon Feb 26 00:43:12 2007 From: ynakam at hitachisoft.jp (Yuichi Nakamura) Date: Mon, 26 Feb 2007 09:43:12 +0900 Subject: [ANN] SELinux Policy Editor 2.1.0 Message-ID: <20070226094312.b1e4067a.ynakam@hitachisoft.jp> Hi, I would like to announce SELinux Policy Editor(SEEdit) 2.1.0 is released. SEEdit is a tool that makes SELinux easy. It supports Fedora Core 6 and Cent OS4. * Changes from 2.0: - Merged to Fedora Extras CVS You can get seedit more easily for Fedora! - Improved rpm package - Thanks to reviewers in Fedora bugzilla - New icons - Improved performance of policy generation tool - Created new button "guess policy" For detail please visit http://seedit.sourceforge.net/ -- Yuichi Nakamura Hitachi Software Engineering Co., Ltd. SELinux Policy Editor: http://seedit.sourceforge.net/ From casper.gasper at gmail.com Mon Feb 26 00:47:43 2007 From: casper.gasper at gmail.com (Casper Gasper) Date: Mon, 26 Feb 2007 00:47:43 +0000 Subject: SELinux stats Message-ID: <82ffac9b0702251647w3023161am4159688c9b1176be@mail.gmail.com> I'm looking for some figures on the success rate of SELinux, a count of vulnerabilities for RHEL/Fedora which are mitigated with targeted mode. I'm sure people must have done assessments on it efficacy, but so far my googling skills have failed me. thanks, Casper. From sds at tycho.nsa.gov Mon Feb 26 12:46:10 2007 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 26 Feb 2007 07:46:10 -0500 Subject: selinux-policy-2.5.4 In-Reply-To: <57839.39145.qm@web51509.mail.yahoo.com> References: <57839.39145.qm@web51509.mail.yahoo.com> Message-ID: <1172493970.19041.155.camel@moss-spartans.epoch.ncsc.mil> On Sun, 2007-02-25 at 12:15 -0800, Steve G wrote: > Hi, > > I am curious about the testing process for policy releases. Seems like everytime > a new upstream policy is pulled in, we suddenly have a bunch of avcs. For the > newest policy, 2.5.4, I have all these: > > allow avahi_t unlabeled_t : packet { recv send }; > allow bluetooth_t lib_t : file execute_no_trans; > allow mount_t security_t : filesystem getattr; > allow postfix_local_t mail_spool_t : file append; > allow postfix_local_t unlabeled_t : packet send; > allow postfix_master_t security_t : filesystem getattr; > allow restorecon_t security_t : filesystem getattr; > allow setrans_t security_t : filesystem getattr; > allow setroubleshootd_t mail_spool_t : lnk_file read; > allow setroubleshootd_t security_t : filesystem getattr; > allow vpnc_t security_t : filesystem getattr; > allow vpnc_t unlabeled_t : packet { recv send }; > > These are simply from booting and connecting to the network. I haven't even tried > to start X or do any serious work. The security_t:filesystem getattr ones would be from your libselinux patch (not yet merged, at least upstream). -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Mon Feb 26 13:21:44 2007 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 26 Feb 2007 08:21:44 -0500 Subject: selinux-policy-2.5.4 In-Reply-To: <1172493970.19041.155.camel@moss-spartans.epoch.ncsc.mil> References: <57839.39145.qm@web51509.mail.yahoo.com> <1172493970.19041.155.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1172496104.19041.177.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2007-02-26 at 07:46 -0500, Stephen Smalley wrote: > On Sun, 2007-02-25 at 12:15 -0800, Steve G wrote: > > Hi, > > > > I am curious about the testing process for policy releases. Seems like everytime > > a new upstream policy is pulled in, we suddenly have a bunch of avcs. For the > > newest policy, 2.5.4, I have all these: > > > > allow avahi_t unlabeled_t : packet { recv send }; > > allow bluetooth_t lib_t : file execute_no_trans; > > allow mount_t security_t : filesystem getattr; > > allow postfix_local_t mail_spool_t : file append; > > allow postfix_local_t unlabeled_t : packet send; > > allow postfix_master_t security_t : filesystem getattr; > > allow restorecon_t security_t : filesystem getattr; > > allow setrans_t security_t : filesystem getattr; > > allow setroubleshootd_t mail_spool_t : lnk_file read; > > allow setroubleshootd_t security_t : filesystem getattr; > > allow vpnc_t security_t : filesystem getattr; > > allow vpnc_t unlabeled_t : packet { recv send }; > > > > These are simply from booting and connecting to the network. I haven't even tried > > to start X or do any serious work. > > The security_t:filesystem getattr ones would be from your libselinux > patch (not yet merged, at least upstream). The unlabeled_t:packet { recv send } ones suggest that you have secmark enabled (w/o any iptables rules)? $ cat /selinux/compat_net -- Stephen Smalley National Security Agency From kas at fi.muni.cz Tue Feb 27 16:27:43 2007 From: kas at fi.muni.cz (Jan Kasprzak) Date: Tue, 27 Feb 2007 17:27:43 +0100 Subject: Confining TeX Message-ID: <20070227162743.GB24300@fi.muni.cz> Hello, I am implementing a remote TeX server for our users, and I would like to confine it using SELinux (FC6, targeted policy). I need help or suggestions on possible approaches. What I want to do is the following: - I have a TeX installation in a separate directory - I want local users to be able to run TeX commands without restrictions - I want to have a daemon, running under a separate user, which will handle remote requests for TeX compilation. Under this user/daemon the TeX commands should be confined, so that they can only read TeX data files (the texmf/ tree), execute the TeX sub-commands (i.e. files under /bin/ directory) - including the rights to the system libraries, locales, etc. as necessary. And the confined processes should write only to the texmf-var tree (autogenerated bitmap fonts, etc.) and to the temporary directory, reserved for TeX outputs (logs, DVI files, dvips outputs, etc.). My current solution is to create the tex_t domain, and tex_exec_t, tex_data_t, and tex_tmp_t file types, and make the daemon run "runcon -t tex_t -- tex myfile.tex" instead of plain "tex myfile.tex". Maybe there are better approaches than this: - maybe the "runcon" is not necessary, and TeX executables can be made to enter the tex_t domain automatically, when started by the UNIX user under which the daemon runs. - or maybe I should use SELinux users or roles instead of domains (?) - or maybe the daemon should run under its own special domain? The "runcon" approach allows local users to compile also untrusted TeX sources - i.e. they can be able to run TeX either under their own context, or via "runcon" in the confined mode. Any suggestions? -Yenya -- | Jan "Yenya" Kasprzak | | GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E | | http://www.fi.muni.cz/~kas/ Journal: http://www.fi.muni.cz/~kas/blog/ | > I will never go to meetings again because I think face to face meetings < > are the biggest waste of time you can ever have. --Linus Torvalds <