From jmorris at namei.org Tue Nov 1 15:57:10 2005 From: jmorris at namei.org (James Morris) Date: Tue, 1 Nov 2005 10:57:10 -0500 (EST) Subject: More MCS In-Reply-To: <1130789176.22731.197.camel@moss-spartans.epoch.ncsc.mil> References: <200510311449.15468.gene@czarc.net> <1130789176.22731.197.camel@moss-spartans.epoch.ncsc.mil> Message-ID: On Mon, 31 Oct 2005, Stephen Smalley wrote: > Looks like the MCS constraints (as defined in policy/mcs) only constrain > access to files, not directories, presently (and this is noted in a > comment in that file, so it seems to be intentional). They do appear to > work correctly for files. Use of categories on directories doesn't seem > to be supported at present under MCS. MCS is initially for files only, although it could be extended to directories if it makes sense. What does it mean to say that /tmp/foo is "Company Confidential" ? If the files under that directory are not all labeled with that category, they'll lose the MCS protection if copied or moved. I think we really want to make sure that that each file is correctly labeled under MCS and not depend on parent directories, and not have to think about label inheritance semantics. My view is that the MCS label is a security category explicitly assigned to a file, and should not change unless the user again explicitly changes it. The label itself and its meaning have no hierarchical properties. - James -- James Morris From nicolas.mailhot at laposte.net Tue Nov 1 16:46:54 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 01 Nov 2005 17:46:54 +0100 Subject: Webdav problems in enforcing mode in Raw Hide In-Reply-To: <436640DB.3080304@redhat.com> References: <1130750043.11775.7.camel@rousalka.dyndns.org> <436640DB.3080304@redhat.com> Message-ID: <1130863614.20713.57.camel@rousalka.dyndns.org> Le lundi 31 octobre 2005 ? 11:05 -0500, Daniel J Walsh a ?crit : > You need to change the context of those directories so that httpd can > read/write them > > chcon -R -t httpd_sys_script_rw_t /var/lib/dav Test shows this work. Thank you Joe Orton wrote in the bugzilla entry to add /var/lib/dav do the default policy and let admins manage the contents of /srv themselves. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From sds at tycho.nsa.gov Tue Nov 1 19:13:46 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 01 Nov 2005 14:13:46 -0500 Subject: More MCS In-Reply-To: References: <200510311449.15468.gene@czarc.net> <1130789176.22731.197.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1130872426.22731.263.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-11-01 at 10:57 -0500, James Morris wrote: > MCS is initially for files only, although it could be extended to > directories if it makes sense. > > What does it mean to say that /tmp/foo is "Company Confidential" ? If the > files under that directory are not all labeled with that category, they'll > lose the MCS protection if copied or moved. I think we really want to > make sure that that each file is correctly labeled under MCS and not > depend on parent directories, and not have to think about label > inheritance semantics. > > My view is that the MCS label is a security category explicitly assigned > to a file, and should not change unless the user again explicitly changes > it. The label itself and its meaning have no hierarchical properties. I understand this POV, but I'm not sure it will translate well to how people want to apply protection to their data. On the other hand, directory hierarchy-based protection often doesn't map well to the desired security properties either, and does leave one open to aliasing (via hard links or bind mounts) as well as relocation. In any event, we might want to generalize the mls_compute_sid logic to support either case, driven by the configuration, so that we can later support such directory-based inheritance for MCS if desired without having to patch the SELinux module. -- Stephen Smalley National Security Agency From dragoran at feuerpokemon.de Wed Nov 2 11:31:28 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Wed, 02 Nov 2005 12:31:28 +0100 Subject: FC4 + targetpolicy+samba + cdrom Message-ID: <4368A390.90307@feuerpokemon.de> hi the selinux-targeted-policy in fc4 prevents samba from sharing a dvd drive. I had to disable selinux protection for samba to get this to work. Should I fill this in bugzilla? From paul at city-fan.org Wed Nov 2 11:37:22 2005 From: paul at city-fan.org (Paul Howarth) Date: Wed, 02 Nov 2005 11:37:22 +0000 Subject: FC4 + targetpolicy+samba + cdrom In-Reply-To: <4368A390.90307@feuerpokemon.de> References: <4368A390.90307@feuerpokemon.de> Message-ID: <1130931443.3668.172.camel@laurel.intra.city-fan.org> On Wed, 2005-11-02 at 12:31 +0100, dragoran wrote: > the selinux-targeted-policy in fc4 prevents samba from sharing a dvd drive. > I had to disable selinux protection for samba to get this to work. > Should I fill this in bugzilla? Try mounting the dvd using the mount option "fscontext=system_u:object_r:samba_share_t" Paul. -- Paul Howarth From dragoran at feuerpokemon.de Thu Nov 3 08:56:27 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Thu, 03 Nov 2005 09:56:27 +0100 Subject: sharing other filesystems using samba Message-ID: <4369D0BB.8040809@feuerpokemon.de> Why does the selinux-targeted-policy does not allow samba to share mounted volumes? like CD/DVD or FAT/NTFS volumes? From jorton at redhat.com Thu Nov 3 09:52:09 2005 From: jorton at redhat.com (Joe Orton) Date: Thu, 3 Nov 2005 09:52:09 +0000 Subject: libselinux question for httpd Message-ID: <20051103095209.GA25421@redhat.com> Is there is a simple libselinux call I can make in httpd to determine whether or not the SELinux policy is enabled and applied? I'd like to add a one-line notice to the default error_log when it is, to give an obvious tip-off to confused new users. joe From jorton at redhat.com Thu Nov 3 10:15:29 2005 From: jorton at redhat.com (Joe Orton) Date: Thu, 3 Nov 2005 10:15:29 +0000 Subject: applying SELinux policy for httpd Message-ID: <20051103101529.GB25421@redhat.com> I'd also like to mention again that the new FC4 policy of only applying SELinux policy if httpd is started from the init script is confusing the hell out of people. It breaks the principle of least astonishment. I'd much rather live with the fact that SELinux policy is *always* applied, and the fallout from that, than see this confusion of people hitting SELinux policy issues, get confused, restart httpd, see them disappear, etc. I'd really like to see this change reverted for FC5. joe From russell at coker.com.au Thu Nov 3 13:11:50 2005 From: russell at coker.com.au (Russell Coker) Date: Fri, 4 Nov 2005 00:11:50 +1100 Subject: applying SELinux policy for httpd In-Reply-To: <20051103101529.GB25421@redhat.com> References: <20051103101529.GB25421@redhat.com> Message-ID: <200511040011.57196.russell@coker.com.au> On Thursday 03 November 2005 21:15, Joe Orton wrote: > I'd also like to mention again that the new FC4 policy of only applying > SELinux policy if httpd is started from the init script is confusing the > hell out of people. It breaks the principle of least astonishment. I'd > much rather live with the fact that SELinux policy is *always* applied, > and the fallout from that, than see this confusion of people hitting > SELinux policy issues, get confused, restart httpd, see them disappear, > etc. That would be a bug not a feature. I've tried to reproduce your problem but I can't. I installed a FC4 machine and updated it to selinux-policy-targeted-1.27.1-2.11 and kernel-2.6.13-1.1532_FC4. I tried both with and without httpd_disable_trans set, in both cases the same domain was used for the httpd regardless of whether it was started by system boot scripts or the administrator. Tell me more details about your problem and I'll try to reproduce it. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From jorton at redhat.com Thu Nov 3 13:33:30 2005 From: jorton at redhat.com (Joe Orton) Date: Thu, 3 Nov 2005 13:33:30 +0000 Subject: applying SELinux policy for httpd In-Reply-To: <200511040011.57196.russell@coker.com.au> References: <20051103101529.GB25421@redhat.com> <200511040011.57196.russell@coker.com.au> Message-ID: <20051103133330.GA29022@redhat.com> On Fri, Nov 04, 2005 at 12:11:50AM +1100, Russell Coker wrote: > On Thursday 03 November 2005 21:15, Joe Orton wrote: > > I'd also like to mention again that the new FC4 policy of only applying > > SELinux policy if httpd is started from the init script is confusing the > > hell out of people. It breaks the principle of least astonishment. I'd > > much rather live with the fact that SELinux policy is *always* applied, > > and the fallout from that, than see this confusion of people hitting > > SELinux policy issues, get confused, restart httpd, see them disappear, > > etc. > > That would be a bug not a feature. > > I've tried to reproduce your problem but I can't. I installed a FC4 machine > and updated it to selinux-policy-targeted-1.27.1-2.11 and > kernel-2.6.13-1.1532_FC4. I tried both with and without httpd_disable_trans > set, in both cases the same domain was used for the httpd regardless of > whether it was started by system boot scripts or the administrator. [root at jolt ~]# service httpd start Starting httpd: [ OK ] [root at jolt ~]# ps -Z -C httpd LABEL PID TTY TIME CMD root:system_r:httpd_t 4027 ? 00:00:00 httpd root:system_r:httpd_t 4029 ? 00:00:00 httpd ... [root at jolt ~]# service httpd stop Stopping httpd: [ OK ] [root at jolt ~]# httpd -k start [root at jolt ~]# ps -Z -C httpd LABEL PID TTY TIME CMD root:system_r:unconfined_t 4059 ? 00:00:00 httpd root:system_r:unconfined_t 4060 ? 00:00:00 httpd root:system_r:unconfined_t 4061 ? 00:00:00 httpd ... [root at jolt ~]# rpm -q httpd fedora-release selinux-policy-targeted httpd-2.0.54-10.2 fedora-release-4-2 selinux-policy-targeted-1.27.1-2.11 From sds at tycho.nsa.gov Thu Nov 3 13:35:56 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 03 Nov 2005 08:35:56 -0500 Subject: libselinux question for httpd In-Reply-To: <20051103095209.GA25421@redhat.com> References: <20051103095209.GA25421@redhat.com> Message-ID: <1131024956.23420.5.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-11-03 at 09:52 +0000, Joe Orton wrote: > Is there is a simple libselinux call I can make in httpd to determine > whether or not the SELinux policy is enabled and applied? > > I'd like to add a one-line notice to the default error_log when it is, > to give an obvious tip-off to confused new users. is_selinux_enabled() will return > 0 if SELinux is enabled. getcon(&con) will set con to the context in which the process is running. -- Stephen Smalley National Security Agency From ivg2 at cornell.edu Thu Nov 3 13:55:10 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Thu, 03 Nov 2005 08:55:10 -0500 Subject: applying SELinux policy for httpd In-Reply-To: <20051103101529.GB25421@redhat.com> References: <20051103101529.GB25421@redhat.com> Message-ID: <436A16BE.2000208@cornell.edu> Joe Orton wrote: > I'd also like to mention again that the new FC4 policy of only applying > SELinux policy if httpd is started from the init script is confusing the > hell out of people. It breaks the principle of least astonishment. I'd > much rather live with the fact that SELinux policy is *always* applied, > and the fallout from that, than see this confusion of people hitting > SELinux policy issues, get confused, restart httpd, see them disappear, > etc. > > I'd really like to see this change reverted for FC5. > Check the state of the "direct_sysadm_daemon" tunable... I think it should be set to 1 in your case. I am not quite sure of the justification for a tunable. From ivg2 at cornell.edu Thu Nov 3 14:02:14 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Thu, 03 Nov 2005 09:02:14 -0500 Subject: applying SELinux policy for httpd In-Reply-To: <436A16BE.2000208@cornell.edu> References: <20051103101529.GB25421@redhat.com> <436A16BE.2000208@cornell.edu> Message-ID: <436A1866.3020904@cornell.edu> Ivan Gyurdiev wrote: > Joe Orton wrote: >> I'd also like to mention again that the new FC4 policy of only >> applying SELinux policy if httpd is started from the init script is >> confusing the hell out of people. It breaks the principle of least >> astonishment. I'd much rather live with the fact that SELinux policy >> is *always* applied, and the fallout from that, than see this >> confusion of people hitting SELinux policy issues, get confused, >> restart httpd, see them disappear, etc. >> >> I'd really like to see this change reverted for FC5. >> > > Check the state of the "direct_sysadm_daemon" tunable... > I think it should be set to 1 in your case. I am not quite sure of the > justification for a tunable. Or rather.. maybe it needs to be defined in the sources package from which policy is built. I always get confused as to whether or not tunables can be changed at runtime - IIRC they can't. From sds at tycho.nsa.gov Thu Nov 3 14:00:04 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 03 Nov 2005 09:00:04 -0500 Subject: applying SELinux policy for httpd In-Reply-To: <20051103101529.GB25421@redhat.com> References: <20051103101529.GB25421@redhat.com> Message-ID: <1131026404.23420.18.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-11-03 at 10:15 +0000, Joe Orton wrote: > I'd also like to mention again that the new FC4 policy of only applying > SELinux policy if httpd is started from the init script is confusing the > hell out of people. It breaks the principle of least astonishment. I'd > much rather live with the fact that SELinux policy is *always* applied, > and the fallout from that, than see this confusion of people hitting > SELinux policy issues, get confused, restart httpd, see them disappear, > etc. > > I'd really like to see this change reverted for FC5. Previously discussed in this thread: http://marc.theaimsgroup.com/?t=112089638800001&r=1&w=2 -- Stephen Smalley National Security Agency From dwalsh at redhat.com Thu Nov 3 14:06:51 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 03 Nov 2005 09:06:51 -0500 Subject: libselinux question for httpd In-Reply-To: <20051103095209.GA25421@redhat.com> References: <20051103095209.GA25421@redhat.com> Message-ID: <436A197B.4040300@redhat.com> Joe Orton wrote: > Is there is a simple libselinux call I can make in httpd to determine > whether or not the SELinux policy is enabled and applied? > > I'd like to add a one-line notice to the default error_log when it is, > to give an obvious tip-off to confused new users. > > I am not sure what you want. You can ask whether SELinux is enabled. is_selinux_enabled(), or you can getcon to get the current context. So you could show that the context is system_u:system_r:httpd_t in the log file if getcon is called. > joe > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- From sds at tycho.nsa.gov Thu Nov 3 14:02:16 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 03 Nov 2005 09:02:16 -0500 Subject: applying SELinux policy for httpd In-Reply-To: <436A1866.3020904@cornell.edu> References: <20051103101529.GB25421@redhat.com> <436A16BE.2000208@cornell.edu> <436A1866.3020904@cornell.edu> Message-ID: <1131026536.23420.21.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-11-03 at 09:02 -0500, Ivan Gyurdiev wrote: > > Check the state of the "direct_sysadm_daemon" tunable... > > I think it should be set to 1 in your case. I am not quite sure of the > > justification for a tunable. > Or rather.. maybe it needs to be defined in the sources package from > which policy is built. > I always get confused as to whether or not tunables can be changed at > runtime - IIRC they can't. In the current policy, tunables are compile-time (handled via m4 macro expansion) and booleans are runtime (handled via policy language support for conditional TE rules). -- Stephen Smalley National Security Agency From dwalsh at redhat.com Thu Nov 3 14:08:32 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 03 Nov 2005 09:08:32 -0500 Subject: applying SELinux policy for httpd In-Reply-To: <20051103101529.GB25421@redhat.com> References: <20051103101529.GB25421@redhat.com> Message-ID: <436A19E0.4030502@redhat.com> Joe Orton wrote: > I'd also like to mention again that the new FC4 policy of only applying > SELinux policy if httpd is started from the init script is confusing the > hell out of people. It breaks the principle of least astonishment. I'd > much rather live with the fact that SELinux policy is *always* applied, > and the fallout from that, than see this confusion of people hitting > SELinux policy issues, get confused, restart httpd, see them disappear, > etc. > We can revert it back. The problem this is trying to solve is the terminal problem. IE a user goes out and runs a cgi script and he gets no output. This is very confusing to the user. What I can change is to transition httpd_exec_t from unconfined_t to httpd_t, but not the cgi scripts. Would that work for you? > I'd really like to see this change reverted for FC5. > > joe > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- From jorton at redhat.com Thu Nov 3 14:10:43 2005 From: jorton at redhat.com (Joe Orton) Date: Thu, 3 Nov 2005 14:10:43 +0000 Subject: applying SELinux policy for httpd In-Reply-To: <1131026404.23420.18.camel@moss-spartans.epoch.ncsc.mil> References: <20051103101529.GB25421@redhat.com> <1131026404.23420.18.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20051103141043.GC29022@redhat.com> On Thu, Nov 03, 2005 at 09:00:04AM -0500, Stephen Smalley wrote: > On Thu, 2005-11-03 at 10:15 +0000, Joe Orton wrote: > > I'd also like to mention again that the new FC4 policy of only applying > > SELinux policy if httpd is started from the init script is confusing the > > hell out of people. It breaks the principle of least astonishment. I'd > > much rather live with the fact that SELinux policy is *always* applied, > > and the fallout from that, than see this confusion of people hitting > > SELinux policy issues, get confused, restart httpd, see them disappear, > > etc. > > > > I'd really like to see this change reverted for FC5. > > Previously discussed in this thread: > http://marc.theaimsgroup.com/?t=112089638800001&r=1&w=2 The argument above still stands after the change to make apachectl behave like the init script. People are still getting confused by the fact that Apache behaves differently if started via /usr/sbin/httpd. joe From sds at tycho.nsa.gov Thu Nov 3 14:12:24 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 03 Nov 2005 09:12:24 -0500 Subject: applying SELinux policy for httpd In-Reply-To: <20051103141043.GC29022@redhat.com> References: <20051103101529.GB25421@redhat.com> <1131026404.23420.18.camel@moss-spartans.epoch.ncsc.mil> <20051103141043.GC29022@redhat.com> Message-ID: <1131027144.23420.32.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-11-03 at 14:10 +0000, Joe Orton wrote: > On Thu, Nov 03, 2005 at 09:00:04AM -0500, Stephen Smalley wrote: > > On Thu, 2005-11-03 at 10:15 +0000, Joe Orton wrote: > > > I'd also like to mention again that the new FC4 policy of only applying > > > SELinux policy if httpd is started from the init script is confusing the > > > hell out of people. It breaks the principle of least astonishment. I'd > > > much rather live with the fact that SELinux policy is *always* applied, > > > and the fallout from that, than see this confusion of people hitting > > > SELinux policy issues, get confused, restart httpd, see them disappear, > > > etc. > > > > > > I'd really like to see this change reverted for FC5. > > > > Previously discussed in this thread: > > http://marc.theaimsgroup.com/?t=112089638800001&r=1&w=2 > > The argument above still stands after the change to make apachectl > behave like the init script. People are still getting confused by the > fact that Apache behaves differently if started via /usr/sbin/httpd. That's fine, but they then need to know to use runcon or to enable httpd_tty_com if they want to run httpd -t and see the output on their tty. Likewise for cgis, unless they are handled differently. -- Stephen Smalley National Security Agency From paul at city-fan.org Thu Nov 3 14:18:06 2005 From: paul at city-fan.org (Paul Howarth) Date: Thu, 03 Nov 2005 14:18:06 +0000 Subject: FC4 + targetpolicy+samba + cdrom In-Reply-To: <436A1518.6030706@feuerpokemon.de> References: <4368A390.90307@feuerpokemon.de> <1130931443.3668.172.camel@laurel.intra.city-fan.org> <436A1518.6030706@feuerpokemon.de> Message-ID: <436A1C1E.90206@city-fan.org> dragoran wrote: > Paul Howarth wrote: > >> On Wed, 2005-11-02 at 12:31 +0100, dragoran wrote: >> >> >>> the selinux-targeted-policy in fc4 prevents samba from sharing a dvd >>> drive. >>> I had to disable selinux protection for samba to get this to work. >>> Should I fill this in bugzilla? >>> >> >> >> Try mounting the dvd using the mount option >> "fscontext=system_u:object_r:samba_share_t" >> >> Paul. >> >> > this does not work... > it is still > system_u:object_r:iso9660_t (which does not work) It works for me: # mount -r -o fscontext=system_u:object_r:samba_share_t /dev/hdc /media/cdrom The resulting mountpoint /media/cdrom is browsable using samba. Paul. From jorton at redhat.com Thu Nov 3 14:22:46 2005 From: jorton at redhat.com (Joe Orton) Date: Thu, 3 Nov 2005 14:22:46 +0000 Subject: applying SELinux policy for httpd In-Reply-To: <1131027144.23420.32.camel@moss-spartans.epoch.ncsc.mil> References: <20051103101529.GB25421@redhat.com> <1131026404.23420.18.camel@moss-spartans.epoch.ncsc.mil> <20051103141043.GC29022@redhat.com> <1131027144.23420.32.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20051103142246.GD29022@redhat.com> On Thu, Nov 03, 2005 at 09:12:24AM -0500, Stephen Smalley wrote: > On Thu, 2005-11-03 at 14:10 +0000, Joe Orton wrote: > > On Thu, Nov 03, 2005 at 09:00:04AM -0500, Stephen Smalley wrote: > > > On Thu, 2005-11-03 at 10:15 +0000, Joe Orton wrote: > > > > I'd also like to mention again that the new FC4 policy of only applying > > > > SELinux policy if httpd is started from the init script is confusing the > > > > hell out of people. It breaks the principle of least astonishment. I'd > > > > much rather live with the fact that SELinux policy is *always* applied, > > > > and the fallout from that, than see this confusion of people hitting > > > > SELinux policy issues, get confused, restart httpd, see them disappear, > > > > etc. > > > > > > > > I'd really like to see this change reverted for FC5. > > > > > > Previously discussed in this thread: > > > http://marc.theaimsgroup.com/?t=112089638800001&r=1&w=2 > > > > The argument above still stands after the change to make apachectl > > behave like the init script. People are still getting confused by the > > fact that Apache behaves differently if started via /usr/sbin/httpd. > > That's fine, but they then need to know to use runcon or to enable > httpd_tty_com if they want to run httpd -t and see the output on their > tty. It's a trade-off and this is the more acceptable option to me. Consistently different is better than inconsistently different. (but I would really also prefer that httpd_tty_comm was active by default to avoid that issue as well) > Likewise for cgis, unless they are handled differently. What's the problem for CGI scripts, I'm not sure what you're referring to here? Regards, joe From jorton at redhat.com Thu Nov 3 14:24:29 2005 From: jorton at redhat.com (Joe Orton) Date: Thu, 3 Nov 2005 14:24:29 +0000 Subject: libselinux question for httpd In-Reply-To: <1131024956.23420.5.camel@moss-spartans.epoch.ncsc.mil> References: <20051103095209.GA25421@redhat.com> <1131024956.23420.5.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20051103142429.GE29022@redhat.com> On Thu, Nov 03, 2005 at 08:35:56AM -0500, Stephen Smalley wrote: > On Thu, 2005-11-03 at 09:52 +0000, Joe Orton wrote: > > Is there is a simple libselinux call I can make in httpd to determine > > whether or not the SELinux policy is enabled and applied? > > > > I'd like to add a one-line notice to the default error_log when it is, > > to give an obvious tip-off to confused new users. > > is_selinux_enabled() will return > 0 if SELinux is enabled. > getcon(&con) will set con to the context in which the process is > running. Great, thanks. Is it OK to presume that security_context_t is always a char * and just print that string? joe From sds at tycho.nsa.gov Thu Nov 3 14:25:01 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 03 Nov 2005 09:25:01 -0500 Subject: libselinux question for httpd In-Reply-To: <20051103142429.GE29022@redhat.com> References: <20051103095209.GA25421@redhat.com> <1131024956.23420.5.camel@moss-spartans.epoch.ncsc.mil> <20051103142429.GE29022@redhat.com> Message-ID: <1131027901.23420.39.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-11-03 at 14:24 +0000, Joe Orton wrote: > Great, thanks. Is it OK to presume that security_context_t is always a > char * and just print that string? Yes. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Thu Nov 3 14:27:51 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 03 Nov 2005 09:27:51 -0500 Subject: applying SELinux policy for httpd In-Reply-To: <20051103142246.GD29022@redhat.com> References: <20051103101529.GB25421@redhat.com> <1131026404.23420.18.camel@moss-spartans.epoch.ncsc.mil> <20051103141043.GC29022@redhat.com> <1131027144.23420.32.camel@moss-spartans.epoch.ncsc.mil> <20051103142246.GD29022@redhat.com> Message-ID: <1131028071.23420.43.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-11-03 at 14:22 +0000, Joe Orton wrote: > What's the problem for CGI scripts, I'm not sure what you're referring > to here? A similar issue exists for them: whether or not to transition them into their separate domains by default when a user runs them directly. As with httpd, they lose access to the tty in that case, and thus cannot display diagnostics. runcon can be used to force the desired behavior regardless of the default. -- Stephen Smalley National Security Agency From ivg2 at cornell.edu Thu Nov 3 14:49:09 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Thu, 03 Nov 2005 09:49:09 -0500 Subject: libselinux question for httpd In-Reply-To: <1131027901.23420.39.camel@moss-spartans.epoch.ncsc.mil> References: <20051103095209.GA25421@redhat.com> <1131024956.23420.5.camel@moss-spartans.epoch.ncsc.mil> <20051103142429.GE29022@redhat.com> <1131027901.23420.39.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <436A2365.4040408@cornell.edu> Stephen Smalley wrote: > On Thu, 2005-11-03 at 14:24 +0000, Joe Orton wrote: > >> Great, thanks. Is it OK to presume that security_context_t is always a >> char * and just print that string? >> > > Yes. > The natural followup question is - why is security_context_t being used, instead of char* ? From jorton at redhat.com Thu Nov 3 14:42:01 2005 From: jorton at redhat.com (Joe Orton) Date: Thu, 3 Nov 2005 14:42:01 +0000 Subject: applying SELinux policy for httpd In-Reply-To: <1131028071.23420.43.camel@moss-spartans.epoch.ncsc.mil> References: <20051103101529.GB25421@redhat.com> <1131026404.23420.18.camel@moss-spartans.epoch.ncsc.mil> <20051103141043.GC29022@redhat.com> <1131027144.23420.32.camel@moss-spartans.epoch.ncsc.mil> <20051103142246.GD29022@redhat.com> <1131028071.23420.43.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20051103144201.GF29022@redhat.com> On Thu, Nov 03, 2005 at 09:27:51AM -0500, Stephen Smalley wrote: > On Thu, 2005-11-03 at 14:22 +0000, Joe Orton wrote: > > What's the problem for CGI scripts, I'm not sure what you're referring > > to here? > > A similar issue exists for them: whether or not to transition them into > their separate domains by default when a user runs them directly. As > with httpd, they lose access to the tty in that case, and thus cannot > display diagnostics. runcon can be used to force the desired behavior > regardless of the default. Oh, I see, tricky. I think I would go the opposite way on that one and not transition the scripts when run directly. (or if enabling httpd_tty_comm by default solves that problem too, just do that) joe From sds at tycho.nsa.gov Thu Nov 3 14:39:33 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 03 Nov 2005 09:39:33 -0500 Subject: libselinux question for httpd In-Reply-To: <436A2365.4040408@cornell.edu> References: <20051103095209.GA25421@redhat.com> <1131024956.23420.5.camel@moss-spartans.epoch.ncsc.mil> <20051103142429.GE29022@redhat.com> <1131027901.23420.39.camel@moss-spartans.epoch.ncsc.mil> <436A2365.4040408@cornell.edu> Message-ID: <1131028773.23420.50.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-11-03 at 09:49 -0500, Ivan Gyurdiev wrote: > Stephen Smalley wrote: > > On Thu, 2005-11-03 at 14:24 +0000, Joe Orton wrote: > > > >> Great, thanks. Is it OK to presume that security_context_t is always a > >> char * and just print that string? > >> > > > > Yes. > > > The natural followup question is - why is security_context_t being used, > instead of char* ? Fair question, but removing the typedef now would be rather painful. In any event, they are strings and are handled as such by the existing SELinux patches to userland. We just don't want applications making assumptions about the internal format of the strings; they should always use the libselinux context_* functions to get/set individual fields of the context if they need to do that. -- Stephen Smalley National Security Agency From ivg2 at cornell.edu Thu Nov 3 15:05:59 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Thu, 03 Nov 2005 10:05:59 -0500 Subject: libselinux question for httpd In-Reply-To: <1131028773.23420.50.camel@moss-spartans.epoch.ncsc.mil> References: <20051103095209.GA25421@redhat.com> <1131024956.23420.5.camel@moss-spartans.epoch.ncsc.mil> <20051103142429.GE29022@redhat.com> <1131027901.23420.39.camel@moss-spartans.epoch.ncsc.mil> <436A2365.4040408@cornell.edu> <1131028773.23420.50.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <436A2757.8090207@cornell.edu> > >>>> Great, thanks. Is it OK to presume that security_context_t is always a >>>> char * and just print that string? >>>> >>>> >>> Yes. >>> >>> >> The natural followup question is - why is security_context_t being used, >> instead of char* ? >> > > Fair question, but removing the typedef now would be rather painful. In > any event, they are strings and are handled as such by the existing > SELinux patches to userland. We just don't want applications making > assumptions about the internal format of the strings; they should always > use the libselinux context_* functions to get/set individual fields of > the context if they need to do that. > Chances are that if something's possible without a warning, someone will eventually do it... Also, it seems rather confusing to me to have two data structures for the same thing (not to mention the 2+ other ones used in sepol/semanage). From sds at tycho.nsa.gov Thu Nov 3 15:14:38 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 03 Nov 2005 10:14:38 -0500 Subject: libselinux question for httpd In-Reply-To: <436A2757.8090207@cornell.edu> References: <20051103095209.GA25421@redhat.com> <1131024956.23420.5.camel@moss-spartans.epoch.ncsc.mil> <20051103142429.GE29022@redhat.com> <1131027901.23420.39.camel@moss-spartans.epoch.ncsc.mil> <436A2365.4040408@cornell.edu> <1131028773.23420.50.camel@moss-spartans.epoch.ncsc.mil> <436A2757.8090207@cornell.edu> Message-ID: <1131030878.23420.83.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-11-03 at 10:05 -0500, Ivan Gyurdiev wrote: > Chances are that if something's possible without a warning, someone will > eventually do it... > Also, it seems rather confusing to me to have two data structures for > the same thing > (not to mention the 2+ other ones used in sepol/semanage). Hysterical raisins, er historical reasons. security_context_t was the original type, a string representation of the security attributes that could be handled by the kernel and applications without tying them to a specific security model. Only the security server could truly interpret the content (relative to a given policy), and only SELinux code (libselinux or kernel security server) could even interpret the format (e.g. breaking out the fields). The separate context structure type was introduced to allow security-aware applications to further manipulate the individual fields without needing to know the internal format of the string. Naturally, you can extract the string from the structure, so one could have then replaced all direct uses of the string with the struct, but I don't think that would be optimal; plenty of applications only want to deal with the string. ls -Z, ps -Z, mkdir -Z, ... As you know, libsepol was a much later creation from the core checkpolicy code (which in turn was derived from the security server code), and is for policy manipulation rather than interacting with the SELinux kernel. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Thu Nov 3 15:20:42 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 03 Nov 2005 10:20:42 -0500 Subject: applying SELinux policy for httpd In-Reply-To: <436A19E0.4030502@redhat.com> References: <20051103101529.GB25421@redhat.com> <436A19E0.4030502@redhat.com> Message-ID: <436A2ACA.4050905@redhat.com> Daniel J Walsh wrote: > Joe Orton wrote: >> I'd also like to mention again that the new FC4 policy of only >> applying SELinux policy if httpd is started from the init script is >> confusing the hell out of people. It breaks the principle of least >> astonishment. I'd much rather live with the fact that SELinux policy >> is *always* applied, and the fallout from that, than see this >> confusion of people hitting SELinux policy issues, get confused, >> restart httpd, see them disappear, etc. >> Maybe we could put something in apache to check if httpd_tty_comm is active or at least see if writing to the terminal is allowed, if (access(tty, W_OK)) then put a message in the log file stating that output to the terminal is disabled you can enable using setsebool or system-config-securitylevel. We can change the default to httpd_tty_com being true, but this potentially allows cgi scripts to interact with the terminal, by default. -- From ivg2 at cornell.edu Thu Nov 3 15:45:27 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Thu, 03 Nov 2005 10:45:27 -0500 Subject: libselinux question for httpd In-Reply-To: <1131030878.23420.83.camel@moss-spartans.epoch.ncsc.mil> References: <20051103095209.GA25421@redhat.com> <1131024956.23420.5.camel@moss-spartans.epoch.ncsc.mil> <20051103142429.GE29022@redhat.com> <1131027901.23420.39.camel@moss-spartans.epoch.ncsc.mil> <436A2365.4040408@cornell.edu> <1131028773.23420.50.camel@moss-spartans.epoch.ncsc.mil> <436A2757.8090207@cornell.edu> <1131030878.23420.83.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <436A3097.8050100@cornell.edu> Stephen Smalley wrote: > On Thu, 2005-11-03 at 10:05 -0500, Ivan Gyurdiev wrote: > >> Chances are that if something's possible without a warning, someone will >> eventually do it... >> Also, it seems rather confusing to me to have two data structures for >> the same thing >> (not to mention the 2+ other ones used in sepol/semanage). >> > > Hysterical raisins, er historical reasons. > Someone should write a bug, er...book on the history of SELinux... It's fascinating how much code exists purely for historical considerations :) > The separate context structure type was introduced to allow > security-aware applications to further manipulate the individual fields > without needing to know the internal format of the string. Naturally, > you can extract the string from the structure, so one could have then > replaced all direct uses of the string with the struct, but I don't > think that would be optimal; plenty of applications only want to deal > with the string. ls -Z, ps -Z, mkdir -Z, ... > So, there should be convert functions to go from one to the other, and the library interfaces should work with the opaque structure, not with the string. Anyway, I'm not volunteering to do this right now - just making some observations. From sds at tycho.nsa.gov Thu Nov 3 15:43:02 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 03 Nov 2005 10:43:02 -0500 Subject: libselinux question for httpd In-Reply-To: <436A3097.8050100@cornell.edu> References: <20051103095209.GA25421@redhat.com> <1131024956.23420.5.camel@moss-spartans.epoch.ncsc.mil> <20051103142429.GE29022@redhat.com> <1131027901.23420.39.camel@moss-spartans.epoch.ncsc.mil> <436A2365.4040408@cornell.edu> <1131028773.23420.50.camel@moss-spartans.epoch.ncsc.mil> <436A2757.8090207@cornell.edu> <1131030878.23420.83.camel@moss-spartans.epoch.ncsc.mil> <436A3097.8050100@cornell.edu> Message-ID: <1131032582.23420.104.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-11-03 at 10:45 -0500, Ivan Gyurdiev wrote: > Stephen Smalley wrote: > Naturally, > > you can extract the string from the structure, so one could have then > > replaced all direct uses of the string with the struct, but I don't > > think that would be optimal; plenty of applications only want to deal > > with the string. ls -Z, ps -Z, mkdir -Z, ... > > > So, there should be convert functions to go from one to the other, and the > library interfaces should work with the opaque structure, not with the > string. I don't think so. Consider: today, ls can call getfilecon(), which internally performs a getxattr(), which returns the string stored in the attribute value, and returns it back to ls for display to the user. Why force that process to go through an extra conversion to struct and back for no reason? > Anyway, I'm not volunteering to do this right now - just making some > observations. -- Stephen Smalley National Security Agency From ivg2 at cornell.edu Thu Nov 3 16:15:15 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Thu, 03 Nov 2005 11:15:15 -0500 Subject: libselinux question for httpd In-Reply-To: <1131032582.23420.104.camel@moss-spartans.epoch.ncsc.mil> References: <20051103095209.GA25421@redhat.com> <1131024956.23420.5.camel@moss-spartans.epoch.ncsc.mil> <20051103142429.GE29022@redhat.com> <1131027901.23420.39.camel@moss-spartans.epoch.ncsc.mil> <436A2365.4040408@cornell.edu> <1131028773.23420.50.camel@moss-spartans.epoch.ncsc.mil> <436A2757.8090207@cornell.edu> <1131030878.23420.83.camel@moss-spartans.epoch.ncsc.mil> <436A3097.8050100@cornell.edu> <1131032582.23420.104.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <436A3793.9090804@cornell.edu> > > I don't think so. Consider: today, ls can call getfilecon(), which > internally performs a getxattr(), which returns the string stored in the > attribute value, and returns it back to ls for display to the user. Why > force that process to go through an extra conversion to struct and back > for no reason? > You could still store it as a string, instead of piecewise, and then extract fields on demand, when set() or get() is called. Then the conversion can be done as a cast for users that want the whole string. Anyway I haven't thought much about this problem, as optimization and data hiding are usually the opposite of each other.. but there's probably a way to combine them... From kcarr at tresys.com Thu Nov 3 21:24:52 2005 From: kcarr at tresys.com (Kevin Carr) Date: Thu, 3 Nov 2005 16:24:52 -0500 Subject: ANN: Setools-2.2 Message-ID: <200511032124.jA3LOqYs026202@gotham.columbia.tresys.com> A new version of setools is available for download on the Tresys Technology website. http://www.tresys.com Included in this release is a new tool called sechecker. This tool performs a number of checks on a SELinux policy and is designed to be modular so that it is easily extensible in the future. We will be extending the capability of this tool in the next release. Sediffx has an updated user interface that separates key elements of the policy difference for easier analysis (for example rules that were removed because a type was removed from the policy). Also added was the ability to specify renamed types when computing a difference. Libapol now has support for storing some additional policy components such as MLS, and constraints. Various bug fixes are included in this release as well. Kevin Carr Tresys Technology 410.290.1411 x137 From jayendren at hivsa.com Fri Nov 4 09:44:28 2005 From: jayendren at hivsa.com (Jayendren Anand Maduray) Date: Fri, 04 Nov 2005 11:44:28 +0200 Subject: Selinux with Apache running PHP In-Reply-To: <20051103170014.64605739D0@hormel.redhat.com> References: <20051103170014.64605739D0@hormel.redhat.com> Message-ID: <436B2D7C.4000909@hivsa.com> Good day all. I am having trouble running PHP files in my webserver: Apache. Here is some information: [root at shiva warez]# rpm -qi php Name : php Relocations: (not relocatable) Version : 4.3.11 Vendor: Red Hat, Inc. Release : 2.7 Build Date: Thu 25 Aug 2005 11:26:47 SAST Install Date: Thu 03 Nov 2005 13:51:24 SAST Build Host: tweety.build.redhat.com Group : Development/Languages Source RPM: php-4.3.11-2.7.src.rpm Size : 3373100 License: The PHP License Signature : DSA/SHA1, Thu 25 Aug 2005 18:02:04 SAST, Key ID b44269d04f2a6fd2 Packager : Red Hat, Inc. URL : http://www.php.net/ Summary : The PHP HTML-embedded scripting language. (PHP: Hypertext Preprocessor) [root at shiva warez]# rpm -qi httpd Name : httpd Relocations: (not relocatable) Version : 2.0.52 Vendor: Red Hat, Inc. Release : 3.1 Build Date: Thu 11 Nov 2004 17:39:18 SAST Install Date: Fri 22 Apr 2005 08:37:05 SAST Build Host: dolly.build.redhat.com Group : System Environment/Daemons Source RPM: httpd-2.0.52-3.1.src.rpm Size : 2407431 License: Apache Software License Signature : DSA/SHA1, Fri 12 Nov 2004 22:58:01 SAST, Key ID b44269d04f2a6fd2 Packager : Red Hat, Inc. URL : http://httpd.apache.org/ Summary : The httpd Web server [root at shiva warez]# uname -a Linux shiva 2.6.9-1.667smp #1 SMP Tue Nov 2 14:59:52 EST 2004 i686 i686 i386 GNU/Linux SElinux is running in enforcing mode, and I have disabled protection for apache. I am trying to setup PHP Nuke on my webserver, but it has trouble running PHP files. Also tried the following from the fedora-forum: changed permissions of the php files: chmod 755 *.php turning off SELinux protection, which works of course. But I like SELinux!!! Please advise. -- Jayendren Anand Maduray Microsoft Certified Professional Network Plus IT Administrator Perinatal HIV Research Unit Old Potch Road Chris Hani Baragwanath Hospital Soweto South Africa Tel: +27 11 989 9776 Tel: +27 11 989 9999 Fax: +27 11 938 3973 Cel: 082 22 774 94 Alternate email address: jayendren at mweb.co.za From sds at tycho.nsa.gov Fri Nov 4 13:59:30 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 04 Nov 2005 08:59:30 -0500 Subject: libselinux question for httpd In-Reply-To: <436A3793.9090804@cornell.edu> References: <20051103095209.GA25421@redhat.com> <1131024956.23420.5.camel@moss-spartans.epoch.ncsc.mil> <20051103142429.GE29022@redhat.com> <1131027901.23420.39.camel@moss-spartans.epoch.ncsc.mil> <436A2365.4040408@cornell.edu> <1131028773.23420.50.camel@moss-spartans.epoch.ncsc.mil> <436A2757.8090207@cornell.edu> <1131030878.23420.83.camel@moss-spartans.epoch.ncsc.mil> <436A3097.8050100@cornell.edu> <1131032582.23420.104.camel@moss-spartans.epoch.ncsc.mil> <436A3793.9090804@cornell.edu> Message-ID: <1131112770.23420.223.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-11-03 at 11:15 -0500, Ivan Gyurdiev wrote: > > > > I don't think so. Consider: today, ls can call getfilecon(), which > > internally performs a getxattr(), which returns the string stored in the > > attribute value, and returns it back to ls for display to the user. Why > > force that process to go through an extra conversion to struct and back > > for no reason? > > > You could still store it as a string, instead of piecewise, and then > extract fields on demand, when set() or get() is called. Then the > conversion can be done as a cast for users that want the whole string. > Anyway I haven't thought much about this problem, as optimization and > data hiding are usually the opposite of each other.. but there's > probably a way to combine them... But the question is still why do so? You gain nothing from such "data hiding" in this case, as the application still ends up converting to string form and can still violate the "encapsulation" at that point by peeking inside the string. It ends up being no different from directly returning the string form in that case as far as "data hiding" is concerned, and the string form is what most users of libselinux want. The structure is for a minority of users of libselinux that actually care about the individual fields. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Fri Nov 4 14:07:02 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 04 Nov 2005 09:07:02 -0500 Subject: libselinux question for httpd In-Reply-To: <1131112770.23420.223.camel@moss-spartans.epoch.ncsc.mil> References: <20051103095209.GA25421@redhat.com> <1131024956.23420.5.camel@moss-spartans.epoch.ncsc.mil> <20051103142429.GE29022@redhat.com> <1131027901.23420.39.camel@moss-spartans.epoch.ncsc.mil> <436A2365.4040408@cornell.edu> <1131028773.23420.50.camel@moss-spartans.epoch.ncsc.mil> <436A2757.8090207@cornell.edu> <1131030878.23420.83.camel@moss-spartans.epoch.ncsc.mil> <436A3097.8050100@cornell.edu> <1131032582.23420.104.camel@moss-spartans.epoch.ncsc.mil> <436A3793.9090804@cornell.edu> <1131112770.23420.223.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1131113222.23420.226.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-11-04 at 08:59 -0500, Stephen Smalley wrote: > But the question is still why do so? You gain nothing from such "data > hiding" in this case, as the application still ends up converting to > string form and can still violate the "encapsulation" at that point by > peeking inside the string. It ends up being no different from directly > returning the string form in that case as far as "data hiding" is > concerned, and the string form is what most users of libselinux want. > The structure is for a minority of users of libselinux that actually > care about the individual fields. So, in summary, the libselinux interface is exactly right - most of its interfaces operate on the abstraction/data type that is most commonly needed by its users, and it provides separate conversion and manipulation functions for the minority of users that need to operate on the structured form. The only mistake was bothering to create a typedef for security_context_t versus just using char* everywhere. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Fri Nov 4 14:46:26 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 04 Nov 2005 09:46:26 -0500 Subject: Selinux with Apache running PHP In-Reply-To: <436B2D7C.4000909@hivsa.com> References: <20051103170014.64605739D0@hormel.redhat.com> <436B2D7C.4000909@hivsa.com> Message-ID: <436B7442.8090205@redhat.com> Jayendren Anand Maduray wrote: > > Good day all. > > I am having trouble running PHP files in my webserver: Apache. > > Here is some information: > > [root at shiva warez]# rpm -qi php > Name : php Relocations: (not relocatable) > Version : 4.3.11 Vendor: Red Hat, Inc. > Release : 2.7 Build Date: Thu 25 Aug > 2005 11:26:47 SAST > Install Date: Thu 03 Nov 2005 13:51:24 SAST Build Host: > tweety.build.redhat.com > Group : Development/Languages Source RPM: > php-4.3.11-2.7.src.rpm > Size : 3373100 License: The PHP License > Signature : DSA/SHA1, Thu 25 Aug 2005 18:02:04 SAST, Key ID > b44269d04f2a6fd2 > Packager : Red Hat, Inc. > URL : http://www.php.net/ > Summary : The PHP HTML-embedded scripting language. (PHP: > Hypertext Preprocessor) > > [root at shiva warez]# rpm -qi httpd > Name : httpd Relocations: (not relocatable) > Version : 2.0.52 Vendor: Red Hat, Inc. > Release : 3.1 Build Date: Thu 11 Nov > 2004 17:39:18 SAST > Install Date: Fri 22 Apr 2005 08:37:05 SAST Build Host: > dolly.build.redhat.com > Group : System Environment/Daemons Source RPM: > httpd-2.0.52-3.1.src.rpm > Size : 2407431 License: Apache > Software License > Signature : DSA/SHA1, Fri 12 Nov 2004 22:58:01 SAST, Key ID > b44269d04f2a6fd2 > Packager : Red Hat, Inc. > URL : http://httpd.apache.org/ > Summary : The httpd Web server > > [root at shiva warez]# uname -a > Linux shiva 2.6.9-1.667smp #1 SMP Tue Nov 2 14:59:52 EST 2004 i686 > i686 i386 GNU/Linux > > SElinux is running in enforcing mode, and I have disabled protection > for apache. > > I am trying to setup PHP Nuke on my webserver, but it has trouble > running PHP files. > > Also tried the following from the fedora-forum: > > changed permissions of the php files: chmod 755 *.php > turning off SELinux protection, which works of course. > > But I like SELinux!!! > > Please advise. > What avc messages are you seeing in /var/log/messages or /var/log/audit/audit.log? -- From nicolas.mailhot at laposte.net Sat Nov 5 09:41:12 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 05 Nov 2005 10:41:12 +0100 Subject: pam_abl selinux problem Message-ID: <1131183672.10387.35.camel@rousalka.dyndns.org> Hi, Following a thread on the fedora-extra list about which tool in FE should be used to protect against sshd brute-force attacks I installed pam_abl on my fedora devel box. Pam_abl is a security module that checks every login attempt against user and host blacklists, and automatically fill these lists after too frequent login failures. Unfortunately it seems the devel security policies are not nice to pam_abl, so it doesn't work : Nov 5 10:27:02 rousalka pam_abl[3917]: Permission denied (13) while opening or creating database I've posted the relevant details (full audit logs...) in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172496 Could someone more qualified than me take a peek at them ? -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From linux_4ever at yahoo.com Sat Nov 5 13:20:38 2005 From: linux_4ever at yahoo.com (Steve G) Date: Sat, 5 Nov 2005 05:20:38 -0800 (PST) Subject: Rotate audit log? In-Reply-To: <435D1718.50004@mindspring.com> Message-ID: <20051105132038.97396.qmail@web51503.mail.yahoo.com> >Is there something other than the size of the logfile that can be used >to cause the rotation? Would an RFE for a command to the deamon to cause >a rotation be appropriate? How about something in the config file to >tell it "daily" or similar? OK. I thought about this problem. Keeping track of time and deciding when to rotate is an ugly problem. What I decided to do is make sigusr1 force a rotation of the logs. I added a rotate command to the initscript so that you can do "service auditd rotate". Then I created a small script that is stored in the docs directory, /usr/share/doc/audit-1.0.10/auditd.cron, since I don't want it installed by default. The script is intended to be used with cron so that you can force a rotation at whatever is convenient - daily, weekly, every 12 hours. I would also like to point out that if you are wanting to see what time ranges are contained in the logs, you just run "aureport -t". The changes are in audit-1.0.10-1 which is in rawhide. If there are no problems reported with that release, I will roll it out for FC4 next week. Please let me know if there are any problems with this scheme. -Steve __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs From smooge at gmail.com Sat Nov 5 20:00:20 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Sat, 5 Nov 2005 13:00:20 -0700 Subject: Rotate audit log? In-Reply-To: <20051105132038.97396.qmail@web51503.mail.yahoo.com> References: <435D1718.50004@mindspring.com> <20051105132038.97396.qmail@web51503.mail.yahoo.com> Message-ID: <80d7e4090511051200w66a4b454me639597feea2b93c@mail.gmail.com> On 11/5/05, Steve G wrote: > >Is there something other than the size of the logfile that can be used > >to cause the rotation? Would an RFE for a command to the deamon to cause > >a rotation be appropriate? How about something in the config file to > >tell it "daily" or similar? > > OK. I thought about this problem. Keeping track of time and deciding when to > rotate is an ugly problem. What I decided to do is make sigusr1 force a rotation > of the logs. > > I added a rotate command to the initscript so that you can do "service auditd > rotate". Then I created a small script that is stored in the docs directory, > /usr/share/doc/audit-1.0.10/auditd.cron, since I don't want it installed by > default. The script is intended to be used with cron so that you can force a > rotation at whatever is convenient - daily, weekly, every 12 hours. > Wouldnt it be better to add this to logrotate? There are several programs that get rotated and get a signal to them to get to a new log. The details being getting the signal without losing events or soemthing.. need more sleep. -- Stephen J Smoogen. CSIRT/Linux System Administrator From dant at cdkkt.com Thu Nov 3 23:16:04 2005 From: dant at cdkkt.com (Daniel B. Thurman) Date: Thu, 3 Nov 2005 15:16:04 -0800 Subject: Problems with httpd and SElinux. Message-ID: Folks, I was asked to post this information here. To explain things, I have installed FrontPage extensions on FC4 but not realizing that I had to first disable SElinux for httpd first, but to make a long story short, I was able to install FP and then restore SElinux protections for httpd, but on reboot, SElinux refused to allow httpd to start and I suspect it had something to do with the FrontPage additions to the /etc/httpd/conf/httpd.conf file. I currently have SElinux protections turned off for https. Below is the audit file, hope it helps show the problem. type=AVC msg=audit(1131056930.757:251): avc: denied { name_bind } for pid=4946 comm="httpd" src=8090 scontext=root:system_r:httpd_t tcontext=system_u:object_r:port_t tclass=tcp_socket type=SYSCALL msg=audit(1131056930.757:251): arch=40000003 syscall=102 success=no exit=-13 a0=2 a1=bfc779f0 a2=750218 a3=8b8da58 items=0 pid=4946 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="httpd" exe="/usr/sbin/httpd" type=SOCKADDR msg=audit(1131056930.757:251): saddr=0A001F9A000000000000000000000000000000000000000000000000 type=SOCKETCALL msg=audit(1131056930.757:251): nargs=3 a0=5 a1=8b8da84 a2=1c Kind regards, Dan -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.7/159 - Release Date: 11/2/2005 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.7/159 - Release Date: 11/2/2005 From olivares14031 at yahoo.com Sat Nov 5 04:09:00 2005 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Fri, 4 Nov 2005 20:09:00 -0800 (PST) Subject: Selinux and kernel-2.6.12-1.1381 Fedora Core 3 In-Reply-To: <436C2BB6.7020001@redhat.com> Message-ID: <20051105040900.7671.qmail@web52611.mail.yahoo.com> --- Rahul Sundaram wrote: > Antonio Olivares wrote: > > >Dear Kind Folks, > > I recently updated one of my machines at work > which > >was running Fedora Core 3 to kernel-2.6.12-1.1381 > via > >yum. When I rebooted and booted to the new kernel, > I > >fired up firefox and could not load yahoo webpage. > I > >tried google, Fedorafaq, Distrowatch and nothing. > I > >suspected Selinux could be the culprit, so I did: > >Hat -> System Settings -> Security Level and > disabled > >selinux. Rebooted with new settings and viola I > could > >see yahoo, distrowatch, google, etc. I went to > >terminal fired up yum and yum update selinux and > gave > >me error message. I tried again this time with > >selinux-targetpolicy? (not to sure) but it went > >through. I reenabled selinux, and rebooted and > could > >not view any webpages again. I will get back to > the > >machine on Monday, and it makes me wonder about > what > >do I need to do, which updates I need to run. > > > >kernel installed -> [kernel-2.6.12-1.1381_FC3.i686] > > > >I read very carefully the FAQ for SELinux from > >http://www.nsa.gov/selinux/info/faq.cfm > >but I am still clueless. I would like to keep > selinux > >enabled and still view webpages. How can I still > do > >that? > > > > > post to the fedora-selinux list with the AVC denied > messages in > /var/log/messages. Fedora SELinux FAQ is available > from > > http://fedoraproject.org/wiki/Communicate > http://fedora.redhat.com/docs/selinux-faq/ > > regards > Rahul > > -- > fedora-list mailing list > fedora-list at redhat.com > To unsubscribe: > https://www.redhat.com/mailman/listinfo/fedora-list > I'll do that come Monday, thanks for helping. In any case, at home same thing happened, here are some avc messages audit(1131052412.181:2): avc: denied { name_connect } for pid=4314 comm="gkrellm" dest=7634 scontext=user_u:system_r:unconfined_t tcontext=system_u:object_r:port_t tclass=tcp_socket audit(1131052412.349:3): avc: denied { name_connect } for pid=4317 comm="eggcups" dest=631 scontext=user_u:system_r:unconfined_t tcontext=system_u:object_r:reserved_port_t tclass=tcp_socket audit(1131052412.349:4): avc: denied { name_connect } for pid=4317 comm="eggcups" dest=631 scontext=user_u:system_r:unconfined_t tcontext=system_u:object_r:reserved_port_t tclass=tcp_socket CSLIP: code copyright 1989 Regents of the University of California PPP generic driver version 2.4.2 PPP Deflate Compression module registered audit(1131052690.058:5): avc: denied { name_connect } for pid=4602 comm="firefox-bin" dest=80 scontext=user_u:system_r:unconfined_t tcontext=system_u:object_r:http_port_t tclass=tcp_socket audit(1131052692.227:6): avc: denied { name_connect } for pid=4602 comm="firefox-bin" dest=80 scontext=user_u:system_r:unconfined_t tcontext=system_u:object_r:http_port_t tclass=tcp_socket audit(1131052699.727:7): avc: denied { name_connect } for pid=4602 comm="firefox-bin" dest=80 scontext=user_u:system_r:unconfined_t tcontext=system_u:object_r:http_port_t tclass=tcp_socket audit(1131052702.155:8): avc: denied { name_connect } for pid=4602 comm="firefox-bin" dest=80 scontext=user_u:system_r:unconfined_t tcontext=system_u:object_r:http_port_t tclass=tcp_socket audit(1131052713.032:9): avc: denied { name_connect } for pid=4602 comm="firefox-bin" dest=80 scontext=user_u:system_r:unconfined_t tcontext=system_u:object_r:http_port_t tclass=tcp_socket audit(1131052718.472:10): avc: denied { name_connect } for pid=4602 comm="firefox-bin" dest=80 scontext=user_u:system_r:unconfined_t tcontext=system_u:object_r:http_port_t tclass=tcp_socket audit(1131052726.685:11): avc: denied { name_connect } for pid=4602 comm="firefox-bin" dest=80 scontext=user_u:system_r:unconfined_t tcontext=system_u:object_r:http_port_t tclass=tcp_socket audit(1131052730.917:12): avc: denied { name_connect } for pid=4602 comm="firefox-bin" dest=80 scontext=user_u:system_r:unconfined_t tcontext=system_u:object_r:http_port_t tclass=tcp_socket audit(1131052743.510:13): avc: denied { name_connect } for pid=4617 comm="mozilla-bin" dest=80 scontext=user_u:system_r:unconfined_t tcontext=system_u:object_r:http_port_t tclass=tcp_socket audit(1131052746.942:14): avc: denied { name_connect } for pid=4617 comm="mozilla-bin" dest=80 scontext=user_u:system_r:unconfined_t tcontext=system_u:object_r:http_port_t tclass=tcp_socket audit(1131052843.092:15): avc: denied { name_connect } for pid=4692 comm="mozilla-bin" dest=80 scontext=user_u:system_r:unconfined_t tcontext=system_u:object_r:http_port_t tclass=tcp_socket audit(1131052848.928:16): avc: denied { name_connect } for pid=4692 comm="mozilla-bin" dest=443 scontext=user_u:system_r:unconfined_t tcontext=system_u:object_r:http_port_t tclass=tcp_socket [root at localhost ~]# [root at localhost ~]# tail /var/log/messages Nov 3 21:20:37 localhost pppd[4658]: local IP address 66.201.8.152 Nov 3 21:20:37 localhost pppd[4658]: remote IP address 66.201.8.6 Nov 3 21:20:37 localhost pppd[4658]: primary DNS address 168.215.176.2 Nov 3 21:20:37 localhost pppd[4658]: secondary DNS address 12.176.80.9 Nov 3 21:20:43 localhost kernel: audit(1131052843.092:15): avc: denied { name_connect } for pid=4692 comm="mozilla-bin" dest=80 scontext=user_u:system_r:unconfined_t tcontext=system_u:object_r:http_port_t tclass=tcp_socket Nov 3 21:20:48 localhost kernel: audit(1131052848.928:16): avc: denied { name_connect } for pid=4692 comm="mozilla-bin" dest=443 scontext=user_u:system_r:unconfined_t tcontext=system_u:object_r:http_port_t tclass=tcp_socket Nov 3 21:23:01 localhost kernel: audit(1131052981.865:17): avc: denied { name_connect } for pid=4692 comm="mozilla-bin" dest=80 scontext=user_u:system_r:unconfined_t tcontext=system_u:object_r:http_port_t tclass=tcp_socket Nov 3 21:23:03 localhost kernel: audit(1131052983.717:18): avc: denied { name_connect } for pid=4692 comm="mozilla-bin" dest=80 scontext=user_u:system_r:unconfined_t tcontext=system_u:object_r:http_port_t tclass=tcp_socket Nov 3 21:25:01 localhost crond(pam_unix)[4703]: session opened for user root by (uid=0) Nov 3 21:25:02 localhost crond(pam_unix)[4703]: session closed for user root Regards, Antonio __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs From ad+lists at uni-x.org Sun Nov 6 03:33:10 2005 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Sun, 06 Nov 2005 04:33:10 +0100 Subject: pam_abl selinux problem In-Reply-To: <1131183672.10387.35.camel@rousalka.dyndns.org> References: <1131183672.10387.35.camel@rousalka.dyndns.org> Message-ID: <1131247990.29562.221.camel@serendipity.dogma.lan> Am Sa, den 05.11.2005 schrieb Nicolas Mailhot um 10:41: > Hi, > > Following a thread on the fedora-extra list about which tool in FE > should be used to protect against sshd brute-force attacks I installed > pam_abl on my fedora devel box. Pam_abl is a security module that checks > every login attempt against user and host blacklists, and automatically > fill these lists after too frequent login failures. > > Unfortunately it seems the devel security policies are not nice to > pam_abl, so it doesn't work : > > Nov 5 10:27:02 rousalka pam_abl[3917]: Permission denied (13) while > opening or creating database > > I've posted the relevant details (full audit logs...) in > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172496 > > Could someone more qualified than me take a peek at them ? Sorry that I am not helpful at this stage. Just want to show I am following both the bugzilla ticket as well hopefully upcoming qualified discussion by the SELinux gurus, as being the FE package maintainer of pam_abl. What I would like to know - besides resolving the ticketed problem - is whether such kind of packages from Fedora Extras will have to carry policy modifications / adds themselves or whether approved FE packages should come up with Core policy package adjustments. Regards Alexander -- Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773 legal statement: http://www.uni-x.org/legal.html Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.11-1.35_FC2smp Serendipity 04:20:26 up 8 days, 2:20, load average: 1.82, 1.53, 1.24 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From nicolas.mailhot at laposte.net Sun Nov 6 09:07:27 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 06 Nov 2005 10:07:27 +0100 Subject: pam_abl selinux problem In-Reply-To: <1131247990.29562.221.camel@serendipity.dogma.lan> References: <1131183672.10387.35.camel@rousalka.dyndns.org> <1131247990.29562.221.camel@serendipity.dogma.lan> Message-ID: <1131268048.2696.10.camel@rousalka.dyndns.org> Le dimanche 06 novembre 2005 ? 04:33 +0100, Alexander Dalloz a ?crit : > What I would like to know - besides resolving the ticketed problem - is > whether such kind of packages from Fedora Extras will have to carry > policy modifications / adds themselves or whether approved FE packages > should come up with Core policy package adjustments. My understanding in the FC core policy can be updated on request when the need is clear. Also, pam_abl has been suggested as a future core component and was not rejected, but put on the backburner, which suggests some period of testing in extras is wished by Red Hat. This testing won't happen if the package is blocked by default selinux policy. However it's up to Daniel and the Red Hat selinux team to decide this. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From gene at czarc.net Sun Nov 6 17:12:16 2005 From: gene at czarc.net (Gene Czarcinski) Date: Sun, 6 Nov 2005 12:12:16 -0500 Subject: policy sources disappearing? Message-ID: <200511061212.16371.gene@czarc.net> IIRC there was (at one time) a check box in system-config-security to force autorelabel at the next reboot. Since it is now not there I looked through the rpm changelog to see why it was dropped ... I did not find an entry for autorelabel but I did find: - Remove support for modifying tunables since policy source will be disappearing in the future (#160896). I have browsed/searched the various selinux mailing lists and not found anything which discussed this. Can someone expand one what is going on and how policy changes will be made in the future? Is this similar to the kernel source situation where we will need to install the src rpm for selinux-policy to get at the sources? Gene From ivg2 at cornell.edu Sun Nov 6 19:47:07 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Sun, 06 Nov 2005 14:47:07 -0500 Subject: policy sources disappearing? In-Reply-To: <200511061212.16371.gene@czarc.net> References: <200511061212.16371.gene@czarc.net> Message-ID: <436E5DBB.1030809@cornell.edu> Gene Czarcinski wrote: > IIRC there was (at one time) a check box in system-config-security to force > autorelabel at the next reboot. Since it is now not there I looked through > the rpm changelog to see why it was dropped ... I did not find an entry for > autorelabel but I did find: > I don't know about this, but you can force an autorelabel by running: touch /.autorelabel. > - Remove support for modifying tunables since policy source will be > disappearing in the future (#160896). > > I have browsed/searched the various selinux mailing lists and not found > anything which discussed this. Can someone expand one what is going on and > how policy changes will be made in the future? > I'm not aware of plans to remove the policy sources. You shouldn't need them to use selinux, however. Tunables are for making compile-time changes to policy, while booleans are for making runtime changes to policy. I suspect what happened here is that tunable support got dropped, but booleans will be kept. Tunables are things the package distributor might want to control, while booleans are for changes by the end user. > Is this similar to the kernel source situation where we will need to install > the src rpm for selinux-policy to get at the sources? > Sources are already in a separate package, and I think they would be required if you wanted to modify tunables - not the case for booleans. From gene at czarc.net Sun Nov 6 20:00:27 2005 From: gene at czarc.net (Gene Czarcinski) Date: Sun, 6 Nov 2005 15:00:27 -0500 Subject: MCS -- some comments for discussion Message-ID: <200511061500.27624.gene@czarc.net> I have started (really just started) to try using the MCS capabilities available in FC5 development. As I go through this, some thought occur to me: 1. MCS is intended (as I understand it) to simplify some of the capabilities of the MLS functionality which is now in (or being developed) in FC5. This simplification is intended to make the functionality more acceptable/useable by a wider set of users. This is goodness! This should make an actual MLS system (which stays current) much more possible. 2. As I see it, MCS is "simply" another type of ACL but one which (to me) is a better design (more useable) than the existing ACL capability. However, whereas I can categorize (protect) both files and directories with ACL, I can currently only categorize (protect) files (not directories) with MCS. I consider this to be a problem/deficiency. Consider that when I create new application files (e.g, with openoffice.org), they will not have a category assigned by default. This could leave a sensitive file available for others to access. With directory protection, this could be mitigated. 3. Roles ... right now I don;t see much use of roles in MCS. Now this might be an RFE which will be done later (after stuff basically works), but I see that one way of using MCS would require a user to be able to switch to different roles ("newrole") in order to access files and directories with different categories. The "requirement" is to be able to switch roles and have "all" programs that invoke from that point on run with the new role ... including programs I run from the menu. Right now, the easiest way I see of having different roles is to have different userids and requiring a user to logout/login with the new userid to switch roles. This is for gdm login (gdm could be modified to permit specification of the role). If I use runlevel 3, then I could terminate X, switch roles with "newrole,", and then startx to run in the new role. OK, these are some of my initial reactions ... comments (good, bad, indifferent) solicited. Gene From vladimir at acm.org Sun Nov 6 20:03:13 2005 From: vladimir at acm.org (Vladimir G. Ivanovic) Date: Sun, 06 Nov 2005 12:03:13 -0800 Subject: SELinux errors: invalid context & inode_doinit_with_dentry: context_to_sid() returned 22 In-Reply-To: Your message of "Wed, 26 Oct 2005 20:34:11 PDT." <200510270334.j9R3YBFW010095@bach.leonora.org> Message-ID: <200511062003.jA6K3D8F007083@bach.leonora.org> Davide Bolcioni asks: Vladimir G. Ivanovic wrote: vgi> Note to self: When replacing *important* libraries like vgi> libselinux.so, don't just blast the unwanted RPM vgi> package away, figuring on then installing the new one. vgi> Instead, use --oldpackage or --force to vgi> replace the unwanted package with the desired one in vgi> atomic operation. Failure to do so will make both rpm vgi> and yum (and many other programs) unusable. db> Is the above advisable ? Does this mean that "rpm -U" or db> even "yum update" would be inappropriate ? "rpm -U" and "yum update" do not (AFAIK) install older versions. My advice applies only when one is going backwards in versions. --- Vladimir -- Vladimir G. Ivanovic Palo Alto, CA 94306 +1 650 678 8014 From jmorris at namei.org Mon Nov 7 01:04:17 2005 From: jmorris at namei.org (James Morris) Date: Sun, 6 Nov 2005 20:04:17 -0500 (EST) Subject: MCS -- some comments for discussion In-Reply-To: <200511061500.27624.gene@czarc.net> References: <200511061500.27624.gene@czarc.net> Message-ID: On Sun, 6 Nov 2005, Gene Czarcinski wrote: > 2. As I see it, MCS is "simply" another type of ACL but one which (to me) is > a better design (more useable) than the existing ACL capability. However, > whereas I can categorize (protect) both files and directories with ACL, I can > currently only categorize (protect) files (not directories) with MCS. I > consider this to be a problem/deficiency. > > Consider that when I create new application files (e.g, with openoffice.org), > they will not have a category assigned by default. This could leave a > sensitive file available for others to access. With directory protection, > this could be mitigated. Yes, inheriting a directory's categories on file creation (only) is something we'll probably investigate soon. - James -- James Morris From jayendren at hivsa.com Mon Nov 7 06:23:02 2005 From: jayendren at hivsa.com (Jayendren Anand Maduray) Date: Mon, 07 Nov 2005 08:23:02 +0200 Subject: Selinux with Apache running PHP In-Reply-To: <436B7442.8090205@redhat.com> References: <20051103170014.64605739D0@hormel.redhat.com> <436B2D7C.4000909@hivsa.com> <436B7442.8090205@redhat.com> Message-ID: <436EF2C6.2000400@hivsa.com> Hi! >What avc messages are you seeing in /var/log/messages or /var/log/audit/audit.log? From /var/log/messages: Nov 4 20:27:22 shiva dbus: avc: 1 AV entries and 1/512 buckets used, longest chain length 1 Nov 4 20:27:49 shiva dbus: avc: 3 AV entries and 3/512 buckets used, longest chain length 1 From var/log/audit/audit.log: NONE - i do not have the specified directory on my system? Daniel J Walsh wrote: > Jayendren Anand Maduray wrote: > >> >> Good day all. >> >> I am having trouble running PHP files in my webserver: Apache. >> >> Here is some information: >> >> [root at shiva warez]# rpm -qi php >> Name : php Relocations: (not >> relocatable) >> Version : 4.3.11 Vendor: Red Hat, Inc. >> Release : 2.7 Build Date: Thu 25 Aug >> 2005 11:26:47 SAST >> Install Date: Thu 03 Nov 2005 13:51:24 SAST Build Host: >> tweety.build.redhat.com >> Group : Development/Languages Source RPM: >> php-4.3.11-2.7.src.rpm >> Size : 3373100 License: The PHP License >> Signature : DSA/SHA1, Thu 25 Aug 2005 18:02:04 SAST, Key ID >> b44269d04f2a6fd2 >> Packager : Red Hat, Inc. >> URL : http://www.php.net/ >> Summary : The PHP HTML-embedded scripting language. (PHP: >> Hypertext Preprocessor) >> >> [root at shiva warez]# rpm -qi httpd >> Name : httpd Relocations: (not >> relocatable) >> Version : 2.0.52 Vendor: Red Hat, Inc. >> Release : 3.1 Build Date: Thu 11 Nov >> 2004 17:39:18 SAST >> Install Date: Fri 22 Apr 2005 08:37:05 SAST Build Host: >> dolly.build.redhat.com >> Group : System Environment/Daemons Source RPM: >> httpd-2.0.52-3.1.src.rpm >> Size : 2407431 License: Apache >> Software License >> Signature : DSA/SHA1, Fri 12 Nov 2004 22:58:01 SAST, Key ID >> b44269d04f2a6fd2 >> Packager : Red Hat, Inc. >> URL : http://httpd.apache.org/ >> Summary : The httpd Web server >> >> [root at shiva warez]# uname -a >> Linux shiva 2.6.9-1.667smp #1 SMP Tue Nov 2 14:59:52 EST 2004 i686 >> i686 i386 GNU/Linux >> >> SElinux is running in enforcing mode, and I have disabled protection >> for apache. >> >> I am trying to setup PHP Nuke on my webserver, but it has trouble >> running PHP files. >> >> Also tried the following from the fedora-forum: >> >> changed permissions of the php files: chmod 755 *.php >> turning off SELinux protection, which works of course. >> >> But I like SELinux!!! >> >> Please advise. >> > What avc messages are you seeing in /var/log/messages or > /var/log/audit/audit.log? > -- Jayendren Anand Maduray Microsoft Certified Professional Network Plus IT Administrator Perinatal HIV Research Unit Old Potch Road Chris Hani Baragwanath Hospital Soweto South Africa Tel: +27 11 989 9776 Tel: +27 11 989 9999 Fax: +27 11 938 3973 Cel: 082 22 774 94 Alternate email address: jayendren at mweb.co.za From gene at czarc.net Mon Nov 7 14:50:55 2005 From: gene at czarc.net (Gene Czarcinski) Date: Mon, 7 Nov 2005 09:50:55 -0500 Subject: MCS -- some comments for discussion In-Reply-To: References: <200511061500.27624.gene@czarc.net> Message-ID: <200511070950.56330.gene@czarc.net> On Sunday 06 November 2005 20:04, James Morris wrote: > On Sun, 6 Nov 2005, Gene Czarcinski wrote: > > 2. As I see it, MCS is "simply" another type of ACL but one which (to > > me) is a better design (more useable) than the existing ACL capability. > > However, whereas I can categorize (protect) both files and directories > > with ACL, I can currently only categorize (protect) files (not > > directories) with MCS. I consider this to be a problem/deficiency. > > > > Consider that when I create new application files (e.g, with > > openoffice.org), they will not have a category assigned by default. This > > could leave a sensitive file available for others to access. With > > directory protection, this could be mitigated. > > Yes, inheriting a directory's categories on file creation (only) is > something we'll probably investigate soon. I am not sure that "inheriting a directory's categories on file creation (only)" is the right answer (although it is one I could live with). ?I can envision a situation where the files under a directory would be a mix of categories. ?My point is that if a directory is categorized, then I should not be able to see the files under that directory unless I was authorized for that category. BTW, one "little" annoyance that I forgot to mention. ?If I have a file categorized s0:moonbean and then I copy it with "cp -p", the copied file has default categorization -- s0:. ?That is, the security attributes are not preserved. ?While I can get them preserved if I use "cp --preserve=all", I believe that this should be the default if I specify "-p". Gene From Jose.Remy at SECUR.NET Mon Nov 7 15:00:06 2005 From: Jose.Remy at SECUR.NET (Jose H. REMY) Date: Mon, 7 Nov 2005 16:00:06 +0100 Subject: Syslogd sending output to devpts Message-ID: <941F634BDD486A44B80120541613D3D22CFF14@gc._msdcs.jr.secur.net> Hi, Since I've installed SElinux (fedora-release-4-2 selinux-policy-targeted-1.23.16-6), configured with targeted policy SELinux status: enabledSELinuxfs mount: /selinuxCurrent mode: enforcingMode from config file: enforcingPolicy version: 19Policy from config file: targeted I've trouble sending outputs of syslog toward a /dev/pts/* window My devpts context : crw--w---- root tty root:object_r:devpts_t My syslogd context : user_u:system_r:syslogd_t 1872 ? 00:00:00 syslogdMy syslog.conf context: -rw-r--r-- root root system_u:object_r:etc_t /etc/syslog.conf Thank you for help and explanation (why I don't always have an "avc" denied message in message log?) Thanks, Jose H. REMY Network administrator SECUR.NET From dwalsh at redhat.com Mon Nov 7 17:14:36 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 07 Nov 2005 12:14:36 -0500 Subject: policy sources disappearing? In-Reply-To: <436E5DBB.1030809@cornell.edu> References: <200511061212.16371.gene@czarc.net> <436E5DBB.1030809@cornell.edu> Message-ID: <436F8B7C.1080606@redhat.com> Ivan Gyurdiev wrote: > Gene Czarcinski wrote: >> IIRC there was (at one time) a check box in system-config-security to >> force autorelabel at the next reboot. Since it is now not there I >> looked through the rpm changelog to see why it was dropped ... I did >> not find an entry for autorelabel but I did find: >> > I don't know about this, but you can force an autorelabel by running: > touch /.autorelabel. I talked to the maintainer and he removed it because of the first boot screen. I have asked him to put it back for the case when the app is run outside of first boot. >> - Remove support for modifying tunables since policy source will be >> disappearing in the future (#160896). >> >> I have browsed/searched the various selinux mailing lists and not >> found anything which discussed this. Can someone expand one what is >> going on and how policy changes will be made in the future? >> > I'm not aware of plans to remove the policy sources. You shouldn't > need them to use selinux, however. Tunables are for making > compile-time changes to policy, while booleans are for making runtime > changes to policy. I suspect what happened here is that tunable > support got dropped, but booleans will be kept. Tunables are things > the package distributor might want to control, while booleans are for > changes by the end user. We will be removing source when we go to ref policy. Tunables are a choice of the distro, while booleans are to be configured by the admin. We are working on an infrastructure to allow users to load their own policy modules to allow local customization, the same way that third parties would load a policy module. We want to get to the point where policysources are handled the same way as kernel sources. IE You can use them as reference, but you do not need them to build policy modules or perform local customizations. We are planning on allowing admins to configure users, booleans, ports and ethernet devices outside of policy. >> Is this similar to the kernel source situation where we will need to >> install the src rpm for selinux-policy to get at the sources? >> > Sources are already in a separate package, and I think they would be > required if you wanted to modify tunables - not the case for booleans. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -- From dwalsh at redhat.com Mon Nov 7 17:21:33 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 07 Nov 2005 12:21:33 -0500 Subject: Selinux and kernel-2.6.12-1.1381 Fedora Core 3 In-Reply-To: <20051105040900.7671.qmail@web52611.mail.yahoo.com> References: <20051105040900.7671.qmail@web52611.mail.yahoo.com> Message-ID: <436F8D1D.5040101@redhat.com> Antonio Olivares wrote: > --- Rahul Sundaram wrote: > > >> Antonio Olivares wrote: >> >> >>> Dear Kind Folks, >>> I recently updated one of my machines at work >>> >> which >> >>> was running Fedora Core 3 to kernel-2.6.12-1.1381 >>> >> via >> >>> yum. When I rebooted and booted to the new kernel, >>> >> I >> >>> fired up firefox and could not load yahoo webpage. >>> >> I >> >>> tried google, Fedorafaq, Distrowatch and nothing. >>> >> I >> >>> suspected Selinux could be the culprit, so I did: >>> Hat -> System Settings -> Security Level and >>> >> disabled >> >>> selinux. Rebooted with new settings and viola I >>> >> could >> >>> see yahoo, distrowatch, google, etc. I went to >>> terminal fired up yum and yum update selinux and >>> >> gave >> >>> me error message. I tried again this time with >>> selinux-targetpolicy? (not to sure) but it went >>> through. I reenabled selinux, and rebooted and >>> >> could >> >>> not view any webpages again. I will get back to >>> >> the >> >>> machine on Monday, and it makes me wonder about >>> >> what >> >>> do I need to do, which updates I need to run. >>> >>> kernel installed -> [kernel-2.6.12-1.1381_FC3.i686] >>> >>> I read very carefully the FAQ for SELinux from >>> http://www.nsa.gov/selinux/info/faq.cfm >>> but I am still clueless. I would like to keep >>> >> selinux >> >>> enabled and still view webpages. How can I still >>> >> do >> >>> that? >>> >>> >>> >> post to the fedora-selinux list with the AVC denied >> messages in >> /var/log/messages. Fedora SELinux FAQ is available >> from >> >> http://fedoraproject.org/wiki/Communicate >> http://fedora.redhat.com/docs/selinux-faq/ >> >> regards >> Rahul >> >> -- >> fedora-list mailing list >> fedora-list at redhat.com >> To unsubscribe: >> https://www.redhat.com/mailman/listinfo/fedora-list >> >> > > I'll do that come Monday, thanks for helping. In any > case, at home same thing happened, here are some avc > messages > > audit(1131052412.181:2): avc: denied { name_connect > } for pid=4314 comm="gkrellm" dest=7634 > scontext=user_u:system_r:unconfined_t > tcontext=system_u:object_r:port_t tclass=tcp_socket > audit(1131052412.349:3): avc: denied { name_connect > } for pid=4317 comm="eggcups" dest=631 > scontext=user_u:system_r:unconfined_t > tcontext=system_u:object_r:reserved_port_t > tclass=tcp_socket > audit(1131052412.349:4): avc: denied { name_connect > } for pid=4317 comm="eggcups" dest=631 > scontext=user_u:system_r:unconfined_t > tcontext=system_u:object_r:reserved_port_t > tclass=tcp_socket > CSLIP: code copyright 1989 Regents of the University > of California > PPP generic driver version 2.4.2 > PPP Deflate Compression module registered > audit(1131052690.058:5): avc: denied { name_connect > } for pid=4602 comm="firefox-bin" dest=80 > scontext=user_u:system_r:unconfined_t > tcontext=system_u:object_r:http_port_t > tclass=tcp_socket > audit(1131052692.227:6): avc: denied { name_connect > } for pid=4602 comm="firefox-bin" dest=80 > scontext=user_u:system_r:unconfined_t > tcontext=system_u:object_r:http_port_t > tclass=tcp_socket > audit(1131052699.727:7): avc: denied { name_connect > } for pid=4602 comm="firefox-bin" dest=80 > scontext=user_u:system_r:unconfined_t > tcontext=system_u:object_r:http_port_t > tclass=tcp_socket > audit(1131052702.155:8): avc: denied { name_connect > } for pid=4602 comm="firefox-bin" dest=80 > scontext=user_u:system_r:unconfined_t > tcontext=system_u:object_r:http_port_t > tclass=tcp_socket > audit(1131052713.032:9): avc: denied { name_connect > } for pid=4602 comm="firefox-bin" dest=80 > scontext=user_u:system_r:unconfined_t > tcontext=system_u:object_r:http_port_t > tclass=tcp_socket > audit(1131052718.472:10): avc: denied { name_connect > } for pid=4602 comm="firefox-bin" dest=80 > scontext=user_u:system_r:unconfined_t > tcontext=system_u:object_r:http_port_t > tclass=tcp_socket > audit(1131052726.685:11): avc: denied { name_connect > } for pid=4602 comm="firefox-bin" dest=80 > scontext=user_u:system_r:unconfined_t > tcontext=system_u:object_r:http_port_t > tclass=tcp_socket > audit(1131052730.917:12): avc: denied { name_connect > } for pid=4602 comm="firefox-bin" dest=80 > scontext=user_u:system_r:unconfined_t > tcontext=system_u:object_r:http_port_t > tclass=tcp_socket > audit(1131052743.510:13): avc: denied { name_connect > } for pid=4617 comm="mozilla-bin" dest=80 > scontext=user_u:system_r:unconfined_t > tcontext=system_u:object_r:http_port_t > tclass=tcp_socket > audit(1131052746.942:14): avc: denied { name_connect > } for pid=4617 comm="mozilla-bin" dest=80 > scontext=user_u:system_r:unconfined_t > tcontext=system_u:object_r:http_port_t > tclass=tcp_socket > audit(1131052843.092:15): avc: denied { name_connect > } for pid=4692 comm="mozilla-bin" dest=80 > scontext=user_u:system_r:unconfined_t > tcontext=system_u:object_r:http_port_t > tclass=tcp_socket > audit(1131052848.928:16): avc: denied { name_connect > } for pid=4692 comm="mozilla-bin" dest=443 > scontext=user_u:system_r:unconfined_t > tcontext=system_u:object_r:http_port_t > tclass=tcp_socket > [root at localhost ~]# > > [root at localhost ~]# tail /var/log/messages > Nov 3 21:20:37 localhost pppd[4658]: local IP > address 66.201.8.152 > Nov 3 21:20:37 localhost pppd[4658]: remote IP > address 66.201.8.6 > Nov 3 21:20:37 localhost pppd[4658]: primary DNS > address 168.215.176.2 > Nov 3 21:20:37 localhost pppd[4658]: secondary DNS > address 12.176.80.9 > Nov 3 21:20:43 localhost kernel: > audit(1131052843.092:15): avc: denied { name_connect > } for pid=4692 comm="mozilla-bin" dest=80 > scontext=user_u:system_r:unconfined_t > tcontext=system_u:object_r:http_port_t > tclass=tcp_socket > Nov 3 21:20:48 localhost kernel: > audit(1131052848.928:16): avc: denied { name_connect > } for pid=4692 comm="mozilla-bin" dest=443 > scontext=user_u:system_r:unconfined_t > tcontext=system_u:object_r:http_port_t > tclass=tcp_socket > Nov 3 21:23:01 localhost kernel: > audit(1131052981.865:17): avc: denied { name_connect > } for pid=4692 comm="mozilla-bin" dest=80 > scontext=user_u:system_r:unconfined_t > tcontext=system_u:object_r:http_port_t > tclass=tcp_socket > Nov 3 21:23:03 localhost kernel: > audit(1131052983.717:18): avc: denied { name_connect > } for pid=4692 comm="mozilla-bin" dest=80 > scontext=user_u:system_r:unconfined_t > tcontext=system_u:object_r:http_port_t > tclass=tcp_socket > Nov 3 21:25:01 localhost crond(pam_unix)[4703]: > session opened for user root by (uid=0) > Nov 3 21:25:02 localhost crond(pam_unix)[4703]: > session closed for user root > > Regards, > > Antonio > > > > > __________________________________ > Start your day with Yahoo! - Make it your home page! > http://www.yahoo.com/r/hs > > YOu have a policy mismatch. Have you update to the latest policy available for FC3? Please try selinux-policy-targeted-1.17.30-3.19 available in the fedora-test yum repository to see if it solves your problem -- From dwalsh at redhat.com Mon Nov 7 17:22:50 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 07 Nov 2005 12:22:50 -0500 Subject: pam_abl selinux problem In-Reply-To: <1131268048.2696.10.camel@rousalka.dyndns.org> References: <1131183672.10387.35.camel@rousalka.dyndns.org> <1131247990.29562.221.camel@serendipity.dogma.lan> <1131268048.2696.10.camel@rousalka.dyndns.org> Message-ID: <436F8D6A.6010002@redhat.com> Nicolas Mailhot wrote: > Le dimanche 06 novembre 2005 ? 04:33 +0100, Alexander Dalloz a ?crit : > > >> What I would like to know - besides resolving the ticketed problem - is >> whether such kind of packages from Fedora Extras will have to carry >> policy modifications / adds themselves or whether approved FE packages >> should come up with Core policy package adjustments. >> > > My understanding in the FC core policy can be updated on request when > the need is clear. Also, pam_abl has been suggested as a future core > component and was not rejected, but put on the backburner, which > suggests some period of testing in extras is wished by Red Hat. This > testing won't happen if the package is blocked by default selinux > policy. > > However it's up to Daniel and the Red Hat selinux team to decide this. > > Regards, > I have added policy to allow for this in tonights rawhide. selinux-policy-targeted-1.27.2-16 > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -- From dwalsh at redhat.com Mon Nov 7 17:29:57 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 07 Nov 2005 12:29:57 -0500 Subject: Problems with httpd and SElinux. In-Reply-To: References: Message-ID: <436F8F15.2080501@redhat.com> Daniel B. Thurman wrote: > Folks, > > I was asked to post this information here. To explain things, > I have installed FrontPage extensions on FC4 but not realizing > that I had to first disable SElinux for httpd first, but to make > a long story short, I was able to install FP and then restore > SElinux protections for httpd, but on reboot, SElinux refused > to allow httpd to start and I suspect it had something to do > with the FrontPage additions to the /etc/httpd/conf/httpd.conf > file. I currently have SElinux protections turned off for > https. Below is the audit file, hope it helps show the problem. > > type=AVC msg=audit(1131056930.757:251): avc: denied { name_bind } for pid=4946 comm="httpd" src=8090 scontext=root:system_r:httpd_t tcontext=system_u:object_r:port_t tclass=tcp_socket > type=SYSCALL msg=audit(1131056930.757:251): arch=40000003 syscall=102 success=no exit=-13 a0=2 a1=bfc779f0 a2=750218 a3=8b8da58 items=0 pid=4946 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="httpd" exe="/usr/sbin/httpd" > type=SOCKADDR msg=audit(1131056930.757:251): saddr=0A001F9A000000000000000000000000000000000000000000000000 > type=SOCKETCALL msg=audit(1131056930.757:251): nargs=3 a0=5 a1=8b8da84 a2=1c > > Kind regards, > Dan > > We do not currently allow apache to listen on port 8090, but this looks legitimate, so I will add to policy. You can install policy (selinux-policy-targeted-sources for now and add a line to /etc/selinux/targeted/src/policy/domains/misc/local.te portcon tcp 8090 system_u:object_r:http_port_t Then execute make -c /etc/selinux/targeted/src/policy load and you should be able to use that port. -- From dwalsh at redhat.com Mon Nov 7 17:35:11 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 07 Nov 2005 12:35:11 -0500 Subject: Syslogd sending output to devpts In-Reply-To: <941F634BDD486A44B80120541613D3D22CFF14@gc._msdcs.jr.secur.net> References: <941F634BDD486A44B80120541613D3D22CFF14@gc._msdcs.jr.secur.net> Message-ID: <436F904F.40603@redhat.com> Jose H. REMY wrote: > Hi, > > Since I've installed SElinux (fedora-release-4-2 > selinux-policy-targeted-1.23.16-6), configured with targeted policy > SELinux status: enabledSELinuxfs mount: > /selinuxCurrent mode: enforcingMode from config file: > enforcingPolicy version: 19Policy from config file: > targeted > I've trouble sending outputs of syslog toward a /dev/pts/* window > > My devpts context : crw--w---- root tty root:object_r:devpts_t > My syslogd context : user_u:system_r:syslogd_t 1872 ? 00:00:00 > syslogdMy syslog.conf context: -rw-r--r-- root root > system_u:object_r:etc_t /etc/syslog.conf > > Thank you for help and explanation (why I don't always have an "avc" denied > message in message log?) > They are being dontaudited. Please update to the latest policy for FC4. This should be allowed. > Thanks, > > Jose H. REMY > > Network administrator > SECUR.NET > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- From rirving at antient.org Mon Nov 7 19:53:35 2005 From: rirving at antient.org (Richard Irving) Date: Mon, 07 Nov 2005 14:53:35 -0500 Subject: FC4 update and SELINUX In-Reply-To: <4c4ba15305012107382086bc90@mail.gmail.com> References: <4c4ba15305012107382086bc90@mail.gmail.com> Message-ID: <436FB0BF.7090408@antient.org> I seem to remember an email passing this way that the latest FC4 targeted update, nagios stopped working. I recall the response was "setenforce permissive, and capture the audit trail"... or something of that nature. Can anyone help refresh my memory ? As, I just got around to testing FC4 on an AMD64, with it set to "permissive" it -all- works.. with NO AVC messages... and with it set to "enforcing", it stops working ... with NO AVC messages. I tried "audit2allow -i /dev/null", but for some reason, that doesn't help me write policy. :-P Anyone have more informative output, or subtle clues ? :-\ TIA! From dwalsh at redhat.com Mon Nov 7 19:58:16 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 07 Nov 2005 14:58:16 -0500 Subject: FC4 update and SELINUX In-Reply-To: <436FB0BF.7090408@antient.org> References: <4c4ba15305012107382086bc90@mail.gmail.com> <436FB0BF.7090408@antient.org> Message-ID: <436FB1D8.2090307@redhat.com> Richard Irving wrote: > I seem to remember an email passing this way > that the latest FC4 targeted update, > nagios stopped working. > > I recall the response was > "setenforce permissive, and capture > the audit trail"... or something of that nature. > > Can anyone help refresh my memory ? > > As, I just got around to testing FC4 on an AMD64, > with it set to "permissive" it -all- works.. > with NO AVC messages... > Are you looking in /var/log/audit/audit.log for avcs? You can turn off all the dontaudit rules by installing selinux-policy-targeted-source cd /etc/selinux/targeted/src/policy make enableaudit; make load make clean; make load will set it back. > and with it set to "enforcing", it stops > working ... > with NO AVC messages. > > I tried "audit2allow -i /dev/null", > but for some reason, that doesn't help me write policy. > > :-P > > Anyone have more informative output, or subtle clues ? > > :-\ > > TIA! > > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -- From sds at tycho.nsa.gov Mon Nov 7 19:57:33 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 07 Nov 2005 14:57:33 -0500 Subject: FC4 update and SELINUX In-Reply-To: <436FB0BF.7090408@antient.org> References: <4c4ba15305012107382086bc90@mail.gmail.com> <436FB0BF.7090408@antient.org> Message-ID: <1131393453.20591.146.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-11-07 at 14:53 -0500, Richard Irving wrote: > As, I just got around to testing FC4 on an AMD64, > with it set to "permissive" it -all- works.. > with NO AVC messages... > > and with it set to "enforcing", it stops > working ... > with NO AVC messages. If there are truly no audit messages (in /var/log/audit/audit.log), then install selinux-policy-targeted-sources if you don't already have them, and then do: cd /etc/selinux/targeted/src/policy make clean enableaudit load cd /etc/selinux/targeted/src/policy make clean load Then look again at audit.log. -- Stephen Smalley National Security Agency From rirving at antient.org Mon Nov 7 20:15:29 2005 From: rirving at antient.org (Richard Irving) Date: Mon, 07 Nov 2005 15:15:29 -0500 Subject: FC4 update and SELINUX In-Reply-To: <1131393453.20591.146.camel@moss-spartans.epoch.ncsc.mil> References: <4c4ba15305012107382086bc90@mail.gmail.com> <436FB0BF.7090408@antient.org> <1131393453.20591.146.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <436FB5E1.7040304@antient.org> Stephen Smalley wrote: >On Mon, 2005-11-07 at 14:53 -0500, Richard Irving wrote: > > >>As, I just got around to testing FC4 on an AMD64, >>with it set to "permissive" it -all- works.. >>with NO AVC messages... >> >>and with it set to "enforcing", it stops >>working ... >>with NO AVC messages. >> >> Dohh... FC3 to FC4 "OHS". Why is the problem always the loose nut in front of the keyboard ? :-) Thanks All! > >If there are truly no audit messages (in /var/log/audit/audit.log), then >install selinux-policy-targeted-sources if you don't already have them, >and then do: >cd /etc/selinux/targeted/src/policy >make clean enableaudit load > >cd /etc/selinux/targeted/src/policy >make clean load > >Then look again at audit.log. > > > From dwalsh at redhat.com Mon Nov 7 20:28:28 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 07 Nov 2005 15:28:28 -0500 Subject: Selinux with Apache running PHP In-Reply-To: <436B2D7C.4000909@hivsa.com> References: <20051103170014.64605739D0@hormel.redhat.com> <436B2D7C.4000909@hivsa.com> Message-ID: <436FB8EC.2000507@redhat.com> Jayendren Anand Maduray wrote: > > Good day all. > > I am having trouble running PHP files in my webserver: Apache. > > Here is some information: > > [root at shiva warez]# rpm -qi php > Name : php Relocations: (not relocatable) > Version : 4.3.11 Vendor: Red Hat, Inc. > Release : 2.7 Build Date: Thu 25 Aug > 2005 11:26:47 SAST > Install Date: Thu 03 Nov 2005 13:51:24 SAST Build Host: > tweety.build.redhat.com > Group : Development/Languages Source RPM: > php-4.3.11-2.7.src.rpm > Size : 3373100 License: The PHP License > Signature : DSA/SHA1, Thu 25 Aug 2005 18:02:04 SAST, Key ID > b44269d04f2a6fd2 > Packager : Red Hat, Inc. > URL : http://www.php.net/ > Summary : The PHP HTML-embedded scripting language. (PHP: > Hypertext Preprocessor) > > [root at shiva warez]# rpm -qi httpd > Name : httpd Relocations: (not relocatable) > Version : 2.0.52 Vendor: Red Hat, Inc. > Release : 3.1 Build Date: Thu 11 Nov > 2004 17:39:18 SAST > Install Date: Fri 22 Apr 2005 08:37:05 SAST Build Host: > dolly.build.redhat.com > Group : System Environment/Daemons Source RPM: > httpd-2.0.52-3.1.src.rpm > Size : 2407431 License: Apache > Software License > Signature : DSA/SHA1, Fri 12 Nov 2004 22:58:01 SAST, Key ID > b44269d04f2a6fd2 > Packager : Red Hat, Inc. > URL : http://httpd.apache.org/ > Summary : The httpd Web server > > [root at shiva warez]# uname -a > Linux shiva 2.6.9-1.667smp #1 SMP Tue Nov 2 14:59:52 EST 2004 i686 > i686 i386 GNU/Linux > > SElinux is running in enforcing mode, and I have disabled protection > for apache. > > I am trying to setup PHP Nuke on my webserver, but it has trouble > running PHP files. > > Also tried the following from the fedora-forum: > > changed permissions of the php files: chmod 755 *.php > turning off SELinux protection, which works of course. > > But I like SELinux!!! > > Please advise. > avc messages should be being created some where. Most likely you have a problem with labeleing of the directory where php-Nuke is installed. http://fedora.redhat.com/docs/selinux-apache-fc3/ Has a great explanation of how to setup apache with SELinux. -- From justin.conover at gmail.com Tue Nov 8 04:30:51 2005 From: justin.conover at gmail.com (Justin Conover) Date: Mon, 7 Nov 2005 22:30:51 -0600 Subject: Multiple same specifications for /sbin/lvm.static. Message-ID: /etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /sbin/lvm.static. I've been getting this error for awhile when I do "yum updates" Running Fedora Core 4 + update testing on this box. I've done fixfiles relable and /.autorelabel several times and I keep seeing this. Do I need to do some kind of restorcon? Thank you, -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayendren at hivsa.com Tue Nov 8 13:31:54 2005 From: jayendren at hivsa.com (Jayendren Anand Maduray) Date: Tue, 08 Nov 2005 15:31:54 +0200 Subject: Selinux with Apache running PHP In-Reply-To: <436FB8EC.2000507@redhat.com> References: <20051103170014.64605739D0@hormel.redhat.com> <436B2D7C.4000909@hivsa.com> <436FB8EC.2000507@redhat.com> Message-ID: <4370A8CA.8010107@hivsa.com> great! God bless. Daniel J Walsh wrote: > Jayendren Anand Maduray wrote: > >> >> Good day all. >> >> I am having trouble running PHP files in my webserver: Apache. >> >> Here is some information: >> >> [root at shiva warez]# rpm -qi php >> Name : php Relocations: (not >> relocatable) >> Version : 4.3.11 Vendor: Red Hat, Inc. >> Release : 2.7 Build Date: Thu 25 Aug >> 2005 11:26:47 SAST >> Install Date: Thu 03 Nov 2005 13:51:24 SAST Build Host: >> tweety.build.redhat.com >> Group : Development/Languages Source RPM: >> php-4.3.11-2.7.src.rpm >> Size : 3373100 License: The PHP License >> Signature : DSA/SHA1, Thu 25 Aug 2005 18:02:04 SAST, Key ID >> b44269d04f2a6fd2 >> Packager : Red Hat, Inc. >> URL : http://www.php.net/ >> Summary : The PHP HTML-embedded scripting language. (PHP: >> Hypertext Preprocessor) >> >> [root at shiva warez]# rpm -qi httpd >> Name : httpd Relocations: (not >> relocatable) >> Version : 2.0.52 Vendor: Red Hat, Inc. >> Release : 3.1 Build Date: Thu 11 Nov >> 2004 17:39:18 SAST >> Install Date: Fri 22 Apr 2005 08:37:05 SAST Build Host: >> dolly.build.redhat.com >> Group : System Environment/Daemons Source RPM: >> httpd-2.0.52-3.1.src.rpm >> Size : 2407431 License: Apache >> Software License >> Signature : DSA/SHA1, Fri 12 Nov 2004 22:58:01 SAST, Key ID >> b44269d04f2a6fd2 >> Packager : Red Hat, Inc. >> URL : http://httpd.apache.org/ >> Summary : The httpd Web server >> >> [root at shiva warez]# uname -a >> Linux shiva 2.6.9-1.667smp #1 SMP Tue Nov 2 14:59:52 EST 2004 i686 >> i686 i386 GNU/Linux >> >> SElinux is running in enforcing mode, and I have disabled protection >> for apache. >> >> I am trying to setup PHP Nuke on my webserver, but it has trouble >> running PHP files. >> >> Also tried the following from the fedora-forum: >> >> changed permissions of the php files: chmod 755 *.php >> turning off SELinux protection, which works of course. >> >> But I like SELinux!!! >> >> Please advise. >> > avc messages should be being created some where. Most likely you have > a problem with labeleing of the directory where php-Nuke is installed. > > http://fedora.redhat.com/docs/selinux-apache-fc3/ > > Has a great explanation of how to setup apache with SELinux. > > -- Jayendren Anand Maduray Microsoft Certified Professional Network Plus IT Administrator Perinatal HIV Research Unit Wits Health Consortium University of the Witwatersrand Old Potch Road Chris Hani Baragwanath Hospital Soweto South Africa Tel: +27 11 989 9776 Tel: +27 11 989 9999 Fax: +27 11 938 3973 Cel: 082 22 774 94 Alternate email address: jayendren at mweb.co.za From linux_4ever at yahoo.com Tue Nov 8 16:28:52 2005 From: linux_4ever at yahoo.com (Steve G) Date: Tue, 8 Nov 2005 08:28:52 -0800 (PST) Subject: Multiple same specifications for /sbin/lvm.static. In-Reply-To: Message-ID: <20051108162852.81830.qmail@web51501.mail.yahoo.com> >several times and I keep seeing this. Do I need to do some kind of restorcon? This message comes straight out of libselinux when it sees a policy problem. This bug should have been caught by when the policy was built in my opinion. You need to update to a new policy to get rid of it. -Steve __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com From justin.conover at gmail.com Tue Nov 8 17:58:35 2005 From: justin.conover at gmail.com (Justin Conover) Date: Tue, 8 Nov 2005 11:58:35 -0600 Subject: Multiple same specifications for /sbin/lvm.static. In-Reply-To: <20051108162852.81830.qmail@web51501.mail.yahoo.com> References: <20051108162852.81830.qmail@web51501.mail.yahoo.com> Message-ID: On 11/8/05, Steve G wrote: > > > >several times and I keep seeing this. Do I need to do some kind of > restorcon? > > This message comes straight out of libselinux when it sees a policy > problem. This > bug should have been caught by when the policy was built in my opinion. > You need > to update to a new policy to get rid of it. > > -Steve > > > > > __________________________________ > Yahoo! FareChase: Search multiple travel sites in one click. > http://farechase.yahoo.com > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Is this ok [y/N]: y Downloading Packages: (1/2): audit-libs-1.0.12- 100% |=========================| 35 kB 00:00 (2/2): audit-1.0.12-1.fc4 100% |=========================| 170 kB 00:00 Running Transaction Test /etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /sbin/lvm.static. Finished Transaction Test Transaction Test Succeeded Running Transaction /etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /sbin/lvm.static. Updating : audit-libs ######################### [1/4] Updating : audit ######################### [2/4] Cleanup : audit-libs ######################### [3/4] Cleanup : audit ######################### [4/4] Updated: audit.i386 0:1.0.12-1.fc4 audit-libs.i386 0:1.0.12-1.fc4 Complete! $ rpm -qa *\selinux\* libselinux-1.23.10-2 selinux-policy-targeted-1.27.1-2.13 libselinux-devel-1.23.10-2 The selinux-policy-targeted version if from updates-testing. Should I file a bug on this or the libselinux packages? Thank you, -------------- next part -------------- An HTML attachment was scrubbed... URL: From linux_4ever at yahoo.com Tue Nov 8 22:56:28 2005 From: linux_4ever at yahoo.com (Steve G) Date: Tue, 8 Nov 2005 14:56:28 -0800 (PST) Subject: Multiple same specifications for /sbin/lvm.static. In-Reply-To: Message-ID: <20051108225628.37937.qmail@web51505.mail.yahoo.com> >Should I file a bug on this or the libselinux packages? Its a policy bug. -Steve __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com From subscribed-lists at sterndata.com Wed Nov 9 00:28:41 2005 From: subscribed-lists at sterndata.com (Steven Stern) Date: Tue, 08 Nov 2005 18:28:41 -0600 Subject: SELINUX problem and SPAMASSASSIN Message-ID: <437142B9.9020306@sterndata.com> I just built a new FC4 machine and am migrating my mail server to it. I got an error each time I started spamassassin until I put selinux into permissive mode. How can I configure selinux to allow this? Nov 8 17:23:19 mooch spamd[4899]: Error creating a DNS resolver socket: Permission denied at /usr/lib/perl5/site_perl/5.8.6/Mail/SpamAssassin/DnsResolver.pm line 202, line 44. -- Steve From r.godzilla at comcast.net Wed Nov 9 01:17:00 2005 From: r.godzilla at comcast.net (Richard E Miles) Date: Tue, 8 Nov 2005 17:17:00 -0800 Subject: selinux is giving me denied messages for spamassassin Message-ID: <20051108171700.4d68fbcd.r.godzilla@comcast.net> I noticed that other people are getting AVC denied messages when using spamassassin. I checked my audit log and am also getting denied messages. type=AVC msg=audit(1131216876.860:2091): avc: denied { getattr } for pid=2205 comm="spamd" name=".spamassassin" dev=dm-0 ino=11929746 scontext=system_u:system_r:spamd_t tcontext=user_u:object_r:user_home_t tclass=dir I have many many of theses type messages. How can I get spamassassin to work with selinux? -- Richard Miles Federal Way WA. USA registered linux user 46097 From justin.conover at gmail.com Wed Nov 9 16:06:27 2005 From: justin.conover at gmail.com (Justin Conover) Date: Wed, 9 Nov 2005 10:06:27 -0600 Subject: Multiple same specifications for /sbin/lvm.static. In-Reply-To: <20051108225628.37937.qmail@web51505.mail.yahoo.com> References: <20051108225628.37937.qmail@web51505.mail.yahoo.com> Message-ID: On 11/8/05, Steve G wrote: > > > >Should I file a bug on this or the libselinux packages? > > Its a policy bug. > > -Steve > > > > __________________________________ > Yahoo! FareChase: Search multiple travel sites in one click. > http://farechase.yahoo.com > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172479 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jose.Remy at SECUR.NET Thu Nov 10 10:08:49 2005 From: Jose.Remy at SECUR.NET (Jose H. REMY) Date: Thu, 10 Nov 2005 11:08:49 +0100 Subject: Syslogd sending output to devpts Message-ID: <941F634BDD486A44B80120541613D3D22CFF1A@gc._msdcs.jr.secur.net> I have updated to selinux-policy-targeted-1.27.1-2.11, and still be unable to send logs to /dev/pts/* ...........audit.log type=PATH msg=audit(1131616982.431:2085578): item=0 name="/dev/pts/2" inode=1 de v=00:09 mode=040755 ouid=0 ogid=0 rdev=00:00 type=SYSCALL msg=audit(1131616982.431:2085578): arch=40000003 syscall=5 success= no exit=-13 a0=bfa18cda a1=8541 a2=1a4 a3=1 items=1 pid=331 auid=4294967295 uid= 0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="syslogd" exe="/sbin/sy slogd" type=AVC msg=audit(1131616982.431:2085578): avc: denied { append } for pid=33 1 comm="syslogd" name=2 dev=devpts ino=4 scontext=root:system_r:syslogd_t tconte xt=root:object_r:devpts_t tclass=chr_file Jose H. REMY Network administrator -----Original Message----- From: Daniel J Walsh [mailto:dwalsh at redhat.com] Sent: Monday, November 07, 2005 18:35 To: Jose H. REMY Cc: 'fedora-selinux-list at redhat.com' Subject: Re: Syslogd sending output to devpts Jose H. REMY wrote: > Hi, > > Since I've installed SElinux (fedora-release-4-2 > selinux-policy-targeted-1.23.16-6), configured with targeted policy > SELinux status: enabledSELinuxfs mount: > /selinuxCurrent mode: enforcingMode from config file: > enforcingPolicy version: 19Policy from config file: > targeted > I've trouble sending outputs of syslog toward a /dev/pts/* window > > My devpts context : crw--w---- root tty root:object_r:devpts_t > My syslogd context : user_u:system_r:syslogd_t 1872 ? 00:00:00 > syslogdMy syslog.conf context: -rw-r--r-- root root > system_u:object_r:etc_t /etc/syslog.conf > > Thank you for help and explanation (why I don't always have an "avc" denied > message in message log?) > They are being dontaudited. Please update to the latest policy for FC4. This should be allowed. > Thanks, > > Jose H. REMY > > Network administrator > SECUR.NET > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-. -.-. -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-. ATTENTION: This message was automatically controled and filtered. S/MIME will not work, use file encryption/signing instead. Ce message INTERNET a ete controle et filtre par SECUR.NET (filtres: Anomy HTML_cleaner, HTML_parser, MIME_tools); (antivirus: File_Scan, CLAMAV, MacAFEE) postmaster at localhost -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-. -.-. -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-. From malejandra.castillo at gmail.com Thu Nov 10 15:46:11 2005 From: malejandra.castillo at gmail.com (Ma. Alejandra Castillo) Date: Thu, 10 Nov 2005 12:46:11 -0300 Subject: Seaudit in fedora Core 4 Message-ID: <25a49afb0511100746g2b31a8dch@mail.gmail.com> I am occupying the tool seaudit in fedora core 4, but the fields host and executablee they appear always empty, what is very strange. I am charging /var/log/audit.log, some suggestion so that these fields appear? Saludos -- Ma. Alejandra Castillo M. From sds at tycho.nsa.gov Thu Nov 10 18:27:54 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 10 Nov 2005 13:27:54 -0500 Subject: Seaudit in fedora Core 4 In-Reply-To: <25a49afb0511100746g2b31a8dch@mail.gmail.com> References: <25a49afb0511100746g2b31a8dch@mail.gmail.com> Message-ID: <1131647274.19626.104.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-11-10 at 12:46 -0300, Ma. Alejandra Castillo wrote: > I am occupying the tool seaudit in fedora core 4, but the fields host > and executablee they appear always empty, what is very strange. I am > charging /var/log/audit.log, some suggestion so that these fields > appear? Logging of the executable path migrated from the SELinux avc audit code to the syscall audit code due to a deadlock issue, so avc messages only include the comm= information now. However, whenever an avc message is generated, a syscall audit record is also generated when the syscall exits, and that includes the exe= information. The two messages can be correlated using the audit event id. I don't know if newer versions of seaudit perform such correlation or not. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Thu Nov 10 18:31:32 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 10 Nov 2005 13:31:32 -0500 Subject: Seaudit in fedora Core 4 In-Reply-To: <1131647274.19626.104.camel@moss-spartans.epoch.ncsc.mil> References: <25a49afb0511100746g2b31a8dch@mail.gmail.com> <1131647274.19626.104.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1131647492.19626.106.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-11-10 at 13:27 -0500, Stephen Smalley wrote: > On Thu, 2005-11-10 at 12:46 -0300, Ma. Alejandra Castillo wrote: > > I am occupying the tool seaudit in fedora core 4, but the fields host > > and executablee they appear always empty, what is very strange. I am > > charging /var/log/audit.log, some suggestion so that these fields > > appear? > > Logging of the executable path migrated from the SELinux avc audit code > to the syscall audit code due to a deadlock issue, so avc messages only > include the comm= information now. However, whenever an avc message is > generated, a syscall audit record is also generated when the syscall > exits, and that includes the exe= information. The two messages can be > correlated using the audit event id. I don't know if newer versions of > seaudit perform such correlation or not. BTW, you can also use aureport and ausearch to query the audit logs. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Thu Nov 10 20:18:39 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 10 Nov 2005 15:18:39 -0500 Subject: Problems with httpd and SElinux. In-Reply-To: References: Message-ID: <4373AB1F.5010301@redhat.com> Daniel B. Thurman wrote: >> From: Daniel J Walsh [mailto:dwalsh at redhat.com] >> Sent: Monday, November 07, 2005 9:30 AM >> To: Daniel B. Thurman >> Cc: fedora-selinux-list at redhat.com >> Subject: Re: Problems with httpd and SElinux. >> >> >> Daniel B. Thurman wrote: >> >>> Folks, >>> >>> I was asked to post this information here. To explain things, >>> I have installed FrontPage extensions on FC4 but not realizing >>> that I had to first disable SElinux for httpd first, but to make >>> a long story short, I was able to install FP and then restore >>> SElinux protections for httpd, but on reboot, SElinux refused >>> to allow httpd to start and I suspect it had something to do >>> with the FrontPage additions to the /etc/httpd/conf/httpd.conf >>> file. I currently have SElinux protections turned off for >>> https. Below is the audit file, hope it helps show the problem. >>> >>> type=AVC msg=audit(1131056930.757:251): avc: denied { >>> >> name_bind } for pid=4946 comm="httpd" src=8090 >> scontext=root:system_r:httpd_t >> tcontext=system_u:object_r:port_t tclass=tcp_socket >> >>> type=SYSCALL msg=audit(1131056930.757:251): arch=40000003 >>> >> syscall=102 success=no exit=-13 a0=2 a1=bfc779f0 a2=750218 >> a3=8b8da58 items=0 pid=4946 auid=4294967295 uid=0 gid=0 euid=0 >> suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="httpd" exe="/usr/sbin/httpd" >> >>> type=SOCKADDR msg=audit(1131056930.757:251): >>> >> saddr=0A001F9A000000000000000000000000000000000000000000000000 >> >>> type=SOCKETCALL msg=audit(1131056930.757:251): nargs=3 a0=5 >>> >> a1=8b8da84 a2=1c >> >>> Kind regards, >>> Dan >>> >>> >>> >> We do not currently allow apache to listen on port 8090, >> but this looks legitimate, so I will add to policy. >> You can install policy (selinux-policy-targeted-sources >> for now and add a line to: >> /etc/selinux/targeted/src/policy/domains/misc/local.te >> portcon tcp 8090 system_u:object_r:http_port_t >> >> Then execute make -c /etc/selinux/targeted/src/policy load >> >> and you should be able to use that port. >> >> > > The information you gave me above does not work. I got all > sorts of compile errors. BTW, the make should be "make -C". > > From Paul Howarth, I tried: > ============================================= > If you want httpd to be able to listen on port 8090, and you have the > policy sources installed, you can do this by adding the following line > to /etc/selinux/targeted/src/policy/net_contexts: > > portcon tcp 8090 system_u:object_r:http_port_t > > Then you need to compile and reload the security contexts: > # make -C /etc/selinux/targeted/src/policy reload > ============================================= > > This all compiles fine now. > > Testing to see if httpd can now restart with the new policies: > 1) setsebool -P httpd_disable_trans 0 > 2) Restart httpd for this to take effect: service httpd restart > > Httpd can restart with no failure messages. The httpd server > now runs fine. > > HOWEVER - Testing FrontPage client against my FC4 box FAILS to > connect and the reason revealed in /var/log/httpd/error_log: > > [Tue Nov 08 15:25:40 2005] [error] (13)Permission denied: Could not create key file "/usr/local/frontpage/version5.0/apache-fp/suidkey.17096" in FrontPageInit(). Until this problem is fixed, the FrontPage security patch is disabled and the FrontPage extensions may not work correctly. > > I suspect that there is a SElinux policy that is preventing the FP > client program from creating and deleting the suidkey file it needs > in order to startup and begin listening for FP Client requests. Please > note that the process number is created and destroyed for the suidkey file > and this is happening from within the httpd service file and has nothing > to do with the FP client connection attempts. SELinux policy is preventing > the service file from creating and destroying this file. > > So - in order to get back the successful FP client connections as before, > performing these steps: > > 1) setsebool -P httpd_disable_trans 1 > 2) Restart httpd for this to take effect: service httpd restart > > The httpd/error_log error message does not appear and I can now > connect with to the FC4 with the FP client. > > Dan Thurman. > > What did you see for AVC messages in /var/log/messages or /var/log/audit/audit.log? -- From linux_4ever at yahoo.com Fri Nov 11 13:16:50 2005 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 11 Nov 2005 05:16:50 -0800 (PST) Subject: Seaudit in fedora Core 4 In-Reply-To: <1131647492.19626.106.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20051111131651.69289.qmail@web51503.mail.yahoo.com> >BTW, you can also use aureport and ausearch to query the audit logs. If you use aureport and it doesn't do something you need, let me know. I'm still working on it and I'm looking for feedback. Thanks, -Steve __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From mike at easysw.com Fri Nov 11 15:47:11 2005 From: mike at easysw.com (Michael Sweet) Date: Fri, 11 Nov 2005 10:47:11 -0500 Subject: [patch] CUPS 1.2 SELinux policy changes... Message-ID: <4374BCFF.5080603@easysw.com> [Posting here for lack of a better place...] Attached is a patch against the current selinux.sourceforge.net repo, along with an archive of additional files that contain the policies for non-CUPS software. The patch fixes incompatibilities with the current CUPS 1.2 software and removes the non-CUPS software rules from the CUPS policy files. The CUPS 1.2 changes involve adding domain socket support and adding the new files and directories introduced in 1.2... I removed the non-CUPS rules because the mix of software makes debugging and validating the CUPS policies that much harder, and it makes sense to maintain the policies for separate projects separately... Anyways, comments welcome! -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Internet Printing and Publishing Software http://www.easysw.com -------------- next part -------------- A non-text attachment was scrubbed... Name: cups-1.2-moved.tar.gz Type: application/x-gzip Size: 2235 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cups-1.2.patch Type: text/x-patch Size: 15716 bytes Desc: not available URL: From mshaw at dowco.com Fri Nov 11 20:02:12 2005 From: mshaw at dowco.com (Michael Shaw) Date: Fri, 11 Nov 2005 12:02:12 -0800 Subject: Apache, Virtual Servers and SELinux Message-ID: <4374F8C4.8070907@dowco.com> Hi all, I installed Apache on an FC4 machine, and I was trying to get Virtual servers working. To do so, I had the following name based virtual servers. I placed the following directives (among others) in my httpd.conf file: ~~~~~~~~~~~~ # Virtual host default ServerName default DocumentRoot "/var/www/html" DirectoryIndex index.php index.html index.htm index.shtml LogLevel debug HostNameLookups off # Virtual host michael ServerAdmin mshaw at dowco.com DocumentRoot /home/michael/public_html/www ServerName michael DirectoryIndex index.html index.php Options Indexes Includes FollowSymLinks AllowOverride None Allow from all Order allow,deny Options Indexes Includes FollowSymLinks AllowOverride None Order allow,deny Allow from all ~~~~~~~~~~~~ I was very fristrated that the virtual server michael get giving me access denied errors. I disabled SELinux and everythign worked. So I tried fiddling away with all the HTTPD settings but cou;dn't get it to work with SELinux on, including "Allow HTTPD to read home directories". I have seen references to this on the Internet but not a cure. Which check box am I missing? From russell at coker.com.au Sat Nov 12 07:21:38 2005 From: russell at coker.com.au (Russell Coker) Date: Sat, 12 Nov 2005 18:21:38 +1100 Subject: [patch] CUPS 1.2 SELinux policy changes... In-Reply-To: <4374BCFF.5080603@easysw.com> References: <4374BCFF.5080603@easysw.com> Message-ID: <200511121821.44719.russell@coker.com.au> On Saturday 12 November 2005 02:47, Michael Sweet wrote: > I removed the non-CUPS rules because the mix of software makes > debugging and validating the CUPS policies that much harder, and it > makes sense to maintain the policies for separate projects > separately... Firstly, please test your patches first. There is no name_connect access in the unix_stream_socket class or a seteuid capability. Please don't remove comments such as "this is not ideal, and allowing setattr access to cupsd_etc_t is wrong". That's a design flaw in cupsd, eventually we want to fix it. Removing the comment decreases the chance of such a design flaw ever being corrected. The hplip and ptal policies are OK in the same file as cups. They are printer-specific programs. Having separate lpd and cups files is more of a problem. As we seem to be moving away from the traditional lpd we will probably change things in this regard. When there is policy involving access between initrc_t and the domains/types defined in a daemon policy file then this belongs in the policy file for the daemon. Important files such as initrc.te should not have sections for all the many daemons that need to interact with them. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From rhp.lpt at gmail.com Sat Nov 12 08:23:25 2005 From: rhp.lpt at gmail.com (rhp) Date: Sat, 12 Nov 2005 15:23:25 +0700 Subject: SELinux silently disabled on boot under 2.6.14/2.6.14.2 on FC3 system ? Message-ID: 12-nov-05 Hello: I have a FC3 box which requires compiling the kernel from source to accomodate acpi & ec.c related hardware quirks, (its a generic laptop). When compiling & installing the latest kernels, I have discovered an apparent problem with both the 2.6.14 & 2.6.14.2 kernels and SELinux. After compiling these kernels, SELinux is silently disabled on boot; e.g.: sestatus shows SELinux as disabled regardless of /etc/selinux/config being set for 'Permissive-targeted'. ps -Z & ls -Z show no xattributes but returns these values/messages: torus:~/selinux/kernel-tests> ps -Z LABEL PID TTY TIME CMD kernel 3979 pts/6 00:00:00 tcsh kernel 4005 pts/6 00:00:00 ps torus:~/selinux/kernel-tests> ls -Z Sorry, this option can only be used on a SELinux kernel. dmesg does not have any further SELinux entries after these four: SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability SELinux: Registering netfilter hooks nor are there any error messages in /var/log/messages. Kernels built from the 2.6.13.4 & 2.6.12-1.1381_FC3, source trees both work normally with regard to SELinux. After a comparison of the '.config' files from the related builds, I've noticed that the 2.6.14 and 2.6.14.2 kernels no longer support extended attributes for the pseudo filesystems, while the 2.6.13.4 and 2.6.12-1.1381_FC3 kernels do support the extended attributes, this is the only significant difference I could find between these kernels' '.config' files. i.e. Referring to 'make xconfig': in linux-2.6.14/linux-2.6.14.2 these two filesystems no longer exist: 'Psuedo Filesystems -> /dev/pts Extended Attributes -> /dev/pts Security Labels''Psuedo Filesystems -> Virtual memory file system support -> tmpfs Extended Attributes -> tmpfs Security Lables'. Note these error messages were returned when using the '.config' from 2.6.13.4 as a starting point for the '.config' in the 2.6.14/2.6.14.2 trees: /boot/config-2.6.13.4:2649: trying to assign nonexistent symbol DEVPTS_FS_XATTR /boot/config-2.6.13.4:2650: trying to assign nonexistent symbol DEVPTS_FS_SECURITY The Help sections for these options from the 2.6.13.4 kernel indicate these are used by Selinux: Help for /dev/pts Security Labels (DEVPTS_FS_SECURITY) "Security labels support alternative access control models implemented by security modules like SELinux. This option enables an extended attribute handler for file security label in the /dev/pts filesystem. If you are not using a security module that requires using extended attributes for file security labels, say N." Help for tmpfs Security Labels (TMPFS_SECURITY) "Security labels support alternative access control models implemented by security modules like SELinux. This option enables an extended attribute handler for file security labels in the tmpfs filesystem. If you are not using a security module that requires using extended attributes for file security labels, say N." I would like to stress that _All_ previous 2.6 kernels that I have tried prior to 2.6.14 work as expected with regard to SELinux. Has there been a change to SELinux in the FC4 tree but not in the FC3 tree which anticipated this disappearance of the extended attributes in the 2.6.14 kernel's pseudo filesystems - or am I on the wrong track ? Here is my current selinux configuration: selinux-doc-1.14.1-1 selinux-policy-targeted-sources-1.17.30-3.16 libselinux-1.23.10-2 libselinux-devel-1.23.10-2 selinux-policy-targeted-1.17.30-3.16 setools-gui-2.1.1-2 setools-2.1.1-2 checkpolicy-1.23.1-1 I intend to upgrade to FC4/FC5 when I can get the disks, and wonder if the problem could be due to subtle conflicts in the above configuration rather than the disappearance of the extended attributes in the psuedo filesystem in the 2.6.14 kernel series. Thank you, Brgds Bob -- rhp.lpt at gmail.com From mike at easysw.com Sat Nov 12 13:18:30 2005 From: mike at easysw.com (Michael Sweet) Date: Sat, 12 Nov 2005 08:18:30 -0500 Subject: [patch] CUPS 1.2 SELinux policy changes... In-Reply-To: <200511121821.44719.russell@coker.com.au> References: <4374BCFF.5080603@easysw.com> <200511121821.44719.russell@coker.com.au> Message-ID: <4375EBA6.7050807@easysw.com> Russell Coker wrote: > On Saturday 12 November 2005 02:47, Michael Sweet wrote: >> I removed the non-CUPS rules because the mix of software makes >> debugging and validating the CUPS policies that much harder, and it >> makes sense to maintain the policies for separate projects >> separately... > > Firstly, please test your patches first. There is no name_connect access in > the unix_stream_socket class or a seteuid capability. Sorry, I had tested the file context changes but not the rest (still getting my feet wet). I mainly wanted to a) alert folks to a problem with the current policy and b) get feedback. > Please don't remove comments such as "this is not ideal, and allowing setattr > access to cupsd_etc_t is wrong". That's a design flaw in cupsd, eventually > we want to fix it. Removing the comment decreases the chance of such a > design flaw ever being corrected. Well, given that the comment does not describe the "design flaw" in enough detail to be useful, and that no one has posted this "design flaw" to any of the CUPS forums or the STR page on the CUPS site, it seemed like I was removing a comment that was confusing and uninformative. What is the design flaw? > The hplip and ptal policies are OK in the same file as cups. They are > printer-specific programs. Having separate lpd and cups files is more of a > problem. As we seem to be moving away from the traditional lpd we will > probably change things in this regard. > > When there is policy involving access between initrc_t and the domains/types > defined in a daemon policy file then this belongs in the policy file for the > daemon. Important files such as initrc.te should not have sections for all > the many daemons that need to interact with them. Fair enough. Can we at least segment the rules in each of the files so that it is clear which rules apply to which sub-programs? -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Internet Printing and Publishing Software http://www.easysw.com From russell at coker.com.au Sat Nov 12 13:46:12 2005 From: russell at coker.com.au (Russell Coker) Date: Sun, 13 Nov 2005 00:46:12 +1100 Subject: [patch] CUPS 1.2 SELinux policy changes... In-Reply-To: <4375EBA6.7050807@easysw.com> References: <4374BCFF.5080603@easysw.com> <200511121821.44719.russell@coker.com.au> <4375EBA6.7050807@easysw.com> Message-ID: <200511130046.19443.russell@coker.com.au> On Sunday 13 November 2005 00:18, Michael Sweet wrote: > > Please don't remove comments such as "this is not ideal, and allowing > > setattr access to cupsd_etc_t is wrong". That's a design flaw in cupsd, > > eventually we want to fix it. Removing the comment decreases the chance > > of such a design flaw ever being corrected. > > Well, given that the comment does not describe the "design flaw" in > enough detail to be useful, and that no one has posted this "design > flaw" to any of the CUPS forums or the STR page on the CUPS site, it > seemed like I was removing a comment that was confusing and > uninformative. > > What is the design flaw? The fact that cups requires write access to it's config directory and all config files. > > The hplip and ptal policies are OK in the same file as cups. They are > > printer-specific programs. Having separate lpd and cups files is more of > > a problem. As we seem to be moving away from the traditional lpd we will > > probably change things in this regard. > > > > When there is policy involving access between initrc_t and the > > domains/types defined in a daemon policy file then this belongs in the > > policy file for the daemon. Important files such as initrc.te should not > > have sections for all the many daemons that need to interact with them. > > Fair enough. Can we at least segment the rules in each of the files > so that it is clear which rules apply to which sub-programs? Sure. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From mike at easysw.com Sat Nov 12 14:44:08 2005 From: mike at easysw.com (Michael Sweet) Date: Sat, 12 Nov 2005 09:44:08 -0500 Subject: [patch] CUPS 1.2 SELinux policy changes... In-Reply-To: <200511130046.19443.russell@coker.com.au> References: <4374BCFF.5080603@easysw.com> <200511121821.44719.russell@coker.com.au> <4375EBA6.7050807@easysw.com> <200511130046.19443.russell@coker.com.au> Message-ID: <4375FFB8.3070206@easysw.com> Russell Coker wrote: > On Sunday 13 November 2005 00:18, Michael Sweet wrote: >>> Please don't remove comments such as "this is not ideal, and allowing >>> setattr access to cupsd_etc_t is wrong". That's a design flaw in cupsd, >>> eventually we want to fix it. Removing the comment decreases the chance >>> of such a design flaw ever being corrected. >> Well, given that the comment does not describe the "design flaw" in >> enough detail to be useful, and that no one has posted this "design >> flaw" to any of the CUPS forums or the STR page on the CUPS site, it >> seemed like I was removing a comment that was confusing and >> uninformative. >> >> What is the design flaw? > > The fact that cups requires write access to it's config directory and all > config files. I know some people would prefer to hand-edit all files and place printer state data in 5 different places, however no one has proposed an alternate location for these files that makes sense WRT to the FHS. We are absolutely committed to making CUPS easy-to-use, which means allowing programs (in particular cupsd, which can provide finer-grained authorization/access control to the configuration data than selinux) to edit those files. CUPS also updates the printers.conf, classes.conf, and subscriptions.conf files based on (persistent) state changes. Anyways, I will update the comment to reflect this discussion. ........ On a related note, you have comments on a few other rules I'm not clear on: # temporary solution, we need something better allow cupsd_t serial_device:chr_file rw_file_perms; I'm guessing this refers to allowing write access to all serial ports? Any thoughts/wishes on this end? We've looked at a variety of schemes to identifying serial printer ports - providing separate device links would seem to be the simplest solution - but there would need to be some standardization (i.e. Linux distributors need to use it) for it to be effective. # for /var/lib/defoma allow cupsd_t var_lib_t:dir search; r_dir_file(cupsd_t, readable_t) This appears to provide read/search access to files in /var/lib, but I'm confused by the "defoma" bit? # lots of errors generated requiring the following allow cupsd_t self:netlink_audit_socket { create_netlink_socket_perms nlmsg_relay }; allow cupsd_t self:netlink_route_socket { r_netlink_socket_perms }; What errors are generated? What programs are involved? Why are we allowing rather than fixing? Thanks again for your feedback - I hope my next patch will be both less invasive and more accurate... :) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Internet Printing and Publishing Software http://www.easysw.com From paul at city-fan.org Sat Nov 12 16:22:30 2005 From: paul at city-fan.org (Paul Howarth) Date: Sat, 12 Nov 2005 16:22:30 +0000 Subject: Apache, Virtual Servers and SELinux In-Reply-To: <4374F8C4.8070907@dowco.com> References: <4374F8C4.8070907@dowco.com> Message-ID: <1131812550.3668.280.camel@laurel.intra.city-fan.org> On Fri, 2005-11-11 at 12:02 -0800, Michael Shaw wrote: > Hi all, > > I installed Apache on an FC4 machine, and I was trying to get Virtual > servers working. To do so, I had the following name based virtual > servers. I placed the following directives (among others) in my > httpd.conf file: > > ~~~~~~~~~~~~ > # Virtual host default > > ServerName default > DocumentRoot "/var/www/html" > DirectoryIndex index.php index.html index.htm index.shtml > LogLevel debug > HostNameLookups off > > > # Virtual host michael > > ServerAdmin mshaw at dowco.com > DocumentRoot /home/michael/public_html/www > ServerName michael > DirectoryIndex index.html index.php > > > > Options Indexes Includes FollowSymLinks > AllowOverride None > Allow from all > Order allow,deny > > > > Options Indexes Includes FollowSymLinks > AllowOverride None > Order allow,deny > Allow from all > > ~~~~~~~~~~~~ > > I was very fristrated that the virtual server michael get giving me > access denied errors. I disabled SELinux and everythign worked. So I > tried fiddling away with all the HTTPD settings but cou;dn't get it to > work with SELinux on, including "Allow HTTPD to read home directories". > > I have seen references to this on the Internet but not a cure. Which > check box am I missing? Make sure your httpd-readable files have the correct context: $ chcon -R -t httpd_user_content_t /home/michael/public_html/www Paul. -- Paul Howarth From mshaw at dowco.com Sat Nov 12 19:06:12 2005 From: mshaw at dowco.com (Michael Shaw) Date: Sat, 12 Nov 2005 11:06:12 -0800 Subject: Apache, Virtual Servers and SELinux In-Reply-To: <1131812550.3668.280.camel@laurel.intra.city-fan.org> References: <4374F8C4.8070907@dowco.com> <1131812550.3668.280.camel@laurel.intra.city-fan.org> Message-ID: <43763D24.8040102@dowco.com> Paul Howarth wrote: >On Fri, 2005-11-11 at 12:02 -0800, Michael Shaw wrote: > > >>Hi all, >> >>I installed Apache on an FC4 machine, and I was trying to get Virtual >>servers working. To do so, I had the following name based virtual >>servers. I placed the following directives (among others) in my >>httpd.conf file: >> >>~~~~~~~~~~~~ >># Virtual host default >> >> ServerName default >> DocumentRoot "/var/www/html" >> DirectoryIndex index.php index.html index.htm index.shtml >> LogLevel debug >> HostNameLookups off >> >> >># Virtual host michael >> >> ServerAdmin mshaw at dowco.com >> DocumentRoot /home/michael/public_html/www >> ServerName michael >> DirectoryIndex index.html index.php >> >> >> >> Options Indexes Includes FollowSymLinks >> AllowOverride None >> Allow from all >> Order allow,deny >> >> >> >> Options Indexes Includes FollowSymLinks >> AllowOverride None >> Order allow,deny >> Allow from all >> >>~~~~~~~~~~~~ >> >>I was very fristrated that the virtual server michael get giving me >>access denied errors. I disabled SELinux and everythign worked. So I >>tried fiddling away with all the HTTPD settings but cou;dn't get it to >>work with SELinux on, including "Allow HTTPD to read home directories". >> >>I have seen references to this on the Internet but not a cure. Which >>check box am I missing? >> >> > >Make sure your httpd-readable files have the correct context: > >$ chcon -R -t httpd_user_content_t /home/michael/public_html/www > >Paul. > > Never mind, changed my configuration to use the method at http://httpd.apache.org/doc/2.0/vhosts/mass.html#simple and now SELinux works when I allow access to home directories. Though I will have to study what chcon mans: I know it means change context, but I will have to get used to it with cmod and chown. Thanks though. Michael From sds at tycho.nsa.gov Mon Nov 14 13:56:47 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 14 Nov 2005 08:56:47 -0500 Subject: SELinux silently disabled on boot under 2.6.14/2.6.14.2 on FC3 system ? In-Reply-To: References: Message-ID: <1131976607.5415.46.camel@moss-spartans.epoch.ncsc.mil> On Sat, 2005-11-12 at 15:23 +0700, rhp wrote: > I have a FC3 box which requires compiling the kernel from source to accomodate > acpi & ec.c related hardware quirks, (its a generic laptop). > > When compiling & installing the latest kernels, I have discovered an apparent > problem with both the 2.6.14 & 2.6.14.2 kernels and SELinux. > > After compiling these kernels, SELinux is silently disabled on boot; > > e.g.: > > sestatus shows SELinux as disabled regardless of /etc/selinux/config > being set for 'Permissive-targeted'. Yes, this is a known issue. /sbin/init in FC3 (and FC4) only tries loading the current binary policy format version supported by the kernel and one version lower before giving up altogether, and there have been two version increments since FC3 was shipped. Note that if your /etc/selinux/config was set to enforcing, /sbin/init should have halted the system at that point; it was only because it was permissive that it proceeded. However I'd agree that the lack of any log message about the inability to load policy is undesirable - not sure why that is. In rawhide, /sbin/init has been changed to use a libselinux helper function to load policy that is more resilient in several respects, and I think that the plan was to back port those changes to FC3 if/when a 2.6.14 kernel is released for it. FC4 is still ok since there has only been one version increment since it was shipped, but will encounter the same issue when/if another version increment occurs and the corresponding kernel is released for it, so it should also get the new /sbin/init and libselinux helper code. > After a comparison of the '.config' files from the related builds, > I've noticed that the 2.6.14 and 2.6.14.2 kernels no longer support > extended attributes for the pseudo filesystems, while the 2.6.13.4 and > 2.6.12-1.1381_FC3 kernels do support the extended attributes, this is > the only significant difference I could find between these kernels' > '.config' files. That is a red herring; the xattr support for pseudo filesystems is still present, but handled via a generic fallback in the VFS rather than separate handlers (so the separate config option is no longer needed). -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Mon Nov 14 15:30:26 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 14 Nov 2005 10:30:26 -0500 Subject: [patch] CUPS 1.2 SELinux policy changes... In-Reply-To: <4374BCFF.5080603@easysw.com> References: <4374BCFF.5080603@easysw.com> Message-ID: <1131982226.5415.122.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-11-11 at 10:47 -0500, Michael Sweet wrote: > [Posting here for lack of a better place...] Just FYI, selinux at tycho.nsa.gov is the upstream SELinux mailing list. List info is at http://www.nsa.gov/selinux/info/list.cfm. fedora-selinux-list is fine too, particularly for Fedora-specific items, but since your patch was against the sourceforge CVS, it was more likely suited to the main list. Various SELinux information resources are listed at http://selinux.sf.net/resources.php3. > Attached is a patch against the current selinux.sourceforge.net repo, > along with an archive of additional files that contain the policies > for non-CUPS software. Thanks for working on this, as it would definitely be a win to have the upstream maintainers of the various software packages helping to maintain the corresponding policy. One thing to be aware of is that the current upstream example policy is in process of being obsoleted by the "reference policy"; see http://serefpolicy.sourceforge.net/ Rawhide should soon be moving to using the reference policy as its baseline; some experimental packages have been built over at: ftp://people.redhat.com/dwalsh/SELinux/refpolicy/ This also introduces the use of the binary/loadable policy module support that is already in rawhide. This should ultimately allow cups policy to be provided by a separate package from the base policy, although that decomposition may not happen until later (e.g. after FC5). Initially, the current policy may just be built as a single monolothic policy module and the module support may just be used for third party packages that are not part of the base Fedora. -- Stephen Smalley National Security Agency From craigwhite at azapple.com Mon Nov 14 15:41:09 2005 From: craigwhite at azapple.com (Craig White) Date: Mon, 14 Nov 2005 08:41:09 -0700 Subject: Is this a place for stupid user questions? Message-ID: <1131982870.31358.13.camel@lin-workstation.azapple.com> If not, please ignore this question. If so... CentOS 4.2 (recently updated from CentOS 4.1) I am getting tons of these messages since I updated to 4.2 Nov 12 12:21:39 srv1 dbus: Can't send to audit system: USER_AVC pid=2839 uid=81 loginuid=-1 message=avc: denied { send_msg } for scontext=user_u:system_r:unconfined_t tcontext=user_u:system_r:initrc_t tclass=dbus Now I can see this process... # ps aux|grep 2839 dbus 2839 0.0 0.3 16168 1888 ? Ssl Nov11 0:13 dbus- daemon-1 --system root 17173 0.0 0.1 3748 668 pts/2 S+ 12:22 0:00 grep 2839 but I'm wondering how do I fix selinux so that it doesn't 'deny' this? I have 'relabeled' the system during a reboot but nothing changed. I haven't done that much to the system except that I have compiled and installed my own appletalk and megaraid kernel modules and perhaps they are the cause. I have raid through the SELinux documentation on both RHEL & Fedora SELinux guides and am apparently lacking the smarts to get it. Thanks Craig -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From sds at tycho.nsa.gov Mon Nov 14 15:39:09 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 14 Nov 2005 10:39:09 -0500 Subject: [patch] CUPS 1.2 SELinux policy changes... In-Reply-To: <4375FFB8.3070206@easysw.com> References: <4374BCFF.5080603@easysw.com> <200511121821.44719.russell@coker.com.au> <4375EBA6.7050807@easysw.com> <200511130046.19443.russell@coker.com.au> <4375FFB8.3070206@easysw.com> Message-ID: <1131982749.5415.132.camel@moss-spartans.epoch.ncsc.mil> On Sat, 2005-11-12 at 09:44 -0500, Michael Sweet wrote: > I know some people would prefer to hand-edit all files and place printer > state data in 5 different places, however no one has proposed an > alternate location for these files that makes sense WRT to the FHS. > > We are absolutely committed to making CUPS easy-to-use, which means > allowing programs (in particular cupsd, which can provide finer-grained > authorization/access control to the configuration data than selinux) to > edit those files. CUPS also updates the printers.conf, classes.conf, > and subscriptions.conf files based on (persistent) state changes. I'm not overly familiar with the specifics of CUPS or its policy myself, but it would likely help if: a) the files that need to be writable by cups would be located in a separate subdirectory from files that should remain read-only (this allows us to place a distinct type on that subdirectory and have it inherited by all files re-created in that subdirectory by default, so that only that type needs to be writable by cups), b) the functionality for modifying those files could be placed in a separate helper program executed by cupsd, so that we could run that helper in a separate domain from cupsd and not give the daemon direct access to rewriting the files, c) the helper program in turn supports applying (optional) filters/checkers to the data so that it can be validated, to prevent it from being used arbitrarily by a compromised cupsd. Also, note that SELinux provides an API for application policy enforcers to support finer-grained controls over application abstractions, and this API is already being used by dbusd and nscd (and a patch exists for X, but isn't yet upstream). Hence, it might make sense to look into using that API from cupsd as well (when running on a SELinux-enabled system, of course, which you can detect at runtime). That allows you to then define SELinux policy over those operations in addition to your existing checks. -- Stephen Smalley National Security Agency From mike at easysw.com Mon Nov 14 16:03:34 2005 From: mike at easysw.com (Michael Sweet) Date: Mon, 14 Nov 2005 11:03:34 -0500 Subject: [patch] CUPS 1.2 SELinux policy changes... In-Reply-To: <1131982749.5415.132.camel@moss-spartans.epoch.ncsc.mil> References: <4374BCFF.5080603@easysw.com> <200511121821.44719.russell@coker.com.au> <4375EBA6.7050807@easysw.com> <200511130046.19443.russell@coker.com.au> <4375FFB8.3070206@easysw.com> <1131982749.5415.132.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4378B556.3090807@easysw.com> Stephen Smalley wrote: > On Sat, 2005-11-12 at 09:44 -0500, Michael Sweet wrote: >> I know some people would prefer to hand-edit all files and place printer >> state data in 5 different places, however no one has proposed an >> alternate location for these files that makes sense WRT to the FHS. >> >> We are absolutely committed to making CUPS easy-to-use, which means >> allowing programs (in particular cupsd, which can provide finer-grained >> authorization/access control to the configuration data than selinux) to >> edit those files. CUPS also updates the printers.conf, classes.conf, >> and subscriptions.conf files based on (persistent) state changes. > > I'm not overly familiar with the specifics of CUPS or its policy myself, > but it would likely help if: > a) the files that need to be writable by cups would be located in a > separate subdirectory from files that should remain read-only (this > allows us to place a distinct type on that subdirectory and have it > inherited by all files re-created in that subdirectory by default, so > that only that type needs to be writable by cups), Technically, all of the files in /etc/cups are configuration files that can be written by cupsd, even the (usually read-only) MIME files (*.types and *.convs). CUPS provides an interface for reading and writing configuration files via HTTP, and that interface allows for such things as remote configuration and mirroring of all CUPS configuration data... > b) the functionality for modifying those files could be placed in a > separate helper program executed by cupsd, so that we could run that > helper in a separate domain from cupsd and not give the daemon direct > access to rewriting the files, That would seriously impact performance and make the code a lot more complicated. Given that cupsd owns and writes these files, adding helper apps would have little practical benefit for CUPS 1.2. We do have plans for supporting alternate storage mechanisms in future (think CUPS 1.4 or later) so that users can put their configuration data in a database, version-controlled repository, etc., however we'll still default to the local, writable files *without* a helper app. > c) the helper program in turn supports applying (optional) > filters/checkers to the data so that it can be validated, to prevent it > from being used arbitrarily by a compromised cupsd. cupsd already validates its input from configuration files... > Also, note that SELinux provides an API for application policy enforcers > to support finer-grained controls over application abstractions, and > this API is already being used by dbusd and nscd (and a patch exists for > X, but isn't yet upstream). Hence, it might make sense to look into > using that API from cupsd as well (when running on a SELinux-enabled > system, of course, which you can detect at runtime). That allows you to > then define SELinux policy over those operations in addition to your > existing checks. I'm not sure that really buys us anything - we already have a system in place that can be used on all systems and provides remote access policies above an beyond the UNIX accounts on the system. Right now I'm more concerned with making the CUPS selinux rules work with CUPS 1.2, and to clear up any issues so that selinux does its job and doesn't get in the way of CUPS's job... :) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Internet Printing and Document Software http://www.easysw.com From russell at coker.com.au Mon Nov 14 16:14:54 2005 From: russell at coker.com.au (Russell Coker) Date: Tue, 15 Nov 2005 03:14:54 +1100 Subject: [patch] CUPS 1.2 SELinux policy changes... In-Reply-To: <4378B556.3090807@easysw.com> References: <4374BCFF.5080603@easysw.com> <1131982749.5415.132.camel@moss-spartans.epoch.ncsc.mil> <4378B556.3090807@easysw.com> Message-ID: <200511150315.03908.russell@coker.com.au> On Tuesday 15 November 2005 03:03, Michael Sweet wrote: > > b) the functionality for modifying those files could be placed in a > > separate helper program executed by cupsd, so that we could run that > > helper in a separate domain from cupsd and not give the daemon direct > > access to rewriting the files, > > That would seriously impact performance and make the code a lot more > complicated. Given that cupsd owns and writes these files, adding > helper apps would have little practical benefit for CUPS 1.2. Is writing config files really a performance bottleneck? I imagine that for the majority of the run time of the daemon there are no changes being made to the configuration. > > Also, note that SELinux provides an API for application policy enforcers > > to support finer-grained controls over application abstractions, and > > this API is already being used by dbusd and nscd (and a patch exists for > > X, but isn't yet upstream). Hence, it might make sense to look into > > using that API from cupsd as well (when running on a SELinux-enabled > > system, of course, which you can detect at runtime). That allows you to > > then define SELinux policy over those operations in addition to your > > existing checks. > > I'm not sure that really buys us anything - we already have a system > in place that can be used on all systems and provides remote access > policies above an beyond the UNIX accounts on the system. You may (and often will) have multiple programs running with the same Unix UID but different SE Linux security context. To handle this situation correctly it is often necessary to have SE Linux support in applications. For example if we have a printer in a public area and a printer in a secure area we want to make sure that documents printed at a high MLS sensitivity level can only go to the printer in the secure area. Implementing this requires that the CUPS server know about SE Linux access controls. I believe that code is already being written to implement such functionality. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From mike at easysw.com Mon Nov 14 16:37:00 2005 From: mike at easysw.com (Michael Sweet) Date: Mon, 14 Nov 2005 11:37:00 -0500 Subject: [patch] CUPS 1.2 SELinux policy changes... In-Reply-To: <200511150315.03908.russell@coker.com.au> References: <4374BCFF.5080603@easysw.com> <1131982749.5415.132.camel@moss-spartans.epoch.ncsc.mil> <4378B556.3090807@easysw.com> <200511150315.03908.russell@coker.com.au> Message-ID: <4378BD2C.9010101@easysw.com> Russell Coker wrote: > On Tuesday 15 November 2005 03:03, Michael Sweet wrote: >>> b) the functionality for modifying those files could be placed in a >>> separate helper program executed by cupsd, so that we could run that >>> helper in a separate domain from cupsd and not give the daemon direct >>> access to rewriting the files, >> That would seriously impact performance and make the code a lot more >> complicated. Given that cupsd owns and writes these files, adding >> helper apps would have little practical benefit for CUPS 1.2. > > Is writing config files really a performance bottleneck? I imagine that for > the majority of the run time of the daemon there are no changes being made to > the configuration. Since printers.conf, classes.conf, and subscriptions.conf are updated whenever the configuration or state of a printer, class, or subscription is updated, it can account for a good amount of time on a busy server with lots of printers/classes. We've looked at only writing the files on a server restart/shutdown, however you run into the possibility that a server crash will lose all of the configuration changes you've made. Also, when we add that plug-in interface to support alternate storage mechanisms we'll also be providing information on the user that made the change (and the nature of the change) to provide important auditing information, so we'll need to save every change to preserve that information anyways... >>> Also, note that SELinux provides an API for application policy enforcers >>> to support finer-grained controls over application abstractions, and >>> this API is already being used by dbusd and nscd (and a patch exists for >>> X, but isn't yet upstream). Hence, it might make sense to look into >>> using that API from cupsd as well (when running on a SELinux-enabled >>> system, of course, which you can detect at runtime). That allows you to >>> then define SELinux policy over those operations in addition to your >>> existing checks. >> I'm not sure that really buys us anything - we already have a system >> in place that can be used on all systems and provides remote access >> policies above an beyond the UNIX accounts on the system. > > You may (and often will) have multiple programs running with the same Unix UID > but different SE Linux security context. To handle this situation correctly > it is often necessary to have SE Linux support in applications. For example > if we have a printer in a public area and a printer in a secure area we want > to make sure that documents printed at a high MLS sensitivity level can only > go to the printer in the secure area. Implementing this requires that the > CUPS server know about SE Linux access controls. I believe that code is > already being written to implement such functionality. Our government customers do not support both secure and non-secure resources from a single server - it violates the policies they have in place. Assuming that, at some point, they trust selinux enough to change those policies and run classified and unclassified processing on the same system image, you will need to make extensive changes at both the client and server levels in order to securely pass and authenticate the document classification data. In short, CUPS is a network service and supporting such a configuration would require a lot more work than adding some simple API hooks which, AFAIK, lack the network scope that is required. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Internet Printing and Document Software http://www.easysw.com From notting at redhat.com Mon Nov 14 17:07:00 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 14 Nov 2005 12:07:00 -0500 Subject: SELinux silently disabled on boot under 2.6.14/2.6.14.2 on FC3 system ? In-Reply-To: <1131976607.5415.46.camel@moss-spartans.epoch.ncsc.mil> References: <1131976607.5415.46.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20051114170700.GB3312@devserv.devel.redhat.com> CC'ing Dave. Stephen Smalley (sds at tycho.nsa.gov) said: > In rawhide, /sbin/init has been changed to use a libselinux helper > function to load policy that is more resilient in several respects, and > I think that the plan was to back port those changes to FC3 if/when a > 2.6.14 kernel is released for it. 2.6.14 for FC3 isn't planned, as far as I know. > FC4 is still ok since there has only > been one version increment since it was shipped, but will encounter the > same issue when/if another version increment occurs and the > corresponding kernel is released for it, so it should also get the > new /sbin/init and libselinux helper code. Hm, OK. We'll probably need poked again if/when that happens. Bill From craigwhite at azapple.com Mon Nov 14 17:55:39 2005 From: craigwhite at azapple.com (Craig White) Date: Mon, 14 Nov 2005 10:55:39 -0700 Subject: simplified question Message-ID: <1131990939.31358.28.camel@lin-workstation.azapple.com> I have selinux-targeted-policy-sources installed. I am trying to make entries that fix these two errors in //etc/selinux/targeted/src/policy/domains/local.te #1 Nov 14 10:43:14 srv1 dbus: Can't send to audit system: USER_AVC pid=3024 uid=81 loginuid=-1 message=avc: denied { send_msg } for scontext=user_u:system_r:unconfined_t tcontext=user_u:system_r:initrc_t tclass=dbus #2 Nov 14 10:43:14 srv1 kernel: audit(1131990194.347:11): avc: denied { connectto } for pid=2941 comm="httpd" name="mysql.sock" scontext=user_u:system_r:httpd_t tcontext=user_u:system_r:initrc_t tclass=unix_stream_socket Can anyone tell me what might work here? This doesn't work... # cat /etc/selinux/targeted/src/policy/domains/local.te ## http to mysql allow httpd_t var_t:sock_file write; allow httpd_t unconfined_t:unix_stream_socket connectto; I need selinux for dummies - any thoughts where I can find such info if not here? Thanks Craig -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From paul at city-fan.org Mon Nov 14 18:06:14 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 14 Nov 2005 18:06:14 +0000 Subject: simplified question In-Reply-To: <1131990939.31358.28.camel@lin-workstation.azapple.com> References: <1131990939.31358.28.camel@lin-workstation.azapple.com> Message-ID: <4378D216.2030302@city-fan.org> Craig White wrote: > I have selinux-targeted-policy-sources installed. > > I am trying to make entries that fix these two errors > in //etc/selinux/targeted/src/policy/domains/local.te > > #1 > > Nov 14 10:43:14 srv1 dbus: Can't send to audit system: USER_AVC pid=3024 > uid=81 loginuid=-1 message=avc: denied { send_msg } for > scontext=user_u:system_r:unconfined_t tcontext=user_u:system_r:initrc_t > tclass=dbus allow unconfined_t initrc_t:dbus send_msg; > #2 > > Nov 14 10:43:14 srv1 kernel: audit(1131990194.347:11): avc: denied > { connectto } for pid=2941 comm="httpd" name="mysql.sock" > scontext=user_u:system_r:httpd_t tcontext=user_u:system_r:initrc_t > tclass=unix_stream_socket allow httpd_t initrc_t:unix_stream_socket connectto; > Can anyone tell me what might work here? This doesn't work... > > # cat /etc/selinux/targeted/src/policy/domains/local.te > ## http to mysql > allow httpd_t var_t:sock_file write; > allow httpd_t unconfined_t:unix_stream_socket connectto; See audit2allow(1) for a tool to generate rules from AVC messages. However, I think the problem might be better resolved by other means. The second of these issues appears to be related to your mysql.sock having context user_u:system_r:initrc_t; on my FC4 box, /var/lib/mysql/mysql.sock has context system_u:object_r:mysqld_var_run_t. You might want to look into why that is first. Paul. From craigwhite at azapple.com Mon Nov 14 18:31:35 2005 From: craigwhite at azapple.com (Craig White) Date: Mon, 14 Nov 2005 11:31:35 -0700 Subject: simplified question In-Reply-To: <4378D216.2030302@city-fan.org> References: <1131990939.31358.28.camel@lin-workstation.azapple.com> <4378D216.2030302@city-fan.org> Message-ID: <1131993096.31358.45.camel@lin-workstation.azapple.com> On Mon, 2005-11-14 at 18:06 +0000, Paul Howarth wrote: > Craig White wrote: > > I have selinux-targeted-policy-sources installed. > > > > I am trying to make entries that fix these two errors > > in //etc/selinux/targeted/src/policy/domains/local.te > > > > #1 > > > > Nov 14 10:43:14 srv1 dbus: Can't send to audit system: USER_AVC pid=3024 > > uid=81 loginuid=-1 message=avc: denied { send_msg } for > > scontext=user_u:system_r:unconfined_t tcontext=user_u:system_r:initrc_t > > tclass=dbus > > allow unconfined_t initrc_t:dbus send_msg; > > > #2 > > > > Nov 14 10:43:14 srv1 kernel: audit(1131990194.347:11): avc: denied > > { connectto } for pid=2941 comm="httpd" name="mysql.sock" > > scontext=user_u:system_r:httpd_t tcontext=user_u:system_r:initrc_t > > tclass=unix_stream_socket > > allow httpd_t initrc_t:unix_stream_socket connectto; > > > Can anyone tell me what might work here? This doesn't work... > > > > # cat /etc/selinux/targeted/src/policy/domains/local.te > > ## http to mysql > > allow httpd_t var_t:sock_file write; > > allow httpd_t unconfined_t:unix_stream_socket connectto; > > See audit2allow(1) for a tool to generate rules from AVC messages. > > However, I think the problem might be better resolved by other means. > The second of these issues appears to be related to your mysql.sock > having context user_u:system_r:initrc_t; on my FC4 box, > /var/lib/mysql/mysql.sock has context > system_u:object_r:mysqld_var_run_t. You might want to look into why that > is first. ---- Thanks Paul, well - this was from CentOS 4.2 so that may account for a difference. I tried asking on CentOS list several times and all that seems to do is spark a debate between those that simply shut off SELinux and those like me who want to learn to live with it...of course the questions never get answered. audit2allow doesn't show anything concerning the dbus error. That still is present. The above did fix the problem with connecting between httpd -> mysql.sock so that is cool. The dbus error has been around for a while and it doesn't seem to prevent anything that I need but would like the education of it - so it remains. audit2allow doesn't have a man page so I haven't garnered much of anything that isn't in audit2allow --help. I'll keep looking but I appreciate the help and I have learned much today already (selinux-targeted-policy-sources was a good one) grep -r mysql /etc/selinux |grep run turns up (among other things)... /etc/selinux/targeted/contexts/files/file_contexts:/var/lib/mysql/mysql \.sock -s system_u:object_r:mysqld_var_run_t Craig -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From sds at tycho.nsa.gov Mon Nov 14 19:18:41 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 14 Nov 2005 14:18:41 -0500 Subject: simplified question In-Reply-To: <1131993096.31358.45.camel@lin-workstation.azapple.com> References: <1131990939.31358.28.camel@lin-workstation.azapple.com> <4378D216.2030302@city-fan.org> <1131993096.31358.45.camel@lin-workstation.azapple.com> Message-ID: <1131995922.5415.219.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-11-14 at 11:31 -0700, Craig White wrote: > audit2allow doesn't show anything concerning the dbus error. That still > is present. The above did fix the problem with connecting between httpd > -> mysql.sock so that is cool. The dbus error has been around for a > while and it doesn't seem to prevent anything that I need but would like > the education of it - so it remains. > > audit2allow doesn't have a man page so I haven't garnered much of > anything that isn't in audit2allow --help. audit2allow man page is available from: http://cvs.sourceforge.net/viewcvs.py/*checkout*/selinux/nsa/selinux-usr/policycoreutils/audit2allow/audit2allow.1 The dbus output suggests two separate problems: 1) dbusd is denying an attempt to send a message through it (this is what you see from the message= payload with the avc: denied message), which can be addressed by adding an appropriate allow rule to policy and reloading it, and 2) dbusd is encountering an error when trying to send the audit message for the above denial to the audit system (this is the "Can't send to audit system" prefix), and thus falls back to using syslog to log the audit message along with the warning. This problem may or may not be due to SELinux (e.g. SELinux might be denying permission to send the audit message to the audit system, or there may be some other error, e.g. since dbusd doesn't run as root, it might not be allowed to use the audit system anyway). -- Stephen Smalley National Security Agency From 3vnkz6u02 at sneakemail.com Mon Nov 14 20:11:02 2005 From: 3vnkz6u02 at sneakemail.com (Eric Howard) Date: 14 Nov 2005 20:11:02 -0000 Subject: Auditing file access Message-ID: <5674-12730@sneakemail.com> Following up on some instructions I found in the list archives (posted by Stephen Smalley), I set up the following policy (local.te) for a stock RHEL AS 4 build (using the targeted policy source) # Allow all user domains to create and modify these files. allow userdomain audited_file_t:dir create_dir_perms; allow userdomain audited_file_t:{ file lnk_file } create_file_perms; # Audit all accesses by user domains to these files. auditallow userdomain audited_file_t:{ dir file lnk_file } * I also set my grub.conf to set audit=1 and also set 'auditctl -e 1' I created a directory off of root called /testdir and assigned it the following context: user_u:object_r:audited_file_t I was hoping that all file activity in this directory would be logged but this does not seem to be happening. Is there something I am missing? Thanks! Eric Howard From linux_4ever at yahoo.com Mon Nov 14 22:14:09 2005 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 14 Nov 2005 14:14:09 -0800 (PST) Subject: simplified question In-Reply-To: <1131995922.5415.219.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20051114221409.47581.qmail@web51514.mail.yahoo.com> >or there may be some other error, e.g. since dbusd doesn't run as root, it >might not be allowed to use the audit system anyway). There is a patch that allows dbus to keep CAP_AUDIT_WRITE when it changes to dbus user. It should be in rawhide real soon and RHEL4 eventually. -Steve __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From stephen.walton at csun.edu Mon Nov 14 22:36:08 2005 From: stephen.walton at csun.edu (Stephen Walton) Date: Mon, 14 Nov 2005 14:36:08 -0800 Subject: SELinux and Big Brother Message-ID: <43791158.5080700@csun.edu> I just got Big Brother working on Fedora Core 4 with SELinux enabled. The key steps: 1. With SELinux turned on, apache adamantly refuses to follow symbolic links, even if FollowSymLinks is set in httpd.conf. (Is this a bug?) The only workaround I've been able to find is a bind mount: # mkdir /var/www/html/bb # mount -o bind /home/bb/bb/www /var/www/html/bb 2. Change the context: # chcon -R -h -t httpd_user_content_t /home/bb/bb/www 3. Change the two 'mv' commands in bb-display.sh to 'cp' commands so that the contexts get preserved when the page is regenerated. Of course in the above I'm assuming DocumentRoot in apache is set to /var/www/html and that your Big Brother server files are in /home/bb/bb. Change as appropriate for your setup. From dant at cdkkt.com Tue Nov 8 23:42:35 2005 From: dant at cdkkt.com (Daniel B. Thurman) Date: Tue, 8 Nov 2005 15:42:35 -0800 Subject: Problems with httpd and SElinux. Message-ID: >From: Daniel J Walsh [mailto:dwalsh at redhat.com] >Sent: Monday, November 07, 2005 9:30 AM >To: Daniel B. Thurman >Cc: fedora-selinux-list at redhat.com >Subject: Re: Problems with httpd and SElinux. > > >Daniel B. Thurman wrote: >> Folks, >> >> I was asked to post this information here. To explain things, >> I have installed FrontPage extensions on FC4 but not realizing >> that I had to first disable SElinux for httpd first, but to make >> a long story short, I was able to install FP and then restore >> SElinux protections for httpd, but on reboot, SElinux refused >> to allow httpd to start and I suspect it had something to do >> with the FrontPage additions to the /etc/httpd/conf/httpd.conf >> file. I currently have SElinux protections turned off for >> https. Below is the audit file, hope it helps show the problem. >> >> type=AVC msg=audit(1131056930.757:251): avc: denied { >name_bind } for pid=4946 comm="httpd" src=8090 >scontext=root:system_r:httpd_t >tcontext=system_u:object_r:port_t tclass=tcp_socket >> type=SYSCALL msg=audit(1131056930.757:251): arch=40000003 >syscall=102 success=no exit=-13 a0=2 a1=bfc779f0 a2=750218 >a3=8b8da58 items=0 pid=4946 auid=4294967295 uid=0 gid=0 euid=0 >suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="httpd" exe="/usr/sbin/httpd" >> type=SOCKADDR msg=audit(1131056930.757:251): >saddr=0A001F9A000000000000000000000000000000000000000000000000 >> type=SOCKETCALL msg=audit(1131056930.757:251): nargs=3 a0=5 >a1=8b8da84 a2=1c >> >> Kind regards, >> Dan >> >> >We do not currently allow apache to listen on port 8090, >but this looks legitimate, so I will add to policy. >You can install policy (selinux-policy-targeted-sources >for now and add a line to: >/etc/selinux/targeted/src/policy/domains/misc/local.te >portcon tcp 8090 system_u:object_r:http_port_t > >Then execute make -c /etc/selinux/targeted/src/policy load > >and you should be able to use that port. > The information you gave me above does not work. I got all sorts of compile errors. BTW, the make should be "make -C". >From Paul Howarth, I tried: ============================================= If you want httpd to be able to listen on port 8090, and you have the policy sources installed, you can do this by adding the following line to /etc/selinux/targeted/src/policy/net_contexts: portcon tcp 8090 system_u:object_r:http_port_t Then you need to compile and reload the security contexts: # make -C /etc/selinux/targeted/src/policy reload ============================================= This all compiles fine now. Testing to see if httpd can now restart with the new policies: 1) setsebool -P httpd_disable_trans 0 2) Restart httpd for this to take effect: service httpd restart Httpd can restart with no failure messages. The httpd server now runs fine. HOWEVER - Testing FrontPage client against my FC4 box FAILS to connect and the reason revealed in /var/log/httpd/error_log: [Tue Nov 08 15:25:40 2005] [error] (13)Permission denied: Could not create key file "/usr/local/frontpage/version5.0/apache-fp/suidkey.17096" in FrontPageInit(). Until this problem is fixed, the FrontPage security patch is disabled and the FrontPage extensions may not work correctly. I suspect that there is a SElinux policy that is preventing the FP client program from creating and deleting the suidkey file it needs in order to startup and begin listening for FP Client requests. Please note that the process number is created and destroyed for the suidkey file and this is happening from within the httpd service file and has nothing to do with the FP client connection attempts. SELinux policy is preventing the service file from creating and destroying this file. So - in order to get back the successful FP client connections as before, performing these steps: 1) setsebool -P httpd_disable_trans 1 2) Restart httpd for this to take effect: service httpd restart The httpd/error_log error message does not appear and I can now connect with to the FC4 with the FP client. Dan Thurman. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.8/162 - Release Date: 11/5/2005 From davej at redhat.com Mon Nov 14 18:00:09 2005 From: davej at redhat.com (Dave Jones) Date: Mon, 14 Nov 2005 13:00:09 -0500 Subject: SELinux silently disabled on boot under 2.6.14/2.6.14.2 on FC3 system ? In-Reply-To: <20051114170700.GB3312@devserv.devel.redhat.com> References: <1131976607.5415.46.camel@moss-spartans.epoch.ncsc.mil> <20051114170700.GB3312@devserv.devel.redhat.com> Message-ID: <20051114180009.GA3652@redhat.com> On Mon, Nov 14, 2005 at 12:07:00PM -0500, Bill Nottingham wrote: > CC'ing Dave. > > Stephen Smalley (sds at tycho.nsa.gov) said: > > In rawhide, /sbin/init has been changed to use a libselinux helper > > function to load policy that is more resilient in several respects, and > > I think that the plan was to back port those changes to FC3 if/when a > > 2.6.14 kernel is released for it. > > 2.6.14 for FC3 isn't planned, as far as I know. Correct. FC3 will stay at 2.6.12 until end of life. Any remaining kernel updates will likely be security errata only at this point. > > FC4 is still ok since there has only > > been one version increment since it was shipped, but will encounter the > > same issue when/if another version increment occurs and the > > corresponding kernel is released for it, so it should also get the > > new /sbin/init and libselinux helper code. > > Hm, OK. We'll probably need poked again if/when that happens. FC4 will continue to rebase to newer upstream kernels until a few months before its end of life. (As has happened with FC3). Dave From dant at cdkkt.com Tue Nov 15 00:52:45 2005 From: dant at cdkkt.com (Daniel B. Thurman) Date: Mon, 14 Nov 2005 16:52:45 -0800 Subject: Problems with httpd and SElinux. Message-ID: >From: fedora-selinux-list-bounces at redhat.com >[mailto:fedora-selinux-list-bounces at redhat.com]On Behalf Of Daniel B. >Thurman >Sent: Tuesday, November 08, 2005 3:43 PM >To: Robert Cahn; Daniel J Walsh >Cc: fedora-list at redhat.com; fedora-selinux-list at redhat.com >Subject: RE: Problems with httpd and SElinux. > > >>From: Daniel J Walsh [mailto:dwalsh at redhat.com] >>Sent: Monday, November 07, 2005 9:30 AM >>To: Daniel B. Thurman >>Cc: fedora-selinux-list at redhat.com >>Subject: Re: Problems with httpd and SElinux. >> >> >>Daniel B. Thurman wrote: >>> Folks, >>> >>> I was asked to post this information here. To explain things, >>> I have installed FrontPage extensions on FC4 but not realizing >>> that I had to first disable SElinux for httpd first, but to make >>> a long story short, I was able to install FP and then restore >>> SElinux protections for httpd, but on reboot, SElinux refused >>> to allow httpd to start and I suspect it had something to do >>> with the FrontPage additions to the /etc/httpd/conf/httpd.conf >>> file. I currently have SElinux protections turned off for >>> https. Below is the audit file, hope it helps show the problem. >>> >>> type=AVC msg=audit(1131056930.757:251): avc: denied { >>name_bind } for pid=4946 comm="httpd" src=8090 >>scontext=root:system_r:httpd_t >>tcontext=system_u:object_r:port_t tclass=tcp_socket >>> type=SYSCALL msg=audit(1131056930.757:251): arch=40000003 >>syscall=102 success=no exit=-13 a0=2 a1=bfc779f0 a2=750218 >>a3=8b8da58 items=0 pid=4946 auid=4294967295 uid=0 gid=0 euid=0 >>suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="httpd" >exe="/usr/sbin/httpd" >>> type=SOCKADDR msg=audit(1131056930.757:251): >>saddr=0A001F9A000000000000000000000000000000000000000000000000 >>> type=SOCKETCALL msg=audit(1131056930.757:251): nargs=3 a0=5 >>a1=8b8da84 a2=1c >>> >>> Kind regards, >>> Dan >>> >>> >>We do not currently allow apache to listen on port 8090, >>but this looks legitimate, so I will add to policy. >>You can install policy (selinux-policy-targeted-sources >>for now and add a line to: >>/etc/selinux/targeted/src/policy/domains/misc/local.te >>portcon tcp 8090 system_u:object_r:http_port_t >> >>Then execute make -c /etc/selinux/targeted/src/policy load >> >>and you should be able to use that port. >> > >The information you gave me above does not work. I got all >sorts of compile errors. BTW, the make should be "make -C". > >>From Paul Howarth, I tried: >============================================= >If you want httpd to be able to listen on port 8090, and you have the >policy sources installed, you can do this by adding the following line >to /etc/selinux/targeted/src/policy/net_contexts: > >portcon tcp 8090 system_u:object_r:http_port_t > >Then you need to compile and reload the security contexts: ># make -C /etc/selinux/targeted/src/policy reload >============================================= > >This all compiles fine now. > >Testing to see if httpd can now restart with the new policies: >1) setsebool -P httpd_disable_trans 0 >2) Restart httpd for this to take effect: service httpd restart > >Httpd can restart with no failure messages. The httpd server >now runs fine. > >HOWEVER - Testing FrontPage client against my FC4 box FAILS to >connect and the reason revealed in /var/log/httpd/error_log: > >[Tue Nov 08 15:25:40 2005] [error] (13)Permission denied: >Could not create key file >"/usr/local/frontpage/version5.0/apache-fp/suidkey.17096" in >FrontPageInit(). Until this problem is fixed, the FrontPage >security patch is disabled and the FrontPage extensions may >not work correctly. > >I suspect that there is a SElinux policy that is preventing the FP >client program from creating and deleting the suidkey file it needs >in order to startup and begin listening for FP Client requests. Please >note that the process number is created and destroyed for the >suidkey file >and this is happening from within the httpd service file and >has nothing >to do with the FP client connection attempts. SELinux policy >is preventing >the service file from creating and destroying this file. > >So - in order to get back the successful FP client connections >as before, >performing these steps: > >1) setsebool -P httpd_disable_trans 1 >2) Restart httpd for this to take effect: service httpd restart > >The httpd/error_log error message does not appear and I can now >connect with to the FC4 with the FP client. > >Dan Thurman. > >-- Huh? Who resent this? This one was sent 11/7/2005... I replied back to Daniel J Walsh with an attachment with the output of /var/log/audit/audit_log file that showed why *many* denials that were occuring with SElinux preventing the FrontPage process from working within httpd. In case Daniel did not get it, I am attaching the file again. ============================================== Daniel J. Walsh: ================ >>What did you see for AVC messages in /var/log/messages or >>/var/log/audit/audit.log? >> > >Please see the attached file. It is the /var/log/audit/audit.log >file and is 13k compressed. I tried best as I could to trucate to >relevant logs pertaining to httpd/fp issues. Please let me know if >you need anything else. ============================================== Kind regards, Dan -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.13.0/167 - Release Date: 11/11/2005 -------------- next part -------------- A non-text attachment was scrubbed... Name: selinix.fp.tar.gz Type: application/x-gzip Size: 12286 bytes Desc: selinix.fp.tar.gz URL: From tdiehl at rogueind.com Tue Nov 15 02:00:20 2005 From: tdiehl at rogueind.com (Tom Diehl) Date: Mon, 14 Nov 2005 21:00:20 -0500 (EST) Subject: SELinux and Big Brother In-Reply-To: <43791158.5080700@csun.edu> References: <43791158.5080700@csun.edu> Message-ID: On Mon, 14 Nov 2005, Stephen Walton wrote: > I just got Big Brother working on Fedora Core 4 with SELinux enabled. > The key steps: > > 1. With SELinux turned on, apache adamantly refuses to follow symbolic > links, even if FollowSymLinks is set in httpd.conf. (Is this a bug?) The > only workaround I've been able to find is a bind mount: Don't know but... > > # mkdir /var/www/html/bb > # mount -o bind /home/bb/bb/www /var/www/html/bb Why don't you simply put something like the following in /etc/httpd/conf.d/bb.conf: # # Big Brother is a web based network monitoring program # Alias /bb /home/bb/bb/www order deny,allow deny from all allow from 127.0.0.1 allow from 192.168.0 Season to taste of course. That way you do not have to mess with symlinks. > 2. Change the context: > > # chcon -R -h -t httpd_user_content_t /home/bb/bb/www > > 3. Change the two 'mv' commands in bb-display.sh to 'cp' commands so > that the contexts get preserved when the page is regenerated. That sounds like the piece I was missing. Thanks. > > Of course in the above I'm assuming DocumentRoot in apache is set to > /var/www/html and that your Big Brother server files are in > /home/bb/bb. Change as appropriate for your setup. That is a standard bb setup, so it should work for most. Regards, Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From rhp.lpt at gmail.com Tue Nov 15 05:21:06 2005 From: rhp.lpt at gmail.com (rhp) Date: Tue, 15 Nov 2005 12:21:06 +0700 Subject: SELinux silently disabled on boot under 2.6.14/2.6.14.2 on FC3 system ? In-Reply-To: <20051114180009.GA3652@redhat.com> References: <1131976607.5415.46.camel@moss-spartans.epoch.ncsc.mil> <20051114170700.GB3312@devserv.devel.redhat.com> <20051114180009.GA3652@redhat.com> Message-ID: 15-nov-05 Hello Dave, Bill, & Stephen: Ok. thanks for the information, I can live with that and just use the 2.6.12-FC3 source for any further upgrades in the FC3 kernel rather than pulling from kernel.org. Would there be any benefit in installing the rawhide /sbin/init on a FC3 box ? I'm rather ambivalent about upgrading to FC4 at this point given FC5 is scheduled for February. FWIW: I did try booting 'enforcing' with 2.6.14 earlier just to see what would happen and, if memory serves, I got a kernel panic on 'no policy loaded' but I didn't pursue it as I got distracted by the 'xattr red herring' Brgds Bob On 11/15/05, Dave Jones wrote: > On Mon, Nov 14, 2005 at 12:07:00PM -0500, Bill Nottingham wrote: > > CC'ing Dave. > > > > Stephen Smalley (sds at tycho.nsa.gov) said: > > > In rawhide, /sbin/init has been changed to use a libselinux helper > > > function to load policy that is more resilient in several respects, and > > > I think that the plan was to back port those changes to FC3 if/when a > > > 2.6.14 kernel is released for it. > > > > 2.6.14 for FC3 isn't planned, as far as I know. > > Correct. FC3 will stay at 2.6.12 until end of life. > Any remaining kernel updates will likely be security errata only > at this point. > > > > FC4 is still ok since there has only > > > been one version increment since it was shipped, but will encounter the > > > same issue when/if another version increment occurs and the > > > corresponding kernel is released for it, so it should also get the > > > new /sbin/init and libselinux helper code. > > > > Hm, OK. We'll probably need poked again if/when that happens. > > FC4 will continue to rebase to newer upstream kernels until a few > months before its end of life. (As has happened with FC3). > > Dave > > -- rhp.lpt at gmail.com From sds at tycho.nsa.gov Tue Nov 15 11:33:56 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 15 Nov 2005 06:33:56 -0500 Subject: SELinux silently disabled on boot under 2.6.14/2.6.14.2 on FC3 system ? In-Reply-To: References: <1131976607.5415.46.camel@moss-spartans.epoch.ncsc.mil> <20051114170700.GB3312@devserv.devel.redhat.com> <20051114180009.GA3652@redhat.com> Message-ID: <1132054436.5415.285.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-11-15 at 12:21 +0700, rhp wrote: > Would there be any benefit in installing the rawhide /sbin/init on a > FC3 box ? I'm rather ambivalent about upgrading to FC4 at this point > given FC5 is scheduled for February. If you do, you'll need the rawhide libselinux and libsepol as well. > FWIW: I did try booting 'enforcing' with 2.6.14 earlier just to see > what would happen and, if memory serves, I got a kernel panic on 'no > policy loaded' but I didn't pursue it as I got distracted by the > 'xattr red herring' Yes, that is the correct behavior for enforcing mode when no policy can be loaded. Still not sure why init didn't display any kind of message in permissive mode about not being able to load the policy. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Tue Nov 15 12:25:00 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 15 Nov 2005 07:25:00 -0500 Subject: Auditing file access In-Reply-To: <5674-12730@sneakemail.com> References: <5674-12730@sneakemail.com> Message-ID: <1132057500.5415.314.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-11-14 at 20:11 +0000, Eric Howard wrote: > Following up on some instructions I found in the list archives (posted by Stephen Smalley), I set up the following policy (local.te) for a stock RHEL AS 4 build (using the targeted policy source) > > # Allow all user domains to create and modify these files. > allow userdomain audited_file_t:dir create_dir_perms; > allow userdomain audited_file_t:{ file lnk_file } create_file_perms; > # Audit all accesses by user domains to these files. > auditallow userdomain audited_file_t:{ dir file lnk_file } * > > I also set my grub.conf to set audit=1 and also set 'auditctl -e 1' > > I created a directory off of root called /testdir and assigned it the following context: user_u:object_r:audited_file_t > > I was hoping that all file activity in this directory would be logged but this does not seem to be happening. Is there something I am missing? I suspect that the problem here is that you are using targeted policy, and targeted policy doesn't deal with user domains. Targeted policy only tries to confine specific daemons, not users. Hence, you likely want your auditallow rule to be in terms of unconfined_t rather than userdomain. But note that RHEL4 Update ?2? should include enhanced auditing support, so you shouldn't even need SELinux per se to apply auditing if that is all you want (i.e. you don't care about mandatory access control). auditctl and auditd should let you configure your auditing directly without dealing with SELinux policy. -- Stephen Smalley National Security Agency From selinux at gmail.com Tue Nov 15 14:38:42 2005 From: selinux at gmail.com (Tom London) Date: Tue, 15 Nov 2005 06:38:42 -0800 Subject: No more selinux-policy-targeted? In-Reply-To: <4c4ba1530511150632qa4aec4fwa106afacced4ed86@mail.gmail.com> References: <4c4ba1530511150632qa4aec4fwa106afacced4ed86@mail.gmail.com> Message-ID: <4c4ba1530511150638m5adfc1bchee1683b44c47f55@mail.gmail.com> On 11/15/05, Tom London wrote: > Noticed in today's rawhide updates that selinux-policy-targeted is to > be deleted, apparently replaced by selinux-policy. > > Besides punning the package name, any changes to be aware of? > > thanks, > tom Sorry about that. Appears to be a 'feature' in the build list. Seems that selinux-policy-targeted-2.0.0-1 'installs' and replaces previous selinux-policy-targeted packages. tom -- Tom London From selinux at gmail.com Tue Nov 15 14:32:52 2005 From: selinux at gmail.com (Tom London) Date: Tue, 15 Nov 2005 06:32:52 -0800 Subject: No more selinux-policy-targeted? Message-ID: <4c4ba1530511150632qa4aec4fwa106afacced4ed86@mail.gmail.com> Noticed in today's rawhide updates that selinux-policy-targeted is to be deleted, apparently replaced by selinux-policy. Besides punning the package name, any changes to be aware of? thanks, tom -- Tom London From linux_4ever at yahoo.com Tue Nov 15 15:00:47 2005 From: linux_4ever at yahoo.com (Steve G) Date: Tue, 15 Nov 2005 07:00:47 -0800 (PST) Subject: Auditing file access In-Reply-To: <5674-12730@sneakemail.com> Message-ID: <20051115150047.96515.qmail@web51515.mail.yahoo.com> >I set up the following policy (local.te) for a stock RHEL AS 4 build >(using the targeted policy source) As Stephen said, RHEL4 has file auditing in it if you upgrade to U2. There is a file /etc/audit.rules where you would put any audit rules that you want. There is another file, capp.rules that is put in the audit package's docs dir that gives you a sample CAPP configuration. In any event, to watch write's to passwd, you would add the following line to /etc/audit.rules. -w /etc/passwd -p w If you put the watch to a directory, you will get updates to the directory entries which may miss events. Fedora does not have the ability to watch files at this point because the patch was rejected due to overlapping hooks with inotify. A new patch will be sent upstream soon so that fedora will have this ability at some point. -Steve __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From sds at tycho.nsa.gov Tue Nov 15 14:54:28 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 15 Nov 2005 09:54:28 -0500 Subject: No more selinux-policy-targeted? In-Reply-To: <4c4ba1530511150638m5adfc1bchee1683b44c47f55@mail.gmail.com> References: <4c4ba1530511150632qa4aec4fwa106afacced4ed86@mail.gmail.com> <4c4ba1530511150638m5adfc1bchee1683b44c47f55@mail.gmail.com> Message-ID: <1132066468.5415.375.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-11-15 at 06:38 -0800, Tom London wrote: > On 11/15/05, Tom London wrote: > > Noticed in today's rawhide updates that selinux-policy-targeted is to > > be deleted, apparently replaced by selinux-policy. > > > > Besides punning the package name, any changes to be aware of? > > > > thanks, > > tom > Sorry about that. Appears to be a 'feature' in the build list. > > Seems that selinux-policy-targeted-2.0.0-1 'installs' and replaces > previous selinux-policy-targeted packages. It is the new refpolicy-based targeted policy. http://serefpolicy.sf.net It is also the first policy to use the policy modules support and libsemanage, although it is presently built as a single monolithic module (but third parties can build separable policy modules that can be linked against it). Some issues still exist with it; see my posting to selinux mailing list. -- Stephen Smalley National Security Agency From kcarr at tresys.com Tue Nov 15 16:19:53 2005 From: kcarr at tresys.com (Kevin Carr) Date: Tue, 15 Nov 2005 11:19:53 -0500 Subject: Seaudit in fedora Core 4 In-Reply-To: <1131647274.19626.104.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200511151620.jAFGJsYs007272@gotham.columbia.tresys.com> > On Thu, 2005-11-10 at 12:46 -0300, Ma. Alejandra Castillo wrote: > > I am occupying the tool seaudit in fedora core 4, but the fields host > > and executablee they appear always empty, what is very strange. I am > > charging /var/log/audit.log, some suggestion so that these fields > > appear? > > Logging of the executable path migrated from the SELinux avc audit code > to the syscall audit code due to a deadlock issue, so avc messages only > include the comm= information now. However, whenever an avc message is > generated, a syscall audit record is also generated when the syscall > exits, and that includes the exe= information. The two messages can be > correlated using the audit event id. I don't know if newer versions of > seaudit perform such correlation or not. We don't support the syscall records now, so correlation is not supported either. We are looking into this as it seems useful especially now that there is less information in the avc messages. Kevin Carr Tresys Technology 410.290.1411 x137 From stephen.walton at csun.edu Tue Nov 15 16:35:50 2005 From: stephen.walton at csun.edu (Stephen Walton) Date: Tue, 15 Nov 2005 08:35:50 -0800 Subject: SELinux and Big Brother In-Reply-To: References: <43791158.5080700@csun.edu> Message-ID: <437A0E66.4050100@csun.edu> Tom Diehl wrote: >Why don't you simply put something like the following in >/etc/httpd/conf.d/bb.conf: > ># ># Big Brother is a web based network monitoring program ># > >Alias /bb /home/bb/bb/www > > > order deny,allow > deny from all > allow from 127.0.0.1 > allow from 192.168.0 > > > I tried this, but it also doesn't work. With SELinux set to "enforcing," I get Forbidden You don't have permission to access /bb on this server. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request. From stephen.walton at csun.edu Tue Nov 15 17:17:35 2005 From: stephen.walton at csun.edu (Stephen Walton) Date: Tue, 15 Nov 2005 09:17:35 -0800 Subject: SELinux and Big Brother In-Reply-To: <437A0E66.4050100@csun.edu> References: <43791158.5080700@csun.edu> <437A0E66.4050100@csun.edu> Message-ID: <437A182F.9000800@csun.edu> It turns out my previous post is not a complete solution to the clash between Big Brother and SELinux. The BB cgi scripts still don't work, because even though they are in /var/www/cgi-bin, they run in a context which doesn't give them access to the files in bb's home directory. Is there a fix to this problem short of changing all of the bb user's files to type httpd_user_content_t? From nicolas.mailhot at laposte.net Tue Nov 15 20:17:14 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 15 Nov 2005 21:17:14 +0100 Subject: selinux-policy-targeted-2.0.0-1 is very raw Message-ID: <1132085834.2893.1.camel@rousalka.dyndns.org> Hi, Is selinux-policy-targeted-2.0.0-1 really ready for use ? Basic stuff like udev access to /dev/.udevdb and su seems to be blocked Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From cpebenito at tresys.com Tue Nov 15 21:45:47 2005 From: cpebenito at tresys.com (Christopher J. PeBenito) Date: Tue, 15 Nov 2005 16:45:47 -0500 Subject: selinux-policy-targeted-2.0.0-1 is very raw In-Reply-To: <1132085834.2893.1.camel@rousalka.dyndns.org> References: <1132085834.2893.1.camel@rousalka.dyndns.org> Message-ID: <1132091147.7259.3.camel@sgc.columbia.tresys.com> On Tue, 2005-11-15 at 21:17 +0100, Nicolas Mailhot wrote: > Is selinux-policy-targeted-2.0.0-1 really ready for use ? Basic stuff > like udev access to /dev/.udevdb and su seems to be blocked Can you provide denials from your audit.log? I can't reproduce these problems. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 From nicolas.mailhot at laposte.net Tue Nov 15 22:16:41 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 15 Nov 2005 23:16:41 +0100 Subject: selinux-policy-targeted-2.0.0-1 is very raw In-Reply-To: <1132091147.7259.3.camel@sgc.columbia.tresys.com> References: <1132085834.2893.1.camel@rousalka.dyndns.org> <1132091147.7259.3.camel@sgc.columbia.tresys.com> Message-ID: <1132093001.2924.5.camel@rousalka.dyndns.org> Le mardi 15 novembre 2005 ? 16:45 -0500, Christopher J. PeBenito a ?crit : > On Tue, 2005-11-15 at 21:17 +0100, Nicolas Mailhot wrote: > > Is selinux-policy-targeted-2.0.0-1 really ready for use ? Basic stuff > > like udev access to /dev/.udevdb and su seems to be blocked > > Can you provide denials from your audit.log? I can't reproduce these > problems. The udev bit is too early to end in the logs, it flashes during the boot messages. Maybe it's not selinux related but it looks like it Strangely su works from the console but not from gnome-terminal Attached a full audit.log for the system. Generation process : - force an autorelabel (touch /.autorelabel) - reboot - switch to init 1 - remove /var/log/audit/audit.log - reboot - do_stuff (including a failed root login ;)) - copy the resulting audit.log All the denied accesses in the log can therefore be attributed directly to the policy. Lots of denied stuff for 2 minutes of system activity before copying the log. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: audit.log.bz2 Type: application/x-bzip Size: 3315 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From sds at tycho.nsa.gov Wed Nov 16 13:21:17 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 16 Nov 2005 08:21:17 -0500 Subject: selinux-policy-targeted-2.0.0-1 is very raw In-Reply-To: <1132085834.2893.1.camel@rousalka.dyndns.org> References: <1132085834.2893.1.camel@rousalka.dyndns.org> Message-ID: <1132147277.12540.24.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-11-15 at 21:17 +0100, Nicolas Mailhot wrote: > Hi, > > Is selinux-policy-targeted-2.0.0-1 really ready for use ? Basic stuff > like udev access to /dev/.udevdb and su seems to be blocked The xdm policy (which covers all of [xgk]dm) was accidentally disabled, so that accounts for a lot of breakage on the desktop (processes aren't transitioned into the proper domains). -- Stephen Smalley National Security Agency From dwalsh at redhat.com Wed Nov 16 20:54:37 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 16 Nov 2005 15:54:37 -0500 Subject: Is this a place for stupid user questions? In-Reply-To: <1131982870.31358.13.camel@lin-workstation.azapple.com> References: <1131982870.31358.13.camel@lin-workstation.azapple.com> Message-ID: <437B9C8D.7020507@redhat.com> Craig White wrote: > If not, please ignore this question. > > If so... > > CentOS 4.2 (recently updated from CentOS 4.1) > > I am getting tons of these messages since I updated to 4.2 > > Nov 12 12:21:39 srv1 dbus: Can't send to audit system: USER_AVC pid=2839 > uid=81 loginuid=-1 message=avc: denied { send_msg } for > scontext=user_u:system_r:unconfined_t tcontext=user_u:system_r:initrc_t > tclass=dbus > > Now I can see this process... > > # ps aux|grep 2839 > dbus 2839 0.0 0.3 16168 1888 ? Ssl Nov11 0:13 dbus- > daemon-1 --system > root 17173 0.0 0.1 3748 668 pts/2 S+ 12:22 0:00 grep 2839 > > but I'm wondering how do I fix selinux so that it doesn't 'deny' this? > > I have 'relabeled' the system during a reboot but nothing changed. > > I haven't done that much to the system except that I have compiled and > installed my own appletalk and megaraid kernel modules and perhaps they > are the cause. > > I have raid through the SELinux documentation on both RHEL & Fedora > SELinux guides and am apparently lacking the smarts to get it. > > Thanks > > Craig > > > update to the policy file on ftp://people.redhat.com/dwalsh/SELinux/RHEL4/u3/selinux* -- From dwalsh at redhat.com Wed Nov 16 21:20:36 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 16 Nov 2005 16:20:36 -0500 Subject: SELinux and Big Brother In-Reply-To: <437A182F.9000800@csun.edu> References: <43791158.5080700@csun.edu> <437A0E66.4050100@csun.edu> <437A182F.9000800@csun.edu> Message-ID: <437BA2A4.70208@redhat.com> Stephen Walton wrote: > It turns out my previous post is not a complete solution to the clash > between Big Brother and SELinux. The BB cgi scripts still don't work, > because even though they are in /var/www/cgi-bin, they run in a > context which doesn't give them access to the files in bb's home > directory. Is there a fix to this problem short of changing all of > the bb user's files to type httpd_user_content_t? > Why wouldn't you want to change the context of the files? That is the hole idea, you are telling the kernel that httpd can access these files. > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -- From dwalsh at redhat.com Wed Nov 16 21:43:31 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 16 Nov 2005 16:43:31 -0500 Subject: selinux-policy-targeted-2.0.0-1 is very raw In-Reply-To: <1132147277.12540.24.camel@moss-spartans.epoch.ncsc.mil> References: <1132085834.2893.1.camel@rousalka.dyndns.org> <1132147277.12540.24.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <437BA803.6070807@redhat.com> Yes it is raw. And has been pulled out of Test1. It should be udpated in Rawhide as soon as test1 is released. Updated policy is available on people.redhat.com/dwalsh/SELinux/Fedora This seems to be working better. -- From mont.rothstein at gmail.com Wed Nov 16 23:16:33 2005 From: mont.rothstein at gmail.com (Mont Rothstein) Date: Wed, 16 Nov 2005 15:16:33 -0800 Subject: Auditing file access below a directory Message-ID: <467a83630511161516y7cfb2a52x123ac36e4fdda050@mail.gmail.com> I am trying to determine if it is possible to audit all file access under a directory for all users. I've been looking at auditd/auditctl and it seems like only individual files or directories can be watched, but not directory trees. My current work around is to audit the gid of the default group for all of the users I care about (accessing the server as a file server via samba). This is obviously not ideal. Does anyone know if there is a way to do this? Thanks, -Mont P.S. This seemed to be the appropriate list for this. If it isn't I apologize. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mra at hp.com Wed Nov 16 23:21:34 2005 From: mra at hp.com (Matt Anderson) Date: Wed, 16 Nov 2005 18:21:34 -0500 Subject: Auditing file access below a directory In-Reply-To: <467a83630511161516y7cfb2a52x123ac36e4fdda050@mail.gmail.com> References: <467a83630511161516y7cfb2a52x123ac36e4fdda050@mail.gmail.com> Message-ID: <437BBEFE.30007@hp.com> Mont Rothstein wrote: > I am trying to determine if it is possible to audit all file access under a > directory for all users. > > I've been looking at auditd/auditctl and it seems like only individual files > or directories can be watched, but not directory trees. > > My current work around is to audit the gid of the default group for all of > the users I care about (accessing the server as a file server via samba). > > This is obviously not ideal. > > Does anyone know if there is a way to do this? > > Thanks, > -Mont > > P.S. This seemed to be the appropriate list for this. If it isn't I > apologize. This is perhaps a better list for your question. From linux_4ever at yahoo.com Thu Nov 17 00:20:51 2005 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 16 Nov 2005 16:20:51 -0800 (PST) Subject: Auditing file access below a directory In-Reply-To: <467a83630511161516y7cfb2a52x123ac36e4fdda050@mail.gmail.com> Message-ID: <20051117002051.40431.qmail@web51514.mail.yahoo.com> >I've been looking at auditd/auditctl and it seems like only individual >files or directories can be watched, but not directory trees. This is correct. The patches that do file system auditing were rejected and we were asked to try to combine the hooks with inotify. That was done. I did bring this up with the audit working group that we should look into this capability since it seems useful. So, to sum it up...it would need kernel work and that will take a while. There is a workaround that may help. If your samba share is on its own partition, then you can use the devmajor & minor fields in creating an audit rule. For example, suppose I wanted to do this for /tmp: [root at endeavor ~]# mount | grep tmp none on /dev/shm type tmpfs (rw) /dev/hda8 on /tmp type ext3 (rw) [root at endeavor ~]# stat /dev/hda8 | grep type Device: dh/13d Inode: 919 Links: 1 Device type: 3,8 So the rule would be: auditctl -a exit,always -S open -F devmajor=3 -F devminor=8 To test: vi /tmp/gconfd-sgrubb/ ausearch -f gconfd-sgrubb time->Wed Nov 16 19:17:28 2005 type=PATH msg=audit(1132186648.942:633): name="/tmp/gconfd-sgrubb/" flags=103 inode=16419 dev=03:08 mode=040700 ouid=4325 ogid=4325 rdev=00:00 type=CWD msg=audit(1132186648.942:633): cwd="/root" type=SYSCALL msg=audit(1132186648.942:633): arch=40000003 syscall=5 success=yes exit=3 a0=92152b0 a1=18800 a2=3 a3=18800 items=1 pid=2937 auid=4325 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="vim" exe="/usr/bin/vim" So this works. Hope this helps... -Steve __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From mont.rothstein at gmail.com Thu Nov 17 00:40:54 2005 From: mont.rothstein at gmail.com (Mont Rothstein) Date: Wed, 16 Nov 2005 16:40:54 -0800 Subject: Auditing file access below a directory In-Reply-To: <20051117002051.40431.qmail@web51514.mail.yahoo.com> References: <467a83630511161516y7cfb2a52x123ac36e4fdda050@mail.gmail.com> <20051117002051.40431.qmail@web51514.mail.yahoo.com> Message-ID: <467a83630511161640h1960f51ap59f294c5c8ecdf9a@mail.gmail.com> That definitely helps! I already planned to make this hierarchy have its own partition. This also gets around the issue of having to know the uid or gid. We plan to move to a Fedora Directory Server based solution and thus creating rules for each user was going to be a problem. Thanks, -Mont On 11/16/05, Steve G wrote: > > >I've been looking at auditd/auditctl and it seems like only individual > >files or directories can be watched, but not directory trees. > > This is correct. The patches that do file system auditing were rejected > and we > were asked to try to combine the hooks with inotify. That was done. I did > bring > this up with the audit working group that we should look into this > capability > since it seems useful. So, to sum it up...it would need kernel work and > that will > take a while. > > There is a workaround that may help. If your samba share is on its own > partition, > then you can use the devmajor & minor fields in creating an audit rule. > For > example, suppose I wanted to do this for /tmp: > > [root at endeavor ~]# mount | grep tmp > none on /dev/shm type tmpfs (rw) > /dev/hda8 on /tmp type ext3 (rw) > [root at endeavor ~]# stat /dev/hda8 | grep type > Device: dh/13d Inode: 919 Links: 1 Device type: 3,8 > > So the rule would be: > auditctl -a exit,always -S open -F devmajor=3 -F devminor=8 > > To test: > vi /tmp/gconfd-sgrubb/ > ausearch -f gconfd-sgrubb > > time->Wed Nov 16 19:17:28 2005 > type=PATH msg=audit(1132186648.942:633): name="/tmp/gconfd-sgrubb/" > flags=103 > inode=16419 dev=03:08 mode=040700 ouid=4325 ogid=4325 rdev=00:00 > type=CWD msg=audit(1132186648.942:633): cwd="/root" > type=SYSCALL msg=audit(1132186648.942:633): arch=40000003 syscall=5 > success=yes > exit=3 a0=92152b0 a1=18800 a2=3 a3=18800 items=1 pid=2937 auid=4325 uid=0 > gid=0 > euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="vim" exe="/usr/bin/vim" > > So this works. Hope this helps... > > -Steve > > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.walton at csun.edu Thu Nov 17 19:54:22 2005 From: stephen.walton at csun.edu (Stephen Walton) Date: Thu, 17 Nov 2005 11:54:22 -0800 Subject: SELinux and Big Brother In-Reply-To: <437BA2A4.70208@redhat.com> References: <43791158.5080700@csun.edu> <437A0E66.4050100@csun.edu> <437A182F.9000800@csun.edu> <437BA2A4.70208@redhat.com> Message-ID: <1132257262.4881.11.camel@freyer.sfo.csun.edu> On Wed, 2005-11-16 at 16:20 -0500, Daniel J Walsh wrote: > Why wouldn't you want to change the context of the files? That is the > hole idea, you are telling the kernel that httpd can access these files. You're right, of course, and doing # chcon -R -h -t httpd_sys_content_t ~bb gets Big Brother working 100% (as far as I can tell) with SELinux active. (Is -h needed?) From steve at atc-nycorp.com Thu Nov 17 23:32:11 2005 From: steve at atc-nycorp.com (Steve Brueckner) Date: Thu, 17 Nov 2005 18:32:11 -0500 Subject: default deny for uncofined_t using targeted? Message-ID: <60D45469A1AAD311A04C009027B6BF680591441F@server20.inside.oracorp.com> Can anyone tell me if there is a way to use SELinux under the targeted policy to enforce a default deny rule that prevents all processes from accessing the network? That is to say, all types including unconfined_t may not access eth0, with just a few excepted types that are allowed to network? I'm trying to lock down a system from the inside without having to deal with the strict policy. Thanks, Stephen Brueckner, ATC-NY From sds at tycho.nsa.gov Fri Nov 18 15:17:41 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 18 Nov 2005 10:17:41 -0500 Subject: default deny for uncofined_t using targeted? In-Reply-To: <60D45469A1AAD311A04C009027B6BF680591441F@server20.inside.oracorp.com> References: <60D45469A1AAD311A04C009027B6BF680591441F@server20.inside.oracorp.com> Message-ID: <1132327061.17726.335.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-11-17 at 18:32 -0500, Steve Brueckner wrote: > Can anyone tell me if there is a way to use SELinux under the targeted > policy to enforce a default deny rule that prevents all processes from > accessing the network? That is to say, all types including unconfined_t may > not access eth0, with just a few excepted types that are allowed to network? > I'm trying to lock down a system from the inside without having to deal with > the strict policy. SELinux denies anything that isn't explicitly allowed, so this is just a matter of modifying the policy to not allow such network access in the first place, e.g. - remove the network-related rules from the policy/macros/global_macros.te:unconfined_domain() macro, - remove all uses of the network macros from the other .te files except where you want to preserve such access, or remove the allow rules from the network macros (policy/macros/network_macros.te) and then add them back selectively to the desired domains. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Fri Nov 18 15:24:05 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 18 Nov 2005 10:24:05 -0500 Subject: default deny for uncofined_t using targeted? In-Reply-To: <1132327061.17726.335.camel@moss-spartans.epoch.ncsc.mil> References: <60D45469A1AAD311A04C009027B6BF680591441F@server20.inside.oracorp.com> <1132327061.17726.335.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1132327445.17726.339.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-11-18 at 10:17 -0500, Stephen Smalley wrote: > On Thu, 2005-11-17 at 18:32 -0500, Steve Brueckner wrote: > > Can anyone tell me if there is a way to use SELinux under the targeted > > policy to enforce a default deny rule that prevents all processes from > > accessing the network? That is to say, all types including unconfined_t may > > not access eth0, with just a few excepted types that are allowed to network? > > I'm trying to lock down a system from the inside without having to deal with > > the strict policy. > > SELinux denies anything that isn't explicitly allowed, so this is just a > matter of modifying the policy to not allow such network access in the > first place, e.g. > - remove the network-related rules from the > policy/macros/global_macros.te:unconfined_domain() macro, > - remove all uses of the network macros from the other .te files except > where you want to preserve such access, or remove the allow rules from > the network macros (policy/macros/network_macros.te) and then add them > back selectively to the desired domains. BTW, the way to support this more dynamically (without having to adjust policy sources) would be to first get a patch accepted that introduces a policy boolean and wraps these network-related rules with a conditional on that boolean, so that you can just do a setsebool -P allow_network=0 or similar to shut off network access in the base policy, and then add back network access selectively as desired via your own new policy files. -- Stephen Smalley National Security Agency From paul at city-fan.org Fri Nov 18 15:17:11 2005 From: paul at city-fan.org (Paul Howarth) Date: Fri, 18 Nov 2005 15:17:11 +0000 Subject: default deny for uncofined_t using targeted? In-Reply-To: <1132327061.17726.335.camel@moss-spartans.epoch.ncsc.mil> References: <60D45469A1AAD311A04C009027B6BF680591441F@server20.inside.oracorp.com> <1132327061.17726.335.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <437DF077.9060906@city-fan.org> Stephen Smalley wrote: > On Thu, 2005-11-17 at 18:32 -0500, Steve Brueckner wrote: > >>Can anyone tell me if there is a way to use SELinux under the targeted >>policy to enforce a default deny rule that prevents all processes from >>accessing the network? That is to say, all types including unconfined_t may >>not access eth0, with just a few excepted types that are allowed to network? >>I'm trying to lock down a system from the inside without having to deal with >>the strict policy. > > > SELinux denies anything that isn't explicitly allowed, so this is just a > matter of modifying the policy to not allow such network access in the > first place, e.g. > - remove the network-related rules from the > policy/macros/global_macros.te:unconfined_domain() macro, > - remove all uses of the network macros from the other .te files except > where you want to preserve such access, or remove the allow rules from > the network macros (policy/macros/network_macros.te) and then add them > back selectively to the desired domains. Won't that kill all network access, including via localhost, rather than just eth0 access? Paul. From sds at tycho.nsa.gov Fri Nov 18 15:39:53 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 18 Nov 2005 10:39:53 -0500 Subject: default deny for uncofined_t using targeted? In-Reply-To: <437DF077.9060906@city-fan.org> References: <60D45469A1AAD311A04C009027B6BF680591441F@server20.inside.oracorp.com> <1132327061.17726.335.camel@moss-spartans.epoch.ncsc.mil> <437DF077.9060906@city-fan.org> Message-ID: <1132328393.17726.352.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-11-18 at 15:17 +0000, Paul Howarth wrote: > Won't that kill all network access, including via localhost, rather than > just eth0 access? Well, yes, good point ;) Also looks like Dan reworked the old netifcon statements and netif types as part of the network macro work. Ok, so one approach might be to: - Add a netifcon statement to policy/net_contexts (between the portcon entries and the nodecon entries) to distinguish eth0: netifcon eth0 system_u:object_r:netif_eth0_t system_u:object_r:unlabeled_t - Add the type to policy/types/network.te (or anywhere in the policy): type netif_eth0_t, netif_type; - Change the allow rule in unconfined_domain from allow $1 netif_type:netif *; to: allow $1 netif_t:netif *; so that unconfined_t no longer gets access to all netif types, just the default one (which covers loopback). Looks like macros/network_macros.te already limits itself to netif_t:netif, so it will also cease granting access to eth0 when you make the above changes without needing to modify the macro itself. -- Stephen Smalley National Security Agency From mra at hp.com Fri Nov 18 17:23:05 2005 From: mra at hp.com (Matt Anderson) Date: Fri, 18 Nov 2005 12:23:05 -0500 Subject: [patch] CUPS 1.2 SELinux policy changes... In-Reply-To: <4378BD2C.9010101@easysw.com> References: <4374BCFF.5080603@easysw.com> <1131982749.5415.132.camel@moss-spartans.epoch.ncsc.mil> <4378B556.3090807@easysw.com> <200511150315.03908.russell@coker.com.au> <4378BD2C.9010101@easysw.com> Message-ID: <437E0DF9.2000702@hp.com> Michael Sweet wrote: > Our government customers do not support both secure and non-secure > resources from a single server - it violates the policies they have in > place. Assuming that, at some point, they trust selinux enough to > change those policies and run classified and unclassified processing > on the same system image, you will need to make extensive changes at > both the client and server levels in order to securely pass and > authenticate the document classification data. > > In short, CUPS is a network service and supporting such a > configuration would require a lot more work than adding some simple > API hooks which, AFAIK, lack the network scope that is required. I've been meaning to talk to you about that... I've been working on addressing some of that work. Currently there are three patches against 1.1.23. The initial one was by Cory Olmo from TCS. It provided forced labels based on the SELinux context of the session that submitted the print job. I then added some audit hooks to pass information into Redhat's audit framework. Finally realizing that we wanted to remove CUPS' dependency on labeled network I did a quick proof of concept patch which had CUPS use local unix sockets instead of internet sockets. The initial unix socket patch was compile time and essentially gutted the sockaddr_in replacing them with sockaddr_un. This is less than ideal so I was working on a new patch which would combine all three previous compile times patches into one patch that would make its decisions at runtime. Using sockaddr_storage and some minimally invasive logic I was able to get around the need to replicate the listener_t and http_t data structures. I did end up adding a config option of "socket" to my development stream since I wanted to make it distinct from "listen" or "port". I had been planning on allowing for "Classification" to be set to selinux in order to specify to use the SELinux label as the forced banner. I've since gotten sidetracked off that work so the runtime patch isn't finished yet. I hope to be able to get back to it in a few weeks. In the meantime I can send you the patches so you can see first hand the extent of the damage, and to provide feedback of course ;) -matt From agk at redhat.com Fri Nov 18 22:14:48 2005 From: agk at redhat.com (Alasdair G Kergon) Date: Fri, 18 Nov 2005 22:14:48 +0000 Subject: SELinux AVCs with swap stored in LVM volume In-Reply-To: <1130774134.22731.111.camel@moss-spartans.epoch.ncsc.mil> References: <6f6293f10510300111j1d058d06he0c99f6a135f7060@mail.gmail.com> <43662E72.9010501@redhat.com> <1130774134.22731.111.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20051118221448.GA23190@agk.surrey.redhat.com> On Mon, Oct 31, 2005 at 10:55:34AM -0500, Stephen Smalley wrote: > On Mon, 2005-10-31 at 09:47 -0500, Daniel J Walsh wrote: > > The fd:use and blk_file read is caused by a kernel bug > I think it may be a lvm bug rather than a kernel bug, so you may want to > re-assign it in bugzilla. Note that anything that runs prior to initial > policy load by /sbin/init or anything that runs as a usermode helper > from the kernel without a domain transition defined will run with type > kernel_t. Turned out to be a known bug in nash. nash is a tiny shell used in the initrd and it sometimes appears to not to close the swap device before execing /sbin/init. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169427 # lsof ... init 1 root 53r BLK 8,5 935 /dev/sda5 Patches gratefully received:-) Alasdair -- agk at redhat.com From chanson at TrustedCS.com Mon Nov 21 16:38:06 2005 From: chanson at TrustedCS.com (Chad Hanson) Date: Mon, 21 Nov 2005 11:38:06 -0500 Subject: [patch] CUPS 1.2 SELinux policy changes... Message-ID: <36282A1733C57546BE392885C0618592E1CC39@chaos.tcs.tcs-sec.com> I am positive there are customer requirements for this. The example could be multiple classified networks, instead of unclass/class as well. This can provide printer reduction in these cases with a multilevel print server. > -----Original Message----- > From: Matt Anderson [mailto:mra at hp.com] > Michael Sweet wrote: > > Our government customers do not support both secure and non-secure > > resources from a single server - it violates the policies they have in > > place. Assuming that, at some point, they trust selinux enough to > > change those policies and run classified and unclassified processing > > on the same system image, you will need to make extensive changes at > > both the client and server levels in order to securely pass and > > authenticate the document classification data. > > From mike at easysw.com Mon Nov 21 17:57:50 2005 From: mike at easysw.com (Michael Sweet) Date: Mon, 21 Nov 2005 12:57:50 -0500 Subject: [patch] CUPS 1.2 SELinux policy changes... In-Reply-To: <36282A1733C57546BE392885C0618592E1CC39@chaos.tcs.tcs-sec.com> References: <36282A1733C57546BE392885C0618592E1CC39@chaos.tcs.tcs-sec.com> Message-ID: <43820A9E.40708@easysw.com> Chad Hanson wrote: > I am positive there are customer requirements for this. The example could be > multiple classified networks, instead of unclass/class as well. This can > provide printer reduction in these cases with a multilevel print server. Again, in my experience (having managed many DoD and other gov't contracts), this type of configuration just isn't allowed. There is typically a single "system high" classification level and all print jobs are labeled as such. Users must then mark each page in a document with a lower classification by hand. The CUPS classified printing support is actually modeled on specific DoD requirements... -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Internet Printing and Document Software http://www.easysw.com From joe at nall.com Mon Nov 21 19:08:34 2005 From: joe at nall.com (Joe Nall) Date: Mon, 21 Nov 2005 13:08:34 -0600 Subject: [patch] CUPS 1.2 SELinux policy changes... In-Reply-To: <43820A9E.40708@easysw.com> References: <36282A1733C57546BE392885C0618592E1CC39@chaos.tcs.tcs-sec.com> <43820A9E.40708@easysw.com> Message-ID: <238A00BB-4BB2-4517-982F-D4991A5691A2@nall.com> On Nov 21, 2005, at 11:57 AM, Michael Sweet wrote: > Chad Hanson wrote: >> I am positive there are customer requirements for this. The >> example could be >> multiple classified networks, instead of unclass/class as well. >> This can >> provide printer reduction in these cases with a multilevel print >> server. > > Again, in my experience (having managed many DoD and other gov't > contracts), this type of configuration just isn't allowed. There > is typically a single "system high" classification level and all > print jobs are labeled as such. Users must then mark each page in > a document with a lower classification by hand. The CUPS classified > printing support is actually modeled on specific DoD requirements... Michael, in a non LSPP system environment your summary is correct. In an LSPP system, since the label is bound to the document (file) with some assurance, you can print real labels on documents. We spool multilevel print jobs from our Compartmented Mode Workstations (B1 era MLS) with print banners that reflect the document classification - not the network system high. Banner pages and markings at the top and bottom of each page. Accredited in 5 different countries and multiple domains :) DoD is not the only set of US rules (DCID 6/3 vs DoD 8500) and other nations have their own rules. If possible, I would certainly like to see real multilevel printer support. Anything less will be a step backwards for our users. joe From mike at easysw.com Mon Nov 21 20:31:34 2005 From: mike at easysw.com (Michael Sweet) Date: Mon, 21 Nov 2005 15:31:34 -0500 Subject: [patch] CUPS 1.2 SELinux policy changes... In-Reply-To: <238A00BB-4BB2-4517-982F-D4991A5691A2@nall.com> References: <36282A1733C57546BE392885C0618592E1CC39@chaos.tcs.tcs-sec.com> <43820A9E.40708@easysw.com> <238A00BB-4BB2-4517-982F-D4991A5691A2@nall.com> Message-ID: <43822EA6.6050207@easysw.com> Joe Nall wrote: > ... > DoD is not the only set of US rules (DCID 6/3 vs DoD 8500) and other > nations have their own rules. If possible, I would certainly like to see > real multilevel printer support. Anything less will be a step backwards > for our users. Well, like I said, we'll accept patches to support more SELinux stuff. At this point, we have no plans or desire to support multiple default classification levels within a single cupsd instance, but adding the ability to tag print documents with the appropriate classification level will be useful for some customers. There is also the issue of passing classification info securely over a network connection to another system - is there any mechanism/API within SELinux right now that we could use for this purpose? -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Internet Printing and Document Software http://www.easysw.com From justin.conover at gmail.com Wed Nov 23 02:40:46 2005 From: justin.conover at gmail.com (Justin Conover) Date: Tue, 22 Nov 2005 20:40:46 -0600 Subject: Hacks from Pax - SELinux Articles Message-ID: I was reading through these and thought I would pass them on, pretty good read(s). 1.) http://www.linuxsecurity.com/content/view/120567/49/ 2.) http://www.linuxsecurity.com/content/view/120622/49/ 3.) http://www.linuxsecurity.com/content/view/120700/49/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From linux_4ever at yahoo.com Wed Nov 23 16:19:33 2005 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 23 Nov 2005 08:19:33 -0800 (PST) Subject: Visualizing Audit Log Data Message-ID: <20051123161933.57592.qmail@web51508.mail.yahoo.com> Hi, I wrote up an article about how to use some of the audit utilities + graphviz & gnuplot to make charts and graphs out of the audit logs. You can find the article here: http://people.redhat.com/sgrubb/audit/visualize/index.html I will be writing up more information about using the audit system in the next week or two. -Steve __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com From rirving at antient.org Thu Nov 24 02:00:03 2005 From: rirving at antient.org (Richard Irving) Date: Wed, 23 Nov 2005 21:00:03 -0500 Subject: Another boring question .1.19 targeted Message-ID: <43851EA3.7030004@antient.org> Hello, This is concerning FC3.... I recently updated a laptop, it had FC3 installed, and targeted... It recently updated the selinux libraries to 1.19.xxx, and the *strict* policy sources... for targeted it stopped at a 1.17.xxx version. The problem appears to be when all the selinux libs are synced to 1.19, the 1.17 *targeted* src/policy doesn't compile. (at least on my system) Does anyone have a pointer to 1.19 targeted policy, *and* source ? FWIW, I have trashed the targeted tree, and started from scrap.. and it didn't help. TIA! From twaugh at redhat.com Fri Nov 25 09:35:48 2005 From: twaugh at redhat.com (Tim Waugh) Date: Fri, 25 Nov 2005 09:35:48 +0000 Subject: findutils-selinux.patch critique (was Re: [patch] Recent findutils test suite failures) Message-ID: <20051125093548.GW10349@redhat.com> Forwarding this to a wider SELinux-knowledgeable audience. James had asked me what patches we apply to findutils, so I mentioned SELinux and pointed him to the patch for an initial review. Tim. */ ----- Forwarded message from James Youngman ----- Date: Fri, 25 Nov 2005 08:42:56 +0000 From: James Youngman To: Tim Waugh Cc: bug-findutils at gnu.org Subject: Re: [patch] Recent findutils test suite failures On Thu, Nov 24, 2005 at 11:12:19PM +0000, Tim Waugh wrote: > 2. add support for SELinux. > > At the moment, it isn't autoconf-ed up, but it would be great if you > wanted to take a look. SELinux is on by default in Fedora Core. > > http://cvs.fedora.redhat.com/viewcvs/devel/findutils/findutils-selinux.patch?only_with_tag=HEAD&view=markup I'd certainly consider it. However, I have some comments/questions. 1. I notice that SELinux-enablement creates two new tests, "-context" and "--context". I would eliminate "--context", leaving only "-context". Find predicates aren't GNU-style long options. Find is confusing enough with options as well as predicates, and so I definitely don't want to further blur that line. 2. I see that if you use "find -context" on an SELinux-enabled version of find on a system where SELinux is not enabled, find will immediately perform a fatal exit with an explanatory message. I won't say that that is definitely the wrong behaviour, but why did you choose not to have -context simply always return false (and perhaps issue one warning message)? 3. Security contexts are long multi-part strings. Matching with glob patterns is a reasonable approach. Nevertheless, does the use of glob patterns to match them reflect practice on other systems? 4. I notice that your patch slips in a definition for FNM_CASEFOLD. That looks wrong to me. gl_FUNC_FNMATCH_GNU should call AC_GNU_SOURCE to ensure that #defines FNM_CASEFOLD for you. This should be called by gl_INIT. Is this (a) not working correctly on some of your build systems, (b) not working on any of your build systems, implying a findutils bug, or (c) there for 'historical reasons'? 5. Findutils should probably default to compiling with SELinux support on systems where exists or --with-selinux is specifified to configure, and compile without such support otherwise. 6. Is there a reason you turn off Automake gnits rules checking in the SELinux patch? 7. The configure magic for selinux can be fully generic and self-contained I think: we could just have an selinux.m4 file. That would also make it much easier to reuse it. 8. Are the DejaGnu test cases for the SELinux patch in another patch file somewhere else? Perhaps it's in the same patch file as the update to the Texinfo documentation. :) Regards, James. ----- End forwarded message ----- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mjs at ces.clemson.edu Sat Nov 26 23:03:57 2005 From: mjs at ces.clemson.edu (Matthew Saltzman) Date: Sat, 26 Nov 2005 18:03:57 -0500 (EST) Subject: printer creation in RPM scriptlet Message-ID: I tried installing http://remi.collet.free.fr/rpms/fc4.i386/cups-pdf-2.0.0-0.1.fc4.remi.i386.rpm. The RPM has the following post-install scriptlet: if [ "$1" -eq "1" ]; then /etc/init.d/cups restart ( /usr/sbin/lpadmin -p Cups-PDF -v cups-pdf:/ -m PostscriptColor.ppd -E && echo Cups-PDF printer created ) || true fi With selinux-policy-targeted-1.27.1-2.11 in enforcing mode, the lpadmin command fails with error: lpadmin: add-printer (set device) failed: client-error-not-possible In permissive mode, the install proceeds without problem. The relevant audit.log entries are: type=AVC msg=audit(1133045911.757:788): avc: denied { ioctl } for pid=20774 comm="printconf-backe" name="[7217936]" dev=pipefs ino=7217936 scontext=root:system_r:cupsd_config_t tcontext=root:system_r:unconfined_t tclass=fifo_file type=SYSCALL msg=audit(1133045911.757:788): arch=40000003 syscall=54 success=no exit=-13 a0=0 a1=5401 a2=bfd10098 a3=bfd100d8 items=0 pid=20774 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="printconf-backe" exe="/usr/bin/python" type=AVC_PATH msg=audit(1133045911.757:788): path="pipe:[7217936]" type=AVC msg=audit(1133045911.757:789): avc: denied { getattr } for pid=20774 comm="printconf-backe" name="[7217936]" dev=pipefs ino=7217936 scontext=root:system_r:cupsd_config_t tcontext=root:system_r:unconfined_t tclass=fifo_file type=SYSCALL msg=audit(1133045911.757:789): arch=40000003 syscall=197 success=no exit=-13 a0=0 a1=bfd0fffc a2=960ff4 a3=b7ec4020 items=0 pid=20774 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="printconf-backe" exe="/usr/bin/python" type=AVC_PATH msg=audit(1133045911.757:789): path="pipe:[7217936]" type=AVC msg=audit(1133045911.781:790): avc: denied { ioctl } for pid=20774 comm="printconf-backe" name="[7217936]" dev=pipefs ino=7217936 scontext=root:system_r:cupsd_config_t tcontext=root:system_r:unconfined_t tclass=fifo_file type=SYSCALL msg=audit(1133045911.781:790): arch=40000003 syscall=54 success=no exit=-13 a0=0 a1=5401 a2=bfd0ffb8 a3=bfd0fff8 items=0 pid=20774 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="printconf-backe" exe="/usr/bin/python" type=AVC_PATH msg=audit(1133045911.781:790): path="pipe:[7217936]" type=AVC msg=audit(1133045912.273:791): avc: denied { getattr } for pid=20787 comm="cups-pdf" name="SPOOL" dev=dm-0 ino=737988 scontext=root:system_r:cupsd_t tcontext=system_u:object_r:var_spool_t tclass=dir type=SYSCALL msg=audit(1133045912.273:791): arch=40000003 syscall=195 success=no exit=-13 a0=8057f20 a1=bf9c9a6c a2=960ff4 a3=bf9c9a6c items=1 pid=20787 auid=4294967295 uid=0 gid=7 euid=0 suid=0 fsuid=0 egid=7 sgid=7 fsgid=7 comm="cups-pdf" exe="/usr/lib/cups/backend/cups-pdf" type=AVC_PATH msg=audit(1133045912.273:791): path="/var/spool/cups-pdf/SPOOL" type=CWD msg=audit(1133045912.273:791): cwd="/" type=PATH msg=audit(1133045912.273:791): item=0 name="/var/spool/cups-pdf/SPOOL" flags=1 inode=737988 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From oil.pine at gmail.com Sun Nov 27 00:52:35 2005 From: oil.pine at gmail.com (Oil Pine) Date: Sat, 26 Nov 2005 18:52:35 -0600 Subject: How do I make a text file writable? Message-ID: <1133052755.4438.4.camel@host.yoons.org> The file listed below is a simple text file containing an integer number to denote the number of visits to a web page. A php script (counter.php) is supposed to increase the number by 1 every time the page is accessed. It appears that everything happens as it is supposed except for the incremental number of the visits. I think the counter.txt file is not writable. How do I make it writable? Do I need to change httpd_sys_content_t to something else? ----------------------------------------------------------------------------------------------- -rw-rw-r-- web web system_u:object_r:httpd_sys_content_t counter.txt From paul at city-fan.org Sun Nov 27 10:27:06 2005 From: paul at city-fan.org (Paul Howarth) Date: Sun, 27 Nov 2005 10:27:06 +0000 Subject: How do I make a text file writable? In-Reply-To: <1133052755.4438.4.camel@host.yoons.org> References: <1133052755.4438.4.camel@host.yoons.org> Message-ID: <1133087226.21222.5.camel@laurel.intra.city-fan.org> On Sat, 2005-11-26 at 18:52 -0600, Oil Pine wrote: > The file listed below is a simple text file containing an integer number > to denote the number of visits to a web page. > > A php script (counter.php) is supposed to increase the number by 1 every > time the page is accessed. It appears that everything happens as it is > supposed except for the incremental number of the visits. I think the > counter.txt file is not writable. > > How do I make it writable? Do I need to change httpd_sys_content_t to > something else? > > ----------------------------------------------------------------------------------------------- > -rw-rw-r-- web web system_u:object_r:httpd_sys_content_t counter.txt "man httpd_selinux" suggests that httpd_sys_script_rw_t or public_content_rw_t may be what you're looking for. Paul. -- Paul Howarth From mont.rothstein at gmail.com Mon Nov 28 05:33:19 2005 From: mont.rothstein at gmail.com (Mont Rothstein) Date: Sun, 27 Nov 2005 21:33:19 -0800 Subject: Auditing file access below a directory In-Reply-To: <20051117002051.40431.qmail@web51514.mail.yahoo.com> References: <467a83630511161516y7cfb2a52x123ac36e4fdda050@mail.gmail.com> <20051117002051.40431.qmail@web51514.mail.yahoo.com> Message-ID: <467a83630511272133n2be99e6dof03a107b1d3b99ea@mail.gmail.com> I finally got my new server setup with a dedicated (logical) partition. I tried setting up auditing on the partition but it isn't working. My first suspicion is the version of auditd. I am using the default that is in RHEL 4 which is 1.0.3. Should this version work or do I need to upgrade to 1.1-1? If I do need to upgrade then do you know how to uninstall the previous version? I tried to install 1.1-1 but after the --rebuild I tried to double-click the RPMs and it complained about the 1.0.3 version wanted its lib rpm. Thanks, -Mont On 11/16/05, Steve G wrote: > > >I've been looking at auditd/auditctl and it seems like only individual > >files or directories can be watched, but not directory trees. > > This is correct. The patches that do file system auditing were rejected > and we > were asked to try to combine the hooks with inotify. That was done. I did > bring > this up with the audit working group that we should look into this > capability > since it seems useful. So, to sum it up...it would need kernel work and > that will > take a while. > > There is a workaround that may help. If your samba share is on its own > partition, > then you can use the devmajor & minor fields in creating an audit rule. > For > example, suppose I wanted to do this for /tmp: > > [root at endeavor ~]# mount | grep tmp > none on /dev/shm type tmpfs (rw) > /dev/hda8 on /tmp type ext3 (rw) > [root at endeavor ~]# stat /dev/hda8 | grep type > Device: dh/13d Inode: 919 Links: 1 Device type: 3,8 > > So the rule would be: > auditctl -a exit,always -S open -F devmajor=3 -F devminor=8 > > To test: > vi /tmp/gconfd-sgrubb/ > ausearch -f gconfd-sgrubb > > time->Wed Nov 16 19:17:28 2005 > type=PATH msg=audit(1132186648.942:633): name="/tmp/gconfd-sgrubb/" > flags=103 > inode=16419 dev=03:08 mode=040700 ouid=4325 ogid=4325 rdev=00:00 > type=CWD msg=audit(1132186648.942:633): cwd="/root" > type=SYSCALL msg=audit(1132186648.942:633): arch=40000003 syscall=5 > success=yes > exit=3 a0=92152b0 a1=18800 a2=3 a3=18800 items=1 pid=2937 auid=4325 uid=0 > gid=0 > euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="vim" exe="/usr/bin/vim" > > So this works. Hope this helps... > > -Steve > > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From linux_4ever at yahoo.com Mon Nov 28 14:38:43 2005 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 28 Nov 2005 06:38:43 -0800 (PST) Subject: Auditing file access below a directory In-Reply-To: <467a83630511272133n2be99e6dof03a107b1d3b99ea@mail.gmail.com> Message-ID: <20051128143844.77779.qmail@web51504.mail.yahoo.com> >I am using the default that is in RHEL 4 which is 1.0.3. Should this version >work or do I need to upgrade to 1.1-1? 1.0.3 does work. The other component is the kernel since it is what actually performs the audit. You should be using the -22 kernel at a minimum. My guess is that you don't have the rule exactly right. I would need know the dir that you are wanting to audit, to see the output of mount to see your mount table, the output of running stat on the partition to determine the major & minor numbers, and auditctl -l to see what is in effect. You can send it off list if you need me to help. >If I do need to upgrade then do you know how to uninstall the previous >version? You do not need to upgrade. 1.0.12 is the version for FC4 & RHEL4. 1.1 is for FC5 and future RHEL. >I tried to install 1.1-1 but after the --rebuild I tried to double-click >the RPMs and it complained about the 1.0.3 version wanted its lib rpm. You should just be able to do rpm -Fvh /path-to-rpms/audit-* The audit srpm produces 3 packages. Do not upgrade RHEL4 to 1.1. Hope this helps... -Steve __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ From mjs at ces.clemson.edu Mon Nov 28 15:39:25 2005 From: mjs at ces.clemson.edu (Matthew Saltzman) Date: Mon, 28 Nov 2005 10:39:25 -0500 (EST) Subject: su after disk reorganization. Message-ID: I rebuilt my system disk to change the partitioning arrangment. This involved copying everything off, repartitioning, copying everything back, and creating a new initrd. Almost everything seems to work now except that when I su, after the password prompt, I get the following prompt: $ su Password: Your default context is root:system_r:kernel_t. Do you want to choose a different one? [n] That didn't happen before. I tried autorelabel, but it had no effect. What did the copy fail to preserve, and how can I fix it? Thanks. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From sds at tycho.nsa.gov Mon Nov 28 15:50:10 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 28 Nov 2005 10:50:10 -0500 Subject: su after disk reorganization. In-Reply-To: References: Message-ID: <1133193010.348.121.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-11-28 at 10:39 -0500, Matthew Saltzman wrote: > I rebuilt my system disk to change the partitioning arrangment. This > involved copying everything off, repartitioning, copying everything > back, and creating a new initrd. > > Almost everything seems to work now except that when I su, after the > password prompt, I get the following prompt: > > $ su > Password: > Your default context is root:system_r:kernel_t. > > Do you want to choose a different one? [n] > > That didn't happen before. I tried autorelabel, but it had no effect. > > What did the copy fail to preserve, and how can I fix it? Can you run: /usr/sbin/sestatus -v | grep -v active and show the results? Offhand, I would have assumed that the copy simply failed to preserve the security.selinux attributes, but you said that you tried relabeling (/sbin/fixfiles relabel) and presumably rebooted afterwards. Or perhaps you just touched /.autorelabel and rebooted? Maybe that isn't working properly? Try relabeling explicitly. -- Stephen Smalley National Security Agency From mjs at ces.clemson.edu Mon Nov 28 18:40:05 2005 From: mjs at ces.clemson.edu (Matthew Saltzman) Date: Mon, 28 Nov 2005 13:40:05 -0500 (EST) Subject: su after disk reorganization. In-Reply-To: <1133193010.348.121.camel@moss-spartans.epoch.ncsc.mil> References: <1133193010.348.121.camel@moss-spartans.epoch.ncsc.mil> Message-ID: On Mon, 28 Nov 2005, Stephen Smalley wrote: > On Mon, 2005-11-28 at 10:39 -0500, Matthew Saltzman wrote: >> I rebuilt my system disk to change the partitioning arrangment. This >> involved copying everything off, repartitioning, copying everything >> back, and creating a new initrd. >> >> Almost everything seems to work now except that when I su, after the >> password prompt, I get the following prompt: >> >> $ su >> Password: >> Your default context is root:system_r:kernel_t. >> >> Do you want to choose a different one? [n] >> >> That didn't happen before. I tried autorelabel, but it had no effect. >> >> What did the copy fail to preserve, and how can I fix it? > > Can you run: > /usr/sbin/sestatus -v | grep -v active > and show the results? # /usr/sbin/sestatus -v | grep -v active SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 19 Policy from config file: targeted Policy booleans: Process contexts: Current context: root:system_r:kernel_t Init context: system_u:system_r:init_t /sbin/mingetty system_u:system_r:kernel_t /usr/sbin/sshd system_u:system_r:kernel_t File contexts: Controlling term: system_u:object_r:devpts_t /etc/passwd system_u:object_r:etc_t /etc/shadow system_u:object_r:shadow_t /bin/bash system_u:object_r:shell_exec_t /bin/login system_u:object_r:login_exec_t /bin/sh system_u:object_r:bin_t -> system_u:object_r:shell_exec_t /sbin/agetty system_u:object_r:getty_exec_t /sbin/init system_u:object_r:init_exec_t /sbin/mingetty system_u:object_r:getty_exec_t /usr/sbin/sshd system_u:object_r:sshd_exec_t /lib/libc.so.6 system_u:object_r:lib_t -> system_u:object_r:shlib_t /lib/ld-linux.so.2 system_u:object_r:lib_t -> system_u:object_r:ld_so_t > > Offhand, I would have assumed that the copy simply failed to preserve > the security.selinux attributes, but you said that you tried relabeling > (/sbin/fixfiles relabel) and presumably rebooted afterwards. Or perhaps > you just touched /.autorelabel and rebooted? Maybe that isn't working > properly? Try relabeling explicitly. I just touched /.autorelabel. The relabel did proceed as ordered on reboot. Here are the results of explicit relablel: # /sbin/fixfiles relabel Files in the /tmp directory may be labeled incorrectly, this command can remove all files in /tmp. If you choose to remove files from /tmp, a reboot will be required after completion. Do you wish to clean out the /tmp directory [N]? y /.autofsck: Permission denied /usr/sbin/setfiles: unable to relabel /.autofsck to system_u:object_r:etc_runtime_t /etc/rhgb/temp: Permission denied /usr/sbin/setfiles: unable to relabel /etc/rhgb/temp to system_u:object_r:mnt_t/etc/blkid.tab: Permission denied /usr/sbin/setfiles: unable to relabel /etc/blkid.tab to system_u:object_r:etc_runtime_t /etc/resolv.conf.predhclient: Permission denied /usr/sbin/setfiles: unable to relabel /etc/resolv.conf.predhclient to system_u:object_r:net_conf_t /var/run/utmp: Permission denied /usr/sbin/setfiles: unable to relabel /var/run/utmp to system_u:object_r:initrc_var_run_t /var/run/dhclient-eth0.pid: Permission denied /usr/sbin/setfiles: unable to relabel /var/run/dhclient-eth0.pid to system_u:object_r:dhcpc_var_run_t /var/run/syslogd.pid: Permission denied /usr/sbin/setfiles: unable to relabel /var/run/syslogd.pid to system_u:object_r:syslogd_var_run_t /var/run/klogd.pid: Permission denied /usr/sbin/setfiles: unable to relabel /var/run/klogd.pid to system_u:object_r:klogd_var_run_t /var/run/rpc.statd.pid: Permission denied /usr/sbin/setfiles: unable to relabel /var/run/rpc.statd.pid to system_u:object_r:rpcd_var_run_t /var/run/sdp: Permission denied /usr/sbin/setfiles: unable to relabel /var/run/sdp to system_u:object_r:bluetooth_var_run_t /var/run/nifd.pid: Permission denied /usr/sbin/setfiles: unable to relabel /var/run/nifd.pid to system_u:object_r:howl_var_run_t /var/run/acpid.socket: Permission denied /usr/sbin/setfiles: unable to relabel /var/run/acpid.socket to system_u:object_r:apmd_var_run_t /var/run/ntpd.pid: Permission denied /usr/sbin/setfiles: unable to relabel /var/run/ntpd.pid to system_u:object_r:ntpd_var_run_t /var/run/sendmail.pid: Permission denied /usr/sbin/setfiles: unable to relabel /var/run/sendmail.pid to system_u:object_r:sendmail_var_run_t /var/run/sm-client.pid: Permission denied /usr/sbin/setfiles: unable to relabel /var/run/sm-client.pid to system_u:object_r:sendmail_var_run_t /var/run/crond.pid: Permission denied /usr/sbin/setfiles: unable to relabel /var/run/crond.pid to system_u:object_r:crond_var_run_t /var/run/atd.pid: Permission denied /usr/sbin/setfiles: unable to relabel /var/run/atd.pid to system_u:object_r:crond_var_run_t /var/log/rpmpkgs: Permission denied /usr/sbin/setfiles: unable to relabel /var/log/rpmpkgs to system_u:object_r:rpm_log_t /home/mjs/.Xauthority: Permission denied /usr/sbin/setfiles: unable to relabel /home/mjs/.Xauthority to user_u:object_r:user_home_t /home/mjs/.gpilotd.pid: Permission denied /usr/sbin/setfiles: unable to relabel /home/mjs/.gpilotd.pid to user_u:object_r:user_home_t After rebooting, the problem is apparently solved, however. Entering "su" and password results in a root prompt. Thanks. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From sds at tycho.nsa.gov Mon Nov 28 19:53:22 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 28 Nov 2005 14:53:22 -0500 Subject: findutils-selinux.patch critique (was Re: [patch] Recent findutils test suite failures) In-Reply-To: <20051125093548.GW10349@redhat.com> References: <20051125093548.GW10349@redhat.com> Message-ID: <1133207602.348.240.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-11-25 at 09:35 +0000, Tim Waugh wrote: > Forwarding this to a wider SELinux-knowledgeable audience. James had > asked me what patches we apply to findutils, so I mentioned SELinux > and pointed him to the patch for an initial review. IIRC, the findutils SELinux patch was originally created by a person from MITRE who is no longer involved in the project. Dan later rewrote it for the new SELinux API in Linux 2.6. > 1. I notice that SELinux-enablement creates two new tests, "-context" > and "--context". I would eliminate "--context", leaving only > "-context". Find predicates aren't GNU-style long options. Find > is confusing enough with options as well as predicates, and so I > definitely don't want to further blur that line. This suggestion seems fine. > 2. I see that if you use "find -context" on an SELinux-enabled version > of find on a system where SELinux is not enabled, find will > immediately perform a fatal exit with an explanatory message. I > won't say that that is definitely the wrong behaviour, but why did > you choose not to have -context simply always return false (and > perhaps issue one warning message)? This may be a legacy issue. Since getfilecon is implemented via getxattr(2), and getxattr(2) does not require SELinux to be enabled, we might want to drop this restriction. The older SELinux API (before migrating to using xattrs) would only have worked if SELinux was enabled. > 3. Security contexts are long multi-part strings. Matching with glob > patterns is a reasonable approach. Nevertheless, does the use of > glob patterns to match them reflect practice on other systems? I'm not sure what we would compare against in terms of other systems (Trusted Solaris?), or exactly how they would compare. Some kind of pattern matching (regex or glob patterns) seems necessary to deal with searching for e.g. a particular TE type without being concerned about other fields. > 4. I notice that your patch slips in a definition for FNM_CASEFOLD. > That looks wrong to me. gl_FUNC_FNMATCH_GNU should call > AC_GNU_SOURCE to ensure that #defines FNM_CASEFOLD for > you. This should be called by gl_INIT. Is this (a) not working > correctly on some of your build systems, (b) not working on any of > your build systems, implying a findutils bug, or (c) there for > 'historical reasons'? I don't know - looks like you added these lines earlier this year upon merging 4.2.15. > 5. Findutils should probably default to compiling with SELinux support > on systems where exists or --with-selinux is > specifified to configure, and compile without such support > otherwise. Seems reasonable. > 6. Is there a reason you turn off Automake gnits rules checking in the > SELinux patch? No ideas here - looks like a change by Dan very recently from the cvs log. > 7. The configure magic for selinux can be fully generic and > self-contained I think: we could just have an selinux.m4 file. > That would also make it much easier to reuse it. Seems fine. > 8. Are the DejaGnu test cases for the SELinux patch in another patch > file somewhere else? Perhaps it's in the same patch file as the > update to the Texinfo documentation. :) Likely doesn't exist yet. -- Stephen Smalley National Security Agency From subscribed-lists at sterndata.com Tue Nov 29 04:34:43 2005 From: subscribed-lists at sterndata.com (Steven Stern) Date: Mon, 28 Nov 2005 22:34:43 -0600 Subject: newest(-3.19) selinux? In-Reply-To: <438B80C1.7080608@cam.ac.uk> References: <438B80C1.7080608@cam.ac.uk> Message-ID: <438BDA63.3090803@sterndata.com> Ian Malone wrote: > I see there's an updated selinux-policy-targeted. > I'm currently 1.17.30-3.16, newest is 1.17.30-3.19 > Has anyone had any trouble with this? (i.e. can > I install now or should I wait till the weekend?) > Problems. After installation, I get this when running yum, between the download and the installation: Transaction Test Succeeded Running Transaction /etc/selinux/targeted/contexts/files/file_contexts: line 825 has invalid context system_u:object_r:lvm_exec_t /etc/selinux/targeted/contexts/files/file_contexts: line 1572 has invalid context system_u:object_r:slapd_lock_t /etc/selinux/targeted/contexts/files/file_contexts: line 1579 has invalid context system_u:object_r:slapd_cert_t -- Steve From selinux at gmail.com Tue Nov 29 16:20:14 2005 From: selinux at gmail.com (Tom London) Date: Tue, 29 Nov 2005 08:20:14 -0800 Subject: selinux and udev ? Message-ID: <4c4ba1530511290820m748d86f4ibb08e6528154f6ce@mail.gmail.com> There are reports in fedora-test about the 2.X policy slowing down udev. (Appears that folks are comparing booting with selinxux=1 with selinux=0). I have to admit that udev is running slower (targeted/enforcing). Any validity to this? Known issue? How to track down? tom -- Tom London From dwalsh at redhat.com Tue Nov 29 16:28:13 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 29 Nov 2005 11:28:13 -0500 Subject: newest(-3.19) selinux? In-Reply-To: <438BDA63.3090803@sterndata.com> References: <438B80C1.7080608@cam.ac.uk> <438BDA63.3090803@sterndata.com> Message-ID: <438C819D.3050006@redhat.com> Steven Stern wrote: > Ian Malone wrote: >> I see there's an updated selinux-policy-targeted. >> I'm currently 1.17.30-3.16, newest is 1.17.30-3.19 >> Has anyone had any trouble with this? (i.e. can >> I install now or should I wait till the weekend?) >> > > Problems. > > After installation, I get this when running yum, between the download > and the installation: > > Transaction Test Succeeded > Running Transaction > /etc/selinux/targeted/contexts/files/file_contexts: line 825 has > invalid context system_u:object_r:lvm_exec_t > /etc/selinux/targeted/contexts/files/file_contexts: line 1572 has > invalid context system_u:object_r:slapd_lock_t > /etc/selinux/targeted/contexts/files/file_contexts: line 1579 has > invalid context system_u:object_r:slapd_cert_t > > Do you have policy sources installed? If yes could you do a make -C /etc/selinux/targeted/src/policy reload -- From dwalsh at redhat.com Tue Nov 29 16:34:13 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 29 Nov 2005 11:34:13 -0500 Subject: SELINUX problem and SPAMASSASSIN In-Reply-To: <437142B9.9020306@sterndata.com> References: <437142B9.9020306@sterndata.com> Message-ID: <438C8305.1070907@redhat.com> Steven Stern wrote: > I just built a new FC4 machine and am migrating my mail server to it. I > got an error each time I started spamassassin until I put selinux into > permissive mode. > > How can I configure selinux to allow this? > > > > Nov 8 17:23:19 mooch spamd[4899]: Error creating a DNS resolver socket: > Permission denied at > /usr/lib/perl5/site_perl/5.8.6/Mail/SpamAssassin/DnsResolver.pm line > 202, line 44. > > > Have you updated to the latest released packages? -- From sds at tycho.nsa.gov Tue Nov 29 16:48:13 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 29 Nov 2005 11:48:13 -0500 Subject: selinux and udev ? In-Reply-To: <4c4ba1530511290820m748d86f4ibb08e6528154f6ce@mail.gmail.com> References: <4c4ba1530511290820m748d86f4ibb08e6528154f6ce@mail.gmail.com> Message-ID: <1133282893.26593.137.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-11-29 at 08:20 -0800, Tom London wrote: > There are reports in fedora-test about the 2.X policy slowing down > udev. (Appears that folks are comparing booting with selinxux=1 with > selinux=0). > > I have to admit that udev is running slower (targeted/enforcing). > > Any validity to this? Known issue? How to track down? First, check whether you have any avc denials associated with udev in your audit.log. If not, then the slowdown is likely in matchpathcon(3), used to match a path against the file_contexts configuration to obtain a security context to apply to the device node. Could be a result of: - differences in the file_contexts configurations between reference policy and the original targeted policy (ordering, regex stem lengths, regex complexity, number of entries, ...), - the introduction of context canonicalization into matchpathcon(3) to avoid problems with type aliases (in which case it shouldn't be different between reference policy and the original targeted policy, just between old libselinux/kernel versus newer libselinux/kernel combination - you need both a recent libselinux and a recent kernel to have the canonicalization support enabled). -- Stephen Smalley National Security Agency From dwalsh at redhat.com Tue Nov 29 16:42:25 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 29 Nov 2005 11:42:25 -0500 Subject: Problems with httpd and SElinux. In-Reply-To: References: Message-ID: <438C84F1.2030706@redhat.com> Daniel B. Thurman wrote: >> From: fedora-selinux-list-bounces at redhat.com >> [mailto:fedora-selinux-list-bounces at redhat.com]On Behalf Of Daniel B. >> Thurman >> Sent: Tuesday, November 08, 2005 3:43 PM >> To: Robert Cahn; Daniel J Walsh >> Cc: fedora-list at redhat.com; fedora-selinux-list at redhat.com >> Subject: RE: Problems with httpd and SElinux. >> >> >> >>> From: Daniel J Walsh [mailto:dwalsh at redhat.com] >>> Sent: Monday, November 07, 2005 9:30 AM >>> To: Daniel B. Thurman >>> Cc: fedora-selinux-list at redhat.com >>> Subject: Re: Problems with httpd and SElinux. >>> >>> >>> Daniel B. Thurman wrote: >>> >>>> Folks, >>>> >>>> I was asked to post this information here. To explain things, >>>> I have installed FrontPage extensions on FC4 but not realizing >>>> that I had to first disable SElinux for httpd first, but to make >>>> a long story short, I was able to install FP and then restore >>>> SElinux protections for httpd, but on reboot, SElinux refused >>>> to allow httpd to start and I suspect it had something to do >>>> with the FrontPage additions to the /etc/httpd/conf/httpd.conf >>>> file. I currently have SElinux protections turned off for >>>> https. Below is the audit file, hope it helps show the problem. >>>> >>>> type=AVC msg=audit(1131056930.757:251): avc: denied { >>>> >>> name_bind } for pid=4946 comm="httpd" src=8090 >>> scontext=root:system_r:httpd_t >>> tcontext=system_u:object_r:port_t tclass=tcp_socket >>> >>>> type=SYSCALL msg=audit(1131056930.757:251): arch=40000003 >>>> >>> syscall=102 success=no exit=-13 a0=2 a1=bfc779f0 a2=750218 >>> a3=8b8da58 items=0 pid=4946 auid=4294967295 uid=0 gid=0 euid=0 >>> suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="httpd" >>> >> exe="/usr/sbin/httpd" >> >>>> type=SOCKADDR msg=audit(1131056930.757:251): >>>> >>> saddr=0A001F9A000000000000000000000000000000000000000000000000 >>> >>>> type=SOCKETCALL msg=audit(1131056930.757:251): nargs=3 a0=5 >>>> >>> a1=8b8da84 a2=1c >>> >>>> Kind regards, >>>> Dan >>>> >>>> >>>> >>> We do not currently allow apache to listen on port 8090, >>> but this looks legitimate, so I will add to policy. >>> You can install policy (selinux-policy-targeted-sources >>> for now and add a line to: >>> /etc/selinux/targeted/src/policy/domains/misc/local.te >>> portcon tcp 8090 system_u:object_r:http_port_t >>> >>> Then execute make -c /etc/selinux/targeted/src/policy load >>> >>> and you should be able to use that port. >>> >>> >> The information you gave me above does not work. I got all >> sorts of compile errors. BTW, the make should be "make -C". >> >> >From Paul Howarth, I tried: >> ============================================= >> If you want httpd to be able to listen on port 8090, and you have the >> policy sources installed, you can do this by adding the following line >> to /etc/selinux/targeted/src/policy/net_contexts: >> >> portcon tcp 8090 system_u:object_r:http_port_t >> >> Then you need to compile and reload the security contexts: >> # make -C /etc/selinux/targeted/src/policy reload >> ============================================= >> >> This all compiles fine now. >> >> Testing to see if httpd can now restart with the new policies: >> 1) setsebool -P httpd_disable_trans 0 >> 2) Restart httpd for this to take effect: service httpd restart >> >> Httpd can restart with no failure messages. The httpd server >> now runs fine. >> >> HOWEVER - Testing FrontPage client against my FC4 box FAILS to >> connect and the reason revealed in /var/log/httpd/error_log: >> >> [Tue Nov 08 15:25:40 2005] [error] (13)Permission denied: >> Could not create key file >> "/usr/local/frontpage/version5.0/apache-fp/suidkey.17096" in >> FrontPageInit(). Until this problem is fixed, the FrontPage >> security patch is disabled and the FrontPage extensions may >> not work correctly. >> >> I suspect that there is a SElinux policy that is preventing the FP >> client program from creating and deleting the suidkey file it needs >> in order to startup and begin listening for FP Client requests. Please >> note that the process number is created and destroyed for the >> suidkey file >> and this is happening from within the httpd service file and >> has nothing >> to do with the FP client connection attempts. SELinux policy >> is preventing >> the service file from creating and destroying this file. >> >> So - in order to get back the successful FP client connections >> as before, >> performing these steps: >> >> 1) setsebool -P httpd_disable_trans 1 >> 2) Restart httpd for this to take effect: service httpd restart >> >> The httpd/error_log error message does not appear and I can now >> connect with to the FC4 with the FP client. >> >> Dan Thurman. >> >> -- >> > > Huh? Who resent this? This one was sent 11/7/2005... > > I replied back to Daniel J Walsh with an attachment with > the output of /var/log/audit/audit_log file that showed > why *many* denials that were occuring with SElinux preventing > the FrontPage process from working within httpd. > > In case Daniel did not get it, I am attaching the file again. > > ============================================== > Daniel J. Walsh: > ================ > >>> What did you see for AVC messages in /var/log/messages or >>> /var/log/audit/audit.log? >>> >>> >> Please see the attached file. It is the /var/log/audit/audit.log >> file and is 13k compressed. I tried best as I could to trucate to >> relevant logs pertaining to httpd/fp issues. Please let me know if >> you need anything else. >> > ============================================== > > Kind regards, > Dan > > > Looks like apache is trying to write to apache-fp directory under /usr somewhere. This dir needs to be labeled httpd_sys_script_rw_t to work correctly. Also looks like apache tried to do a ps -e or such to get all the process on the system. -- From sds at tycho.nsa.gov Tue Nov 29 16:51:59 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 29 Nov 2005 11:51:59 -0500 Subject: selinux and udev ? In-Reply-To: <1133282893.26593.137.camel@moss-spartans.epoch.ncsc.mil> References: <4c4ba1530511290820m748d86f4ibb08e6528154f6ce@mail.gmail.com> <1133282893.26593.137.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1133283119.26593.141.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-11-29 at 11:48 -0500, Stephen Smalley wrote: > On Tue, 2005-11-29 at 08:20 -0800, Tom London wrote: > > There are reports in fedora-test about the 2.X policy slowing down > > udev. (Appears that folks are comparing booting with selinxux=1 with > > selinux=0). > > > > I have to admit that udev is running slower (targeted/enforcing). > > > > Any validity to this? Known issue? How to track down? > > First, check whether you have any avc denials associated with udev in > your audit.log. > > If not, then the slowdown is likely in matchpathcon(3), used to match a > path against the file_contexts configuration to obtain a security > context to apply to the device node. Could be a result of: > - differences in the file_contexts configurations between reference > policy and the original targeted policy (ordering, regex stem lengths, > regex complexity, number of entries, ...), > - the introduction of context canonicalization into matchpathcon(3) to > avoid problems with type aliases (in which case it shouldn't be > different between reference policy and the original targeted policy, > just between old libselinux/kernel versus newer libselinux/kernel > combination - you need both a recent libselinux and a recent kernel to > have the canonicalization support enabled). Random thought: As udev only manages devices, why not run file_contexts through a filter to extract /dev entries at policy build time, saving the result as a file_contexts.dev file, and have udev use matchpathcon_init() to select that file for its matching. That would then avoid having to process the entire file contexts configuration for udev. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Tue Nov 29 16:47:16 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 29 Nov 2005 11:47:16 -0500 Subject: printer creation in RPM scriptlet In-Reply-To: References: Message-ID: <438C8614.3070009@redhat.com> Matthew Saltzman wrote: > I tried installing > http://remi.collet.free.fr/rpms/fc4.i386/cups-pdf-2.0.0-0.1.fc4.remi.i386.rpm. > The RPM has the following post-install scriptlet: > > if [ "$1" -eq "1" ]; then > /etc/init.d/cups restart > ( /usr/sbin/lpadmin -p Cups-PDF -v cups-pdf:/ -m > PostscriptColor.ppd -E && > echo Cups-PDF printer created > ) || true > fi > > With selinux-policy-targeted-1.27.1-2.11 in enforcing mode, the > lpadmin command fails with error: > > lpadmin: add-printer (set device) failed: client-error-not-possible > > In permissive mode, the install proceeds without problem. > > The relevant audit.log entries are: > > type=AVC msg=audit(1133045911.757:788): avc: denied { ioctl } for > pid=20774 comm="printconf-backe" name="[7217936]" dev=pipefs > ino=7217936 scontext=root:system_r:cupsd_config_t > tcontext=root:system_r:unconfined_t tclass=fifo_file > > type=SYSCALL msg=audit(1133045911.757:788): arch=40000003 syscall=54 > success=no exit=-13 a0=0 a1=5401 a2=bfd10098 a3=bfd100d8 items=0 > pid=20774 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 comm="printconf-backe" exe="/usr/bin/python" > > type=AVC_PATH msg=audit(1133045911.757:788): path="pipe:[7217936]" > > type=AVC msg=audit(1133045911.757:789): avc: denied { getattr } for > pid=20774 comm="printconf-backe" name="[7217936]" dev=pipefs > ino=7217936 scontext=root:system_r:cupsd_config_t > tcontext=root:system_r:unconfined_t tclass=fifo_file > > type=SYSCALL msg=audit(1133045911.757:789): arch=40000003 syscall=197 > success=no exit=-13 a0=0 a1=bfd0fffc a2=960ff4 a3=b7ec4020 items=0 > pid=20774 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 comm="printconf-backe" exe="/usr/bin/python" > > type=AVC_PATH msg=audit(1133045911.757:789): path="pipe:[7217936]" > > type=AVC msg=audit(1133045911.781:790): avc: denied { ioctl } for > pid=20774 comm="printconf-backe" name="[7217936]" dev=pipefs > ino=7217936 scontext=root:system_r:cupsd_config_t > tcontext=root:system_r:unconfined_t tclass=fifo_file > > type=SYSCALL msg=audit(1133045911.781:790): arch=40000003 syscall=54 > success=no exit=-13 a0=0 a1=5401 a2=bfd0ffb8 a3=bfd0fff8 items=0 > pid=20774 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 comm="printconf-backe" exe="/usr/bin/python" > > type=AVC_PATH msg=audit(1133045911.781:790): path="pipe:[7217936]" > > type=AVC msg=audit(1133045912.273:791): avc: denied { getattr } for > pid=20787 comm="cups-pdf" name="SPOOL" dev=dm-0 ino=737988 > scontext=root:system_r:cupsd_t tcontext=system_u:object_r:var_spool_t > tclass=dir > > type=SYSCALL msg=audit(1133045912.273:791): arch=40000003 syscall=195 > success=no exit=-13 a0=8057f20 a1=bf9c9a6c a2=960ff4 a3=bf9c9a6c > items=1 pid=20787 auid=4294967295 uid=0 gid=7 euid=0 suid=0 fsuid=0 > egid=7 sgid=7 fsgid=7 comm="cups-pdf" > exe="/usr/lib/cups/backend/cups-pdf" > > type=AVC_PATH msg=audit(1133045912.273:791): > path="/var/spool/cups-pdf/SPOOL" > > type=CWD msg=audit(1133045912.273:791): cwd="/" > > type=PATH msg=audit(1133045912.273:791): item=0 > name="/var/spool/cups-pdf/SPOOL" flags=1 inode=737988 dev=fd:00 > mode=040755 ouid=0 ogid=0 rdev=00:00 > Fixed in selinux-policy-targeted-1.27.1-2.15 -- From sds at tycho.nsa.gov Tue Nov 29 17:04:32 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 29 Nov 2005 12:04:32 -0500 Subject: selinux and udev ? In-Reply-To: <1133283119.26593.141.camel@moss-spartans.epoch.ncsc.mil> References: <4c4ba1530511290820m748d86f4ibb08e6528154f6ce@mail.gmail.com> <1133282893.26593.137.camel@moss-spartans.epoch.ncsc.mil> <1133283119.26593.141.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1133283872.26593.143.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-11-29 at 11:51 -0500, Stephen Smalley wrote: > Random thought: As udev only manages devices, why not run file_contexts > through a filter to extract /dev entries at policy build time, saving > the result as a file_contexts.dev file, and have udev use > matchpathcon_init() to select that file for its matching. That would > then avoid having to process the entire file contexts configuration for > udev. An unscientific experiment, with a slightly modified matchpathcon util that lets me specify the file_contexts path: $ grep '^/dev' file_contexts > file_contexts.dev $ time ./matchpathcon -f file_contexts.dev /dev/ttyS0 /dev/ttyS0 system_u:object_r:tty_device_t real 0m0.023s user 0m0.012s sys 0m0.008s $ time ./matchpathcon -f file_contexts /dev/ttyS0 /dev/ttyS0 system_u:object_r:tty_device_t real 0m0.216s user 0m0.152s sys 0m0.064s Quite the difference, no? -- Stephen Smalley National Security Agency From selinux at gmail.com Tue Nov 29 17:17:45 2005 From: selinux at gmail.com (Tom London) Date: Tue, 29 Nov 2005 09:17:45 -0800 Subject: selinux and udev ? In-Reply-To: <1133283872.26593.143.camel@moss-spartans.epoch.ncsc.mil> References: <4c4ba1530511290820m748d86f4ibb08e6528154f6ce@mail.gmail.com> <1133282893.26593.137.camel@moss-spartans.epoch.ncsc.mil> <1133283119.26593.141.camel@moss-spartans.epoch.ncsc.mil> <1133283872.26593.143.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4c4ba1530511290917r8d2bd5bk4abfba5321fc1fdb@mail.gmail.com> On 11/29/05, Stephen Smalley wrote: > On Tue, 2005-11-29 at 11:51 -0500, Stephen Smalley wrote: > > Random thought: As udev only manages devices, why not run file_contexts > > through a filter to extract /dev entries at policy build time, saving > > the result as a file_contexts.dev file, and have udev use > > matchpathcon_init() to select that file for its matching. That would > > then avoid having to process the entire file contexts configuration for > > udev. > > An unscientific experiment, with a slightly modified matchpathcon util > that lets me specify the file_contexts path: > > $ grep '^/dev' file_contexts > file_contexts.dev > $ time ./matchpathcon -f file_contexts.dev /dev/ttyS0 > /dev/ttyS0 system_u:object_r:tty_device_t > > real 0m0.023s > user 0m0.012s > sys 0m0.008s > $ time ./matchpathcon -f file_contexts /dev/ttyS0 > /dev/ttyS0 system_u:object_r:tty_device_t > > real 0m0.216s > user 0m0.152s > sys 0m0.064s > > Quite the difference, no? > Cool. I take it matchpathcon() is called approx. once per created entry in /dev, etc. If so, 'du -a /dev | wc' reports about 310 entries on my system. If so, that would be noticable. ;) tom -- Tom London From ivg2 at cornell.edu Tue Nov 29 17:46:25 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Tue, 29 Nov 2005 12:46:25 -0500 Subject: selinux and udev ? In-Reply-To: <1133283872.26593.143.camel@moss-spartans.epoch.ncsc.mil> References: <4c4ba1530511290820m748d86f4ibb08e6528154f6ce@mail.gmail.com> <1133282893.26593.137.camel@moss-spartans.epoch.ncsc.mil> <1133283119.26593.141.camel@moss-spartans.epoch.ncsc.mil> <1133283872.26593.143.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <438C93F1.4040300@cornell.edu> > Quite the difference, no? > Maybe this could be generalized (what's special about /dev?). "make install" does not need to analyze all the paths on the system (per file!)... From selinux at gmail.com Tue Nov 29 17:43:15 2005 From: selinux at gmail.com (Tom London) Date: Tue, 29 Nov 2005 09:43:15 -0800 Subject: selinux and udev ? In-Reply-To: <438C93F1.4040300@cornell.edu> References: <4c4ba1530511290820m748d86f4ibb08e6528154f6ce@mail.gmail.com> <1133282893.26593.137.camel@moss-spartans.epoch.ncsc.mil> <1133283119.26593.141.camel@moss-spartans.epoch.ncsc.mil> <1133283872.26593.143.camel@moss-spartans.epoch.ncsc.mil> <438C93F1.4040300@cornell.edu> Message-ID: <4c4ba1530511290943x2fa1a616x549bdfa309a248f8@mail.gmail.com> On 11/29/05, Ivan Gyurdiev wrote: > > > Quite the difference, no? > > > Maybe this could be generalized (what's special about /dev?). > "make install" does not need to analyze all the paths on the system > (per file!)... > Hmm.... This sort of suggests a different file organization, no? How about 'overlaying' something like a trie or some search tree organized by directory 'prefixes' (e.g., '/dev', '/lib', etc.). Should be possible to organize the general matching cases into one bucket. tom -- Tom London From sds at tycho.nsa.gov Tue Nov 29 18:22:01 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 29 Nov 2005 13:22:01 -0500 Subject: selinux and udev ? In-Reply-To: <4c4ba1530511290943x2fa1a616x549bdfa309a248f8@mail.gmail.com> References: <4c4ba1530511290820m748d86f4ibb08e6528154f6ce@mail.gmail.com> <1133282893.26593.137.camel@moss-spartans.epoch.ncsc.mil> <1133283119.26593.141.camel@moss-spartans.epoch.ncsc.mil> <1133283872.26593.143.camel@moss-spartans.epoch.ncsc.mil> <438C93F1.4040300@cornell.edu> <4c4ba1530511290943x2fa1a616x549bdfa309a248f8@mail.gmail.com> Message-ID: <1133288521.26593.167.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-11-29 at 09:43 -0800, Tom London wrote: > On 11/29/05, Ivan Gyurdiev wrote: > > > > > Quite the difference, no? > > > > > Maybe this could be generalized (what's special about /dev?). > > "make install" does not need to analyze all the paths on the system > > (per file!)... > > > Hmm.... > > This sort of suggests a different file organization, no? > > How about 'overlaying' something like a trie or some search tree > organized by directory 'prefixes' (e.g., '/dev', '/lib', etc.). Should > be possible to organize the general matching cases into one bucket. IIUC, the primary overhead isn't during the matching phase; it is during initial processing of file_contexts by matchpathcon_init(), when it loads the entire file_contexts configuration into the in-memory representation and compiles all of the regexes. Most of the time is spent in regcomp(). So the only way to reduce it is to reduce the set of entries processed during matchpathcon_init(), which doesn't know what paths you are going to subsequently try matching via matchpathcon(). The expected usage model was that matchpathcon_init() would be invoked once followed by multiple matchpathcon() calls by the application, as in setfiles and restorecon (the original users). IIUC, udev is executed on each event, so it ends up performing matchpathcon_init() on every node creation and we don't get any caching of the data. We could introduce a variant interface that is optimized for the case where you are only going to perform matchpathcon() calls on paths with a common prefix (e.g. /dev), or the SELinux support in udev could be re-visited (leveraging the udevd daemon to cache the data once for all udev instances?). -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Tue Nov 29 18:23:30 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 29 Nov 2005 13:23:30 -0500 Subject: selinux and udev ? In-Reply-To: <1133286973.17843.7.camel@rousalka.dyndns.org> References: <4c4ba1530511290820m748d86f4ibb08e6528154f6ce@mail.gmail.com> <1133282893.26593.137.camel@moss-spartans.epoch.ncsc.mil> <1133286973.17843.7.camel@rousalka.dyndns.org> Message-ID: <1133288610.26593.169.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-11-29 at 18:56 +0100, Nicolas Mailhot wrote: > Le mardi 29 novembre 2005 ? 11:48 -0500, Stephen Smalley a ?crit : > > On Tue, 2005-11-29 at 08:20 -0800, Tom London wrote: > > > There are reports in fedora-test about the 2.X policy slowing down > > > udev. (Appears that folks are comparing booting with selinxux=1 with > > > selinux=0). > > > > > > I have to admit that udev is running slower (targeted/enforcing). > > > > > > Any validity to this? Known issue? How to track down? > > > > First, check whether you have any avc denials associated with udev in > > your audit.log. > > There are certainly many denials with the new 2.0 policy, including udev > stuff (at least it was the case a week ago). I've posted 2.0 audit logs > many times in bugzilla. I think many of those avc issues have been resolved, although there may still be lingering ones. I think that the udev slowdown is more likely matchpathcon / file_contexts issues. -- Stephen Smalley National Security Agency From nicolas.mailhot at laposte.net Tue Nov 29 17:56:10 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 29 Nov 2005 18:56:10 +0100 Subject: selinux and udev ? In-Reply-To: <1133282893.26593.137.camel@moss-spartans.epoch.ncsc.mil> References: <4c4ba1530511290820m748d86f4ibb08e6528154f6ce@mail.gmail.com> <1133282893.26593.137.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1133286973.17843.7.camel@rousalka.dyndns.org> Le mardi 29 novembre 2005 ? 11:48 -0500, Stephen Smalley a ?crit : > On Tue, 2005-11-29 at 08:20 -0800, Tom London wrote: > > There are reports in fedora-test about the 2.X policy slowing down > > udev. (Appears that folks are comparing booting with selinxux=1 with > > selinux=0). > > > > I have to admit that udev is running slower (targeted/enforcing). > > > > Any validity to this? Known issue? How to track down? > > First, check whether you have any avc denials associated with udev in > your audit.log. There are certainly many denials with the new 2.0 policy, including udev stuff (at least it was the case a week ago). I've posted 2.0 audit logs many times in bugzilla. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From sds at tycho.nsa.gov Tue Nov 29 18:45:24 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 29 Nov 2005 13:45:24 -0500 Subject: selinux and udev ? In-Reply-To: <1133288521.26593.167.camel@moss-spartans.epoch.ncsc.mil> References: <4c4ba1530511290820m748d86f4ibb08e6528154f6ce@mail.gmail.com> <1133282893.26593.137.camel@moss-spartans.epoch.ncsc.mil> <1133283119.26593.141.camel@moss-spartans.epoch.ncsc.mil> <1133283872.26593.143.camel@moss-spartans.epoch.ncsc.mil> <438C93F1.4040300@cornell.edu> <4c4ba1530511290943x2fa1a616x549bdfa309a248f8@mail.gmail.com> <1133288521.26593.167.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1133289924.26593.177.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-11-29 at 13:22 -0500, Stephen Smalley wrote: > We could introduce a variant interface that is optimized for the case > where you are only going to perform matchpathcon() calls on paths with a > common prefix (e.g. /dev), or the SELinux support in udev could be > re-visited (leveraging the udevd daemon to cache the data once for all > udev instances?). Note that the latter might not help with system initialization, as I assume udev is still executed separately each time during early initialization prior to the start of udevd? -- Stephen Smalley National Security Agency From nicolas.mailhot at laposte.net Tue Nov 29 18:39:33 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 29 Nov 2005 19:39:33 +0100 Subject: selinux and udev ? In-Reply-To: <1133288610.26593.169.camel@moss-spartans.epoch.ncsc.mil> References: <4c4ba1530511290820m748d86f4ibb08e6528154f6ce@mail.gmail.com> <1133282893.26593.137.camel@moss-spartans.epoch.ncsc.mil> <1133286973.17843.7.camel@rousalka.dyndns.org> <1133288610.26593.169.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1133289576.3475.6.camel@rousalka.dyndns.org> Le mardi 29 novembre 2005 ? 13:23 -0500, Stephen Smalley a ?crit : > On Tue, 2005-11-29 at 18:56 +0100, Nicolas Mailhot wrote: > > Le mardi 29 novembre 2005 ? 11:48 -0500, Stephen Smalley a ?crit : > > > On Tue, 2005-11-29 at 08:20 -0800, Tom London wrote: > > > > There are reports in fedora-test about the 2.X policy slowing down > > > > udev. (Appears that folks are comparing booting with selinxux=1 with > > > > selinux=0). > > > > > > > > I have to admit that udev is running slower (targeted/enforcing). > > > > > > > > Any validity to this? Known issue? How to track down? > > > > > > First, check whether you have any avc denials associated with udev in > > > your audit.log. > > > > There are certainly many denials with the new 2.0 policy, including udev > > stuff (at least it was the case a week ago). I've posted 2.0 audit logs > > many times in bugzilla. > > I think many of those avc issues have been resolved, although there may > still be lingering ones. I think that the udev slowdown is more likely > matchpathcon / file_contexts issues. The udev denial seems fixed with selinux-policy-targeted-2.0.6-1. So things get (slowly) fixed. But most issues are still there : audit2allow < /var/log/audit/audit.log allow dovecot_auth_t var_lib_t:dir search; allow system_chkpwd_t devpts_t:chr_file { read write }; allow procmail_t spamd_port_t:tcp_socket name_connect; allow updfstab_t tmpfs_t:dir getattr; allow dovecot_auth_t etc_runtime_t:file read; allow spamd_t port_t:udp_socket name_bind; (this bit is the spamassassin resolver issue Steven Stern just reported for FC4. It was briefly fixed in Rawhide, then regressed to broken stage with the 2.x policy change) (generated on a clean fully relabeled system after 3 min of activity) That's almost the same list I had with selinux-policy-targeted-2.0.0 Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From dwalsh at redhat.com Tue Nov 29 20:01:41 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 29 Nov 2005 15:01:41 -0500 Subject: selinux and udev ? In-Reply-To: <1133289576.3475.6.camel@rousalka.dyndns.org> References: <4c4ba1530511290820m748d86f4ibb08e6528154f6ce@mail.gmail.com> <1133282893.26593.137.camel@moss-spartans.epoch.ncsc.mil> <1133286973.17843.7.camel@rousalka.dyndns.org> <1133288610.26593.169.camel@moss-spartans.epoch.ncsc.mil> <1133289576.3475.6.camel@rousalka.dyndns.org> Message-ID: <438CB3A5.8000403@redhat.com> Nicolas Mailhot wrote: > Le mardi 29 novembre 2005 ? 13:23 -0500, Stephen Smalley a ?crit : > >> On Tue, 2005-11-29 at 18:56 +0100, Nicolas Mailhot wrote: >> >>> Le mardi 29 novembre 2005 ? 11:48 -0500, Stephen Smalley a ?crit : >>> >>>> On Tue, 2005-11-29 at 08:20 -0800, Tom London wrote: >>>> >>>>> There are reports in fedora-test about the 2.X policy slowing down >>>>> udev. (Appears that folks are comparing booting with selinxux=1 with >>>>> selinux=0). >>>>> >>>>> I have to admit that udev is running slower (targeted/enforcing). >>>>> >>>>> Any validity to this? Known issue? How to track down? >>>>> >>>> First, check whether you have any avc denials associated with udev in >>>> your audit.log. >>>> >>> There are certainly many denials with the new 2.0 policy, including udev >>> stuff (at least it was the case a week ago). I've posted 2.0 audit logs >>> many times in bugzilla. >>> >> I think many of those avc issues have been resolved, although there may >> still be lingering ones. I think that the udev slowdown is more likely >> matchpathcon / file_contexts issues. >> > > The udev denial seems fixed with selinux-policy-targeted-2.0.6-1. So > things get (slowly) fixed. But most issues are still there : > > audit2allow < /var/log/audit/audit.log > allow dovecot_auth_t var_lib_t:dir search; > allow system_chkpwd_t devpts_t:chr_file { read write }; > allow procmail_t spamd_port_t:tcp_socket name_connect; > allow updfstab_t tmpfs_t:dir getattr; > allow dovecot_auth_t etc_runtime_t:file read; > allow spamd_t port_t:udp_socket name_bind; > (this bit is the spamassassin resolver issue Steven Stern just reported > for FC4. It was briefly fixed in Rawhide, then regressed to broken stage > with the 2.x policy change) > > (generated on a clean fully relabeled system after 3 min of activity) > > That's almost the same list I had with selinux-policy-targeted-2.0.0 > > Regards, > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list selinux-policy-2.0.6-2 should fix most of those. Available on ftp://people.redhat.com/dwalsh/SELinux/Fedora -- From nicolas.mailhot at laposte.net Tue Nov 29 21:18:49 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 29 Nov 2005 22:18:49 +0100 Subject: selinux and udev ? In-Reply-To: <438CB3A5.8000403@redhat.com> References: <4c4ba1530511290820m748d86f4ibb08e6528154f6ce@mail.gmail.com> <1133282893.26593.137.camel@moss-spartans.epoch.ncsc.mil> <1133286973.17843.7.camel@rousalka.dyndns.org> <1133288610.26593.169.camel@moss-spartans.epoch.ncsc.mil> <1133289576.3475.6.camel@rousalka.dyndns.org> <438CB3A5.8000403@redhat.com> Message-ID: <1133299132.3426.10.camel@rousalka.dyndns.org> Le mardi 29 novembre 2005 ? 15:01 -0500, Daniel J Walsh a ?crit : > Nicolas Mailhot wrote: > > The udev denial seems fixed with selinux-policy-targeted-2.0.6-1. So > > things get (slowly) fixed. But most issues are still there : > > > > audit2allow < /var/log/audit/audit.log > > allow dovecot_auth_t var_lib_t:dir search; > > allow system_chkpwd_t devpts_t:chr_file { read write }; > > allow procmail_t spamd_port_t:tcp_socket name_connect; > > allow updfstab_t tmpfs_t:dir getattr; > > allow dovecot_auth_t etc_runtime_t:file read; > > allow spamd_t port_t:udp_socket name_bind; > > (this bit is the spamassassin resolver issue Steven Stern just reported > > for FC4. It was briefly fixed in Rawhide, then regressed to broken stage > > with the 2.x policy change) > > > > (generated on a clean fully relabeled system after 3 min of activity) > > > > That's almost the same list I had with selinux-policy-targeted-2.0.0 > selinux-policy-2.0.6-2 should fix most of those. This one is much better, right. I had to work a little harder to fill my AVC quota. Now I only get : # audit2allow < /var/log/audit/audit.log | sort allow dovecot_auth_t var_auth_t:dir write; (on-the-fly pam_abl database creation failure, strangely works fine from ssh) allow saslauthd_t self:capability setuid; (should saslauthd be allowed setuid ?) allow saslauthd_t var_auth_t:dir search; (more pam_abl stuff) allow spamd_t port_t:udp_socket name_bind; Probably related to one of those : Nov 29 22:08:11 rousalka spamd[2382]: Error creating a DNS resolver socket: Permission non accord?e at /usr/lib/perl5/vendor_perl/5.8.7/Mail/SpamAssassin/DnsResolver.pm line 202, line 120. Nov 29 22:08:11 rousalka spamd[2382]: spamd: Error creating a DNS resolver socket: Permission non accord?e at /usr/lib/perl5/vendor_perl/5.8.7/Mail/SpamAssassin/DnsResolver.pm line 202, line 120. Nov 29 22:09:38 rousalka spamd[2382]: spamd: connection from localhost.localdomain [127.0.0.1] at port 50657 Nov 29 22:09:38 rousalka spamd[2382]: spamd: setuid to nim succeeded Nov 29 22:09:38 rousalka spamd[2382]: spamd: creating default_prefs: /home/nim/.spamassassin/user_prefs Nov 29 22:09:38 rousalka spamd[2382]: mkdir /home/nim: Le fichier existe. at /usr/lib/perl5/vendor_perl/5.8.7/Mail/SpamAssassin.pm line 1467 Nov 29 22:09:38 rousalka spamd[2382]: config: cannot write to /home/nim/.spamassassin/user_prefs: Permission non accord?e Nov 29 22:09:38 rousalka spamd[2382]: spamd: failed to create readable default_prefs: /home/nim/.spamassassin/user_prefs Nov 29 22:09:38 rousalka spamd[2382]: mkdir /home/nim: Le fichier existe. at /usr/lib/perl5/vendor_perl/5.8.7/Mail/SpamAssassin.pm line 1467 Nov 29 22:09:38 rousalka spamd[2382]: spamd: checking message <1133298570.3426.4.camel at rousalka.dyndns.org> for nim:500 Nov 29 22:09:38 rousalka spamd[2382]: internal error Nov 29 22:09:38 rousalka spamd[2382]: pyzor: check failed: internal error Nov 29 22:09:38 rousalka spamd[2382]: mkdir /home/nim: Le fichier existe. at /usr/lib/perl5/vendor_perl/5.8.7/Mail/SpamAssassin.pm line 1467 Nov 29 22:09:38 rousalka spamd[2382]: locker: safe_lock: cannot create tmp lockfile /home/nim/.spamassassin/auto-whitelist.lock.rousalka.dyndns.org.2382 for /home/nim/.spamassassin/auto-whitelist.lock: Permission non accord?e Nov 29 22:09:38 rousalka spamd[2382]: auto-whitelist: open of auto-whitelist file failed: locker: safe_lock: cannot create tmp lockfile /home/nim/.spamassassin/auto-whitelist.lock.rousalka.dyndns.org.2382 for /home/nim/.spamassassin/auto-whitelist.lock: Permission non accord?e Nov 29 22:09:38 rousalka spamd[2382]: Can't call method "finish" on an undefined value at /usr/lib/perl5/vendor_perl/5.8.7/Mail/SpamAssassin/Plugin/AWL.pm line 397. Nov 29 22:09:38 rousalka spamd[2382]: bayes: locker: safe_lock: cannot create tmp lockfile /home/nim/.spamassassin/bayes.lock.rousalka.dyndns.org.2382 for /home/nim/.spamassassin/bayes.lock: Permission non accord?e allow system_chkpwd_t devpts_t:chr_file { read write }; (this one is pam-related - may be serious) allow updfstab_t tmpfs_t:dir getattr; (fstab-sync is blocked) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From pax at guardiandigital.com Tue Nov 29 22:11:26 2005 From: pax at guardiandigital.com (Pax Dickinson) Date: Tue, 29 Nov 2005 17:11:26 -0500 Subject: Hacks from Pax - SELinux Articles In-Reply-To: References: Message-ID: <438CD20E.5000303@guardiandigital.com> Justin, Thanks, I'm glad you enjoyed the articles. The fourth and last in the series was posted today: http://www.linuxsecurity.com/content/view/120837/49/ Pax Justin Conover wrote: > I was reading through these and thought I would pass them on, pretty > good read(s). > > 1.) http://www.linuxsecurity.com/content/view/120567/49/ > > 2.) http://www.linuxsecurity.com/content/view/120622/49/ > > 3.) http://www.linuxsecurity.com/content/view/120700/49/ From kwade at redhat.com Tue Nov 29 22:21:06 2005 From: kwade at redhat.com (Karsten Wade) Date: Tue, 29 Nov 2005 14:21:06 -0800 Subject: help with the SELinux FAQ Message-ID: <1133302866.19569.38.camel@erato.phig.org> If you would like to help write or update the Fedora SELinux FAQ[1], please follow up to this thread on fedora-docs-list at redhat.com (reply-to set). I've been unable to maintain the FAQ in a proper state for a while now, and we need the content to be significantly updated for FC5. Changes made now can be included in the FC5 testing process. To fill this role, you need to know what is going on in the Fedora SELinux project. We can take care of the rest with you, from access to the content and tools to make the changes. Thanks - Karsten, lazy FAQ maintainer [1] http://fedora.redhat.com/docs/selinux-faq/ -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Content Services Fedora Documentation Project http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwalsh at redhat.com Tue Nov 29 23:49:44 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 29 Nov 2005 18:49:44 -0500 Subject: selinux and udev ? In-Reply-To: <1133299132.3426.10.camel@rousalka.dyndns.org> References: <4c4ba1530511290820m748d86f4ibb08e6528154f6ce@mail.gmail.com> <1133282893.26593.137.camel@moss-spartans.epoch.ncsc.mil> <1133286973.17843.7.camel@rousalka.dyndns.org> <1133288610.26593.169.camel@moss-spartans.epoch.ncsc.mil> <1133289576.3475.6.camel@rousalka.dyndns.org> <438CB3A5.8000403@redhat.com> <1133299132.3426.10.camel@rousalka.dyndns.org> Message-ID: <438CE918.6060409@redhat.com> Nicolas Mailhot wrote: > Le mardi 29 novembre 2005 ? 15:01 -0500, Daniel J Walsh a ?crit : > >> Nicolas Mailhot wrote: >> > > >>> The udev denial seems fixed with selinux-policy-targeted-2.0.6-1. So >>> things get (slowly) fixed. But most issues are still there : >>> >>> audit2allow < /var/log/audit/audit.log >>> You should do audit2allow -l < /var/log/audit/audit.log To only get the messages of what AVC messages you got after the last reload. >>> allow dovecot_auth_t var_lib_t:dir search; >>> allow system_chkpwd_t devpts_t:chr_file { read write }; >>> allow procmail_t spamd_port_t:tcp_socket name_connect; >>> allow updfstab_t tmpfs_t:dir getattr; >>> allow dovecot_auth_t etc_runtime_t:file read; >>> allow spamd_t port_t:udp_socket name_bind; >>> (this bit is the spamassassin resolver issue Steven Stern just reported >>> for FC4. It was briefly fixed in Rawhide, then regressed to broken stage >>> with the 2.x policy change) >>> >>> (generated on a clean fully relabeled system after 3 min of activity) >>> >>> That's almost the same list I had with selinux-policy-targeted-2.0.0 >>> > > >> selinux-policy-2.0.6-2 should fix most of those. >> > > This one is much better, right. I had to work a little harder to fill my > AVC quota. Now I only get : > > # audit2allow < /var/log/audit/audit.log | sort > allow dovecot_auth_t var_auth_t:dir write; > (on-the-fly pam_abl database creation failure, strangely works fine from > ssh) > > allow saslauthd_t self:capability setuid; > (should saslauthd be allowed setuid ?) > > allow saslauthd_t var_auth_t:dir search; > (more pam_abl stuff) > > allow spamd_t port_t:udp_socket name_bind; > > Probably related to one of those : > > Nov 29 22:08:11 rousalka spamd[2382]: Error creating a DNS resolver > socket: Permission non accord?e > at /usr/lib/perl5/vendor_perl/5.8.7/Mail/SpamAssassin/DnsResolver.pm > line 202, line 120. > Nov 29 22:08:11 rousalka spamd[2382]: spamd: Error creating a DNS > resolver socket: Permission non accord?e > at /usr/lib/perl5/vendor_perl/5.8.7/Mail/SpamAssassin/DnsResolver.pm > line 202, line 120. > > > Nov 29 22:09:38 rousalka spamd[2382]: spamd: connection from > localhost.localdomain [127.0.0.1] at port 50657 > Nov 29 22:09:38 rousalka spamd[2382]: spamd: setuid to nim succeeded > Nov 29 22:09:38 rousalka spamd[2382]: spamd: creating > default_prefs: /home/nim/.spamassassin/user_prefs > Nov 29 22:09:38 rousalka spamd[2382]: mkdir /home/nim: Le fichier > existe. at /usr/lib/perl5/vendor_perl/5.8.7/Mail/SpamAssassin.pm line > 1467 > Nov 29 22:09:38 rousalka spamd[2382]: config: cannot write > to /home/nim/.spamassassin/user_prefs: Permission non accord?e > Nov 29 22:09:38 rousalka spamd[2382]: spamd: failed to create readable > default_prefs: /home/nim/.spamassassin/user_prefs > Nov 29 22:09:38 rousalka spamd[2382]: mkdir /home/nim: Le fichier > existe. at /usr/lib/perl5/vendor_perl/5.8.7/Mail/SpamAssassin.pm line > 1467 > Nov 29 22:09:38 rousalka spamd[2382]: spamd: checking message > <1133298570.3426.4.camel at rousalka.dyndns.org> for nim:500 > Nov 29 22:09:38 rousalka spamd[2382]: internal error > Nov 29 22:09:38 rousalka spamd[2382]: pyzor: check failed: internal > error > Nov 29 22:09:38 rousalka spamd[2382]: mkdir /home/nim: Le fichier > existe. at /usr/lib/perl5/vendor_perl/5.8.7/Mail/SpamAssassin.pm line > 1467 > Nov 29 22:09:38 rousalka spamd[2382]: locker: safe_lock: cannot create > tmp > lockfile /home/nim/.spamassassin/auto-whitelist.lock.rousalka.dyndns.org.2382 for /home/nim/.spamassassin/auto-whitelist.lock: Permission non accord?e > Nov 29 22:09:38 rousalka spamd[2382]: auto-whitelist: open of > auto-whitelist file failed: locker: safe_lock: cannot create tmp > lockfile /home/nim/.spamassassin/auto-whitelist.lock.rousalka.dyndns.org.2382 for /home/nim/.spamassassin/auto-whitelist.lock: Permission non accord?e > Nov 29 22:09:38 rousalka spamd[2382]: Can't call method "finish" on an > undefined value > at /usr/lib/perl5/vendor_perl/5.8.7/Mail/SpamAssassin/Plugin/AWL.pm line > 397. > Nov 29 22:09:38 rousalka spamd[2382]: bayes: locker: safe_lock: cannot > create tmp > lockfile /home/nim/.spamassassin/bayes.lock.rousalka.dyndns.org.2382 > for /home/nim/.spamassassin/bayes.lock: Permission non accord?e > > allow system_chkpwd_t devpts_t:chr_file { read write }; > (this one is pam-related - may be serious) > > allow updfstab_t tmpfs_t:dir getattr; > (fstab-sync is blocked) > > Regards, > > Please attach the audit.log -- From linux_4ever at yahoo.com Wed Nov 30 13:38:52 2005 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 30 Nov 2005 05:38:52 -0800 (PST) Subject: selinux and udev ? In-Reply-To: <438CE918.6060409@redhat.com> Message-ID: <20051130133852.45877.qmail@web51503.mail.yahoo.com> >You should do > >audit2allow -l < /var/log/audit/audit.log I would like to take this opportunity to point out that you should not be using the audit logs directly. ausearch is the correct way to access the logs. I would recommend: ausearch -m avc,selinux_err | audit2allow -l There's 3 reasons for this. 1) There may be more than 1 log file that needs to be examined. ausearch automatically looks at all of them. You can restrict its search by using the -ts & -te parameters. 2) Sometimes file names or sockets get encoded and cannot be read without ausearch's interpretation...and 3) we may be changing to binary log format at some point during fc5/6 time frame. -Steve __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From sds at tycho.nsa.gov Wed Nov 30 15:08:39 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 30 Nov 2005 10:08:39 -0500 Subject: selinux and udev ? In-Reply-To: <20051130133852.45877.qmail@web51503.mail.yahoo.com> References: <20051130133852.45877.qmail@web51503.mail.yahoo.com> Message-ID: <1133363319.26593.312.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-11-30 at 05:38 -0800, Steve G wrote: > >You should do > > > >audit2allow -l < /var/log/audit/audit.log > > I would like to take this opportunity to point out that you should not be using > the audit logs directly. ausearch is the correct way to access the logs. I would > recommend: > > ausearch -m avc,selinux_err | audit2allow -l > > There's 3 reasons for this. 1) There may be more than 1 log file that needs to be > examined. ausearch automatically looks at all of them. You can restrict its > search by using the -ts & -te parameters. 2) Sometimes file names or sockets get > encoded and cannot be read without ausearch's interpretation...and 3) we may be > changing to binary log format at some point during fc5/6 time frame. Hmm...this should likely get reflected in the audit2allow man page... -- Stephen Smalley National Security Agency From Valdis.Kletnieks at vt.edu Wed Nov 30 19:09:16 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 30 Nov 2005 14:09:16 -0500 Subject: 'install' command goes "oink!" after recent updates. Message-ID: <200511301909.jAUJ9Gh6022351@turing-police.cc.vt.edu> coreutils-5.93-4 libsepol-1.9.41-1 libsemanage-1.3.59-1 libsetrans-0.1.8-1 Not sure if this is a coreutils bug or an selinux bug. Recently, I noticed that a 'make install' that called /usr/bin/install ran *very* slowly: % time cp hello.c /tmp/hello.c real 0m0.040s user 0m0.008s sys 0m0.016s % time /usr/bin/install -c -m 644 hello.c /tmp/hello.c real 0m4.641s user 0m1.608s sys 0m0.388s Literally 100 times slower. Gaak. A bit of playing with strace showed why: strace install -c -m 644 hello.c /tmp/hello.c 7,745 system calls. Of those, only 297 were *not* part of the 1,862 times that 'install' did an open/write/read/close of /selinux/context - once for every single file context type it found, whether or not it had anything to do with the file that was actually being installed. This is a show-stopper guys - when something like this bloats a 'make install' from something that takes 2 minute into something that you don't bother checking until you get back from lunch, it *will* add dramatically to the "security takes waaaay too much resources" bandwagon. Almost-full strace follows. execve("/usr/bin/install", ["install", "-c", "-m", "644", "hello.c", "/tmp/hello.c"], [/* 56 vars */]) = 0 brk(0) = 0x805a000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f16000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=72776, ...}) = 0 mmap2(NULL, 72776, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f04000 close(3) = 0 open("/usr/lib/libacl.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\23"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=24996, ...}) = 0 mmap2(NULL, 27832, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7efd000 mmap2(0xb7f03000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5) = 0xb7f03000 close(3) = 0 open("/lib/libselinux.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`2\0\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=83848, ...}) = 0 mmap2(NULL, 85008, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7ee8000 mmap2(0xb7efc000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14) = 0xb7efc000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0ZW\1\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1460028, ...}) = 0 mmap2(NULL, 1227740, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7dbc000 mmap2(0xb7ee2000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x125) = 0xb7ee2000 mmap2(0xb7ee6000, 7132, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7ee6000 close(3) = 0 open("/usr/lib/libattr.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\v\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=32990, ...}) = 0 mmap2(NULL, 15376, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7db8000 mmap2(0xb7dbb000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2) = 0xb7dbb000 close(3) = 0 open("/lib/libdl.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\f\0\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=13892, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7db7000 mmap2(NULL, 12408, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7db3000 mmap2(0xb7db5000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb7db5000 close(3) = 0 open("/lib/libsepol.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200#\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=204168, ...}) = 0 mmap2(NULL, 249380, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7d76000 mmap2(0xb7da8000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x31) = 0xb7da8000 mmap2(0xb7da9000, 40484, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7da9000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7d75000 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7d756b0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 mprotect(0xb7db5000, 4096, PROT_READ) = 0 mprotect(0xb7ee2000, 8192, PROT_READ) = 0 mprotect(0xb7f30000, 4096, PROT_READ) = 0 munmap(0xb7f04000, 72776) = 0 access("/etc/selinux/", F_OK) = 0 brk(0) = 0x805a000 brk(0x807b000) = 0x807b000 open("/etc/selinux/config", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=71, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f15000 read(3, "# Stray comment\nSELINUX=permissi"..., 4096) = 71 read(3, "", 4096) = 0 close(3) = 0 munmap(0xb7f15000, 4096) = 0 open("/proc/mounts", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f15000 read(3, "rootfs / rootfs rw 0 0\n/dev/root"..., 1024) = 1024 close(3) = 0 munmap(0xb7f15000, 4096) = 0 open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=72776, ...}) = 0 mmap2(NULL, 72776, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f04000 close(3) = 0 open("/lib/libsetrans.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\n\0\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=6804, ...}) = 0 mmap2(NULL, 9680, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7d72000 mmap2(0xb7d74000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb7d74000 close(3) = 0 munmap(0xb7f04000, 72776) = 0 open("/selinux/mls", O_RDONLY|O_LARGEFILE) = 3 read(3, "1", 19) = 1 close(3) = 0 open("/etc/selinux/strict/setrans.conf", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=594, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f15000 read(3, "#\n# Multi-Category Security tran"..., 4096) = 594 read(3, "", 4096) = 0 close(3) = 0 munmap(0xb7f15000, 4096) = 0 open("/proc/filesystems", O_RDONLY|O_LARGEFILE) = 3 read(3, "nodev\tsysfs\nnodev\trootfs\nnodev\tb"..., 4095) = 305 open("/proc/self/attr/current", O_RDONLY|O_LARGEFILE) = 4 read(4, "valdis:staff_r:staff_t:s0-s0:c0."..., 4095) = 37 close(4) = 0 close(3) = 0 open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=54054656, ...}) = 0 mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7b72000 mmap2(NULL, 204800, PROT_READ, MAP_PRIVATE, 3, 0x121f) = 0xb7b40000 mmap2(NULL, 4096, PROT_READ, MAP_PRIVATE, 3, 0x2b89) = 0xb7b3f000 close(3) = 0 geteuid32() = 967 umask(0) = 022 stat64("/tmp/hello.c", {st_mode=S_IFREG|0644, st_size=35, ...}) = 0 stat64("hello.c", {st_mode=S_IFREG|0664, st_size=35, ...}) = 0 stat64("/tmp/hello.c", {st_mode=S_IFREG|0644, st_size=35, ...}) = 0 unlink("/tmp/hello.c") = 0 open("hello.c", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0664, st_size=35, ...}) = 0 open("/tmp/hello.c", O_WRONLY|O_CREAT|O_LARGEFILE, 0100664) = 4 fstat64(4, {st_mode=S_IFREG|0664, st_size=0, ...}) = 0 fstat64(3, {st_mode=S_IFREG|0664, st_size=35, ...}) = 0 read(3, "main() {printf(\"Hello world!\\n\")"..., 4096) = 35 write(4, "main() {printf(\"Hello world!\\n\")"..., 35) = 35 read(3, "", 4096) = 0 close(4) = 0 close(3) = 0 setxattr("/tmp/hello.c", "system.posix_acl_access", "\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x04\x00\x00\x00\xff\xff\xff\xff \x00\x00\x00\xff\xff\xff\xff", 28, 0) = -1 EOPNOTSUPP (Operation not supported) chmod("/tmp/hello.c", 0600) = 0 chown32("/tmp/hello.c", -1, -1) = 0 chmod("/tmp/hello.c", 0644) = 0 lstat64("/tmp/hello.c", {st_mode=S_IFREG|0644, st_size=35, ...}) = 0 open("/selinux/mls", O_RDONLY|O_LARGEFILE) = 3 read(3, "1", 19) = 1 close(3) = 0 open("/etc/selinux/strict/contexts/files/file_contexts", O_RDONLY|O_LARGEFILE) = 3 open("/etc/selinux/strict/contexts/files/file_contexts.homedirs", O_RDONLY|O_LARGEFILE) = 4 open("/etc/selinux/strict/contexts/files/file_contexts.local", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) fstat64(3, {st_mode=S_IFREG|0644, st_size=114044, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7b3e000 read(3, "# Distro-specific customizations"..., 4096) = 4096 read(3, "b[^/]*\\.so(\\.[^/]*)* --\tsystem_u"..., 4096) = 4096 read(3, "ovable device...\n/dev/pd[a-d][^/"..., 4096) = 4096 read(3, "r:bin_t:s0\n/opt(/.*)?/sbin(/.*)?"..., 4096) = 4096 read(3, "*)?\tsystem_u:object_r:man_t:s0\n/"..., 4096) = 4096 read(3, "/usr/sbin/accton\t--\tsystem_u:obj"..., 4096) = 4096 read(3, "-\tsystem_u:object_r:amanda_user_"..., 4096) = 4096 read(3, "\n/var/run/\\.?acpid\\.socket\t-s\tsy"..., 4096) = 4096 read(3, "ject_r:comsat_exec_t:s0\n# consol"..., 4096) = 4096 read(3, "r:bin_t:s0\n/usr/lib(64)?/cups/cg"..., 4096) = 4096 read(3, "larm-notify.*\t--\tsystem_u:object"..., 4096) = 4096 read(3, "object_r:xferlog_t:s0\n/var/log/x"..., 4096) = 4096 read(3, "usr/lib/gnupg/.*\t--\tsystem_u:obj"..., 4096) = 4096 read(3, "_t:s0\n/etc/init\\.d/.*\t\t--\tsystem"..., 4096) = 4096 read(3, "tem_u:object_r:innd_exec_t:s0\n# "..., 4096) = 4096 read(3, "--\tsystem_u:object_r:load_policy"..., 4096) = 4096 read(3, "ct_r:lvm_exec_t:s0\n/sbin/vgscan\t"..., 4096) = 4096 read(3, "luggerrc system_u:object_r:mozil"..., 4096) = 4096 read(3, "\t\tsystem_u:object_r:ntpd_log_t:s"..., 4096) = 4096 read(3, "\n/usr/sbin/postqueue\t--\tsystem_u"..., 4096) = 4096 read(3, "voxy(/.*)?\t\tsystem_u:object_r:pr"..., 4096) = 4096 read(3, "_u:object_r:samba_log_t:s0\n/var/"..., 4096) = 4096 read(3, "var_run_t:s0\n/var/run/snmpd\t\t-d\t"..., 4096) = 4096 read(3, "ct_r:traceroute_exec_t:s0\n/usr/b"..., 4096) = 4096 read(3, ":s0\n#/usr/local/vmware/[^/]*/.*\\"..., 4096) = 4096 read(3, "on\n/usr/sbin/zebra\t\t--\tsystem_u:"..., 4096) = 4096 read(3, "tem_u:object_r:bin_t:s0\n/emul/ia"..., 4096) = 4096 read(3, "r:texrel_shlib_t:s0\n/usr/lib/lad"..., 4096) = 3452 read(3, "", 4096) = 0 fstat64(4, {st_mode=S_IFREG|0644, st_size=9381, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7b3d000 read(4, "\n#\n#\n# User-specific file contex"..., 4096) = 4096 read(4, "onts.cache-.*\t--\troot:object_r:s"..., 4096) = 4096 read(4, "me_t:s0\n/home/valdis/\\.screenrc\t"..., 4096) = 1189 read(4, "", 4096) = 0 _llseek(3, 0, [0], SEEK_SET) = 0 _llseek(4, 0, [0], SEEK_SET) = 0 read(3, "# Distro-specific customizations"..., 4096) = 4096 open("/selinux/context", O_RDWR|O_LARGEFILE) = 5 write(5, "system_u:object_r:default_t:s0\0", 31) = 31 read(5, "system_u:object_r:default_t:s0\0", 4095) = 31 close(5) = 0 open("/selinux/context", O_RDWR|O_LARGEFILE) = 5 write(5, "system_u:object_r:root_t:s0\0", 28) = 28 read(5, "system_u:object_r:root_t:s0\0", 4095) = 28 close(5) = 0 (1,858 iterations of open/write/read/close deleted) open("/selinux/context", O_RDWR|O_LARGEFILE) = 5 write(5, "valdis:object_r:staff_orbit_tmp_"..., 37) = 37 read(5, "valdis:object_r:staff_orbit_tmp_"..., 4095) = 37 close(5) = 0 open("/selinux/context", O_RDWR|O_LARGEFILE) = 5 write(5, "valdis:object_r:staff_orbit_tmp_"..., 37) = 37 read(5, "valdis:object_r:staff_orbit_tmp_"..., 4095) = 37 close(5) = 0 close(3) = 0 munmap(0xb7b3e000, 4096) = 0 close(4) = 0 munmap(0xb7b3d000, 4096) = 0 brk(0x863e000) = 0x863e000 close(1) = 0 munmap(0xb7d72000, 9680) = 0 exit_group(0) = ? Process 17917 detached -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From dwalsh at redhat.com Wed Nov 30 19:24:20 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 30 Nov 2005 14:24:20 -0500 Subject: 'install' command goes "oink!" after recent updates. In-Reply-To: <200511301909.jAUJ9Gh6022351@turing-police.cc.vt.edu> References: <200511301909.jAUJ9Gh6022351@turing-police.cc.vt.edu> Message-ID: <438DFC64.2090905@redhat.com> Valdis.Kletnieks at vt.edu wrote: > coreutils-5.93-4 > libsepol-1.9.41-1 > libsemanage-1.3.59-1 > libsetrans-0.1.8-1 > > Not sure if this is a coreutils bug or an selinux bug. Recently, I noticed > that a 'make install' that called /usr/bin/install ran *very* slowly: > > % time cp hello.c /tmp/hello.c > real 0m0.040s > user 0m0.008s > sys 0m0.016s > % time /usr/bin/install -c -m 644 hello.c /tmp/hello.c > real 0m4.641s > user 0m1.608s > sys 0m0.388s > > Literally 100 times slower. Gaak. > > A bit of playing with strace showed why: > > strace install -c -m 644 hello.c /tmp/hello.c > > 7,745 system calls. Of those, only 297 were *not* part of the 1,862 times > that 'install' did an open/write/read/close of /selinux/context - once for every > single file context type it found, whether or not it had anything to do with > the file that was actually being installed. > > This is a show-stopper guys - when something like this bloats a 'make install' > from something that takes 2 minute into something that you don't bother checking > until you get back from lunch, it *will* add dramatically to the "security takes > waaaay too much resources" bandwagon. > > Almost-full strace follows. > > execve("/usr/bin/install", ["install", "-c", "-m", "644", "hello.c", "/tmp/hello.c"], [/* 56 vars */]) = 0 > brk(0) = 0x805a000 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f16000 > access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) > open("/etc/ld.so.cache", O_RDONLY) = 3 > fstat64(3, {st_mode=S_IFREG|0644, st_size=72776, ...}) = 0 > mmap2(NULL, 72776, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f04000 > close(3) = 0 > open("/usr/lib/libacl.so.1", O_RDONLY) = 3 > read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\23"..., 512) = 512 > fstat64(3, {st_mode=S_IFREG|0755, st_size=24996, ...}) = 0 > mmap2(NULL, 27832, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7efd000 > mmap2(0xb7f03000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5) = 0xb7f03000 > close(3) = 0 > open("/lib/libselinux.so.1", O_RDONLY) = 3 > read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`2\0\000"..., 512) = 512 > fstat64(3, {st_mode=S_IFREG|0755, st_size=83848, ...}) = 0 > mmap2(NULL, 85008, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7ee8000 > mmap2(0xb7efc000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14) = 0xb7efc000 > close(3) = 0 > open("/lib/libc.so.6", O_RDONLY) = 3 > read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0ZW\1\000"..., 512) = 512 > fstat64(3, {st_mode=S_IFREG|0755, st_size=1460028, ...}) = 0 > mmap2(NULL, 1227740, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7dbc000 > mmap2(0xb7ee2000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x125) = 0xb7ee2000 > mmap2(0xb7ee6000, 7132, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7ee6000 > close(3) = 0 > open("/usr/lib/libattr.so.1", O_RDONLY) = 3 > read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\v\0"..., 512) = 512 > fstat64(3, {st_mode=S_IFREG|0755, st_size=32990, ...}) = 0 > mmap2(NULL, 15376, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7db8000 > mmap2(0xb7dbb000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2) = 0xb7dbb000 > close(3) = 0 > open("/lib/libdl.so.2", O_RDONLY) = 3 > read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\f\0\000"..., 512) = 512 > fstat64(3, {st_mode=S_IFREG|0755, st_size=13892, ...}) = 0 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7db7000 > mmap2(NULL, 12408, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7db3000 > mmap2(0xb7db5000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb7db5000 > close(3) = 0 > open("/lib/libsepol.so.1", O_RDONLY) = 3 > read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200#\0"..., 512) = 512 > fstat64(3, {st_mode=S_IFREG|0755, st_size=204168, ...}) = 0 > mmap2(NULL, 249380, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7d76000 > mmap2(0xb7da8000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x31) = 0xb7da8000 > mmap2(0xb7da9000, 40484, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7da9000 > close(3) = 0 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7d75000 > set_thread_area({entry_number:-1 -> 6, base_addr:0xb7d756b0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 > mprotect(0xb7db5000, 4096, PROT_READ) = 0 > mprotect(0xb7ee2000, 8192, PROT_READ) = 0 > mprotect(0xb7f30000, 4096, PROT_READ) = 0 > munmap(0xb7f04000, 72776) = 0 > access("/etc/selinux/", F_OK) = 0 > brk(0) = 0x805a000 > brk(0x807b000) = 0x807b000 > open("/etc/selinux/config", O_RDONLY|O_LARGEFILE) = 3 > fstat64(3, {st_mode=S_IFREG|0644, st_size=71, ...}) = 0 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f15000 > read(3, "# Stray comment\nSELINUX=permissi"..., 4096) = 71 > read(3, "", 4096) = 0 > close(3) = 0 > munmap(0xb7f15000, 4096) = 0 > open("/proc/mounts", O_RDONLY|O_LARGEFILE) = 3 > fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f15000 > read(3, "rootfs / rootfs rw 0 0\n/dev/root"..., 1024) = 1024 > close(3) = 0 > munmap(0xb7f15000, 4096) = 0 > open("/etc/ld.so.cache", O_RDONLY) = 3 > fstat64(3, {st_mode=S_IFREG|0644, st_size=72776, ...}) = 0 > mmap2(NULL, 72776, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f04000 > close(3) = 0 > open("/lib/libsetrans.so.0", O_RDONLY) = 3 > read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\n\0\000"..., 512) = 512 > fstat64(3, {st_mode=S_IFREG|0755, st_size=6804, ...}) = 0 > mmap2(NULL, 9680, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7d72000 > mmap2(0xb7d74000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb7d74000 > close(3) = 0 > munmap(0xb7f04000, 72776) = 0 > open("/selinux/mls", O_RDONLY|O_LARGEFILE) = 3 > read(3, "1", 19) = 1 > close(3) = 0 > open("/etc/selinux/strict/setrans.conf", O_RDONLY|O_LARGEFILE) = 3 > fstat64(3, {st_mode=S_IFREG|0644, st_size=594, ...}) = 0 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f15000 > read(3, "#\n# Multi-Category Security tran"..., 4096) = 594 > read(3, "", 4096) = 0 > close(3) = 0 > munmap(0xb7f15000, 4096) = 0 > open("/proc/filesystems", O_RDONLY|O_LARGEFILE) = 3 > read(3, "nodev\tsysfs\nnodev\trootfs\nnodev\tb"..., 4095) = 305 > open("/proc/self/attr/current", O_RDONLY|O_LARGEFILE) = 4 > read(4, "valdis:staff_r:staff_t:s0-s0:c0."..., 4095) = 37 > close(4) = 0 > close(3) = 0 > open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3 > fstat64(3, {st_mode=S_IFREG|0644, st_size=54054656, ...}) = 0 > mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7b72000 > mmap2(NULL, 204800, PROT_READ, MAP_PRIVATE, 3, 0x121f) = 0xb7b40000 > mmap2(NULL, 4096, PROT_READ, MAP_PRIVATE, 3, 0x2b89) = 0xb7b3f000 > close(3) = 0 > geteuid32() = 967 > umask(0) = 022 > stat64("/tmp/hello.c", {st_mode=S_IFREG|0644, st_size=35, ...}) = 0 > stat64("hello.c", {st_mode=S_IFREG|0664, st_size=35, ...}) = 0 > stat64("/tmp/hello.c", {st_mode=S_IFREG|0644, st_size=35, ...}) = 0 > unlink("/tmp/hello.c") = 0 > open("hello.c", O_RDONLY|O_LARGEFILE) = 3 > fstat64(3, {st_mode=S_IFREG|0664, st_size=35, ...}) = 0 > open("/tmp/hello.c", O_WRONLY|O_CREAT|O_LARGEFILE, 0100664) = 4 > fstat64(4, {st_mode=S_IFREG|0664, st_size=0, ...}) = 0 > fstat64(3, {st_mode=S_IFREG|0664, st_size=35, ...}) = 0 > read(3, "main() {printf(\"Hello world!\\n\")"..., 4096) = 35 > write(4, "main() {printf(\"Hello world!\\n\")"..., 35) = 35 > read(3, "", 4096) = 0 > close(4) = 0 > close(3) = 0 > setxattr("/tmp/hello.c", "system.posix_acl_access", "\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x04\x00\x00\x00\xff\xff\xff\xff \x00\x00\x00\xff\xff\xff\xff", 28, 0) = -1 EOPNOTSUPP (Operation not supported) > chmod("/tmp/hello.c", 0600) = 0 > chown32("/tmp/hello.c", -1, -1) = 0 > chmod("/tmp/hello.c", 0644) = 0 > lstat64("/tmp/hello.c", {st_mode=S_IFREG|0644, st_size=35, ...}) = 0 > open("/selinux/mls", O_RDONLY|O_LARGEFILE) = 3 > read(3, "1", 19) = 1 > close(3) = 0 > open("/etc/selinux/strict/contexts/files/file_contexts", O_RDONLY|O_LARGEFILE) = 3 > open("/etc/selinux/strict/contexts/files/file_contexts.homedirs", O_RDONLY|O_LARGEFILE) = 4 > open("/etc/selinux/strict/contexts/files/file_contexts.local", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) > fstat64(3, {st_mode=S_IFREG|0644, st_size=114044, ...}) = 0 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7b3e000 > read(3, "# Distro-specific customizations"..., 4096) = 4096 > read(3, "b[^/]*\\.so(\\.[^/]*)* --\tsystem_u"..., 4096) = 4096 > read(3, "ovable device...\n/dev/pd[a-d][^/"..., 4096) = 4096 > read(3, "r:bin_t:s0\n/opt(/.*)?/sbin(/.*)?"..., 4096) = 4096 > read(3, "*)?\tsystem_u:object_r:man_t:s0\n/"..., 4096) = 4096 > read(3, "/usr/sbin/accton\t--\tsystem_u:obj"..., 4096) = 4096 > read(3, "-\tsystem_u:object_r:amanda_user_"..., 4096) = 4096 > read(3, "\n/var/run/\\.?acpid\\.socket\t-s\tsy"..., 4096) = 4096 > read(3, "ject_r:comsat_exec_t:s0\n# consol"..., 4096) = 4096 > read(3, "r:bin_t:s0\n/usr/lib(64)?/cups/cg"..., 4096) = 4096 > read(3, "larm-notify.*\t--\tsystem_u:object"..., 4096) = 4096 > read(3, "object_r:xferlog_t:s0\n/var/log/x"..., 4096) = 4096 > read(3, "usr/lib/gnupg/.*\t--\tsystem_u:obj"..., 4096) = 4096 > read(3, "_t:s0\n/etc/init\\.d/.*\t\t--\tsystem"..., 4096) = 4096 > read(3, "tem_u:object_r:innd_exec_t:s0\n# "..., 4096) = 4096 > read(3, "--\tsystem_u:object_r:load_policy"..., 4096) = 4096 > read(3, "ct_r:lvm_exec_t:s0\n/sbin/vgscan\t"..., 4096) = 4096 > read(3, "luggerrc system_u:object_r:mozil"..., 4096) = 4096 > read(3, "\t\tsystem_u:object_r:ntpd_log_t:s"..., 4096) = 4096 > read(3, "\n/usr/sbin/postqueue\t--\tsystem_u"..., 4096) = 4096 > read(3, "voxy(/.*)?\t\tsystem_u:object_r:pr"..., 4096) = 4096 > read(3, "_u:object_r:samba_log_t:s0\n/var/"..., 4096) = 4096 > read(3, "var_run_t:s0\n/var/run/snmpd\t\t-d\t"..., 4096) = 4096 > read(3, "ct_r:traceroute_exec_t:s0\n/usr/b"..., 4096) = 4096 > read(3, ":s0\n#/usr/local/vmware/[^/]*/.*\\"..., 4096) = 4096 > read(3, "on\n/usr/sbin/zebra\t\t--\tsystem_u:"..., 4096) = 4096 > read(3, "tem_u:object_r:bin_t:s0\n/emul/ia"..., 4096) = 4096 > read(3, "r:texrel_shlib_t:s0\n/usr/lib/lad"..., 4096) = 3452 > read(3, "", 4096) = 0 > fstat64(4, {st_mode=S_IFREG|0644, st_size=9381, ...}) = 0 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7b3d000 > read(4, "\n#\n#\n# User-specific file contex"..., 4096) = 4096 > read(4, "onts.cache-.*\t--\troot:object_r:s"..., 4096) = 4096 > read(4, "me_t:s0\n/home/valdis/\\.screenrc\t"..., 4096) = 1189 > read(4, "", 4096) = 0 > _llseek(3, 0, [0], SEEK_SET) = 0 > _llseek(4, 0, [0], SEEK_SET) = 0 > read(3, "# Distro-specific customizations"..., 4096) = 4096 > open("/selinux/context", O_RDWR|O_LARGEFILE) = 5 > write(5, "system_u:object_r:default_t:s0\0", 31) = 31 > read(5, "system_u:object_r:default_t:s0\0", 4095) = 31 > close(5) = 0 > open("/selinux/context", O_RDWR|O_LARGEFILE) = 5 > write(5, "system_u:object_r:root_t:s0\0", 28) = 28 > read(5, "system_u:object_r:root_t:s0\0", 4095) = 28 > close(5) = 0 > > (1,858 iterations of open/write/read/close deleted) > > open("/selinux/context", O_RDWR|O_LARGEFILE) = 5 > write(5, "valdis:object_r:staff_orbit_tmp_"..., 37) = 37 > read(5, "valdis:object_r:staff_orbit_tmp_"..., 4095) = 37 > close(5) = 0 > open("/selinux/context", O_RDWR|O_LARGEFILE) = 5 > write(5, "valdis:object_r:staff_orbit_tmp_"..., 37) = 37 > read(5, "valdis:object_r:staff_orbit_tmp_"..., 4095) = 37 > close(5) = 0 > close(3) = 0 > munmap(0xb7b3e000, 4096) = 0 > close(4) = 0 > munmap(0xb7b3d000, 4096) = 0 > brk(0x863e000) = 0x863e000 > close(1) = 0 > munmap(0xb7d72000, 9680) = 0 > exit_group(0) = ? > Process 17917 detached > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Sounds like that is probably the udev problem also. -- From sds at tycho.nsa.gov Wed Nov 30 19:52:47 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 30 Nov 2005 14:52:47 -0500 Subject: 'install' command goes "oink!" after recent updates. In-Reply-To: <438DFC64.2090905@redhat.com> References: <200511301909.jAUJ9Gh6022351@turing-police.cc.vt.edu> <438DFC64.2090905@redhat.com> Message-ID: <1133380367.26593.371.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-11-30 at 14:24 -0500, Daniel J Walsh wrote: > Sounds like that is probably the udev problem also. The issue is the complete processing of file_contexts by matchpathcon_init() even when the caller is only going to do a single matchpathcon(). That costs us both in regex compilation time and in context validation/canonicalization time (the only change in the latter is that we now read back the canonical context from the kernel; we were already writing the context to the kernel to validate it). As the original user of matchpathcon was setfiles/restorecon, that was reasonable (we wanted the entire configuration). For udev and install, it isn't. Solution is likely to provide a variant of matchpathcon_init() that allows the caller to specify a prefix, and only process file_contexts entries with that prefix. -- Stephen Smalley National Security Agency From nicolas.mailhot at laposte.net Wed Nov 30 20:12:36 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 30 Nov 2005 21:12:36 +0100 Subject: selinux and udev ? In-Reply-To: <438CE918.6060409@redhat.com> References: <4c4ba1530511290820m748d86f4ibb08e6528154f6ce@mail.gmail.com> <1133282893.26593.137.camel@moss-spartans.epoch.ncsc.mil> <1133286973.17843.7.camel@rousalka.dyndns.org> <1133288610.26593.169.camel@moss-spartans.epoch.ncsc.mil> <1133289576.3475.6.camel@rousalka.dyndns.org> <438CB3A5.8000403@redhat.com> <1133299132.3426.10.camel@rousalka.dyndns.org> <438CE918.6060409@redhat.com> Message-ID: <1133381563.10697.14.camel@rousalka.dyndns.org> Le mardi 29 novembre 2005 ? 18:49 -0500, Daniel J Walsh a ?crit : > Nicolas Mailhot wrote: > > Le mardi 29 novembre 2005 ? 15:01 -0500, Daniel J Walsh a ?crit : > > > >> Nicolas Mailhot wrote: > >> > > > > > >>> The udev denial seems fixed with selinux-policy-targeted-2.0.6-1. So > >>> things get (slowly) fixed. But most issues are still there : > >>> > >>> audit2allow < /var/log/audit/audit.log > >>> > You should do > > audit2allow -l < /var/log/audit/audit.log > > To only get the messages of what AVC messages you got after the last reload. Right now my procedure is : 1. install policy 2. touch ./autorelabel 3. init 6 4. init 1 5. mv /var/log/audit/audit.log somewhere_else 6. init 6 7. do some stuff 8. audit2allow which should be at least as strict of what you propose > Please attach the audit.log https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172496#c23 Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From wswilburn at earthlink.net Sun Nov 20 17:22:45 2005 From: wswilburn at earthlink.net (W. Scott Wilburn) Date: Sun, 20 Nov 2005 17:22:45 -0000 Subject: Spamassasin Problem Message-ID: <20051120155222.GA13990@scooby> Hi, Since upgrading from spamassassin.i386 3.0.4-2.fc4 to spamassassin.i386 3.0.4-1.fc4, I get avc denied messages: Nov 20 04:05:44 scooby kernel: audit(1132484744.807:45387): avc: denied { search } for pid=25548 comm="spamd" name=".spamassassin" dev=md0 ino=2197675 scontext=root:system_r:spamd_t tcontext=user_u:object_r:user_home_t tclass=dir FC4, targeted policy enforcing mode selinux-policy-targeted-sources.noarch 1.27.1-2.11 Since the problem occurred with a spamassassin update, not selinux, I assume something in the behavior of spamassassin has changed. Any help appreciated. Scott Wilburn -- From wswilburn at earthlink.net Tue Nov 29 02:12:10 2005 From: wswilburn at earthlink.net (W. Scott Wilburn) Date: Mon, 28 Nov 2005 19:12:10 -0700 Subject: Spamassasin Problem Message-ID: <20051129021210.GA13567@scooby> Hi, I'm resending this as it seems to have been lost. Scott Wilburn -- -------------- next part -------------- An embedded message was scrubbed... From: "W. Scott Wilburn" Subject: Spamassasin Problem Date: Sun, 20 Nov 2005 08:52:22 -0700 Size: 970 URL: