From bench at silentmedia.com Fri Apr 1 03:06:55 2005 From: bench at silentmedia.com (Ben) Date: Thu, 31 Mar 2005 19:06:55 -0800 Subject: CGI permissions for targeted policy Message-ID: <10512119e563d2c084c21048db40d1be@silentmedia.com> I have been having some problems with a CGI program, and audit2allow shows I should add these permissions: allow httpd_sys_script_t devpts_t:chr_file { read write }; allow httpd_sys_script_t httpd_tmp_t:file getattr; allow httpd_sys_script_t httpd_tmp_t:file read; I'm pretty green at SELinux, so I'm not too sure what these allow. I suspect that the last rule lets httpd_sys_script_t programs read files of type httpd_tmp_t, and the second rule lets them stat() those files. What does the first rule mean, exactly? The CGI program I'm trying to run creates a random filename, and I expect this is related to that, but there ends my speculation. From lfarkas at bppiac.hu Fri Apr 1 09:10:00 2005 From: lfarkas at bppiac.hu (Farkas Levente) Date: Fri, 01 Apr 2005 11:10:00 +0200 Subject: nscd with selinux with ssl In-Reply-To: <424C2470.4050506@redhat.com> References: <424C18D2.1080300@bppiac.hu> <424C18B3.3010201@redhat.com> <424C2037.3080006@bppiac.hu> <424C219D.4070206@redhat.com> <424C24D4.9080109@bppiac.hu> <424C2470.4050506@redhat.com> Message-ID: <424D0FE8.1030000@bppiac.hu> Daniel J Walsh wrote: >>>> ---------------------------- >>>> # ls -aZ /etc/ssl/certs/cacert.pem >>>> -rw-r--r-- root root root:object_r:usr_t >>>> /etc/ssl/certs/cacert.pem >>>> ---------------------------- >>>> and in my messages: >>>> ---------------------------- >>>> Mar 31 17:08:23 kek kernel: audit(1112281703.777:0): avc: denied { >>>> read } for pid=14271 exe=/usr/sbin/nscd name=cacert.pem dev=md0 >>>> ino=2291612 scontext=root:system_r:nscd_t >>>> tcontext=root:object_r:usr_t tclass=file >>>> ---------------------------- >>>> that's why i ask for it:-) >>>> yours. >>>> >>> I believe FC3 policy selinux-policy-targeted-1.17.30-2.90, has >>> nscd.te allow to read usr_t >>> >>> Rawhide has added a type of cert_t, so you could execute >>> >>> chcon -t cert_t /etc/ssl/certs/cacert.pem >> >> >> >> the truth is that this is a rhel 4 (but there is not redhat-selinux >> list:-) and afaik on it the latest update is >> selinux-policy-targeted-1.17.30-2.52.1 so i rather wait for a official >> update (from you:-) and not run nscd until this happend... >> thanks anyway. >> > Ok you can get the semi-official one from (It is being tested for U1 now.) > ftp://people.redhat.com/dwalsh/SELinux/RHEL4/{selinux-policy-targeted, > policycoreutils} it's still said there is no type as cert_t and nscd still can't read usr_t:-( -- Levente "Si vis pacem para bellum!" From sds at tycho.nsa.gov Fri Apr 1 13:26:18 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 01 Apr 2005 08:26:18 -0500 Subject: Problems with firmware loader and selinux In-Reply-To: References: Message-ID: <1112361978.14481.21.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-03-31 at 17:39 -0500, Dmitry Torokhov wrote: > I have a FC3 with day-before-yesterday pull from Linus and > selinux-policy-targeted installed from rawhide. Everything seems to be > working fine ecxept for my wireless card (prism54), which can't get > it's firmware loaded. It looks like selinux policy prevents firmware > loader to create "firmware" class device. I get avc denied search > message for process /sbin/ip (which is ifconfig_t) and tcontext is > sysfs_t. It looks like the rights are inherited from "ip" markings > whereas I would say that firmware loader is should operate in > completely different context. Module initialization runs in the context of the process that performs the insertion. There is no other context at that point; if the module creates kernel threads and reparents/daemonize's them, they will pick up the kernel's context for subsequent operations. In the short term (i.e. until FC3 policy gets updated to allow this), you can customize your policy sources, e.g.: yum install selinux-policy-targeted-sources cd /etc/selinux/targeted/src/policy audit2allow -d -l -o domains/misc/local.te make load -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Fri Apr 1 14:14:44 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 01 Apr 2005 09:14:44 -0500 Subject: Problems with firmware loader and selinux In-Reply-To: References: <1112361978.14481.21.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1112364884.14481.54.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-04-01 at 09:11 -0500, Dmitry Torokhov wrote: > So the question is - should there be a way for the kernel to temporary > switch context to "kernel" before executing some operations? I could > hack firmware loader to always start a new thread, but I wonder if we > have more places that need to temporarily override callers context and > therefore more general solution is needed. At present, the security_task_reparent_to_init LSM hook is used (by the kernel reparent_to_init function, which is also called by its daemonize function) to change the security state of the task, including both the SELinux state and the normal uid/capability state. But that assumes a non-reversible transformation, not a temporary change, with a definite break from any original user context. There used to also be a kmod_set_label hook for the kernel module loader, but that was obsoleted by keventd. Whether or not an interface as you describe is needed is unclear; there is no usage case at present, and temporary changes in credentials are often a source of security flaws. -- Stephen Smalley National Security Agency From dmitry.torokhov at gmail.com Fri Apr 1 14:11:19 2005 From: dmitry.torokhov at gmail.com (Dmitry Torokhov) Date: Fri, 1 Apr 2005 09:11:19 -0500 Subject: Problems with firmware loader and selinux In-Reply-To: <1112361978.14481.21.camel@moss-spartans.epoch.ncsc.mil> References: <1112361978.14481.21.camel@moss-spartans.epoch.ncsc.mil> Message-ID: On Apr 1, 2005 8:26 AM, Stephen Smalley wrote: > On Thu, 2005-03-31 at 17:39 -0500, Dmitry Torokhov wrote: > > I have a FC3 with day-before-yesterday pull from Linus and > > selinux-policy-targeted installed from rawhide. Everything seems to be > > working fine ecxept for my wireless card (prism54), which can't get > > it's firmware loaded. It looks like selinux policy prevents firmware > > loader to create "firmware" class device. I get avc denied search > > message for process /sbin/ip (which is ifconfig_t) and tcontext is > > sysfs_t. It looks like the rights are inherited from "ip" markings > > whereas I would say that firmware loader is should operate in > > completely different context. > > Module initialization runs in the context of the process that performs > the insertion. There is no other context at that point; if the module > creates kernel threads and reparents/daemonize's them, they will pick up > the kernel's context for subsequent operations. In the short term (i.e. > until FC3 policy gets updated to allow this), you can customize your > policy sources, e.g.: > yum install selinux-policy-targeted-sources > cd /etc/selinux/targeted/src/policy > audit2allow -d -l -o domains/misc/local.te > > make load Thank you for the pointer. I still have some concerns though - I am not sure that just policy update is enough: In case of prism54 firmware is loaded not at the module initialization time but at open (configure interface) time to, as far as I understand, avoid issues when driver is built in the kernel since userspace (and therefore firmware) might not be uawailable at that time. What I am trying to say is that firmware loader can potentially be invoked as a result of "unpriveleged" access - I do not a really see why /sbin/ip should be given sysfs_t or other rights, the utility itself does not try to access sysfs. We can't even say that kernel accesses sysfs on its behalf since /sbin/ip does not care, firmware loading is kernel private mechanism. So the question is - should there be a way for the kernel to temporary switch context to "kernel" before executing some operations? I could hack firmware loader to always start a new thread, but I wonder if we have more places that need to temporarily override callers context and therefore more general solution is needed. Thank you. -- Dmitry From dmitry.torokhov at gmail.com Fri Apr 1 14:34:09 2005 From: dmitry.torokhov at gmail.com (Dmitry Torokhov) Date: Fri, 1 Apr 2005 09:34:09 -0500 Subject: Problems with firmware loader and selinux In-Reply-To: <1112364884.14481.54.camel@moss-spartans.epoch.ncsc.mil> References: <1112361978.14481.21.camel@moss-spartans.epoch.ncsc.mil> <1112364884.14481.54.camel@moss-spartans.epoch.ncsc.mil> Message-ID: On Apr 1, 2005 9:14 AM, Stephen Smalley wrote: > On Fri, 2005-04-01 at 09:11 -0500, Dmitry Torokhov wrote: > > So the question is - should there be a way for the kernel to temporary > > switch context to "kernel" before executing some operations? I could > > hack firmware loader to always start a new thread, but I wonder if we > > have more places that need to temporarily override callers context and > > therefore more general solution is needed. > ... > > Whether or not an interface as you describe is needed is unclear; there > is no usage case at present, I am confused, I thought I described a scenario why it might be needed. I probably just misunderstand what you mean by "usage case". >and temporary changes in credentials are > often a source of security flaws. Yes, I understand that. I guess adjusting firmware loader to do the job from a separate thread is the easiest way for now... -- Dmitry From dwalsh at redhat.com Fri Apr 1 18:57:20 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 01 Apr 2005 13:57:20 -0500 Subject: CGI permissions for targeted policy In-Reply-To: <10512119e563d2c084c21048db40d1be@silentmedia.com> References: <10512119e563d2c084c21048db40d1be@silentmedia.com> Message-ID: <424D9990.5060303@redhat.com> Ben wrote: > I have been having some problems with a CGI program, and audit2allow > shows I should add these permissions: > > allow httpd_sys_script_t devpts_t:chr_file { read write }; > allow httpd_sys_script_t httpd_tmp_t:file getattr; > allow httpd_sys_script_t httpd_tmp_t:file read; > > I'm pretty green at SELinux, so I'm not too sure what these allow. I > suspect that the last rule lets httpd_sys_script_t programs read files > of type httpd_tmp_t, and the second rule lets them stat() those files. > What does the first rule mean, exactly? The CGI program I'm trying to > run creates a random filename, and I expect this is related to that, > but there ends my speculation. > The first error is the httpd script trying to access a terminal. The other errors are httpd trying to read the tmp file. Is the tmp file created by a builtin function (php)? And the a cgi script runs to read it? Dan > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list -- From dwalsh at redhat.com Fri Apr 1 19:01:30 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 01 Apr 2005 14:01:30 -0500 Subject: nscd with selinux with ssl In-Reply-To: <424D0FE8.1030000@bppiac.hu> References: <424C18D2.1080300@bppiac.hu> <424C18B3.3010201@redhat.com> <424C2037.3080006@bppiac.hu> <424C219D.4070206@redhat.com> <424C24D4.9080109@bppiac.hu> <424C2470.4050506@redhat.com> <424D0FE8.1030000@bppiac.hu> Message-ID: <424D9A8A.2040508@redhat.com> Farkas Levente wrote: > Daniel J Walsh wrote: > >>>>> ---------------------------- >>>>> # ls -aZ /etc/ssl/certs/cacert.pem >>>>> -rw-r--r-- root root root:object_r:usr_t >>>>> /etc/ssl/certs/cacert.pem >>>>> ---------------------------- >>>>> and in my messages: >>>>> ---------------------------- >>>>> Mar 31 17:08:23 kek kernel: audit(1112281703.777:0): avc: denied >>>>> { read } for pid=14271 exe=/usr/sbin/nscd name=cacert.pem dev=md0 >>>>> ino=2291612 scontext=root:system_r:nscd_t >>>>> tcontext=root:object_r:usr_t tclass=file >>>>> ---------------------------- >>>>> that's why i ask for it:-) >>>>> yours. >>>>> >>>> I believe FC3 policy selinux-policy-targeted-1.17.30-2.90, has >>>> nscd.te allow to read usr_t >>>> >>>> Rawhide has added a type of cert_t, so you could execute >>>> >>>> chcon -t cert_t /etc/ssl/certs/cacert.pem >>> >>> >>> >>> >>> the truth is that this is a rhel 4 (but there is not redhat-selinux >>> list:-) and afaik on it the latest update is >>> selinux-policy-targeted-1.17.30-2.52.1 so i rather wait for a >>> official update (from you:-) and not run nscd until this happend... >>> thanks anyway. >>> >> Ok you can get the semi-official one from (It is being tested for U1 >> now.) >> ftp://people.redhat.com/dwalsh/SELinux/RHEL4/{selinux-policy-targeted, >> policycoreutils} > > > it's still said there is no type as cert_t and nscd still can't read > usr_t:-( > Are you sure? I just looked in my version and I have the following rule r_dir_file(nscd_t, usr_t) ftp://people.redhat.com/dwalsh/SELinux/RHEL4/selinux-policy-targeted-1.17.30-2.88.noarch.rpm ftp://people.redhat.com/dwalsh/SELinux/RHEL4/selinux-policy-targeted-sources-1.17.30-2.88.noarch.rpm -- From lfarkas at bppiac.hu Sat Apr 2 20:22:22 2005 From: lfarkas at bppiac.hu (Farkas Levente) Date: Sat, 02 Apr 2005 22:22:22 +0200 Subject: nscd with selinux with ssl In-Reply-To: <424D9A8A.2040508@redhat.com> References: <424C18D2.1080300@bppiac.hu> <424C18B3.3010201@redhat.com> <424C2037.3080006@bppiac.hu> <424C219D.4070206@redhat.com> <424C24D4.9080109@bppiac.hu> <424C2470.4050506@redhat.com> <424D0FE8.1030000@bppiac.hu> <424D9A8A.2040508@redhat.com> Message-ID: <424EFEFE.5050007@bppiac.hu> Daniel J Walsh wrote: > Farkas Levente wrote: > >> Daniel J Walsh wrote: >> >>>>>> ---------------------------- >>>>>> # ls -aZ /etc/ssl/certs/cacert.pem >>>>>> -rw-r--r-- root root root:object_r:usr_t >>>>>> /etc/ssl/certs/cacert.pem >>>>>> ---------------------------- >>>>>> and in my messages: >>>>>> ---------------------------- >>>>>> Mar 31 17:08:23 kek kernel: audit(1112281703.777:0): avc: denied >>>>>> { read } for pid=14271 exe=/usr/sbin/nscd name=cacert.pem dev=md0 >>>>>> ino=2291612 scontext=root:system_r:nscd_t >>>>>> tcontext=root:object_r:usr_t tclass=file >>>>>> ---------------------------- >>>>>> that's why i ask for it:-) >>>>>> yours. >>>>>> >>>>> I believe FC3 policy selinux-policy-targeted-1.17.30-2.90, has >>>>> nscd.te allow to read usr_t >>>>> >>>>> Rawhide has added a type of cert_t, so you could execute >>>>> >>>>> chcon -t cert_t /etc/ssl/certs/cacert.pem >>>> >>>> >>>> >>>> >>>> >>>> the truth is that this is a rhel 4 (but there is not redhat-selinux >>>> list:-) and afaik on it the latest update is >>>> selinux-policy-targeted-1.17.30-2.52.1 so i rather wait for a >>>> official update (from you:-) and not run nscd until this happend... >>>> thanks anyway. >>>> >>> Ok you can get the semi-official one from (It is being tested for U1 >>> now.) >>> ftp://people.redhat.com/dwalsh/SELinux/RHEL4/{selinux-policy-targeted, >>> policycoreutils} >> >> >> >> it's still said there is no type as cert_t and nscd still can't read >> usr_t:-( >> > Are you sure? I just looked in my version and I have the following rule > > r_dir_file(nscd_t, usr_t) > ftp://people.redhat.com/dwalsh/SELinux/RHEL4/selinux-policy-targeted-1.17.30-2.88.noarch.rpm > > ftp://people.redhat.com/dwalsh/SELinux/RHEL4/selinux-policy-targeted-sources-1.17.30-2.88.noarch.rpm ops. sorry, these packages are not signed and therefore yum not install them:-( nscd now can read usr_t, but is seem there is still no cert_t type: chcon -t cert_t /etc/ssl/certs/cacert.pem chcon: failed to change context of /etc/ssl/certs/cacert.pem to root:object_r:cert_t: Invalid argument -- Levente "Si vis pacem para bellum!" From russell at coker.com.au Sun Apr 3 06:00:34 2005 From: russell at coker.com.au (Russell Coker) Date: Sun, 3 Apr 2005 16:00:34 +1000 Subject: dhclient and restorecon Message-ID: <200504031600.35751.russell@coker.com.au> Why do we have restorecon being called from /sbin/dhclient-script? In the latest strict policy in rawhide dhcpc_t is not permitted to execute restorecon and a cursory glance at the targeted policy suggests that it can't execute it there either. dhcpc_t can only create files of types dhcpc_var_run_t, net_conf_t, dhcpc_tmp_t, and dhcpc_state_t. Of those the type net_conf_t is specified by the domain_auto_trans() rule for files created under /etc. I can't work out how dhclient could create a file with the wrong type to the call to restorecon seems redundant. We don't want to use the policy domain_auto_trans(dhcpc_t, restorecon_exec_t, restorecon_t) because restorecon_t is a highly privileged domain that we want to limit access to (every domain that has such a transition should ideally have it's main programs audited). We don't want to use the policy can_exec(dhcpc_t, restorecon_exec_t) as that will require allowing dhcpc_t to read the policy source which may be regarded as secret (and therefore something that we don't want to give to a program that is always running and has network access). I think it would be best if dhclient-script did not call restorecon at all. -- 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 selinux at gmail.com Sun Apr 3 23:47:23 2005 From: selinux at gmail.com (Tom London) Date: Sun, 3 Apr 2005 16:47:23 -0700 Subject: 'cannot relabel' miscue on shutdown .... Message-ID: <4c4ba1530504031647e9e769e@mail.gmail.com> Running targeted/enforcing, latest rawhide. Each time I halt/reboot, I seem to get a message like the following (the 'funny text' varies): Apr 3 11:58:51 localhost su[3659]: Warning! Could not relabel ,\uffff\uff7f\u0661\uffff with user_u:object_r:devpts_t, not relabeling. But the system shuts down (or reboots) normally. Typically, I have an 'su -' window open, and typically I enter 'halt' or 'reboot' there (instead of using the gnome menu 'logout'. The 'funny' name seems troubling. Anything to be concerned about? tom -- Tom London From dwalsh at redhat.com Mon Apr 4 14:55:43 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 04 Apr 2005 10:55:43 -0400 Subject: nscd with selinux with ssl In-Reply-To: <424EFEFE.5050007@bppiac.hu> References: <424C18D2.1080300@bppiac.hu> <424C18B3.3010201@redhat.com> <424C2037.3080006@bppiac.hu> <424C219D.4070206@redhat.com> <424C24D4.9080109@bppiac.hu> <424C2470.4050506@redhat.com> <424D0FE8.1030000@bppiac.hu> <424D9A8A.2040508@redhat.com> <424EFEFE.5050007@bppiac.hu> Message-ID: <4251556F.9060108@redhat.com> Farkas Levente wrote: > Daniel J Walsh wrote: > >> Farkas Levente wrote: >> >>> Daniel J Walsh wrote: >>> >>>>>>> ---------------------------- >>>>>>> # ls -aZ /etc/ssl/certs/cacert.pem >>>>>>> -rw-r--r-- root root root:object_r:usr_t >>>>>>> /etc/ssl/certs/cacert.pem >>>>>>> ---------------------------- >>>>>>> and in my messages: >>>>>>> ---------------------------- >>>>>>> Mar 31 17:08:23 kek kernel: audit(1112281703.777:0): avc: >>>>>>> denied { read } for pid=14271 exe=/usr/sbin/nscd >>>>>>> name=cacert.pem dev=md0 ino=2291612 >>>>>>> scontext=root:system_r:nscd_t tcontext=root:object_r:usr_t >>>>>>> tclass=file >>>>>>> ---------------------------- >>>>>>> that's why i ask for it:-) >>>>>>> yours. >>>>>>> >>>>>> I believe FC3 policy selinux-policy-targeted-1.17.30-2.90, has >>>>>> nscd.te allow to read usr_t >>>>>> >>>>>> Rawhide has added a type of cert_t, so you could execute >>>>>> >>>>>> chcon -t cert_t /etc/ssl/certs/cacert.pem >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> the truth is that this is a rhel 4 (but there is not >>>>> redhat-selinux list:-) and afaik on it the latest update is >>>>> selinux-policy-targeted-1.17.30-2.52.1 so i rather wait for a >>>>> official update (from you:-) and not run nscd until this happend... >>>>> thanks anyway. >>>>> >>>> Ok you can get the semi-official one from (It is being tested for >>>> U1 now.) >>>> ftp://people.redhat.com/dwalsh/SELinux/RHEL4/{selinux-policy-targeted, >>>> policycoreutils} >>> >>> >>> >>> >>> it's still said there is no type as cert_t and nscd still can't read >>> usr_t:-( >>> >> Are you sure? I just looked in my version and I have the following rule >> >> r_dir_file(nscd_t, usr_t) >> ftp://people.redhat.com/dwalsh/SELinux/RHEL4/selinux-policy-targeted-1.17.30-2.88.noarch.rpm >> >> ftp://people.redhat.com/dwalsh/SELinux/RHEL4/selinux-policy-targeted-sources-1.17.30-2.88.noarch.rpm > > > > ops. sorry, these packages are not signed and therefore yum not > install them:-( > nscd now can read usr_t, but is seem there is still no cert_t type: > chcon -t cert_t /etc/ssl/certs/cacert.pem > chcon: failed to change context of /etc/ssl/certs/cacert.pem to > root:object_r:cert_t: Invalid argument > > Yes cert_t is in the rawhide policy not yet in the FC3/RHEL4 policy trees. It might show up in the future. Dan -- From dwalsh at redhat.com Mon Apr 4 14:58:06 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 04 Apr 2005 10:58:06 -0400 Subject: dhclient and restorecon In-Reply-To: <200504031600.35751.russell@coker.com.au> References: <200504031600.35751.russell@coker.com.au> Message-ID: <425155FE.8050103@redhat.com> Russell Coker wrote: >Why do we have restorecon being called from /sbin/dhclient-script? > >In the latest strict policy in rawhide dhcpc_t is not permitted to execute >restorecon and a cursory glance at the targeted policy suggests that it can't >execute it there either. > >dhcpc_t can only create files of types dhcpc_var_run_t, net_conf_t, >dhcpc_tmp_t, and dhcpc_state_t. Of those the type net_conf_t is specified by >the domain_auto_trans() rule for files created under /etc. I can't work out >how dhclient could create a file with the wrong type to the call to >restorecon seems redundant. > > Yes this is a reported bug. dhcpc_t was not in targeted policy, so the dhcpc maintainer added this call which would work from unconfined_t. Rawhide/FC4 policy has the dhcpc policy, so the files will get created with the correct context and the restorecon can be removed. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=153244 >We don't want to use the policy domain_auto_trans(dhcpc_t, restorecon_exec_t, >restorecon_t) because restorecon_t is a highly privileged domain that we want >to limit access to (every domain that has such a transition should ideally >have it's main programs audited). > >We don't want to use the policy can_exec(dhcpc_t, restorecon_exec_t) as that >will require allowing dhcpc_t to read the policy source which may be regarded >as secret (and therefore something that we don't want to give to a program >that is always running and has network access). > >I think it would be best if dhclient-script did not call restorecon at all. > >-- >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 > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- From russell at coker.com.au Mon Apr 4 15:09:06 2005 From: russell at coker.com.au (Russell Coker) Date: Tue, 5 Apr 2005 01:09:06 +1000 Subject: restorecon and targeted policy Message-ID: <200504050109.08794.russell@coker.com.au> It seems that restorecon needs to be handled in the targeted policy in the same way as udev. I've just been working on setting up kickstart installs for FC4T1 machines with strict policy. I use lokkit in the kickstart %post to convert it to strict policy before the first boot. When it boots up the rc.sysinit calls to restorecon fail if unlimitedRC is not defined (IE a more strict than default config of the strict policy). We probably don't need to actually define types for this, just adding appropriate typealias rules should do as long as the .fc file is there. The same applies to fsadm and mount. It will also apply to anything else that can be run before all file systems are mounted. -- 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 sds at tycho.nsa.gov Mon Apr 4 15:06:30 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 04 Apr 2005 11:06:30 -0400 Subject: Setting SELinux context of loop-mounted ISO filesystem In-Reply-To: <5c06fa77050404080231d92e77@mail.gmail.com> References: <5c06fa77050404080231d92e77@mail.gmail.com> Message-ID: <1112627190.7629.82.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-04-04 at 11:02 -0400, Deron Meranda wrote: > I'm trying to mount some ISO files using the loop device. However > I can't seem to get the context= option on the mount to work. As > such the mounted files have no SELinux context set. In particular > I'm trying the following, > > mount -t iso9660 \ > -o context=system_u:object_r:httpd_sys_content_t,loop,ro,noexec,nodev,nosuid > \ > /path/to/file.iso /mountpoint > > I'm running in enforcing mode with selinux-policy-targeted-1.17.30-2.93 > > How can one mount an ISO image file and force all files to appear > to have a particular SELinux context? What makes you think it isn't working? ls -Z isn't going to work regardless, as iso9660 doesn't provide extended attribute handlers. But the context= option should set the security context that is applied internally by SELinux to the incore inodes, so that they will be access controlled accordingly. BTW, fscontext= may be more suitable here than context=. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Mon Apr 4 15:48:09 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 04 Apr 2005 11:48:09 -0400 Subject: Setting SELinux context of loop-mounted ISO filesystem In-Reply-To: <5c06fa7705040408447f87ad57@mail.gmail.com> References: <5c06fa77050404080231d92e77@mail.gmail.com> <1112627190.7629.82.camel@moss-spartans.epoch.ncsc.mil> <5c06fa7705040408447f87ad57@mail.gmail.com> Message-ID: <1112629689.7629.114.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-04-04 at 11:44 -0400, Deron Meranda wrote: > I was, though, expecting ls -Z to show the applied label. So the filesystem > context is being applied, but you can't see it via ls -Z? I guess that makes > sense now that I think about it, but it was a little surprising. I > kind of expected > the context= option to work somewhat like the uid= and gid= options as far > as it's visibility to ls. Unfortunately, no. ls -Z ultimately calls getxattr on the inode, and unless the filesystem implementation provides a getxattr method, you can't get that information. There has been discussion of putting a transparent redirect in the VFS so that if the filesystem implementation doesn't provide getxattr/setxattr on the security namespace, the VFS will automatically redirect the request to the security module (i.e. SELinux) and let it handle it based on the incore inode security context. > Also I think context= is what I want, versus fscontext=, since this is > an ISO9660 > filesystem that doesn't support extended attributes (xattr). Otherwise Apache > could see the filesystem, but not the individual files inside it. > Isn't that correct? I think for iso9660 they are effectively equivalent. It would make a difference for filesystems that have native xattr support. -- Stephen Smalley National Security Agency From hampton-rh at rainbolthampton.net Mon Apr 4 16:27:00 2005 From: hampton-rh at rainbolthampton.net (David Hampton) Date: Mon, 04 Apr 2005 12:27:00 -0400 Subject: invalid context root:object_r:httpd_sysadm_content_t Message-ID: <1112632020.7877.35.camel@hampton-pc.rainbolthampton.net> I've started getting this error message recently when I updated from the rawhide strict policy. I've tried a bunch of policy tweaks to no avail, and I'm at a loss for how to fix it. I even went as far as deleting my /etc/selinux/strict/src directory and reinstalling both the policy and policy-sources rpms. That I still have the problem implies that it wasn't caused by any of my local modifications. Any suggested solutions or things for me to try? Thanks. David From dwalsh at redhat.com Mon Apr 4 18:23:45 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 04 Apr 2005 14:23:45 -0400 Subject: invalid context root:object_r:httpd_sysadm_content_t In-Reply-To: <1112632020.7877.35.camel@hampton-pc.rainbolthampton.net> References: <1112632020.7877.35.camel@hampton-pc.rainbolthampton.net> Message-ID: <42518631.20407@redhat.com> David Hampton wrote: >I've started getting this error message recently when I updated from the >rawhide strict policy. I've tried a bunch of policy tweaks to no avail, >and I'm at a loss for how to fix it. I even went as far as deleting >my /etc/selinux/strict/src directory and reinstalling both the policy >and policy-sources rpms. That I still have the problem implies that it >wasn't caused by any of my local modifications. Any suggested solutions >or things for me to try? Thanks. > >David > > > Try yum update to ftp://people.redhat.com/dwalsh/SELinux/Fedora selinux-policy-strict-1.23.6-1.noarch.rpm should fix this. >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- From hampton-rh at rainbolthampton.net Mon Apr 4 19:08:31 2005 From: hampton-rh at rainbolthampton.net (David Hampton) Date: Mon, 04 Apr 2005 15:08:31 -0400 Subject: invalid context root:object_r:httpd_sysadm_content_t In-Reply-To: <42518631.20407@redhat.com> References: <1112632020.7877.35.camel@hampton-pc.rainbolthampton.net> <42518631.20407@redhat.com> Message-ID: <1112641711.7877.39.camel@hampton-pc.rainbolthampton.net> On Mon, 2005-04-04 at 14:23 -0400, Daniel J Walsh wrote: > Try yum update to > > ftp://people.redhat.com/dwalsh/SELinux/Fedora > selinux-policy-strict-1.23.6-1.noarch.rpm should fix this. That fixed it. David From hampton-rh at rainbolthampton.net Mon Apr 4 19:20:59 2005 From: hampton-rh at rainbolthampton.net (David Hampton) Date: Mon, 04 Apr 2005 15:20:59 -0400 Subject: Another Apache problem Message-ID: <1112642459.7877.53.camel@hampton-pc.rainbolthampton.net> I noticed that I had "r_dir_file(httpd_t, httpdcontent)" in my domains/misc/local.te file so I removed it. After I did this I started getting avc errors for all web access to my server. Audit2allow says I need: allow httpd_t httpd_sys_content_t:dir { getattr search }; allow httpd_t httpd_sys_content_t:file { getattr read }; Poking through the policy sources, it appears that httpd_t no longer has permission to read files with the httpdcontent attribute. Grep shows only this one place where httpd_t gets permission to read the content... ./domains/program/apache.te:create_dir_file(httpd_t, httpdcontent) ...but this line is protected by what looks like a four way conditional and doesn't appear to have any effect. Would it make sense to add unconditional read access to httpd before checking/allowing write and execute access on the files? My system is an FC3 base running with Daniel Walsh's 1.23.6-1 strict policy. David From dwalsh at redhat.com Mon Apr 4 20:09:14 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 04 Apr 2005 16:09:14 -0400 Subject: Another Apache problem In-Reply-To: <1112642459.7877.53.camel@hampton-pc.rainbolthampton.net> References: <1112642459.7877.53.camel@hampton-pc.rainbolthampton.net> Message-ID: <42519EEA.2060400@redhat.com> David Hampton wrote: >I noticed that I had "r_dir_file(httpd_t, httpdcontent)" in my >domains/misc/local.te file so I removed it. After I did this I started >getting avc errors for all web access to my server. Audit2allow says I >need: > >allow httpd_t httpd_sys_content_t:dir { getattr search }; >allow httpd_t httpd_sys_content_t:file { getattr read }; > >Poking through the policy sources, it appears that httpd_t no longer has >permission to read files with the httpdcontent attribute. Grep shows >only this one place where httpd_t gets permission to read the content... > >./domains/program/apache.te:create_dir_file(httpd_t, httpdcontent) > >...but this line is protected by what looks like a four way conditional >and doesn't appear to have any effect. Would it make sense to add >unconditional read access to httpd before checking/allowing write and >execute access on the files? > >My system is an FC3 base running with Daniel Walsh's 1.23.6-1 strict >policy. > >David > > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Do you have httpd_unified && httpd_enable_cgi && httpd_builtin_scripting turned on? getsebool -a | grep httpd setsebool -P httpd_enable_cgi=1 httpd_unified=1 httpd_builtin_scripting=1 Will turn it on. -- From hampton-rh at rainbolthampton.net Mon Apr 4 20:41:23 2005 From: hampton-rh at rainbolthampton.net (David Hampton) Date: Mon, 04 Apr 2005 16:41:23 -0400 Subject: Another Apache problem In-Reply-To: <42519EEA.2060400@redhat.com> References: <1112642459.7877.53.camel@hampton-pc.rainbolthampton.net> <42519EEA.2060400@redhat.com> Message-ID: <1112647283.7877.61.camel@hampton-pc.rainbolthampton.net> On Mon, 2005-04-04 at 16:09 -0400, Daniel J Walsh wrote: > Do you have httpd_unified && httpd_enable_cgi && httpd_builtin_scripting > turned on? > > getsebool -a | grep httpd httpd_builtin_scripting --> inactive httpd_can_network_connect --> inactive httpd_enable_cgi --> active httpd_enable_homedirs --> active httpd_ssi_exec --> active httpd_tty_comm --> inactive httpd_unified --> inactive I don't think I've ever set any of these (except maybe homedirs), so I can't tell you why they are in this state. > setsebool -P httpd_enable_cgi=1 httpd_unified=1 httpd_builtin_scripting=1 > Will turn it on. Thanks. My question is the obvious one. Why do I need to enable cgi, unified and scripting in order to serve static web pages? David From dwalsh at redhat.com Mon Apr 4 21:01:03 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 04 Apr 2005 17:01:03 -0400 Subject: Another Apache problem In-Reply-To: <1112647283.7877.61.camel@hampton-pc.rainbolthampton.net> References: <1112642459.7877.53.camel@hampton-pc.rainbolthampton.net> <42519EEA.2060400@redhat.com> <1112647283.7877.61.camel@hampton-pc.rainbolthampton.net> Message-ID: <4251AB0F.1030501@redhat.com> David Hampton wrote: >On Mon, 2005-04-04 at 16:09 -0400, Daniel J Walsh wrote: > > > >>Do you have httpd_unified && httpd_enable_cgi && httpd_builtin_scripting >>turned on? >> >>getsebool -a | grep httpd >> >> > >httpd_builtin_scripting --> inactive >httpd_can_network_connect --> inactive >httpd_enable_cgi --> active >httpd_enable_homedirs --> active >httpd_ssi_exec --> active >httpd_tty_comm --> inactive >httpd_unified --> inactive > >I don't think I've ever set any of these (except maybe homedirs), so I >can't tell you why they are in this state. > > > >>setsebool -P httpd_enable_cgi=1 httpd_unified=1 httpd_builtin_scripting=1 >>Will turn it on. >> >> > >Thanks. > >My question is the obvious one. Why do I need to enable cgi, unified >and scripting in order to serve static web pages? > >David > > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Because we have a bug in policy. All you needed to turn on is httpd_builtin_scripting=1 r_dir_file(httpd_t, http_$1_content_t) was locked in this boolean. I have moved it outside and once you update to tomorrows policy, you should be able to turn off all booleans and still serve pages. Updated policy is available now at Fedora/selinux-policy-*-1.23.6-3.noarch.rpm ftp://people.redhat.com/dwalsh/SELinux/Fedora -- From bench at silentmedia.com Tue Apr 5 04:01:23 2005 From: bench at silentmedia.com (Ben) Date: Mon, 4 Apr 2005 21:01:23 -0700 Subject: CGI permissions for targeted policy In-Reply-To: <424D9990.5060303@redhat.com> References: <10512119e563d2c084c21048db40d1be@silentmedia.com> <424D9990.5060303@redhat.com> Message-ID: <514a43236b15b4497893e92a13364e5a@silentmedia.com> Yes exactly; the tmp file is being created by php and then the CGI program reads the file. On Apr 1, 2005, at 10:57 AM, Daniel J Walsh wrote: > Ben wrote: > >> I have been having some problems with a CGI program, and audit2allow >> shows I should add these permissions: >> >> allow httpd_sys_script_t devpts_t:chr_file { read write }; >> allow httpd_sys_script_t httpd_tmp_t:file getattr; >> allow httpd_sys_script_t httpd_tmp_t:file read; >> >> I'm pretty green at SELinux, so I'm not too sure what these allow. I >> suspect that the last rule lets httpd_sys_script_t programs read >> files of type httpd_tmp_t, and the second rule lets them stat() those >> files. What does the first rule mean, exactly? The CGI program I'm >> trying to run creates a random filename, and I expect this is related >> to that, but there ends my speculation. >> > The first error is the httpd script trying to access a terminal. The > other errors are httpd trying to read the tmp file. Is the tmp file > created by a builtin function (php)? And the a cgi script runs to > read it? > > Dan > >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > -- > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From russell at coker.com.au Tue Apr 5 05:45:06 2005 From: russell at coker.com.au (Russell Coker) Date: Tue, 5 Apr 2005 15:45:06 +1000 Subject: 'cannot relabel' miscue on shutdown .... In-Reply-To: <4c4ba1530504031647e9e769e@mail.gmail.com> References: <4c4ba1530504031647e9e769e@mail.gmail.com> Message-ID: <200504051545.10768.russell@coker.com.au> On Monday 04 April 2005 09:47, Tom London wrote: > Running targeted/enforcing, latest rawhide. This one happens under strict as well. > Each time I halt/reboot, I seem to get a message like the following > (the 'funny text' varies): Firstly the method of reproducing this is to kill -1 the top level process. For a console login that means killing /bin/login, for a remote login that means the sshd for the session in question. Much easier than rebooting the machine to reproduce the bug. ;) > Apr 3 11:58:51 localhost su[3659]: Warning! Could not relabel > ,\uffff\uff7f\u0661\uffff with user_u:object_r:devpts_t, not > relabeling. Here's the strace output from reproducing that: waitpid(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGHUP}], WSTOPPED) = 26120 setxattr("/dev/pts/1", "security.selinux", "user_u:object_r:user_devpts_t", 30, ) = -1 ENOENT (No such file or directory) open("/usr/share/locale/locale.alias", O_RDONLY) = 3 [read locale stuff] close(3) = 0 munmap(0xb7d40000, 4096) = 0 [try unsuccessfully to open other locale files] time([1112716582]) = 1112716582 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=785, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=785, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=785, ...}) = 0 socket(PF_FILE, SOCK_DGRAM, 0) = 3 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 connect(3, {sa_family=AF_FILE, path="/dev/log"}, 16) = 0 send(3, "<37>Apr 6 01:56:22 su[26119]: Warning! Could not relabel \374\322\360\277)1\307 with user_u:object_r:user_devpts_t, not relabeling. \n", 119, MSG_NOSIGNAL) = 119 So it seems that the code does the correct thing but just logs bogus data. The below code from pam-0.78-selinux.patch in the PAM package source seems to be the culprit. If the variable tty already has "/dev/" at the start then ttybuf will not be initialised. + if(strncmp("/dev/", tty, 5)) { + snprintf(ttybuf,sizeof(ttybuf),"/dev/%s",tty); + ptr = ttybuf; + } + else + ptr = tty; + + if (setfilecon(ptr, context)) + { + syslog(LOG_NOTICE, + _("Warning! Could not relabel %s with %s, not relabeling.\n"), + ttybuf,context); + } I've filed a bugzilla report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=153711 -- 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 dwalsh at redhat.com Tue Apr 5 12:39:24 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 05 Apr 2005 08:39:24 -0400 Subject: CGI permissions for targeted policy In-Reply-To: <514a43236b15b4497893e92a13364e5a@silentmedia.com> References: <10512119e563d2c084c21048db40d1be@silentmedia.com> <424D9990.5060303@redhat.com> <514a43236b15b4497893e92a13364e5a@silentmedia.com> Message-ID: <425286FC.3000201@redhat.com> Ben wrote: > Yes exactly; the tmp file is being created by php and then the CGI > program reads the file. > Do you have the ability to change the PHP script to not create in /tmp but to create some where under /var/www? > On Apr 1, 2005, at 10:57 AM, Daniel J Walsh wrote: > >> Ben wrote: >> >>> I have been having some problems with a CGI program, and audit2allow >>> shows I should add these permissions: >>> >>> allow httpd_sys_script_t devpts_t:chr_file { read write }; >>> allow httpd_sys_script_t httpd_tmp_t:file getattr; >>> allow httpd_sys_script_t httpd_tmp_t:file read; >>> >>> I'm pretty green at SELinux, so I'm not too sure what these allow. I >>> suspect that the last rule lets httpd_sys_script_t programs read >>> files of type httpd_tmp_t, and the second rule lets them stat() >>> those files. What does the first rule mean, exactly? The CGI program >>> I'm trying to run creates a random filename, and I expect this is >>> related to that, but there ends my speculation. >>> >> The first error is the httpd script trying to access a terminal. The >> other errors are httpd trying to read the tmp file. Is the tmp file >> created by a builtin function (php)? And the a cgi script runs to >> read it? >> >> Dan >> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> http://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >> >> >> >> -- >> >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list -- From jwcart2 at epoch.ncsc.mil Tue Apr 5 13:52:43 2005 From: jwcart2 at epoch.ncsc.mil (James Carter) Date: Tue, 05 Apr 2005 09:52:43 -0400 Subject: Additions to net_contexts In-Reply-To: <1110979052.20316.16.camel@hampton-pc.rainbolthampton.net> References: <1110979052.20316.16.camel@hampton-pc.rainbolthampton.net> Message-ID: <1112709163.1883.6.camel@moss-lions.epoch.ncsc.mil> Merged into the SELinux policy CVS tree at sourceforge. On Wed, 2005-03-16 at 08:17 -0500, David Hampton wrote: > Here are some additions to net_contexts to define additional privileged > ports. I'll be submitting policies that reference these ports over the > next week or so as I get them cleaned up. This is based on the file > from the selinux-policy-strict-sources-1.22.1-2 rpm on my FC3 system. > > David > -- James Carter National Security Agency From jwcart2 at epoch.ncsc.mil Tue Apr 5 13:53:21 2005 From: jwcart2 at epoch.ncsc.mil (James Carter) Date: Tue, 05 Apr 2005 09:53:21 -0400 Subject: Tweaks to the clamav policy In-Reply-To: <1110979071.20316.17.camel@hampton-pc.rainbolthampton.net> References: <1110979071.20316.17.camel@hampton-pc.rainbolthampton.net> Message-ID: <1112709201.1883.8.camel@moss-lions.epoch.ncsc.mil> Merged into the SELinux policy CVS tree at sourceforge. On Wed, 2005-03-16 at 08:17 -0500, David Hampton wrote: > I've added support to the (unused) clamav policy to allow listening for > service requests on a TCP socket, and for interacting with amavis. I > also made some tweaks that tighten up the network access allowed by > freshclam, split the freshclam and spamd log files into two different > types, and make the clamd control socket a unique type. Thanks. > > David > > P.S. These diffs are based on the files from the selinux-policy-strict- > sources-1.22.1-2 rpm. -- James Carter National Security Agency From jwcart2 at epoch.ncsc.mil Tue Apr 5 13:53:56 2005 From: jwcart2 at epoch.ncsc.mil (James Carter) Date: Tue, 05 Apr 2005 09:53:56 -0400 Subject: Tweaks to the amavis policy In-Reply-To: <1110979100.20316.18.camel@hampton-pc.rainbolthampton.net> References: <1110979100.20316.18.camel@hampton-pc.rainbolthampton.net> Message-ID: <1112709236.1883.10.camel@moss-lions.epoch.ncsc.mil> Merged into the SELinux policy CVS tree at sourceforge. On Wed, 2005-03-16 at 08:18 -0500, David Hampton wrote: > I've added support to the (unused) amavis policy to allow interaction > with additional mail filters, and added a new type specifically for > quarantined spam and viruses. I also tweaked the network access to > limit ports that can be used by amavisd. I'd appreciate any feedback on > these changes or tips on how to write better policies. Thanks. > > David > > P.S. These diffs are based on the files from the selinux-policy-strict- > sources-1.22.1-2 rpm. -- James Carter National Security Agency From jwcart2 at epoch.ncsc.mil Tue Apr 5 13:54:13 2005 From: jwcart2 at epoch.ncsc.mil (James Carter) Date: Tue, 05 Apr 2005 09:54:13 -0400 Subject: New policy for razor In-Reply-To: <1111454590.18940.52.camel@hampton-pc.rainbolthampton.net> References: <1111454590.18940.52.camel@hampton-pc.rainbolthampton.net> Message-ID: <1112709253.1883.12.camel@moss-lions.epoch.ncsc.mil> Merged into the SELinux policy CVS tree at sourceforge. On Mon, 2005-03-21 at 20:23 -0500, David Hampton wrote: > This is a new strict policy for the razor spam filter. It is based on > the selinux-policy-strict-sources-1.23.2-1 fedora RPM. This policy > requires the definition of a razor reserved port that was in the > net_contexts diff I sent last Wednesday. Please let me know if there > are any problems with or changes needed to this policy. > > David > -- James Carter National Security Agency From jwcart2 at epoch.ncsc.mil Tue Apr 5 13:54:22 2005 From: jwcart2 at epoch.ncsc.mil (James Carter) Date: Tue, 05 Apr 2005 09:54:22 -0400 Subject: New policy for pyzor In-Reply-To: <1111454594.18940.54.camel@hampton-pc.rainbolthampton.net> References: <1111454594.18940.54.camel@hampton-pc.rainbolthampton.net> Message-ID: <1112709262.1883.14.camel@moss-lions.epoch.ncsc.mil> Merged into the SELinux policy CVS tree at sourceforge. On Mon, 2005-03-21 at 20:23 -0500, David Hampton wrote: > This is a new strict policy for the pyzor spam filter. It is based on > the selinux-policy-strict-sources-1.23.2-1 fedora RPM. This policy > requires the definition of a pyzor reserved port that was in the > net_contexts diff I sent last Wednesday. Please let me know if there > are any problems with or changes needed to this policy. > > David > -- James Carter National Security Agency From jwcart2 at epoch.ncsc.mil Tue Apr 5 13:54:31 2005 From: jwcart2 at epoch.ncsc.mil (James Carter) Date: Tue, 05 Apr 2005 09:54:31 -0400 Subject: New policy for DCC In-Reply-To: <1111454598.18940.57.camel@hampton-pc.rainbolthampton.net> References: <1111454598.18940.57.camel@hampton-pc.rainbolthampton.net> Message-ID: <1112709271.1883.16.camel@moss-lions.epoch.ncsc.mil> Merged into the SELinux policy CVS tree at sourceforge. On Mon, 2005-03-21 at 20:23 -0500, David Hampton wrote: > This is a new strict policy for the DCC spam filter. It is based on the > selinux-policy-strict-sources-1.23.2-1 fedora RPM. This policy requires > the definition of dcc reserved ports that were in the net_contexts diff > I sent last Wednesday. Please let me know if there are any problems > with or changes needed to this policy. > > David > -- James Carter National Security Agency From hongwei at wustl.edu Tue Apr 5 20:13:57 2005 From: hongwei at wustl.edu (Hongwei Li) Date: Tue, 5 Apr 2005 15:13:57 -0500 (CDT) Subject: Can somebody help me? Message-ID: <4039.128.252.85.103.1112732037.squirrel@morpheus.wustl.edu> Hi, I just found that my fc3 system log shows many, many entries like below: Apr 5 14:50:42 morpheus kernel: audit(1112730642.889:0): avc: denied { ioctl } for pid=32509 exe=/usr/bin/perl path=/proc/loadavg dev=proc ino=-268435456 scontext=user_u:system_r:httpd_sys_script_t tcontext=system_u:object_r:proc_t tclass=file Apr 5 14:51:19 morpheus kernel: audit(1112730679.318:0): avc: denied { ioctl } for pid=32579 exe=/usr/bin/perl path=/proc/loadavg dev=proc ino=-268435456 scontext=user_u:system_r:httpd_sys_script_t tcontext=system_u:object_r:proc_t tclass=file ... what does it mean? Although I haven't got real trouble in email service, web service, squirrelmail, etc., I'd like to know if it means something bad in the system and how to fix it. Thanks a lot! Hongwei Li From hampton-rh at rainbolthampton.net Wed Apr 6 14:49:28 2005 From: hampton-rh at rainbolthampton.net (David Hampton) Date: Wed, 06 Apr 2005 10:49:28 -0400 Subject: Another Apache problem In-Reply-To: <4251AB0F.1030501@redhat.com> References: <1112642459.7877.53.camel@hampton-pc.rainbolthampton.net> <42519EEA.2060400@redhat.com> <1112647283.7877.61.camel@hampton-pc.rainbolthampton.net> <4251AB0F.1030501@redhat.com> Message-ID: <1112798968.7334.18.camel@hampton-pc.rainbolthampton.net> On Mon, 2005-04-04 at 17:01 -0400, Daniel J Walsh wrote: > r_dir_file(httpd_t, http_$1_content_t) was locked in this boolean. > > I have moved it outside and once you update to tomorrows policy, you should > be able to turn off all booleans and still serve pages. Should there also be an "r_dir_file(httpd_t, httpdcontent)" statement in the same place? (Or in its place, since http_$1_content_t is marked with the httpdcontent attribute). Or am I misunderstanding the reason behind the httpdcontent attribute? The comment with this attribute is pretty sparse. The question comes up because in one of the policies I submitted, I had type yam_content_t, file_type, sysadmfile, httpdcontent; Should this be sufficient to allow httpd to serve the files, or do I need to explicitly add r_dir_file(httpd_t, yam_content_t) I have the equivalent of this line at the moment, but would like to remove it if its redundant (or should be redundant). Thanks. David From mike at flyn.org Wed Apr 6 18:01:06 2005 From: mike at flyn.org (W. Michael Petullo) Date: Wed, 6 Apr 2005 13:01:06 -0500 Subject: Error loading libsepol on during system boot Message-ID: <20050406180106.GA7107@imp.flyn.org> I have been sitting on a problem for a few weeks, waiting to see if a forthcoming policy package would fix it. I wanted to mention it on this mailing list before entering it into Bugzilla because I am not convinced it is not my fault. When I try to boot my system with Fedora's strict policy, the process stops with the following message: ... denied { execmem } for pid=1 comm=init scontext=system_u:system_r:init_t tcontext=system_u:system_r:init_t tclass=process /sbin/init: error while loading shared libraries: libsepol.so.1: failed to map segment from shared object: Permission denied kernel panic - not syncing: Attempted to kill init! I am using: SysVinit-2.85-37 selinux-policy-strict-1.23.6-3 libsepol-1.5.3-1 Has anyone else experienced this? -- Mike :wq From dwalsh at redhat.com Wed Apr 6 18:31:08 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 06 Apr 2005 14:31:08 -0400 Subject: Another Apache problem In-Reply-To: <1112798968.7334.18.camel@hampton-pc.rainbolthampton.net> References: <1112642459.7877.53.camel@hampton-pc.rainbolthampton.net> <42519EEA.2060400@redhat.com> <1112647283.7877.61.camel@hampton-pc.rainbolthampton.net> <4251AB0F.1030501@redhat.com> <1112798968.7334.18.camel@hampton-pc.rainbolthampton.net> Message-ID: <42542AEC.9010204@redhat.com> David Hampton wrote: >On Mon, 2005-04-04 at 17:01 -0400, Daniel J Walsh wrote: > > > >>r_dir_file(httpd_t, http_$1_content_t) was locked in this boolean. >> >>I have moved it outside and once you update to tomorrows policy, you should >>be able to turn off all booleans and still serve pages. >> >> > >Should there also be an "r_dir_file(httpd_t, httpdcontent)" statement in >the same place? (Or in its place, since http_$1_content_t is marked >with the httpdcontent attribute). Or am I misunderstanding the reason >behind the httpdcontent attribute? The comment with this attribute is >pretty sparse. > >The question comes up because in one of the policies I submitted, I had > > type yam_content_t, file_type, sysadmfile, httpdcontent; > >Should this be sufficient to allow httpd to serve the files, or do I >need to explicitly add > > r_dir_file(httpd_t, yam_content_t) > >I have the equivalent of this line at the moment, but would like to >remove it if its redundant (or should be redundant). > >Thanks. > > httpdcontent is used to by the httpd_unified domain. Which says treat all httpdcontent the same. So that would only be used within that boolean. So if you want to turn off all booleans for httpd(Most secure) You would have to add r_dir_file(httpd_t, yam_content_t) If you want to run with httpd_unified you don't need to. httpd_unified on a machine without httpd scripts would not make much difference. Dan >David > > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- From hampton-rh at rainbolthampton.net Wed Apr 6 19:06:08 2005 From: hampton-rh at rainbolthampton.net (David Hampton) Date: Wed, 06 Apr 2005 15:06:08 -0400 Subject: Another Apache problem In-Reply-To: <42542AEC.9010204@redhat.com> References: <1112642459.7877.53.camel@hampton-pc.rainbolthampton.net> <42519EEA.2060400@redhat.com> <1112647283.7877.61.camel@hampton-pc.rainbolthampton.net> <4251AB0F.1030501@redhat.com> <1112798968.7334.18.camel@hampton-pc.rainbolthampton.net> <42542AEC.9010204@redhat.com> Message-ID: <1112814368.26744.5.camel@hampton-pc.rainbolthampton.net> On Wed, 2005-04-06 at 14:31 -0400, Daniel J Walsh wrote: > httpdcontent is used to by the httpd_unified domain. Which says treat > all httpdcontent the same. > So that would only be used within that boolean. That's the information I was missing. > So if you want to turn > off all booleans for httpd(Most secure) > You would have to add > > r_dir_file(httpd_t, yam_content_t) I'll leave this in the policy. Thanks. David From sds at tycho.nsa.gov Thu Apr 7 12:42:11 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 07 Apr 2005 08:42:11 -0400 Subject: Error loading libsepol on during system boot In-Reply-To: <20050406180106.GA7107@imp.flyn.org> References: <20050406180106.GA7107@imp.flyn.org> Message-ID: <1112877731.27110.23.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-04-06 at 13:01 -0500, W. Michael Petullo wrote: > I have been sitting on a problem for a few weeks, waiting to see if a > forthcoming policy package would fix it. I wanted to mention it on this > mailing list before entering it into Bugzilla because I am not convinced > it is not my fault. > > When I try to boot my system with Fedora's strict policy, the process > stops with the following message: > > ... denied { execmem } for pid=1 comm=init scontext=system_u:system_r:init_t tcontext=system_u:system_r:init_t tclass=process > /sbin/init: error while loading shared libraries: libsepol.so.1: failed to map segment from shared object: Permission denied > kernel panic - not syncing: Attempted to kill init! > > I am using: > > SysVinit-2.85-37 > selinux-policy-strict-1.23.6-3 > libsepol-1.5.3-1 > > Has anyone else experienced this? If your architecture is ppc32, then you are likely encountering the issue described in bugzilla 149819. A patch was created and upstreamed, and included in the rawhide kernel, so you shouldn't still see it if you have updated your kernel. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Thu Apr 7 12:00:55 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 07 Apr 2005 08:00:55 -0400 Subject: Error loading libsepol on during system boot In-Reply-To: <20050406180106.GA7107@imp.flyn.org> References: <20050406180106.GA7107@imp.flyn.org> Message-ID: <1112875255.27110.0.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-04-06 at 13:01 -0500, W. Michael Petullo wrote: > I have been sitting on a problem for a few weeks, waiting to see if a > forthcoming policy package would fix it. I wanted to mention it on this > mailing list before entering it into Bugzilla because I am not convinced > it is not my fault. > > When I try to boot my system with Fedora's strict policy, the process > stops with the following message: > > ... denied { execmem } for pid=1 comm=init scontext=system_u:system_r:init_t tcontext=system_u:system_r:init_t tclass=process > /sbin/init: error while loading shared libraries: libsepol.so.1: failed to map segment from shared object: Permission denied > kernel panic - not syncing: Attempted to kill init! > > I am using: > > SysVinit-2.85-37 > selinux-policy-strict-1.23.6-3 > libsepol-1.5.3-1 > > Has anyone else experienced this? What is your kernel? What is your architecture? -- Stephen Smalley National Security Agency From mike at flyn.org Thu Apr 7 15:23:00 2005 From: mike at flyn.org (W. Michael Petullo) Date: Thu, 7 Apr 2005 10:23:00 -0500 (CDT) Subject: Error loading libsepol on during system boot In-Reply-To: <1112877731.27110.23.camel@moss-spartans.epoch.ncsc.mil> References: <20050406180106.GA7107@imp.flyn.org> <1112877731.27110.23.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <28511.66.151.13.191.1112887380.squirrel@zero.voxel.net> >> I have been sitting on a problem for a few weeks, waiting to see if a >> forthcoming policy package would fix it. I wanted to mention it on this >> mailing list before entering it into Bugzilla because I am not convinced >> it is not my fault. >> >> When I try to boot my system with Fedora's strict policy, the process >> stops with the following message: >> >> ... denied { execmem } for pid=1 comm=init >> scontext=system_u:system_r:init_t tcontext=system_u:system_r:init_t >> tclass=process >> /sbin/init: error while loading shared libraries: libsepol.so.1: failed >> to map segment from shared object: Permission denied >> kernel panic - not syncing: Attempted to kill init! >> >> I am using: >> >> SysVinit-2.85-37 >> selinux-policy-strict-1.23.6-3 >> libsepol-1.5.3-1 >> >> Has anyone else experienced this? > If your architecture is ppc32, then you are likely encountering the > issue described in bugzilla 149819. A patch was created and upstreamed, > and included in the rawhide kernel, so you shouldn't still see it if you > have updated your kernel. Yes, my architecture is ppc. Upgrading my kernel fixed the problem. Thank you, Stephen. -- Mike From lfarkas at bppiac.hu Thu Apr 7 21:25:29 2005 From: lfarkas at bppiac.hu (Farkas Levente) Date: Thu, 07 Apr 2005 23:25:29 +0200 Subject: snmpd bug Message-ID: <4255A549.9060408@bppiac.hu> hi, i'm just notice this bug in out firewall's log file: ----------------------------------- Apr 7 17:50:23 portal kernel: audit(1112889023.021:0): avc: denied { search } for pid=6409 exe=/usr/sbin/snmpd name=net dev=proc ino=-268435351 scontext=user_u:system_r:snmpd_t tcontext=system_u:object_r:sysctl_net_t tclass=dir ----------------------------------- it seems snmpd try to do something which is not allowed:-) yours. -- Levente "Si vis pacem para bellum!" From russell at coker.com.au Fri Apr 8 11:22:57 2005 From: russell at coker.com.au (Russell Coker) Date: Fri, 8 Apr 2005 21:22:57 +1000 Subject: Here is an interesting one In-Reply-To: <1109999863.6774.2.camel@cobra.ivg2.net> References: <4228DFDE.7080203@rhjensen.com> <422913C2.1030406@antient.org> <1109999863.6774.2.camel@cobra.ivg2.net> Message-ID: <200504082122.59616.russell@coker.com.au> On Saturday 05 March 2005 16:17, Ivan Gyurdiev wrote: > --- snmpd.te 2005-03-05 00:13:17.000000000 -0500 > +++ snmpd.new 2005-03-05 00:13:46.000000000 -0500 > @@ -45,6 +45,7 @@ > allow snmpd_t proc_t:dir search; > allow snmpd_t proc_t:file r_file_perms; > allow snmpd_t self:file { getattr read }; > +allow snmpd_t self:fifo_file { read write }; In a case such as this I suggest using rw_file_perms instead of { read write }. The reason is that restricting access of a domain to itself is of little benefit and that once the main access is granted you may as well grant the other accesses for the same class. ioctl access is commonly requested, often a child process inherits the file handle and does not know that it's a pipe and will perform an ioctl to find out. -- 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 russell at coker.com.au Fri Apr 8 11:26:51 2005 From: russell at coker.com.au (Russell Coker) Date: Fri, 8 Apr 2005 21:26:51 +1000 Subject: Here is an interesting one In-Reply-To: <422CD54B.9030502@antient.org> References: <4228DFDE.7080203@rhjensen.com> <422A02DC.3060806@antient.org> <422CD54B.9030502@antient.org> Message-ID: <200504082126.54239.russell@coker.com.au> On Tuesday 08 March 2005 09:27, Richard Irving wrote: > "dontaudit snmpd_t unconfined_t:process signull;" Which process is it trying to send signull to? You will have to either enable auditing or use strace or gdb to trace it to discover what is going on. The access in question may be undesired or it may be something that is actually required, without knowing more about your situation it's impossible to determine. It would be best if you could track this down, I don't recommend the dontaudit rule without more investigation. -- 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 russell at coker.com.au Fri Apr 8 11:10:51 2005 From: russell at coker.com.au (Russell Coker) Date: Fri, 8 Apr 2005 21:10:51 +1000 Subject: hello all, I just joined the list In-Reply-To: <200503010030.j210U5el017444@mx3.redhat.com> References: <200503010030.j210U5el017444@mx3.redhat.com> Message-ID: <200504082110.54213.russell@coker.com.au> On Tuesday 01 March 2005 10:54, "nanocurie" wrote: > I just joined the list. I just downloaded and installed FC3, > and noticed that it had SE-Linux installed by default. I thought okay, so > the NSA now can/will take control of my secure computers. Good, if there's The SE Linux code is clean and reasonably easy to read, it has been checked by many people. If you are concerned about back-doors in kernel code then you should be concerned about the device drivers for less popular hardware and other code that doesn't get much attention. -- 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 w5set at alltel.net Fri Apr 8 15:14:34 2005 From: w5set at alltel.net (steve) Date: Fri, 8 Apr 2005 10:14:34 -0500 Subject: hello all, I just joined the list In-Reply-To: <200504082110.54213.russell@coker.com.au> References: <200503010030.j210U5el017444@mx3.redhat.com> <200504082110.54213.russell@coker.com.au> Message-ID: <200504081014.34761.w5set@alltel.net> OH-MY, could my computer be a zombie of of NSA? Could I be a part of a weird plot with the NSA and Aliens using SELinux and parallel computing and my computer to create an Intelligent Supercomputer that will rule the world? UHHHH--forget it--just remembered, that was the dream I had last night about the Dwarf blue Girl from the 7th planet of Zwqqvvzzz--never mind. Just a note to say "THANKS Guys/Girls for being here". I read a lot--post seldom. Still trying to figure out these "zombie" SELinux features--but I like SELINUX. Somebody tell NSA thanks-- even though they have devious dark plans for protecting computer OS's. On Friday April 8 2005 06:10 am, Russell Coker wrote: > On Tuesday 01 March 2005 10:54, "nanocurie" wrote: > > I just joined the list. I just downloaded and installed FC3, > > and noticed that it had SE-Linux installed by default. I thought okay, so > > the NSA now can/will take control of my secure computers. Good, if > > there's > > The SE Linux code is clean and reasonably easy to read, it has been checked > by many people. If you are concerned about back-doors in kernel code then > you should be concerned about the device drivers for less popular hardware > and other code that doesn't get much attention. -- .................steve w5set From rirving at antient.org Sat Apr 9 02:12:41 2005 From: rirving at antient.org (Richard Irving) Date: Fri, 08 Apr 2005 21:12:41 -0500 Subject: hello all, I just joined the list In-Reply-To: <200504081014.34761.w5set@alltel.net> References: <200503010030.j210U5el017444@mx3.redhat.com> <200504082110.54213.russell@coker.com.au> <200504081014.34761.w5set@alltel.net> Message-ID: <42573A19.3010609@antient.org> steve wrote: > OH-MY, could my computer be a zombie of of NSA? It could be, but if it were, _you_ would never know. ;) > Could I be a part of a weird plot with the NSA and Aliens using SELinux and > parallel computing and my computer to create an Intelligent Supercomputer > that will rule the world? Shoot, Mork! we need a more subtle approach, the earthlings are catching on! Nanu Nanu. > UHHHH--forget it--just remembered, that was the dream I had last night about > the Dwarf blue Girl from the 7th planet of Zwqqvvzzz--never mind. I remember her! Careful, she is on the rebound from James T Kirk.... I am not sure I would want to follow his act, I hear James is a "High Risk" Category type... [ Remember, he cried like a Baby when Spock Died, 'nough said ! ] > Just a note to say "THANKS Guys/Girls for being here". I read a lot--post > seldom. Still trying to figure out these "zombie" SELinux features-- Me too, and I think the real trick is.. [the remainder of this sentence has been censored for your own safety, Comrade -- Zombiware (tm)] :O > but I > like SELINUX. Somebody tell NSA thanks-- even though they have devious dark > plans for protecting computer OS's. Oh, no need to... you posted into -this- list. They are -well- aware of you, and your opinions, by now. Remember the TIA slogan: "In God we trust, all else we Monitor!". :D (Caution: Any similarity between this post, and reality, is -purely- coincidental... OK, with the exception of the Kirk-Spock thing.) ;) > On Friday April 8 2005 06:10 am, Russell Coker wrote: > >>On Tuesday 01 March 2005 10:54, "nanocurie" wrote: >> >>> I just joined the list. I just downloaded and installed FC3, >>>and noticed that it had SE-Linux installed by default. I thought okay, so >>>the NSA now can/will take control of my secure computers. Good, if >>>there's >> >>The SE Linux code is clean and reasonably easy to read, it has been checked >>by many people. If you are concerned about back-doors in kernel code then >>you should be concerned about the device drivers for less popular hardware >>and other code that doesn't get much attention. From angela at kahealani.com Sat Apr 9 04:55:40 2005 From: angela at kahealani.com (Angela Kahealani) Date: Fri, 08 Apr 2005 18:55:40 -1000 Subject: hello all, I just threaded the hijack In-Reply-To: <42573A19.3010609@antient.org> References: <200503010030.j210U5el017444@mx3.redhat.com> <200504082110.54213.russell@coker.com.au> <200504081014.34761.w5set@alltel.net> <42573A19.3010609@antient.org> Message-ID: <1113022540.359.43.camel@pc.kahealani.net> On Fri, 2005-04-08 at 21:12 -0500, Richard Irving wrote: > steve wrote: > > Could I be a part of a weird plot with the NSA and Aliens using SELinux and > > parallel computing and my computer to create an Intelligent Supercomputer > > that will rule the world? It's called SETI at Home. > Shoot, Mork! we need a more subtle approach, > the earthlings are catching on! Nanu Nanu. No, they're not, as the mind control is working quite nicely... since they're too stupid to wear their aluminum foil hats. But seriously folks, NSA is the NWO's sigint agency for decrypting "alien" communications... the NWO has already conquered all species *on the surface* of the planet, and is not really concerned with you or your computer... you're just noise in the real power games. And now we return you to your regularly scheduled *programming*... the best HDTV Matrix you can enjoy while in your pod in the powerplant. -- All rights reserved without prejudice. All information and transactions are non negotiable and are private between the parties. Copyright 2005 Angela Kahealani. http://www.kahealani.com/ From fred.new at microlink.ee Sat Apr 9 07:40:10 2005 From: fred.new at microlink.ee (Fred New) Date: Sat, 09 Apr 2005 07:40:10 +0000 Subject: Adobe Reader 7 Message-ID: <1113032411.16942.9.camel@darth> I have installed the beta Adobe Reader 7.0 on my Fedora Core 4 Test 1 system, targeted policy, (ftp://ftp.adobe.com/pub/adobe/reader/unix/7x/7.0/enu/AdbeRdr70_linux_enu.tar.gz) and I had to make the following context changes in order to get it to work: find /usr/local/Adobe -exec chcon -t lib_t {} \; find /usr/local/Adobe/Acrobat7.0/Reader/intellinux \ -type f -exec chcon -t shlib_t {} \; find /usr/local/Adobe/Acrobat7.0/Browser/intellinux \ -type f -exec chcon -t shlib_t {} \; Is this a correct and accepted way of dealing with this without installing the policy sources? Fred From dwalsh at redhat.com Sat Apr 9 11:00:41 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sat, 09 Apr 2005 07:00:41 -0400 Subject: Adobe Reader 7 In-Reply-To: <1113032411.16942.9.camel@darth> References: <1113032411.16942.9.camel@darth> Message-ID: <4257B5D9.3050408@redhat.com> Fred New wrote: >I have installed the beta Adobe Reader 7.0 on my Fedora Core 4 Test 1 >system, targeted policy, >(ftp://ftp.adobe.com/pub/adobe/reader/unix/7x/7.0/enu/AdbeRdr70_linux_enu.tar.gz) >and I had to make the following context changes in order to get it to >work: > >find /usr/local/Adobe -exec chcon -t lib_t {} \; >find /usr/local/Adobe/Acrobat7.0/Reader/intellinux \ > -type f -exec chcon -t shlib_t {} \; >find /usr/local/Adobe/Acrobat7.0/Browser/intellinux \ > -type f -exec chcon -t shlib_t {} \; > >Is this a correct and accepted way of dealing with this without >installing the policy sources? > >Fred > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > restorecon -R -v /usr/local/Adobe should have cleared these up. If not then it is a bug. Dan -- From walters at redhat.com Sat Apr 9 17:15:22 2005 From: walters at redhat.com (Colin Walters) Date: Sat, 09 Apr 2005 13:15:22 -0400 Subject: Adobe Reader 7 In-Reply-To: <1113032411.16942.9.camel@darth> References: <1113032411.16942.9.camel@darth> Message-ID: <1113066922.7744.0.camel@nexus.verbum.private> On Sat, 2005-04-09 at 07:40 +0000, Fred New wrote: > Is this a correct and accepted way of dealing with this without > installing the policy sources? What denials were you getting? We don't presently confine user logins with SELinux, so Adobe Reader should not have been affected. From Fred.New at microlink.ee Sat Apr 9 18:00:43 2005 From: Fred.New at microlink.ee (Fred New) Date: Sat, 9 Apr 2005 21:00:43 +0300 Subject: Adobe Reader 7 Message-ID: <345764DCB65C0C4FACC44529DE273C18BE6217@eemail1.microlink.lan> On Sat 4/9/2005 8:15 PM, Colin Walters wrote: > On Sat, 2005-04-09 at 07:40 +0000, Fred New wrote: > > > Is this a correct and accepted way of dealing with this without > > installing the policy sources? > > What denials were you getting? We don't presently confine user logins > with SELinux, so Adobe Reader should not have been affected. > Unfortunately, this problem seems to be "dontaudited"; I don't see anything in /var/log/messages. If I run it from a terminal, I see [fred at darth ~]$ /usr/local/Adobe/Acrobat7.0/bin/acroread /usr/local/Adobe/Acrobat7.0/Reader/intellinux/bin/acroread: error while loading shared libraries: /usr/local/Adobe/Acrobat7.0/Reader/intellinux/lib/libJP2K.so: cannot restore segment prot after reloc: Permission denied [fred at darth ~]$ But Adobe Reader runs if I go into permissive mode or if I make the context changes previously mentioned. The restorecon command leaves everything with a type of usr_t. I installed Adobe Reader by expanding the tar.gz file as a normal user and running the INSTALL script as root. Fred -------------- next part -------------- An HTML attachment was scrubbed... URL: From russell at coker.com.au Sun Apr 10 14:41:33 2005 From: russell at coker.com.au (Russell Coker) Date: Mon, 11 Apr 2005 00:41:33 +1000 Subject: Can somebody help me? In-Reply-To: <4039.128.252.85.103.1112732037.squirrel@morpheus.wustl.edu> References: <4039.128.252.85.103.1112732037.squirrel@morpheus.wustl.edu> Message-ID: <200504110041.36775.russell@coker.com.au> On Wednesday 06 April 2005 06:13, "Hongwei Li" wrote: > I just found that my fc3 system log shows many, many entries like below: > > Apr 5 14:50:42 morpheus kernel: audit(1112730642.889:0): avc: denied { > ioctl } for pid=32509 exe=/usr/bin/perl path=/proc/loadavg dev=proc > ino=-268435456 scontext=user_u:system_r:httpd_sys_script_t > tcontext=system_u:object_r:proc_t tclass=file To get an ioctl message there must already be read or write access granted. In that case adding ioctl as well won't do any harm, so just add the following to your policy source and load the new policy: allow httpd_sys_script_t:proc_t:file ioctl; We'll need to add that for FC4. -- 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 hongwei at wustl.edu Mon Apr 11 12:55:36 2005 From: hongwei at wustl.edu (Hongwei Li) Date: Mon, 11 Apr 2005 07:55:36 -0500 (CDT) Subject: Can somebody help me? In-Reply-To: <200504110041.36775.russell@coker.com.au> References: <4039.128.252.85.103.1112732037.squirrel@morpheus.wustl.edu> <200504110041.36775.russell@coker.com.au> Message-ID: <3757.128.252.85.103.1113224136.squirrel@morpheus.wustl.edu> > On Wednesday 06 April 2005 06:13, "Hongwei Li" wrote: >> I just found that my fc3 system log shows many, many entries like below: >> >> Apr 5 14:50:42 morpheus kernel: audit(1112730642.889:0): avc: denied >> { >> ioctl } for pid=32509 exe=/usr/bin/perl path=/proc/loadavg dev=proc >> ino=-268435456 scontext=user_u:system_r:httpd_sys_script_t >> tcontext=system_u:object_r:proc_t tclass=file > > To get an ioctl message there must already be read or write access > granted. > In that case adding ioctl as well won't do any harm, so just add the > following to your policy source and load the new policy: > > allow httpd_sys_script_t:proc_t:file ioctl; > > We'll need to add that for FC4. > > -- Thank you! I didn't install the source, but I will try it. Hongwei From dwalsh at redhat.com Mon Apr 11 15:25:10 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 11 Apr 2005 11:25:10 -0400 Subject: Adobe Reader 7 In-Reply-To: <345764DCB65C0C4FACC44529DE273C18BE6217@eemail1.microlink.lan> References: <345764DCB65C0C4FACC44529DE273C18BE6217@eemail1.microlink.lan> Message-ID: <425A96D6.2040907@redhat.com> Fred New wrote: > On Sat 4/9/2005 8:15 PM, Colin Walters wrote: > > On Sat, 2005-04-09 at 07:40 +0000, Fred New wrote: > > > > > Is this a correct and accepted way of dealing with this without > > > installing the policy sources? > > > > What denials were you getting? We don't presently confine user logins > > with SELinux, so Adobe Reader should not have been affected. > > > Unfortunately, this problem seems to be "dontaudited"; I don't > see anything in /var/log/messages. If I run it from a terminal, > I see > > [fred at darth ~]$ /usr/local/Adobe/Acrobat7.0/bin/acroread > /usr/local/Adobe/Acrobat7.0/Reader/intellinux/bin/acroread: error > while loading shared libraries: > /usr/local/Adobe/Acrobat7.0/Reader/intellinux/lib/libJP2K.so: cannot > restore segment prot after reloc: Permission denied > [fred at darth ~]$ > Which policy are you running rpm -q -i selinux-policy-targeted > > But Adobe Reader runs if I go into permissive mode or if I make the > context changes previously mentioned. > > The restorecon command leaves everything with a type of usr_t. > I installed Adobe Reader by expanding the tar.gz file as a normal > user and running the INSTALL script as root. > > Fred > >------------------------------------------------------------------------ > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- From Fred.New at microlink.ee Mon Apr 11 17:51:34 2005 From: Fred.New at microlink.ee (Fred New) Date: Mon, 11 Apr 2005 20:51:34 +0300 Subject: Adobe Reader 7 Message-ID: <345764DCB65C0C4FACC44529DE273C18BE621C@eemail1.microlink.lan> On Mon 4/11/2005 6:25 PM, Daniel J Walsh wrote: > Fred New wrote: > > > [fred at darth ~]$ /usr/local/Adobe/Acrobat7.0/bin/acroread > > /usr/local/Adobe/Acrobat7.0/Reader/intellinux/bin/acroread: error > > while loading shared libraries: > > /usr/local/Adobe/Acrobat7.0/Reader/intellinux/lib/libJP2K.so: cannot > > restore segment prot after reloc: Permission denied > > [fred at darth ~]$ > > > Which policy are you running > rpm -q -i selinux-policy-targeted I am running the latest policy: [fred at darth ~]$ rpm -q selinux-policy-targeted selinux-policy-targeted-1.23.9-1 [fred at darth ~]$ (I'm assuming you didn't really want the "-i" in "rpm -q -i ...".) When I originally wrote a couple days ago, I was running the previous policy, selinux-policy-targeted-1.23.8-2. So I just now deleted the /usr/local/Adobe directory and re-installed it - same results. And "restorecon /usr/local/Adobe" doesn't change anything either. I noticed when I installed selinux-policy-targeted-1.23.9-1 that the context for the Adobe Reader Firefox plugin, /usr/lib/firefox-1.0.2/plugins/nppdf.so, changed from lib_t to shlib_t. Everything in /usr/local/Adobe is still usr_t. Fred -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 2867 bytes Desc: not available URL: From dwalsh at redhat.com Mon Apr 11 18:30:53 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 11 Apr 2005 14:30:53 -0400 Subject: Adobe Reader 7 In-Reply-To: <345764DCB65C0C4FACC44529DE273C18BE621C@eemail1.microlink.lan> References: <345764DCB65C0C4FACC44529DE273C18BE621C@eemail1.microlink.lan> Message-ID: <425AC25D.3090301@redhat.com> Fred New wrote: >On Mon 4/11/2005 6:25 PM, Daniel J Walsh wrote: > > >>Fred New wrote: >> >> >> >>>[fred at darth ~]$ /usr/local/Adobe/Acrobat7.0/bin/acroread >>>/usr/local/Adobe/Acrobat7.0/Reader/intellinux/bin/acroread: error >>>while loading shared libraries: >>>/usr/local/Adobe/Acrobat7.0/Reader/intellinux/lib/libJP2K.so: cannot >>>restore segment prot after reloc: Permission denied >>>[fred at darth ~]$ >>> >>> >>> >>Which policy are you running >>rpm -q -i selinux-policy-targeted >> >> > >I am running the latest policy: > >[fred at darth ~]$ rpm -q selinux-policy-targeted >selinux-policy-targeted-1.23.9-1 >[fred at darth ~]$ > >(I'm assuming you didn't really want the "-i" in "rpm -q -i ...".) > >When I originally wrote a couple days ago, I was running the previous >policy, selinux-policy-targeted-1.23.8-2. So I just now deleted the >/usr/local/Adobe directory and re-installed it - same results. >And "restorecon /usr/local/Adobe" doesn't change anything either. > >I noticed when I installed selinux-policy-targeted-1.23.9-1 >that the context for the Adobe Reader Firefox plugin, >/usr/lib/firefox-1.0.2/plugins/nppdf.so, changed from >lib_t to shlib_t. Everything in /usr/local/Adobe is still usr_t. > > > Ok we have policy for Acrobat but not Adobe. /usr(/.*)?/Acrobat5/Reader/intellinux/plug_ins/.*\.api -- system_u:object_r:shlib_t /usr(/.*)?/Acrobat5/Reader/intellinux/plug_ins/AcroForm\.api -- system_u:object_r:texrel_shlib_t /usr(/.*)?/Acrobat5/Reader/intellinux/plug_ins/EScript\.api -- system_u:object_r:texrel_shlib_t Could you do a find /usr/local/Adobe -print and attach it? I will try to fix the file context file for it. >Fred > > >------------------------------------------------------------------------ > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- From Fred.New at microlink.ee Mon Apr 11 19:15:40 2005 From: Fred.New at microlink.ee (Fred New) Date: Mon, 11 Apr 2005 22:15:40 +0300 Subject: Adobe Reader 7 Message-ID: <345764DCB65C0C4FACC44529DE273C18BE621D@eemail1.microlink.lan> On Mon 4/11/2005 9:30 PM, Daniel J Walsh wrote: > Ok we have policy for Acrobat but not Adobe. > > /usr(/.*)?/Acrobat5/Reader/intellinux/plug_ins/.*\.api -- > system_u:object_r:shlib_t > /usr(/.*)?/Acrobat5/Reader/intellinux/plug_ins/AcroForm\.api -- > system_u:object_r:texrel_shlib_t > /usr(/.*)?/Acrobat5/Reader/intellinux/plug_ins/EScript\.api -- > system_u:object_r:texrel_shlib_t > > Could you do a find /usr/local/Adobe -print and attach it? > I will try to fix the file context file for it. Yeh, everything is under the /usr/local/Adobe/Acrobat7.0 directory. See the attached. Fred -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 4603 bytes Desc: not available URL: From dwalsh at redhat.com Mon Apr 11 19:23:09 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 11 Apr 2005 15:23:09 -0400 Subject: Adobe Reader 7 In-Reply-To: <345764DCB65C0C4FACC44529DE273C18BE621D@eemail1.microlink.lan> References: <345764DCB65C0C4FACC44529DE273C18BE621D@eemail1.microlink.lan> Message-ID: <425ACE9D.7030001@redhat.com> Fred New wrote: >On Mon 4/11/2005 9:30 PM, Daniel J Walsh wrote: > > >>Ok we have policy for Acrobat but not Adobe. >> >>/usr(/.*)?/Acrobat5/Reader/intellinux/plug_ins/.*\.api -- >>system_u:object_r:shlib_t >>/usr(/.*)?/Acrobat5/Reader/intellinux/plug_ins/AcroForm\.api -- >>system_u:object_r:texrel_shlib_t >>/usr(/.*)?/Acrobat5/Reader/intellinux/plug_ins/EScript\.api -- >>system_u:object_r:texrel_shlib_t >> >>Could you do a find /usr/local/Adobe -print and attach it? >>I will try to fix the file context file for it. >> >> > >Yeh, everything is under the /usr/local/Adobe/Acrobat7.0 directory. >See the attached. > >Fred > > Ok I installed the code and ran a restorecon -R -v /usr/local/Adobe and that fixed all of the .so and bin files. The api files need a fix in policy that will be in selinux-policy-targeted-1.23.9-2 >------------------------------------------------------------------------ > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- From mike at navi.cx Mon Apr 11 22:57:06 2005 From: mike at navi.cx (Mike Hearn) Date: Mon, 11 Apr 2005 23:57:06 +0100 Subject: Adobe Reader 7 References: <345764DCB65C0C4FACC44529DE273C18BE6217@eemail1.microlink.lan> Message-ID: On Sat, 09 Apr 2005 21:00:43 +0300, Fred New wrote: > [fred at darth ~]$ /usr/local/Adobe/Acrobat7.0/bin/acroread > /usr/local/Adobe/Acrobat7.0/Reader/intellinux/bin/acroread: error while loading shared libraries: /usr/local/Adobe/Acrobat7.0/Reader/intellinux/lib/libJP2K.so: cannot restore segment prot after reloc: Permission denied What exactly does this message mean? I'm wondering if we need to do stuff in autopackage to ensure things work correctly with SELinux. That said, I have targetted enforcing on and so far, no problems ... thanks -mike From tjikkun at xs4all.nl Tue Apr 12 00:27:22 2005 From: tjikkun at xs4all.nl (Sander Hoentjen) Date: Tue, 12 Apr 2005 02:27:22 +0200 Subject: avc: denied, aMSN Message-ID: <1113265643.3264.8.camel@CC256006-A> Hi, I get the following error in my log: audit(1113264360.332:0): avc: denied { execmod } for pid=3261 comm=wish path=/home/tjikkun/programs/amsn-extras/plugins/tls1.4/libtls1.4.so dev=hda2 ino=243257 scontext=user_u:system_r:unconfined_t tcontext=user_u:object_r:user_home_t tclass=file It happens when I try to use aMSN which in turn wants to use this lib. I am a developer of aMSN and I would really like to know what is the best way to fix it. I guess I could change my policy or something(?), but when we distribute aMSN I would like to have it working "out-of-the-box". Any ideas on how to make this happen? Thanks in advance, Sander Hoentjen From ivg2 at cornell.edu Tue Apr 12 00:51:05 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Mon, 11 Apr 2005 20:51:05 -0400 Subject: avc: denied, aMSN In-Reply-To: <1113265643.3264.8.camel@CC256006-A> References: <1113265643.3264.8.camel@CC256006-A> Message-ID: <1113267066.28958.5.camel@cobra.ivg2.net> On Tue, 2005-04-12 at 02:27 +0200, Sander Hoentjen wrote: > Hi, > > I get the following error in my log: > > audit(1113264360.332:0): avc: denied { execmod } for pid=3261 > comm=wish > path=/home/tjikkun/programs/amsn-extras/plugins/tls1.4/libtls1.4.so > dev=hda2 ino=243257 scontext=user_u:system_r:unconfined_t > tcontext=user_u:object_r:user_home_t tclass=file > > It happens when I try to use aMSN which in turn wants to use this lib. I > am a developer of aMSN and I would really like to know what is the best > way to fix it. I guess I could change my policy or something(?), but > when we distribute aMSN I would like to have it working > "out-of-the-box". Any ideas on how to make this happen? See if the library requires text relocations: readelf -d |grep TEXTREL If so, try to fix that. I'm not sure how - maybe compile with -fPIC? If it can't be fixed, it can be marked texrel_shlib_t to make it work, but the user would have to enable the allow_execmod boolean. I'm not sure if targeted policy has it enabled by default. -- Ivan Gyurdiev Cornell University From selinux at gmail.com Tue Apr 12 00:55:08 2005 From: selinux at gmail.com (Tom London) Date: Mon, 11 Apr 2005 17:55:08 -0700 Subject: cups avcs.... Message-ID: <4c4ba15305041117556e6a1a96@mail.gmail.com> Running targeted/enforcing, latest rawhide. Just noticed the following in the log: Apr 11 17:40:22 localhost kernel: audit(1113266422.034:0): avc: denied { search } for pid=2553 exe=/usr/sbin/cupsd name=dbus dev=dm-0 ino=2142154 scontext=user_u:system_r:cupsd_t tcontext=system_u:object_r:system_dbusd_var_run_t tclass=dir Apr 11 17:40:22 localhost kernel: audit(1113266422.291:0): avc: denied { search } for pid=2553 exe=/usr/sbin/cupsd name=dbus dev=dm-0 ino=2142154 scontext=user_u:system_r:cupsd_t tcontext=system_u:object_r:system_dbusd_var_run_t tclass=dir Apr 11 17:40:22 localhost kernel: audit(1113266422.295:0): avc: denied { search } for pid=2553 exe=/usr/sbin/cupsd name=dbus dev=dm-0 ino=2142154 scontext=user_u:system_r:cupsd_t tcontext=system_u:object_r:system_dbusd_var_run_t tclass=dir Apr 11 17:40:22 localhost kernel: audit(1113266422.709:0): avc: denied { search } for pid=2561 exe=/usr/lib/cups/backend/hal name=dbus dev=dm-0 ino=2142154 scontext=user_u:system_r:cupsd_t tcontext=system_u:object_r:system_dbusd_var_run_t tclass=dir or allow cupsd_t system_dbusd_var_run_t:dir search; Did something change? tom -- Tom London From selinux at gmail.com Tue Apr 12 01:04:05 2005 From: selinux at gmail.com (Tom London) Date: Mon, 11 Apr 2005 18:04:05 -0700 Subject: cups avcs.... In-Reply-To: <4c4ba15305041117556e6a1a96@mail.gmail.com> References: <4c4ba15305041117556e6a1a96@mail.gmail.com> Message-ID: <4c4ba15305041118042b098eee@mail.gmail.com> Seems to be trying to access /var/run/cupsd.pid, I think. ls -lZ /var/run/cupsd.pid: -rw-r--r-- root root user_u:object_r:cupsd_var_run_t cupsd.pid -- Tom London From selinux at gmail.com Tue Apr 12 01:06:17 2005 From: selinux at gmail.com (Tom London) Date: Mon, 11 Apr 2005 18:06:17 -0700 Subject: cups avcs.... In-Reply-To: <4c4ba15305041118042b098eee@mail.gmail.com> References: <4c4ba15305041117556e6a1a96@mail.gmail.com> <4c4ba15305041118042b098eee@mail.gmail.com> Message-ID: <4c4ba15305041118066cf24b3b@mail.gmail.com> Sorry, wrong paste... Seems to be accessing /var/run/dbus drwxr-xr-x root root system_u:object_r:system_dbusd_var_run_t dbus -- Tom London From rirving at antient.org Tue Apr 12 01:56:23 2005 From: rirving at antient.org (Richard Irving) Date: Mon, 11 Apr 2005 20:56:23 -0500 Subject: Whooops - A new kernel problem In-Reply-To: <42573A19.3010609@antient.org> References: <200503010030.j210U5el017444@mx3.redhat.com> <200504082110.54213.russell@coker.com.au> <200504081014.34761.w5set@alltel.net> <42573A19.3010609@antient.org> Message-ID: <425B2AC7.6070100@antient.org> Hey, FYI the latest and greatest kernel, FC3-2.6.11-1.14_FC3, for the i386 kernels broke several things (for me at least on a Dell Inspiron 2600).... [I am -not- seeing the same problems on the X86_64 version for an Athlon 3500+] I might suggest NOT running update for now.... YMMV. One such entry: -------------------------------------------------------------------------------------------- Apr 11 19:22:47 OCIDell audit: Installing Audit Module: Apr 11 19:22:47 OCIDell audit: insmod: can't read 'auditmodule': No such file or directory Apr 11 19:22:47 OCIDell audit: Apr 11 19:22:47 OCIDell audit: Starting /usr/sbin/auditd: Apr 11 19:22:47 OCIDell audit: SNARE audit daemon: I cannot connect to the audit module via the file /proc/audit. Audit module not yet loaded? Apr 11 19:22:47 OCIDell audit: Try installing the audit module using: insmod auditmodule: No such file or directory ---------------------------------------------------------------------------------------------- However rebooting on the Prior kernel, 2.6.10-1.770_FC3, (i386) returns everything to normal, i.e. audit works. Secondly, this kernel wacked the wireless subsystem, in some fashion. Old Kernel, "iwlist wlan0 scan" works fine, blowing the ESSID it see's. under the new kernel it gives me: "wlan0 Interface doesn't support scanning." Boot back on the old kernel, it is just working fine, including the wireless scan. I can neither confirm of deny the wireless on the X86_64, as I don't have it installed. But, I can confirm I am *not* seeing the "audit" problem with x86_64, and I am with the i386. And, the wireless, a nDis Driver, is failing miserably under the new kernel as well, but boot on the old one, and both these issues go away. So, Heads Up. It is recreatable. Richard Irving wrote: > steve wrote: > >> OH-MY, could my computer be a zombie of of NSA? > > > It could be, but if it were, _you_ would never know. ;) > >> Could I be a part of a weird plot with the NSA and Aliens using >> SELinux and parallel computing and my computer to create an >> Intelligent Supercomputer that will rule the world? > > > Shoot, Mork! we need a more subtle approach, the earthlings are > catching on! > > Nanu Nanu. > >> UHHHH--forget it--just remembered, that was the dream I had last >> night about the Dwarf blue Girl from the 7th planet of >> Zwqqvvzzz--never mind. > > > I remember her! > > Careful, she is on the rebound from James T Kirk.... > > I am not sure I would want to follow his act, > I hear James is a "High Risk" Category type... > > [ Remember, he cried like a Baby when Spock Died, 'nough said ! ] > >> Just a note to say "THANKS Guys/Girls for being here". I read a >> lot--post seldom. Still trying to figure out these "zombie" SELinux >> features-- > > > Me too, and I think the real trick is.. [the remainder of this > sentence has been > censored for your own safety, Comrade -- Zombiware (tm)] > > :O > >> but I like SELINUX. Somebody tell NSA thanks-- even though they have >> devious dark plans for protecting computer OS's. > > > Oh, no need to... you posted into -this- list. > > They are -well- aware of you, and your opinions, by now. > > Remember the TIA slogan: "In God we trust, all else we Monitor!". > > :D > > (Caution: Any similarity between this post, and reality, > is -purely- coincidental... > OK, with the exception of the Kirk-Spock thing.) > > ;) > >> On Friday April 8 2005 06:10 am, Russell Coker wrote: >> >>> On Tuesday 01 March 2005 10:54, "nanocurie" >>> wrote: >>> >>>> I just joined the list. I just downloaded and installed FC3, >>>> and noticed that it had SE-Linux installed by default. I thought >>>> okay, so >>>> the NSA now can/will take control of my secure computers. Good, if >>>> there's >>> >>> >>> The SE Linux code is clean and reasonably easy to read, it has been >>> checked >>> by many people. If you are concerned about back-doors in kernel code >>> then >>> you should be concerned about the device drivers for less popular >>> hardware >>> and other code that doesn't get much attention. > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From rirving at antient.org Tue Apr 12 02:16:47 2005 From: rirving at antient.org (Richard Irving) Date: Mon, 11 Apr 2005 21:16:47 -0500 Subject: Whooops - A new kernel problem In-Reply-To: <425B2AC7.6070100@antient.org> References: <200503010030.j210U5el017444@mx3.redhat.com> <200504082110.54213.russell@coker.com.au> <200504081014.34761.w5set@alltel.net> <42573A19.3010609@antient.org> <425B2AC7.6070100@antient.org> Message-ID: <425B2F8F.6080803@antient.org> Richard Irving wrote: > > I can neither confirm of deny the wireless on the X86_64, s/of/or/ > as I don't have it installed. From dwalsh at redhat.com Tue Apr 12 02:16:05 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 11 Apr 2005 22:16:05 -0400 Subject: Adobe Reader 7 In-Reply-To: References: <345764DCB65C0C4FACC44529DE273C18BE6217@eemail1.microlink.lan> Message-ID: <425B2F65.20601@redhat.com> Mike Hearn wrote: >On Sat, 09 Apr 2005 21:00:43 +0300, Fred New wrote: > > >>[fred at darth ~]$ /usr/local/Adobe/Acrobat7.0/bin/acroread >>/usr/local/Adobe/Acrobat7.0/Reader/intellinux/bin/acroread: error while loading shared libraries: /usr/local/Adobe/Acrobat7.0/Reader/intellinux/lib/libJP2K.so: cannot restore segment prot after reloc: Permission denied >> >> > >What exactly does this message mean? I'm wondering if we need to do stuff >in autopackage to ensure things work correctly with SELinux. > >That said, I have targetted enforcing on and so far, no problems ... > >thanks -mike > > I means that acroread was not able to execute a shared library, because it was labeled incorrectly. If you could get autopackage to automatically call restorecon on all libraries as they get installed. A better way of going would be to make it SELinux aware. The install command and rpm have the restorecon capability built into them, so the file can get created with the correct context. Dan >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- From dwalsh at redhat.com Tue Apr 12 02:31:05 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 11 Apr 2005 22:31:05 -0400 Subject: cups avcs.... In-Reply-To: <4c4ba15305041117556e6a1a96@mail.gmail.com> References: <4c4ba15305041117556e6a1a96@mail.gmail.com> Message-ID: <425B32E9.2030609@redhat.com> Tom London wrote: >Running targeted/enforcing, latest rawhide. > >Just noticed the following in the log: > >Apr 11 17:40:22 localhost kernel: audit(1113266422.034:0): avc: >denied { search } for pid=2553 exe=/usr/sbin/cupsd name=dbus >dev=dm-0 ino=2142154 scontext=user_u:system_r:cupsd_t >tcontext=system_u:object_r:system_dbusd_var_run_t tclass=dir >Apr 11 17:40:22 localhost kernel: audit(1113266422.291:0): avc: >denied { search } for pid=2553 exe=/usr/sbin/cupsd name=dbus >dev=dm-0 ino=2142154 scontext=user_u:system_r:cupsd_t >tcontext=system_u:object_r:system_dbusd_var_run_t tclass=dir >Apr 11 17:40:22 localhost kernel: audit(1113266422.295:0): avc: >denied { search } for pid=2553 exe=/usr/sbin/cupsd name=dbus >dev=dm-0 ino=2142154 scontext=user_u:system_r:cupsd_t >tcontext=system_u:object_r:system_dbusd_var_run_t tclass=dir >Apr 11 17:40:22 localhost kernel: audit(1113266422.709:0): avc: >denied { search } for pid=2561 exe=/usr/lib/cups/backend/hal >name=dbus dev=dm-0 ino=2142154 scontext=user_u:system_r:cupsd_t >tcontext=system_u:object_r:system_dbusd_var_run_t tclass=dir > >or >allow cupsd_t system_dbusd_var_run_t:dir search; > >Did something change? > >tom > > This is strange I look at my policy sources allow { cupsd_t } { var_run_t system_dbusd_var_run_t }:dir search; Are you running the latest policy? Dan -- From selinux at gmail.com Tue Apr 12 05:53:39 2005 From: selinux at gmail.com (Tom London) Date: Mon, 11 Apr 2005 22:53:39 -0700 Subject: cups avcs.... In-Reply-To: <425B32E9.2030609@redhat.com> References: <4c4ba15305041117556e6a1a96@mail.gmail.com> <425B32E9.2030609@redhat.com> Message-ID: <4c4ba153050411225317b55ffb@mail.gmail.com> On Apr 11, 2005 7:31 PM, Daniel J Walsh wrote: > This is strange I look at my policy sources > > allow { cupsd_t } { var_run_t system_dbusd_var_run_t }:dir search; > > Are you running the latest policy? > > Dan I'm running: selinux-policy-targeted-sources-1.23.9-1, and I cannot find that line in any domains/program file. Also not in policy.conf. tom -- Tom London From russell at coker.com.au Tue Apr 12 06:20:07 2005 From: russell at coker.com.au (Russell Coker) Date: Tue, 12 Apr 2005 16:20:07 +1000 Subject: mv hard drives with lvm/selinux ? In-Reply-To: References: Message-ID: <200504121620.11965.russell@coker.com.au> On Sunday 13 March 2005 02:07, Justin Conover wrote: > This kind of brings up another question, if I create a raid 5 with 3 > or 4 disk and have my system only one 1 disk, and that one disk blows > up. Will it be easy to replace that disk and see the > raid5/lvm/selinux files? Or should I take the caution and put my > system in a raid 1 too. With some effort you can have grub boot from a RAID-1 (I won't try to explain how as I'm not an expert on booting, but it's something I've done before). You may decide to use non-RAID for /boot. After the kernel and the initrd have been loaded the initrd can setup RAID so you can have LVM on software RAID for the root file system (it's even supported in Anaconda). For a serious machine there are two ways of doing it. One is to have RAID for all file systems including the root file system. The other option is to have a kickstart configuration that completely describes the configuration of the system so that the machine can easily be reinstalled at a moment's notice. For an ideal server room you would have RAID on the system partitions and swap (so that a disk dying won't cause you to do any work at 3AM), RAID for data partitions (of course!), as well as having a dedicated server for kickstart that does DHCP and has NFS read-only shares containing every version of RHEL/Fedora that you run on your network. To do this right the kickstart server would be configured to assign a particular IP address and config file to each machine based on it's MAC address so reinstalling any server could be done by merely booting from a kickstart device (either CD or USB dongle). One thing I'm working on at the moment is a document on kickstart configuration for SE Linux. -- 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.calizo at gmail.com Tue Apr 12 07:09:09 2005 From: mike.calizo at gmail.com (Michael Calizo) Date: Tue, 12 Apr 2005 15:09:09 +0800 Subject: MySQL+Selinux problem Message-ID: Hi, I have been banging my head to resolve this SELinux+MySQL problem on fedora Core 3. I followed this steps from this list:https://www.redhat.com/archives/fedora-selinux-list/2004-November/msg00015.html * Install selinux-policy-targeted-sources. * yum install selinux-policy-targeted-sources * cd /etc/selinux/targeted/src/policy * echo "allow httpd_t var_lib_t:sock_file rw_socket_perms;" > domains/program/httpd_socket.te * make load After make load i get this error: yada yada yada .... Compiling policy ... /usr/bin/checkpolicy -o /etc/selinux/strict/policy/policy.19 policy.conf /usr/bin/checkpolicy: loading policy configuration from policy.conf security: 3 users, 5 roles, 1304 types, 58 bools security: 55 classes, 388377 rules /usr/bin/checkpolicy: policy configuration loaded /usr/bin/checkpolicy: writing binary representation (version 19) to /etc/selinux/strict/policy/policy.19 /usr/bin/checkpolicy -c 18 -o /etc/selinux/strict/policy/policy.18 policy.conf /usr/bin/checkpolicy: loading policy configuration from policy.conf security: 3 users, 5 roles, 1304 types, 58 bools security: 55 classes, 388377 rules /usr/bin/checkpolicy: policy configuration loaded /usr/bin/checkpolicy: writing binary representation (version 18) to /etc/selinux/strict/policy/policy.18 make: *** No rule to make target `file_contexts/program/httpd_socket.fc', needed by `file_contexts/file_contexts'. Stop. Im stuck with this error and i dont know what to do next. Any insights are welcome and appreciated. Thank you very much. -- Mike Calizo Registered Linux User # 365113 _________________________________________________ Even the longest journey has to start with a small first-step From tjikkun at xs4all.nl Tue Apr 12 07:45:35 2005 From: tjikkun at xs4all.nl (Sander Hoentjen) Date: Tue, 12 Apr 2005 09:45:35 +0200 Subject: avc: denied, aMSN In-Reply-To: <1113267066.28958.5.camel@cobra.ivg2.net> References: <1113265643.3264.8.camel@CC256006-A> <1113267066.28958.5.camel@cobra.ivg2.net> Message-ID: <1113291936.3264.12.camel@CC256006-A> On Mon, 2005-04-11 at 20:51 -0400, Ivan Gyurdiev wrote: > On Tue, 2005-04-12 at 02:27 +0200, Sander Hoentjen wrote: > > Hi, > > > > I get the following error in my log: > > > > audit(1113264360.332:0): avc: denied { execmod } for pid=3261 > > comm=wish > > path=/home/tjikkun/programs/amsn-extras/plugins/tls1.4/libtls1.4.so > > dev=hda2 ino=243257 scontext=user_u:system_r:unconfined_t > > tcontext=user_u:object_r:user_home_t tclass=file > > > > It happens when I try to use aMSN which in turn wants to use this lib. I > > am a developer of aMSN and I would really like to know what is the best > > way to fix it. I guess I could change my policy or something(?), but > > when we distribute aMSN I would like to have it working > > "out-of-the-box". Any ideas on how to make this happen? > > See if the library requires text relocations: > readelf -d |grep TEXTREL > > If so, try to fix that. I'm not sure how - maybe compile with -fPIC? Thanks a lot. I found that it indeed had TEXTREL. I downloaded a newer version and this one didn't have TEXTREL. Now it works without problems. Sander From sds at tycho.nsa.gov Tue Apr 12 12:23:58 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 12 Apr 2005 08:23:58 -0400 Subject: MySQL+Selinux problem In-Reply-To: References: Message-ID: <1113308638.25217.34.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-04-12 at 15:09 +0800, Michael Calizo wrote: > Hi, > > I have been banging my head to resolve this SELinux+MySQL problem on > fedora Core 3. > > I followed this steps from this > list:https://www.redhat.com/archives/fedora-selinux-list/2004-November/msg00015.html > > * Install selinux-policy-targeted-sources. > * yum install selinux-policy-targeted-sources > * cd /etc/selinux/targeted/src/policy > * echo "allow httpd_t var_lib_t:sock_file rw_socket_perms;" > > domains/program/httpd_socket.te > * make load > > After make load i get this error: > yada yada yada .... > Compiling policy ... > /usr/bin/checkpolicy -o /etc/selinux/strict/policy/policy.19 policy.conf > /usr/bin/checkpolicy: loading policy configuration from policy.conf > security: 3 users, 5 roles, 1304 types, 58 bools > security: 55 classes, 388377 rules > /usr/bin/checkpolicy: policy configuration loaded > /usr/bin/checkpolicy: writing binary representation (version 19) to > /etc/selinux/strict/policy/policy.19 > /usr/bin/checkpolicy -c 18 -o /etc/selinux/strict/policy/policy.18 policy.conf > /usr/bin/checkpolicy: loading policy configuration from policy.conf > security: 3 users, 5 roles, 1304 types, 58 bools > security: 55 classes, 388377 rules > /usr/bin/checkpolicy: policy configuration loaded > /usr/bin/checkpolicy: writing binary representation (version 18) to > /etc/selinux/strict/policy/policy.18 > make: *** No rule to make target > `file_contexts/program/httpd_socket.fc', needed by > `file_contexts/file_contexts'. Stop. > > Im stuck with this error and i dont know what to do next. Any insights > are welcome and appreciated. The policy Makefile expects a .fc file to exist for every .te file under domains/program. Hence, you have two choices: 1) Move httpd_socket.te from domains/program to domains/misc. This is preferable anyway, and convention has been to put such rules in domains/misc/local.te to reduce the risk that your file will ever conflict with a file in the main policy package. -or- 2) Leave httpd_socket.te under domains/program but touch file_contexts/program/httpd_socket.fc, creating an empty file with that name to satisfy the policy Makefile. I'd favor #1. -- Stephen Smalley National Security Agency From justin.conover at gmail.com Tue Apr 12 14:11:11 2005 From: justin.conover at gmail.com (Justin Conover) Date: Tue, 12 Apr 2005 09:11:11 -0500 Subject: mv hard drives with lvm/selinux ? In-Reply-To: <200504121620.11965.russell@coker.com.au> References: <200504121620.11965.russell@coker.com.au> Message-ID: On Apr 12, 2005 1:20 AM, Russell Coker wrote: > On Sunday 13 March 2005 02:07, Justin Conover > wrote: > > This kind of brings up another question, if I create a raid 5 with 3 > > or 4 disk and have my system only one 1 disk, and that one disk blows > > up. Will it be easy to replace that disk and see the > > raid5/lvm/selinux files? Or should I take the caution and put my > > system in a raid 1 too. > > With some effort you can have grub boot from a RAID-1 (I won't try to explain > how as I'm not an expert on booting, but it's something I've done before). > > You may decide to use non-RAID for /boot. After the kernel and the initrd > have been loaded the initrd can setup RAID so you can have LVM on software > RAID for the root file system (it's even supported in Anaconda). > > For a serious machine there are two ways of doing it. One is to have RAID for > all file systems including the root file system. The other option is to have > a kickstart configuration that completely describes the configuration of the > system so that the machine can easily be reinstalled at a moment's notice. > > For an ideal server room you would have RAID on the system partitions and swap > (so that a disk dying won't cause you to do any work at 3AM), RAID for data > partitions (of course!), as well as having a dedicated server for kickstart > that does DHCP and has NFS read-only shares containing every version of > RHEL/Fedora that you run on your network. To do this right the kickstart > server would be configured to assign a particular IP address and config file > to each machine based on it's MAC address so reinstalling any server could be > done by merely booting from a kickstart device (either CD or USB dongle). > > One thing I'm working on at the moment is a document on kickstart > configuration for SE Linux. > > -- > 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 > Kickstart for SELInux would be great :D I did get the box up with 2x40GB drives fro /boot everything else under /lvm with seperate slices in raid 1 and 4x160GB drives in a raid 5 for /home From dwalsh at redhat.com Tue Apr 12 14:28:33 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 12 Apr 2005 10:28:33 -0400 Subject: MySQL+Selinux problem In-Reply-To: <1113308638.25217.34.camel@moss-spartans.epoch.ncsc.mil> References: <1113308638.25217.34.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <425BDB11.5050702@redhat.com> Stephen Smalley wrote: >On Tue, 2005-04-12 at 15:09 +0800, Michael Calizo wrote: > > >>Hi, >> >>I have been banging my head to resolve this SELinux+MySQL problem on >>fedora Core 3. >> >>I followed this steps from this >>list:https://www.redhat.com/archives/fedora-selinux-list/2004-November/msg00015.html >> >> * Install selinux-policy-targeted-sources. >> * yum install selinux-policy-targeted-sources >> * cd /etc/selinux/targeted/src/policy >> * echo "allow httpd_t var_lib_t:sock_file rw_socket_perms;" > >> domains/program/httpd_socket.te >> * make load >> >>After make load i get this error: >>yada yada yada .... >>Compiling policy ... >>/usr/bin/checkpolicy -o /etc/selinux/strict/policy/policy.19 policy.conf >>/usr/bin/checkpolicy: loading policy configuration from policy.conf >>security: 3 users, 5 roles, 1304 types, 58 bools >>security: 55 classes, 388377 rules >>/usr/bin/checkpolicy: policy configuration loaded >>/usr/bin/checkpolicy: writing binary representation (version 19) to >>/etc/selinux/strict/policy/policy.19 >>/usr/bin/checkpolicy -c 18 -o /etc/selinux/strict/policy/policy.18 policy.conf >>/usr/bin/checkpolicy: loading policy configuration from policy.conf >>security: 3 users, 5 roles, 1304 types, 58 bools >>security: 55 classes, 388377 rules >>/usr/bin/checkpolicy: policy configuration loaded >>/usr/bin/checkpolicy: writing binary representation (version 18) to >>/etc/selinux/strict/policy/policy.18 >>make: *** No rule to make target >>`file_contexts/program/httpd_socket.fc', needed by >>`file_contexts/file_contexts'. Stop. >> >>Im stuck with this error and i dont know what to do next. Any insights >>are welcome and appreciated. >> >> > >The policy Makefile expects a .fc file to exist for every .te file under >domains/program. Hence, you have two choices: >1) Move httpd_socket.te from domains/program to domains/misc. This is >preferable anyway, and convention has been to put such rules in >domains/misc/local.te to reduce the risk that your file will ever >conflict with a file in the main policy package. -or- >2) Leave httpd_socket.te under domains/program but touch >file_contexts/program/httpd_socket.fc, creating an empty file with that >name to satisfy the policy Makefile. > >I'd favor #1. > > > Have you updated to the latest policy available for FC3. This problem I believe has been fixed for a long time. Dan -- From mike at navi.cx Tue Apr 12 15:14:55 2005 From: mike at navi.cx (Mike Hearn) Date: Tue, 12 Apr 2005 16:14:55 +0100 Subject: Adobe Reader 7 References: <345764DCB65C0C4FACC44529DE273C18BE6217@eemail1.microlink.lan> <425B2F65.20601@redhat.com> Message-ID: On Mon, 11 Apr 2005 22:16:05 -0400, Daniel J Walsh wrote: > I means that acroread was not able to execute a shared library, because > it was labeled incorrectly. If you could get autopackage to > automatically call restorecon on all libraries as they get installed. A > better way of going would be to make it SELinux aware. The install > command and rpm have the restorecon capability built into them, so the > file can get created with the correct context. Yep, we have SELinux awareness on the TODO list. Right now I'm thinking of something that could go into a bugfix release (so minimal impact). The install program is a part of coreutils, so the best solution is probably to use that for now. Then we can have explicit labelling later. One question: autopackage knows about the types of files (eg, executable, shared library, man pages, info pages etc) - does it make sense to automatically assign contexts based on that? If you do a "make install prefix=/tmp/foo", do the files in /tmp/foo get given the right contexts by the install program automatically? If so then I guess just ensuring the contexts survive the packaging process would be enough, rather than relabelling on the end users system. The other concern I have is whether distributions policies will be compatible enough, eg if one distro calls it shlib_t and another calls it elfdso_t. It doesn't seem to be a problem right now, but in future ... thanks -mike From dwalsh at redhat.com Tue Apr 12 15:33:12 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 12 Apr 2005 11:33:12 -0400 Subject: Adobe Reader 7 In-Reply-To: References: <345764DCB65C0C4FACC44529DE273C18BE6217@eemail1.microlink.lan> <425B2F65.20601@redhat.com> Message-ID: <425BEA38.10307@redhat.com> Mike Hearn wrote: >On Mon, 11 Apr 2005 22:16:05 -0400, Daniel J Walsh wrote: > > >>I means that acroread was not able to execute a shared library, because >>it was labeled incorrectly. If you could get autopackage to >>automatically call restorecon on all libraries as they get installed. A >>better way of going would be to make it SELinux aware. The install >>command and rpm have the restorecon capability built into them, so the >>file can get created with the correct context. >> >> > >Yep, we have SELinux awareness on the TODO list. Right now I'm thinking of >something that could go into a bugfix release (so minimal impact). > >The install program is a part of coreutils, so the best solution is >probably to use that for now. Then we can have explicit labelling later. > >One question: autopackage knows about the types of files (eg, executable, >shared library, man pages, info pages etc) - does it make sense to >automatically assign contexts based on that? > >If you do a "make install prefix=/tmp/foo", do the files in /tmp/foo get >given the right contexts by the install program automatically? If so then >I guess just ensuring the contexts survive the packaging process would be >enough, rather than relabelling on the end users system. > >The other concern I have is whether distributions policies will be >compatible enough, eg if one distro calls it shlib_t and another calls it >elfdso_t. It doesn't seem to be a problem right now, but in future ... > > > Yes the Fedora Install program will call matchpathcon which reads the currently installed "file context" file so the files will get labeled correctly. As you point out knowing a file is a shared library does not necessarily indicate which context to use. Using install would probably be your best solution. >thanks -mike > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- From mike at navi.cx Tue Apr 12 17:50:40 2005 From: mike at navi.cx (Mike Hearn) Date: Tue, 12 Apr 2005 18:50:40 +0100 Subject: Adobe Reader 7 References: <345764DCB65C0C4FACC44529DE273C18BE6217@eemail1.microlink.lan> <425B2F65.20601@redhat.com> <425BEA38.10307@redhat.com> Message-ID: On Tue, 12 Apr 2005 11:33:12 -0400, Daniel J Walsh wrote: > Yes the Fedora Install program will call matchpathcon which reads the > currently installed "file context" file so the files will get labeled > correctly. Right, for now that's the best solution. In the past Steven Smalley said that security by pathnames was considered harmful though :) As you can install an autopackage to any prefix (so to $HOME/.local or /opt or even /Applications) I'm thinking it'd be better to do it explicitly in a future version. thanks -mike From russell at coker.com.au Tue Apr 12 17:49:43 2005 From: russell at coker.com.au (Russell Coker) Date: Wed, 13 Apr 2005 03:49:43 +1000 Subject: converting between strict and targeted Message-ID: <200504130349.46161.russell@coker.com.au> When I install FC4T2 and convert it to strict policy I get a huge number of AVC messages related to setfiles running in domain initrc_t. It seems that the solution to this problem when converting from targeted to strict is to have the following in setfiles.te: ifdef(`distro_redhat', ` domain_auto_trans(initrc_t, setfiles_exec_t, setfiles_t) ') We already have can_setenforce(initrc_t) in initrc.te so this isn't really granting any extra access. In the targeted policy we need to have definitions of all the types that are used before /.autorelabel is checked. I have attached an archive of the policy necessary in targeted to make the conversion to strict run smoothly. Note that it only adds 9 aliases and 46 lines of file context so it won't have any noticable overhead when using targeted policy, but it will make things quite a bit nicer when converting from targeted to strict. While the AVC messages don't really do any harm, it will give less annoyance and confusion for users to have them gone. Incidentally for my testing I've relabeled the system in enforcing mode and had it work fine. We can't do this in production because in some situations a relabel operation will be because of the configuration of the machine being badly messed up, enough so that it may not be possible to relabel in enforcing mode. Incidentally I've just filed a bugzilla requesting that there be a "autorelabel" option for the kernel command line to give the same results as a /.autorelabel file. That saves booting a messed up machine in permissive mode for the purpose of creating the file. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154496 -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: t.tgz Type: application/x-tgz Size: 671 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Tue Apr 12 18:10:35 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 12 Apr 2005 14:10:35 -0400 Subject: genhomedircon flakyness Message-ID: <200504121810.j3CIAZ0n017370@turing-police.cc.vt.edu> Running fedora-devel tree as of last night, and I'm hitting an oddness. Basic problem: I add a user to /etc/selinux/strict/users/local.users, and at some later point I run 'make' in /etc/selinux/strict/src/policy. After that, genhomedircon barfs because it sees lines like: /home/valdis -d valdis:object_r:staff_home_dir_t in contexts/files/file_contexts.homedirs. However, since it just built the policy using the 'users' file from src/policy/users, that 'user valdis' line isn't there, so the context is invalid.... Does src/policy/Makefile need a ruleset to regenerate its copy of the 'users' file? users: $(USERPATH)/system.users $(USERPATH)/local.users cat $(USERPATH)/system.users $(USERPATH)/local.users > users (Actually, that won't work, as $(USERPATH)/system.users has a dependency on $(USER_FILES), so a more sophisticated solution is needed... -------------- 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 Tue Apr 12 18:15:40 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 12 Apr 2005 14:15:40 -0400 Subject: cups avcs.... In-Reply-To: <4c4ba153050411225317b55ffb@mail.gmail.com> References: <4c4ba15305041117556e6a1a96@mail.gmail.com> <425B32E9.2030609@redhat.com> <4c4ba153050411225317b55ffb@mail.gmail.com> Message-ID: <425C104C.2090105@redhat.com> Tom London wrote: >On Apr 11, 2005 7:31 PM, Daniel J Walsh wrote: > > >>This is strange I look at my policy sources >> >>allow { cupsd_t } { var_run_t system_dbusd_var_run_t }:dir search; >> >>Are you running the latest policy? >> >>Dan >> >> > >I'm running: selinux-policy-targeted-sources-1.23.9-1, and I cannot >find that line in any domains/program file. Also not in policy.conf. > >tom > > > > My mistake. I had dbus.te in my domains/program directory but not in the spec file. selinux-policy-targeted-1.23.10-3 has the fix. -- From sjoerd at acm.org Tue Apr 12 18:53:45 2005 From: sjoerd at acm.org (Sjoerd Mullender) Date: Tue, 12 Apr 2005 20:53:45 +0200 Subject: SELinux not enabled Message-ID: <425C1939.1080409@acm.org> I have a problem getting SELinux to work on my fully up-to-date FC3 system. Here is some relevant output: # ls -l /etc/sysconfig/selinux lrwxrwxrwx 1 root root 19 Apr 12 08:33 /etc/sysconfig/selinux -> /etc/selinux/config # grep -v ^# /etc/selinux/config SELINUX=permissive SELINUXTYPE=targeted # rpm -qa '*policy*' policycoreutils-1.18.1-2.10 selinux-policy-targeted-1.17.30-2.96 # rpm -q kernel kernel-2.6.11-1.14_FC3 # sestatus SELinux status: disabled # dmesg | grep -i selinux SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability SELinux: Registering netfilter hooks # setenforce Permissive setenforce: SELinux is disabled Note that there is a lot of stuff missing from the dmesg output (I compared this with a system where it does work). What I have understood from the FAQ and the config file, all I need to do to get SELinux to work (initially in permissive mode) is set the two values in /etc/selinux/config and then reboot. This I have done. Is there any other file that might interfere? The system was upgraded all the way from at least RedHat 9 via FC1 and FC2 (and various FC1 tests). I have only recently installed the SELinux stuff. -- Sjoerd Mullender -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3931 bytes Desc: S/MIME Cryptographic Signature URL: From sds at tycho.nsa.gov Tue Apr 12 18:59:00 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 12 Apr 2005 14:59:00 -0400 Subject: SELinux not enabled In-Reply-To: <425C1939.1080409@acm.org> References: <425C1939.1080409@acm.org> Message-ID: <1113332340.25217.207.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-04-12 at 20:53 +0200, Sjoerd Mullender wrote: > # dmesg | grep -i selinux > SELinux: Initializing. > SELinux: Starting in permissive mode > selinux_register_security: Registering secondary module capability > SELinux: Registering netfilter hooks > # setenforce Permissive > setenforce: SELinux is disabled > > Note that there is a lot of stuff missing from the dmesg output (I > compared this with a system where it does work). This suggests that policy was never loaded by /sbin/init. What is in /etc/selinux/targeted/policy? Can you load it by hand, i.e. /usr/sbin/load_policy /etc/selinux/targeted/policy/policy.? -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Tue Apr 12 19:04:20 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 12 Apr 2005 15:04:20 -0400 Subject: genhomedircon flakyness In-Reply-To: <200504121810.j3CIAZ0n017370@turing-police.cc.vt.edu> References: <200504121810.j3CIAZ0n017370@turing-police.cc.vt.edu> Message-ID: <1113332660.25217.212.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-04-12 at 14:10 -0400, Valdis.Kletnieks at vt.edu wrote: > Running fedora-devel tree as of last night, and I'm hitting an oddness. > > Basic problem: I add a user to /etc/selinux/strict/users/local.users, > and at some later point I run 'make' in /etc/selinux/strict/src/policy. > After that, genhomedircon barfs because it sees lines like: > > /home/valdis -d valdis:object_r:staff_home_dir_t > > in contexts/files/file_contexts.homedirs. However, since it just built the > policy using the 'users' file from src/policy/users, that 'user valdis' > line isn't there, so the context is invalid.... > > Does src/policy/Makefile need a ruleset to regenerate its copy of the 'users' file? > > users: $(USERPATH)/system.users $(USERPATH)/local.users > cat $(USERPATH)/system.users $(USERPATH)/local.users > users > > (Actually, that won't work, as $(USERPATH)/system.users has a dependency > on $(USER_FILES), so a more sophisticated solution is needed... No, you don't want to pull in the locally customized users into the source tree or policy build; they are incorporated into the policy load automatically via sepol_genusers(3) by load_policy and /sbin/init. Hmm..we specifically disabled checking of file_contexts.homedirs by the setfiles -c validation performed by the policy Makefile, but then added it back again to genhomedircon for runtime updates. But that makes no sense, as the binary policy file doesn't have the user identities. Mea culpa. Option are 1) strip the setfiles -c validation from genhomedircon, or 2) have genhomedircon build a temporary binary policy file via genpolusers that includes the full set of user identities and apply setfiles -c using that file. -- Stephen Smalley National Security Agency From sjoerd at acm.org Tue Apr 12 19:13:23 2005 From: sjoerd at acm.org (Sjoerd Mullender) Date: Tue, 12 Apr 2005 21:13:23 +0200 Subject: SELinux not enabled In-Reply-To: <1113332340.25217.207.camel@moss-spartans.epoch.ncsc.mil> References: <425C1939.1080409@acm.org> <1113332340.25217.207.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <425C1DD3.6080205@acm.org> Stephen Smalley wrote: > On Tue, 2005-04-12 at 20:53 +0200, Sjoerd Mullender wrote: > >># dmesg | grep -i selinux >>SELinux: Initializing. >>SELinux: Starting in permissive mode >>selinux_register_security: Registering secondary module capability >>SELinux: Registering netfilter hooks >># setenforce Permissive >>setenforce: SELinux is disabled >> >>Note that there is a lot of stuff missing from the dmesg output (I >>compared this with a system where it does work). > > > This suggests that policy was never loaded by /sbin/init. What is > in /etc/selinux/targeted/policy? Can you load it by hand, > i.e. /usr/sbin/load_policy /etc/selinux/targeted/policy/policy.? > No: # /usr/sbin/load_policy /etc/selinux/targeted/policy/policy.18 load_policy: booleans.c:48: security_get_boolean_names: Assertion `selinux_mnt' failed. Aborted -- Sjoerd Mullender -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3931 bytes Desc: S/MIME Cryptographic Signature URL: From sds at tycho.nsa.gov Tue Apr 12 19:08:05 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 12 Apr 2005 15:08:05 -0400 Subject: SELinux not enabled In-Reply-To: <425C1DD3.6080205@acm.org> References: <425C1939.1080409@acm.org> <1113332340.25217.207.camel@moss-spartans.epoch.ncsc.mil> <425C1DD3.6080205@acm.org> Message-ID: <1113332885.25217.217.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-04-12 at 21:13 +0200, Sjoerd Mullender wrote: > No: > # /usr/sbin/load_policy /etc/selinux/targeted/policy/policy.18 > load_policy: booleans.c:48: security_get_boolean_names: Assertion > `selinux_mnt' failed. > Aborted That suggests that /sbin/init didn't mount /selinux either. Try: mount -t selinuxfs none /selinux Then try running load_policy again. /sbin/init is supposed to handle all of that for you. -- Stephen Smalley National Security Agency From sjoerd at acm.org Tue Apr 12 19:22:35 2005 From: sjoerd at acm.org (Sjoerd Mullender) Date: Tue, 12 Apr 2005 21:22:35 +0200 Subject: SELinux not enabled In-Reply-To: <1113332885.25217.217.camel@moss-spartans.epoch.ncsc.mil> References: <425C1939.1080409@acm.org> <1113332340.25217.207.camel@moss-spartans.epoch.ncsc.mil> <425C1DD3.6080205@acm.org> <1113332885.25217.217.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <425C1FFB.6020508@acm.org> Stephen Smalley wrote: > On Tue, 2005-04-12 at 21:13 +0200, Sjoerd Mullender wrote: > >>No: >># /usr/sbin/load_policy /etc/selinux/targeted/policy/policy.18 >>load_policy: booleans.c:48: security_get_boolean_names: Assertion >>`selinux_mnt' failed. >>Aborted > > > That suggests that /sbin/init didn't mount /selinux either. > Try: > mount -t selinuxfs none /selinux > Then try running load_policy again. > > /sbin/init is supposed to handle all of that for you. > This works better. I had to create /selinux first: # mount -t selinuxfs none /selinux mount: mount point /selinux does not exist # mkdir /selinux # mount -t selinuxfs none /selinux # /usr/sbin/load_policy /etc/selinux/targeted/policy/policy.18 /usr/sbin/load_policy: Warning! Error while getting boolean names: Success Could that have been the problem (/selinux not being there)? -- Sjoerd Mullender -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3931 bytes Desc: S/MIME Cryptographic Signature URL: From sds at tycho.nsa.gov Tue Apr 12 19:15:38 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 12 Apr 2005 15:15:38 -0400 Subject: SELinux not enabled In-Reply-To: <1113332885.25217.217.camel@moss-spartans.epoch.ncsc.mil> References: <425C1939.1080409@acm.org> <1113332340.25217.207.camel@moss-spartans.epoch.ncsc.mil> <425C1DD3.6080205@acm.org> <1113332885.25217.217.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1113333338.25217.219.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-04-12 at 15:08 -0400, Stephen Smalley wrote: > On Tue, 2005-04-12 at 21:13 +0200, Sjoerd Mullender wrote: > > No: > > # /usr/sbin/load_policy /etc/selinux/targeted/policy/policy.18 > > load_policy: booleans.c:48: security_get_boolean_names: Assertion > > `selinux_mnt' failed. > > Aborted > > That suggests that /sbin/init didn't mount /selinux either. > Try: > mount -t selinuxfs none /selinux > Then try running load_policy again. > > /sbin/init is supposed to handle all of that for you. Also, rpm -q libsepol libselinux SysVinit -- Stephen Smalley National Security Agency From sjoerd at acm.org Tue Apr 12 19:25:38 2005 From: sjoerd at acm.org (Sjoerd Mullender) Date: Tue, 12 Apr 2005 21:25:38 +0200 Subject: SELinux not enabled In-Reply-To: <1113333338.25217.219.camel@moss-spartans.epoch.ncsc.mil> References: <425C1939.1080409@acm.org> <1113332340.25217.207.camel@moss-spartans.epoch.ncsc.mil> <425C1DD3.6080205@acm.org> <1113332885.25217.217.camel@moss-spartans.epoch.ncsc.mil> <1113333338.25217.219.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <425C20B2.801@acm.org> Stephen Smalley wrote: > On Tue, 2005-04-12 at 15:08 -0400, Stephen Smalley wrote: > >>On Tue, 2005-04-12 at 21:13 +0200, Sjoerd Mullender wrote: >> >>>No: >>># /usr/sbin/load_policy /etc/selinux/targeted/policy/policy.18 >>>load_policy: booleans.c:48: security_get_boolean_names: Assertion >>>`selinux_mnt' failed. >>>Aborted >> >>That suggests that /sbin/init didn't mount /selinux either. >>Try: >> mount -t selinuxfs none /selinux >>Then try running load_policy again. >> >>/sbin/init is supposed to handle all of that for you. > > > Also, rpm -q libsepol libselinux SysVinit > # rpm -q libsepol libselinux SysVinit libsepol-1.1.1-2 libselinux-1.19.1-8 SysVinit-2.85-34 -- Sjoerd Mullender -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3931 bytes Desc: S/MIME Cryptographic Signature URL: From sds at tycho.nsa.gov Tue Apr 12 19:19:38 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 12 Apr 2005 15:19:38 -0400 Subject: SELinux not enabled In-Reply-To: <425C1FFB.6020508@acm.org> References: <425C1939.1080409@acm.org> <1113332340.25217.207.camel@moss-spartans.epoch.ncsc.mil> <425C1DD3.6080205@acm.org> <1113332885.25217.217.camel@moss-spartans.epoch.ncsc.mil> <425C1FFB.6020508@acm.org> Message-ID: <1113333578.25217.224.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-04-12 at 21:22 +0200, Sjoerd Mullender wrote: > This works better. I had to create /selinux first: > # mount -t selinuxfs none /selinux > mount: mount point /selinux does not exist > # mkdir /selinux > # mount -t selinuxfs none /selinux > # /usr/sbin/load_policy /etc/selinux/targeted/policy/policy.18 > /usr/sbin/load_policy: Warning! Error while getting boolean names: > Success > > Could that have been the problem (/selinux not being there)? Yes. Looking at the /sbin/init code, it should have logged a 'Failed to mount /selinux: ' message. Although it may have been too early to be captured. Normally, /selinux is created by the installer, but since you upgraded... -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Tue Apr 12 19:22:06 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 12 Apr 2005 15:22:06 -0400 Subject: SELinux not enabled In-Reply-To: <1113333578.25217.224.camel@moss-spartans.epoch.ncsc.mil> References: <425C1939.1080409@acm.org> <1113332340.25217.207.camel@moss-spartans.epoch.ncsc.mil> <425C1DD3.6080205@acm.org> <1113332885.25217.217.camel@moss-spartans.epoch.ncsc.mil> <425C1FFB.6020508@acm.org> <1113333578.25217.224.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1113333726.25217.226.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-04-12 at 15:19 -0400, Stephen Smalley wrote: > Yes. Looking at the /sbin/init code, it should have logged a 'Failed to > mount /selinux: ' message. Although it may have been too > early to be captured. Normally, /selinux is created by the installer, > but since you upgraded... BTW, you now need to run /sbin/fixfiles relabel to assign security labels to your filesystems. That is normally done during installation, again, but since you upgraded, you have to do it manually. -- Stephen Smalley National Security Agency From sjoerd at acm.org Tue Apr 12 19:46:02 2005 From: sjoerd at acm.org (Sjoerd Mullender) Date: Tue, 12 Apr 2005 21:46:02 +0200 Subject: SELinux not enabled In-Reply-To: <1113333726.25217.226.camel@moss-spartans.epoch.ncsc.mil> References: <425C1939.1080409@acm.org> <1113332340.25217.207.camel@moss-spartans.epoch.ncsc.mil> <425C1DD3.6080205@acm.org> <1113332885.25217.217.camel@moss-spartans.epoch.ncsc.mil> <425C1FFB.6020508@acm.org> <1113333578.25217.224.camel@moss-spartans.epoch.ncsc.mil> <1113333726.25217.226.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <425C257A.9010004@acm.org> Stephen Smalley wrote: > On Tue, 2005-04-12 at 15:19 -0400, Stephen Smalley wrote: > >>Yes. Looking at the /sbin/init code, it should have logged a 'Failed to >>mount /selinux: ' message. Although it may have been too >>early to be captured. Normally, /selinux is created by the installer, >>but since you upgraded... > > > BTW, you now need to run /sbin/fixfiles relabel to assign security > labels to your filesystems. That is normally done during installation, > again, but since you upgraded, you have to do it manually. > I rebooted, and all is well now. SELinux is enabled, and since I had created /.autorelabel when I started experimenting, the file system is now also relabeled. Thanks for the help. -- Sjoerd Mullender -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3931 bytes Desc: S/MIME Cryptographic Signature URL: From Valdis.Kletnieks at vt.edu Tue Apr 12 20:16:40 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 12 Apr 2005 16:16:40 -0400 Subject: genhomedircon flakyness In-Reply-To: Your message of "Tue, 12 Apr 2005 15:04:20 EDT." <1113332660.25217.212.camel@moss-spartans.epoch.ncsc.mil> References: <200504121810.j3CIAZ0n017370@turing-police.cc.vt.edu> <1113332660.25217.212.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200504122016.j3CKGeCV022918@turing-police.cc.vt.edu> On Tue, 12 Apr 2005 15:04:20 EDT, Stephen Smalley said: > No, you don't want to pull in the locally customized users into the > source tree or policy build; they are incorporated into the policy load > automatically via sepol_genusers(3) by load_policy and /sbin/init. OK... > Hmm..we specifically disabled checking of file_contexts.homedirs by the > setfiles -c validation performed by the policy Makefile, but then added > it back again to genhomedircon for runtime updates. But that makes no > sense, as the binary policy file doesn't have the user identities. Mea > culpa. Option are 1) strip the setfiles -c validation from > genhomedircon, or 2) have genhomedircon build a temporary binary policy > file via genpolusers that includes the full set of user identities and > apply setfiles -c using that file. Well.. assuming (hah!) that the current policy load has the right user list in it (i.e. that seuser or similar tools have kept things up to date), there's no real reason for the -c in "normal production" use. Do we ever need to run genhomedircon against a non-loaded policy (major upgrades like FC3->FC4 where we're booted of a CD, or an RPM upgrade of one of the SELinux tools where we need to get ducks lined up in an RPM pre/post scriptlet)? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From mike at navi.cx Tue Apr 12 20:36:08 2005 From: mike at navi.cx (Mike Hearn) Date: Tue, 12 Apr 2005 21:36:08 +0100 Subject: Adobe Reader 7 References: <345764DCB65C0C4FACC44529DE273C18BE6217@eemail1.microlink.lan> <425B2F65.20601@redhat.com> <425BEA38.10307@redhat.com> Message-ID: On Tue, 12 Apr 2005 11:33:12 -0400, Daniel J Walsh wrote: > Yes the Fedora Install program will call matchpathcon which reads the > currently installed "file context" file so the files will get labeled > correctly. Oh one other thing, do other distros that are integrating SELinux patch install in the same way? Or is that a Fedora specific feature? thanks -mike From dwalsh at redhat.com Tue Apr 12 21:40:24 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 12 Apr 2005 17:40:24 -0400 Subject: Adobe Reader 7 In-Reply-To: References: <345764DCB65C0C4FACC44529DE273C18BE6217@eemail1.microlink.lan> <425B2F65.20601@redhat.com> <425BEA38.10307@redhat.com> Message-ID: <425C4048.3050005@redhat.com> Mike Hearn wrote: >On Tue, 12 Apr 2005 11:33:12 -0400, Daniel J Walsh wrote: > > >>Yes the Fedora Install program will call matchpathcon which reads the >>currently installed "file context" file so the files will get labeled >>correctly. >> >> > >Oh one other thing, do other distros that are integrating SELinux patch >install in the same way? Or is that a Fedora specific feature? > >thanks -mike > > > > There are other distros besides Fedora and RHEL???? :^) I am not sure. A lot of the other distros have picked up my patches. Dan >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- From mailing.lists.jdueitt at gmail.com Wed Apr 13 03:04:14 2005 From: mailing.lists.jdueitt at gmail.com (Jerry Dueitt) Date: Tue, 12 Apr 2005 22:04:14 -0500 Subject: SVN + SELinux + Apache == Problems Message-ID: <77958214050412200411cce394@mail.gmail.com> I have been trying to get a SVN repository set up for access via the DAV module. I have read that you need to do various things to get this to work on a Fedora Core 3 system. My repository lives in /projects/svn-repos/ which is a local filesystem. I have changed group and owner to apache for all files in that directory with chown -R apache.apache /projects/svn-repos. This obviously didn't work due to SELinux security contexts. I found online that I needed to do chcon -R -h -t httpd_sys_content_t /projects/svn-repos. I still get the following errors in my /var/log/mesages: Apr 12 21:50:39 fry kernel: audit(1113360639.475:0): avc: denied { search } for pid=7147 exe=/usr/sbin/httpd name=/ dev=dm-2 ino=2 scontext=root:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=dir the errors in /var/log/httpd/error_log are like: [Tue Apr 12 22:03:03 2005] [error] [client 10.3.1.105] (20014)Error string not specified yet: Can't open file '/projects/svn-repos/format': Permission denied [Tue Apr 12 22:03:03 2005] [error] [client 10.3.1.105] Could not fetch resource information. [500, #0] [Tue Apr 12 22:03:03 2005] [error] [client 10.3.1.105] Could not open the requested SVN filesystem [500, #13] [Tue Apr 12 22:03:03 2005] [error] [client 10.3.1.105] Could not open the requested SVN filesystem [500, #13] [Tue Apr 12 22:03:03 2005] [error] [client 10.3.1.105] File does not exist: /var/www/html/favicon.ico my /etc/http/conf.d/subversion.conf looks like: DAV svn SVNPath /projects/svn-repos Most of the information online indicated people were just turning off SELinux to avoid this problem. I was wondering if anybody could point me in the direction of resolving this without disabling SELinux. Thanks! -Jerry. From hampton-rh at rainbolthampton.net Wed Apr 13 05:40:08 2005 From: hampton-rh at rainbolthampton.net (David Hampton) Date: Wed, 13 Apr 2005 01:40:08 -0400 Subject: Problems with Mailman under strict Message-ID: <1113370808.5926.19.camel@hampton-pc.rainbolthampton.net> I just started having problem with mailman on my FC3/strict 1.23.10-2 system, but I believe the change is unrelated to policy changes. It seems that the mailman init script now explicitly invokes python mailmanctl -s -q start instead of just mailmanctl -s -q start This prevents the domain_auto_trans rule in mailman.te from switching domains from initrc_t to mailman_mail_t. Fixing the mailman init file has solved my problem for now, but this will just reappear with every upgrade to the mailman package. Any chance of fixing the mailman package? David From walters at redhat.com Wed Apr 13 14:16:13 2005 From: walters at redhat.com (Colin Walters) Date: Wed, 13 Apr 2005 10:16:13 -0400 Subject: SVN + SELinux + Apache == Problems In-Reply-To: <77958214050412200411cce394@mail.gmail.com> References: <77958214050412200411cce394@mail.gmail.com> Message-ID: <1113401774.3691.9.camel@nexus.verbum.private> On Tue, 2005-04-12 at 22:04 -0500, Jerry Dueitt wrote: > I have been trying to get a SVN repository set up for access via the > DAV module. I have read that you need to do various things to get this > to work on a Fedora Core 3 system. My repository lives in > /projects/svn-repos/ which is a local filesystem. I have changed group > and owner to apache for all files in that directory with chown -R > apache.apache /projects/svn-repos. This obviously didn't work due to > SELinux security contexts. I found online that I needed to do chcon -R > -h -t httpd_sys_content_t /projects/svn-repos. Right. > I still get the following errors in my /var/log/mesages: > Apr 12 21:50:39 fry kernel: audit(1113360639.475:0): avc: denied { > search } for pid=7147 exe=/usr/sbin/httpd name=/ dev=dm-2 ino=2 > scontext=root:system_r:httpd_t tcontext=system_u:object_r:file_t > tclass=dir Is /projects a mount for separate LVM device? It must be labeled. If ls -Z /projects shows file_t, then that is the problem. Try this: chcon -t usr_t /projects I picked usr_t because it's going to be accessible to httpd_t. Longer term once we have a better infrastructure for local policy modifications, you'd really want to create a new type such as project_t which you could apply to the directory and give only httpd_t and other domains the access you want. > Most of the information online indicated people were just turning off > SELinux to avoid this problem. I was wondering if anybody could point > me in the direction of resolving this without disabling SELinux. It's much better to disable SELinux enforcement just for Apache HTTPD, not SELinux as a whole. http://fedora.redhat.com/docs/selinux-faq-fc3/index.html#using-s-c-securitylevel From jckyau at cs.hku.hk Wed Apr 13 07:04:39 2005 From: jckyau at cs.hku.hk (jckyau at cs.hku.hk) Date: Wed, 13 Apr 2005 15:04:39 +0800 (HKT) Subject: Problem with installing a new harddisk... Message-ID: <200504130704.j3D74dE22124@faith.cs.hku.hk> Hi, I am very new to SELinux, so, please bear with my ignorance. I have installed a Fedora Core 3 with SELinux enabled. The system has been running pretty stable until I tried to installed a new harddisk to my system. The system fails during the booting process if I have my new harddisk installed. It stops booting whenever I reach the point of setting up the ppp (I rely on a PPPoE line to connect to the Internet). But it boots smoothly when I have the new harddisk removed. I think it is a problem with SELinux (though I am not sure) as it gives me all kinds of complains regarding permissions. I am pretty sure that it isn't a problem with the harddisk, as this harddisk works fine when installed into another computer. I've also tried to install another harddisk to my SELinux box, and got the same result. Any clue?? Many thanx in advance! -- Joe Yau.....The Natural Born Uncle!!! +---------------------------------------------------------------------+ | Email: jckyau at cs.hku.hk WWW: http://www.cs.hku.hk/~jckyau | | | | First they ignore you... Then they ridicule at you... | | Then they fight you... Then you win!!! | | -- Mahatma Gandhi | +---------------------------------------------------------------------+ From dwalsh at redhat.com Wed Apr 13 15:55:08 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 13 Apr 2005 11:55:08 -0400 Subject: Problem with installing a new harddisk... In-Reply-To: <200504130704.j3D74dE22124@faith.cs.hku.hk> References: <200504130704.j3D74dE22124@faith.cs.hku.hk> Message-ID: <425D40DC.3030202@redhat.com> jckyau at cs.hku.hk wrote: >Hi, > >I am very new to SELinux, so, please bear with my ignorance. > >I have installed a Fedora Core 3 with SELinux enabled. The system >has been running pretty stable until I tried to installed a new harddisk >to my system. The system fails during the booting process if I have my >new harddisk installed. It stops booting whenever I reach the point of >setting up the ppp (I rely on a PPPoE line to connect to the Internet). >But it boots smoothly when I have the new harddisk removed. I think it >is a problem with SELinux (though I am not sure) as it gives me all >kinds of complains regarding permissions. > >I am pretty sure that it isn't a problem with the harddisk, as this >harddisk works fine when installed into another computer. I've also >tried to install another harddisk to my SELinux box, and got the same >result. Any clue?? > >Many thanx in advance! > > > It needs to be labeled. touch /.autorelabel shutdown machine add disk boot machine -- From mailing.lists.jdueitt at gmail.com Wed Apr 13 18:58:52 2005 From: mailing.lists.jdueitt at gmail.com (Jerry Dueitt) Date: Wed, 13 Apr 2005 13:58:52 -0500 Subject: SVN + SELinux + Apache == Problems In-Reply-To: <1113401774.3691.9.camel@nexus.verbum.private> References: <77958214050412200411cce394@mail.gmail.com> <1113401774.3691.9.camel@nexus.verbum.private> Message-ID: <7795821405041311583a84323b@mail.gmail.com> Yes /projects is a seperate LVM mountpoint! I tried issuing the chcon -t usr_t /projects and got the following error: chcon: can't apply partial context to unlabeled file /projects Why would that be? Thanks for the help! -Jerry. On 4/13/05, Colin Walters wrote: > On Tue, 2005-04-12 at 22:04 -0500, Jerry Dueitt wrote: > > I have been trying to get a SVN repository set up for access via the > > DAV module. I have read that you need to do various things to get this > > to work on a Fedora Core 3 system. My repository lives in > > /projects/svn-repos/ which is a local filesystem. I have changed group > > and owner to apache for all files in that directory with chown -R > > apache.apache /projects/svn-repos. This obviously didn't work due to > > SELinux security contexts. I found online that I needed to do chcon -R > > -h -t httpd_sys_content_t /projects/svn-repos. > > Right. > > > I still get the following errors in my /var/log/mesages: > > Apr 12 21:50:39 fry kernel: audit(1113360639.475:0): avc: denied { > > search } for pid=7147 exe=/usr/sbin/httpd name=/ dev=dm-2 ino=2 > > scontext=root:system_r:httpd_t tcontext=system_u:object_r:file_t > > tclass=dir > > Is /projects a mount for separate LVM device? It must be labeled. If > ls -Z /projects shows file_t, then that is the problem. > > Try this: > > chcon -t usr_t /projects > > I picked usr_t because it's going to be accessible to httpd_t. Longer > term once we have a better infrastructure for local policy > modifications, you'd really want to create a new type such as project_t > which you could apply to the directory and give only httpd_t and other > domains the access you want. > > > Most of the information online indicated people were just turning off > > SELinux to avoid this problem. I was wondering if anybody could point > > me in the direction of resolving this without disabling SELinux. > > It's much better to disable SELinux enforcement just for Apache HTTPD, > not SELinux as a whole. > http://fedora.redhat.com/docs/selinux-faq-fc3/index.html#using-s-c-securitylevel > > From dwalsh at redhat.com Wed Apr 13 19:14:21 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 13 Apr 2005 15:14:21 -0400 Subject: SVN + SELinux + Apache == Problems In-Reply-To: <7795821405041311583a84323b@mail.gmail.com> References: <77958214050412200411cce394@mail.gmail.com> <1113401774.3691.9.camel@nexus.verbum.private> <7795821405041311583a84323b@mail.gmail.com> Message-ID: <425D6F8D.5000306@redhat.com> Jerry Dueitt wrote: >Yes /projects is a seperate LVM mountpoint! >I tried issuing the chcon -t usr_t /projects and got the following error: >chcon: can't apply partial context to unlabeled file /projects > > > chcon -t usr_t is doing a getfilecon on /projects and attempting to use the user and role and only changing the type, but since the system has no context it is failing try chcon system_u:object_r:usr_t /projects >Why would that be? >Thanks for the help! >-Jerry. > >On 4/13/05, Colin Walters wrote: > > >>On Tue, 2005-04-12 at 22:04 -0500, Jerry Dueitt wrote: >> >> >>>I have been trying to get a SVN repository set up for access via the >>>DAV module. I have read that you need to do various things to get this >>>to work on a Fedora Core 3 system. My repository lives in >>>/projects/svn-repos/ which is a local filesystem. I have changed group >>>and owner to apache for all files in that directory with chown -R >>>apache.apache /projects/svn-repos. This obviously didn't work due to >>>SELinux security contexts. I found online that I needed to do chcon -R >>>-h -t httpd_sys_content_t /projects/svn-repos. >>> >>> >>Right. >> >> >> >>>I still get the following errors in my /var/log/mesages: >>>Apr 12 21:50:39 fry kernel: audit(1113360639.475:0): avc: denied { >>>search } for pid=7147 exe=/usr/sbin/httpd name=/ dev=dm-2 ino=2 >>>scontext=root:system_r:httpd_t tcontext=system_u:object_r:file_t >>>tclass=dir >>> >>> >>Is /projects a mount for separate LVM device? It must be labeled. If >>ls -Z /projects shows file_t, then that is the problem. >> >>Try this: >> >>chcon -t usr_t /projects >> >>I picked usr_t because it's going to be accessible to httpd_t. Longer >>term once we have a better infrastructure for local policy >>modifications, you'd really want to create a new type such as project_t >>which you could apply to the directory and give only httpd_t and other >>domains the access you want. >> >> >> >>>Most of the information online indicated people were just turning off >>>SELinux to avoid this problem. I was wondering if anybody could point >>>me in the direction of resolving this without disabling SELinux. >>> >>> >>It's much better to disable SELinux enforcement just for Apache HTTPD, >>not SELinux as a whole. >>http://fedora.redhat.com/docs/selinux-faq-fc3/index.html#using-s-c-securitylevel >> >> >> >> > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- From rirving at antient.org Wed Apr 13 22:18:50 2005 From: rirving at antient.org (Richard Irving) Date: Wed, 13 Apr 2005 17:18:50 -0500 Subject: Whooops - A new kernel problem In-Reply-To: <425B2F8F.6080803@antient.org> References: <200503010030.j210U5el017444@mx3.redhat.com> <200504082110.54213.russell@coker.com.au> <200504081014.34761.w5set@alltel.net> <42573A19.3010609@antient.org> <425B2AC7.6070100@antient.org> <425B2F8F.6080803@antient.org> Message-ID: <425D9ACA.7090806@antient.org> Richard Irving wrote: > Richard Irving wrote: > > >> I can neither confirm of deny the wireless on the X86_64, > s/of/or/ >> as I don't have it installed. A recompile of the kernel with _4KSTACK, and a recompile of ndiswrapper with that kernel, fixed the issue. It was Noise that I thought was Signal. > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From selinux at lonx.net Thu Apr 14 08:26:43 2005 From: selinux at lonx.net (Dan Am) Date: Thu, 14 Apr 2005 10:26:43 +0200 Subject: FC3 : Strict Policy and Permissive Mode Message-ID: <200504141026.43480.selinux@lonx.net> Hi all, new to the List and SElinux. I installed FC3, patched up-to.date. Then I switched to strict, but stayed with permissive, to just check the scene. However, upon reboot , I could not log in as normal user, with complaints about context. "cat /selinux/enforce" outputs "0". Any ideas, what is going on ? Regrds Dan From russell at coker.com.au Thu Apr 14 10:37:08 2005 From: russell at coker.com.au (Russell Coker) Date: Thu, 14 Apr 2005 20:37:08 +1000 Subject: latest rawhide with strict policy and audit Message-ID: <200504142037.10595.russell@coker.com.au> allow $1_t self:netlink_audit_socket { create bind write nlmsg_read read }; After updating the the latest rawhide stuff I needed the above rule in sshd.te to allow sshd to work correctly (unified diff attached). The first two accesses (create and bind) are needed to allow sshd to work to the stage of permitting logins. The last three to stop it spewing messages. What is this self:netlink_audit_socket access? What is the appropriate access for such things? newrole has the same issue, the file newrole.diff applies to newrole_macros.te. Even after applying that patch I get an error as follows: [root at community ~]# newrole -r sysadm_r Authenticating root. Password: Error sending status request (Operation not permitted) [root at community ~]# id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6 (disk),10(wheel) context=root:sysadm_r:sysadm_t [root at community ~]# I guess that this is in the new pam so local_login_t, xdm_t and other domains will need similar changes. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: ssh.diff Type: text/x-diff Size: 448 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: newrole.diff Type: text/x-diff Size: 357 bytes Desc: not available URL: From dwalsh at redhat.com Thu Apr 14 11:23:26 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 14 Apr 2005 07:23:26 -0400 Subject: FC3 : Strict Policy and Permissive Mode In-Reply-To: <200504141026.43480.selinux@lonx.net> References: <200504141026.43480.selinux@lonx.net> Message-ID: <425E52AE.1020001@redhat.com> Dan Am wrote: >Hi all, >new to the List and SElinux. >I installed FC3, patched up-to.date. >Then I switched to strict, but stayed with permissive, to just check the >scene. However, upon reboot , I could not log in as normal user, with >complaints about context. "cat /selinux/enforce" outputs "0". >Any ideas, what is going on ? >Regrds >Dan > > > Not sure but did you relabel after switching to strict policy? touch /.autorelabel reboot >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- From dwalsh at redhat.com Thu Apr 14 11:27:01 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 14 Apr 2005 07:27:01 -0400 Subject: Problem with installing a new harddisk... In-Reply-To: <200504140043.j3E0hZa01083@faith.cs.hku.hk> References: <200504140043.j3E0hZa01083@faith.cs.hku.hk> Message-ID: <425E5385.1040807@redhat.com> jckyau at cs.hku.hk wrote: >Hello Daniel, > >dwalsh at redhat.com wrote: > > >>jckyau cs hku hk wrote: >> >> >>>Hi, >>> >>>I am very new to SELinux, so, please bear with my ignorance. >>> >>>I have installed a Fedora Core 3 with SELinux enabled. The system >>>has been running pretty stable until I tried to installed a new harddisk >>>to my system. The system fails during the booting process if I have my >>>new harddisk installed. It stops booting whenever I reach the point of >>>setting up the ppp (I rely on a PPPoE line to connect to the Internet). >>>But it boots smoothly when I have the new harddisk removed. I think it >>>is a problem with SELinux (though I am not sure) as it gives me all >>>kinds of complains regarding permissions. >>> >>>I am pretty sure that it isn't a problem with the harddisk, as this >>>harddisk works fine when installed into another computer. I've also >>>tried to install another harddisk to my SELinux box, and got the same >>>result. Any clue?? >>> >>>Many thanx in advance! >>> >>> >>> >>> >>> >>It needs to be labeled. >> >>touch /.autorelabel >>shutdown machine >>add disk >>boot machine >> >> >>-- >> >> >> > Thank you for your reply. However, it didn't work for me. With > "/.autorelabel" and my new harddisk installed, the system took a > very long time to "relabel" the filesystem at the booting phase > (I guess it was my original root filesystem that it was relabeling), > and continued with the booting afterwards. But the booting was done > (took a very long time), my root filesystem (which is the only > filesystem on my original harddisk) was mounted as readonly. > Certainly, a system with a readonly root filesystem doesn't do me any > good. More suggestions? > > Thanx! > > > What kind of log messages are you getting? What file system are you using? Can you boot successfully with enfocing=0 on the kernel line? Dan -- From wolfy at zig-zag.net Thu Apr 14 11:44:11 2005 From: wolfy at zig-zag.net (lonely wolf) Date: Thu, 14 Apr 2005 14:44:11 +0300 Subject: Problem with installing a new harddisk... In-Reply-To: <425E5385.1040807@redhat.com> References: <200504140043.j3E0hZa01083@faith.cs.hku.hk> <425E5385.1040807@redhat.com> Message-ID: <425E578B.6020707@zig-zag.net> Daniel J Walsh wrote: > jckyau at cs.hku.hk wrote: > >> Hello Daniel, >> >> dwalsh at redhat.com wrote: >> >> >>> jckyau cs hku hk wrote: >>> >>> >>>> Hi, >>>> >>>> I am very new to SELinux, so, please bear with my ignorance. >>>> >>>> I have installed a Fedora Core 3 with SELinux enabled. The system >>>> has been running pretty stable until I tried to installed a new >>>> harddisk >>>> to my system. The system fails during the booting process if I >>>> have my >>>> new harddisk installed. It stops booting whenever I reach the >>>> point of >>>> setting up the ppp (I rely on a PPPoE line to connect to the >>>> Internet). >>>> But it boots smoothly when I have the new harddisk removed. I >>>> think it >>>> is a problem with SELinux (though I am not sure) as it gives me all >>>> kinds of complains regarding permissions. >>>> >>>> I am pretty sure that it isn't a problem with the harddisk, as this >>>> harddisk works fine when installed into another computer. I've also >>>> tried to install another harddisk to my SELinux box, and got the same >>>> result. Any clue?? >>>> Many thanx in advance! >>>> >>>> >>>> >>>> >>> >>> It needs to be labeled. >>> >>> touch /.autorelabel >>> shutdown machine >>> add disk >>> boot machine >>> >>> >>> -- >>> >>> >> >> Thank you for your reply. However, it didn't work for me. With >> "/.autorelabel" and my new harddisk installed, the system took a >> very long time to "relabel" the filesystem at the booting phase >> (I guess it was my original root filesystem that it was relabeling), >> and continued with the booting afterwards. But the booting was done >> (took a very long time), my root filesystem (which is the only >> filesystem on my original harddisk) was mounted as readonly. >> Certainly, a system with a readonly root filesystem doesn't do me any >> good. More suggestions? > Are you sure that the problems do not come from the fact that you have two filesystems labeled as '/" and the initialiation process trying to mount the wrong one? I'd give a shot and replace the line (use the values appropiate for you) kernel /vmlinuz-2.6.10-1.770_FC3 ro root=LABEL=/ with kernel /vmlinuz-2.6.10-1.770_FC3 ro root=/dev/hdaN <=== use here the value corresponding to the root partition of your first disk Do not forget to (but I assume you have already done that) - create a valid mount point for the second HD - add an entry for it in fstab - touch /.autorelabel (so that the second HD gets relabeled too) From selinux at lonx.net Thu Apr 14 12:47:57 2005 From: selinux at lonx.net (Dan Am) Date: Thu, 14 Apr 2005 14:47:57 +0200 Subject: FC3 : Strict Policy and Permissive Mode In-Reply-To: <425E52AE.1020001@redhat.com> References: <200504141026.43480.selinux@lonx.net> <425E52AE.1020001@redhat.com> Message-ID: <200504141447.57784.selinux@lonx.net> Hi Daniel, Am Thursday, 14. April 2005 13:23 schrieb Daniel J Walsh: > touch /.autorelabel > reboot Ah, that did it ! Quite some complaints now, but everything working. I'll take it from here. Thanks. Regards Daniel From hongwei at wustl.edu Thu Apr 14 14:47:46 2005 From: hongwei at wustl.edu (Hongwei Li) Date: Thu, 14 Apr 2005 09:47:46 -0500 (CDT) Subject: How to modify the policy? Message-ID: <2197.128.252.85.103.1113490066.squirrel@morpheus.wustl.edu> Hi, I have a fc3 linux (kernel 2.6.10-1.770_FC3) with selinux enforced, targeted policy 1.17.30-2.96. I try to use squirrelmail's plugin change_passwd, but got denied. The system log shows: Apr 14 09:42:59 pippo kernel: audit(1113489779.011:0): avc: denied { search } for pid=13211 exe=/bin/bash name=src dev=hda6 ino=425174 scontext=root:system_r:httpd_sys_script_t tcontext=system_u:object_r:src_t tclass=dir Apr 14 09:42:59 pippo kernel: audit(1113489779.012:0): avc: denied { setuid } for pid=13211 exe=/usr/bin/chpasswd capability=7 scontext=root:system_r:httpd_sys_script_t tcontext=root:system_r:httpd_sys_script_t tclass=capability I can use that plugin's command in ssh console, but just not from the web. Should I change the targeted policy to make it working? If yes, how to modify the policy? Thanks a lot! Hongwei Li From dwalsh at redhat.com Thu Apr 14 18:29:29 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 14 Apr 2005 14:29:29 -0400 Subject: How to modify the policy? In-Reply-To: <2197.128.252.85.103.1113490066.squirrel@morpheus.wustl.edu> References: <2197.128.252.85.103.1113490066.squirrel@morpheus.wustl.edu> Message-ID: <425EB689.1000008@redhat.com> Hongwei Li wrote: >Hi, > >I have a fc3 linux (kernel 2.6.10-1.770_FC3) with selinux enforced, >targeted policy 1.17.30-2.96. I try to use squirrelmail's plugin >change_passwd, but got denied. The system log shows: > >Apr 14 09:42:59 pippo kernel: audit(1113489779.011:0): avc: denied { >search } for pid=13211 exe=/bin/bash name=src dev=hda6 ino=425174 >scontext=root:system_r:httpd_sys_script_t tcontext=system_u:object_r:src_t >tclass=dir >Apr 14 09:42:59 pippo kernel: audit(1113489779.012:0): avc: denied { >setuid } for pid=13211 exe=/usr/bin/chpasswd capability=7 >scontext=root:system_r:httpd_sys_script_t >tcontext=root:system_r:httpd_sys_script_t tclass=capability > >I can use that plugin's command in ssh console, but just not from the web. > Should I change the targeted policy to make it working? If yes, how to >modify the policy? > >Thanks a lot! > >Hongwei Li > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > The only way to do this currently is to install selinux-policy-targeted-sources. Then you can edit apache rules to allow this priv. The problem with this is priv is that it will allow Any cgi script to execute setuid applications. The best solution would be to write policy for change_passwd and then have a domain transfer to this application. -- From hongwei at wustl.edu Thu Apr 14 19:05:33 2005 From: hongwei at wustl.edu (Hongwei Li) Date: Thu, 14 Apr 2005 14:05:33 -0500 (CDT) Subject: How to modify the policy? In-Reply-To: <425EB689.1000008@redhat.com> References: <2197.128.252.85.103.1113490066.squirrel@morpheus.wustl.edu> <425EB689.1000008@redhat.com> Message-ID: <3949.128.252.85.103.1113505533.squirrel@morpheus.wustl.edu> > Hongwei Li wrote: > >>Hi, >> >>I have a fc3 linux (kernel 2.6.10-1.770_FC3) with selinux enforced, >>targeted policy 1.17.30-2.96. I try to use squirrelmail's plugin >>change_passwd, but got denied. The system log shows: >> >>Apr 14 09:42:59 pippo kernel: audit(1113489779.011:0): avc: denied { >>search } for pid=13211 exe=/bin/bash name=src dev=hda6 ino=425174 >>scontext=root:system_r:httpd_sys_script_t >> tcontext=system_u:object_r:src_t >>tclass=dir >>Apr 14 09:42:59 pippo kernel: audit(1113489779.012:0): avc: denied { >>setuid } for pid=13211 exe=/usr/bin/chpasswd capability=7 >>scontext=root:system_r:httpd_sys_script_t >>tcontext=root:system_r:httpd_sys_script_t tclass=capability >> >>I can use that plugin's command in ssh console, but just not from the >> web. >> Should I change the targeted policy to make it working? If yes, how to >>modify the policy? >> >>Thanks a lot! >> >>Hongwei Li >> >>-- >>fedora-selinux-list mailing list >>fedora-selinux-list at redhat.com >>http://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >> > The only way to do this currently is to install > selinux-policy-targeted-sources. > > Then you can edit apache rules to allow this priv. The problem with > this is priv is that > it will allow Any cgi script to execute setuid applications. The best > solution would be > to write policy for change_passwd and then have a domain transfer to > this application. > > -- > I am new to selinux, especially for policy editing/writing. Could you please tell me how to do it in each way (I have installed the sources): 1. how to edit apache rules to allow this priv? 2. how to write a policy for change_passwd and then have a domain transfer to it? I appreciate your help! Hongwei From steve at atc-nycorp.com Thu Apr 14 20:33:32 2005 From: steve at atc-nycorp.com (Steve Brueckner) Date: Thu, 14 Apr 2005 16:33:32 -0400 Subject: Limiting IPC with SELinux? Message-ID: <60D45469A1AAD311A04C009027B6BF6804FCF092@server20.inside.oracorp.com> My understanding of the inner workings of SELinux is fairly limited, so please speak slowly to me. I'm getting the hang of basic file and device access, but I'm not so good with the other resources SELinux controls. I need to lock down the local interprocess communications (sockets, pipes, shared memory...) for a few untrusted applications under the targeted policy. For example, I want to write policies for Mozilla and Eclipse such that Eclipse may connect to Mozilla's tcp socket 80 via loopback, but Eclipse may not connect to any other process's tcp socket 80 via loopback. Same thing goes for other methods of IPC. I suspect this means I have to figure out how to label sockets and the like with special contexts as they are created. Am I on the right track here? If so, how would I adjust my policies to label these IPC resources on a per-process basis? Or is this not do-able with SELinux? What I'm proposing here is a little more involved than most of the SELinux documentation I've found online, so any good resources would be appreciated. Of course, the more that is spelled out for me in a direct reply the bigger my head start will be. At this point I don't even know where to begin. By the way, is the Fedora list or the NSA list more appropriate for this sort of question? I hate to double-post, but I want good exposure. Thanks, Stephen Brueckner, ATC-NY From hampton-rh at rainbolthampton.net Thu Apr 14 21:35:07 2005 From: hampton-rh at rainbolthampton.net (David Hampton) Date: Thu, 14 Apr 2005 17:35:07 -0400 Subject: Description of the httpdcontent attribute [patch] Message-ID: <1113514507.6056.37.camel@hampton-pc.rainbolthampton.net> This patch adds to the description of the httpdcontent attribute. David -------------- next part -------------- A non-text attachment was scrubbed... Name: UDiffs.attrib Type: text/x-patch Size: 823 bytes Desc: not available URL: From hampton-rh at rainbolthampton.net Thu Apr 14 21:35:51 2005 From: hampton-rh at rainbolthampton.net (David Hampton) Date: Thu, 14 Apr 2005 17:35:51 -0400 Subject: Updates to amavisd [patch] Message-ID: <1113514551.6056.38.camel@hampton-pc.rainbolthampton.net> The attached patch updates the (unused) amavisd policy to work with the changes in the FC strict/1.23.10-2 policy. It also fixes the access needed by tmpreaper to delete files from the caught spam/virus directory. David -------------- next part -------------- A non-text attachment was scrubbed... Name: UDiffs.amavid Type: text/x-patch Size: 1592 bytes Desc: not available URL: From hampton-rh at rainbolthampton.net Thu Apr 14 21:36:06 2005 From: hampton-rh at rainbolthampton.net (David Hampton) Date: Thu, 14 Apr 2005 17:36:06 -0400 Subject: Updates to razor [patch] Message-ID: <1113514566.6056.42.camel@hampton-pc.rainbolthampton.net> The attached patch updates the (unused) razor policy to work with the changes in the FC strict/1.23.10-2 policy. David -------------- next part -------------- A non-text attachment was scrubbed... Name: UDiffs.razor Type: text/x-patch Size: 617 bytes Desc: not available URL: From hampton-rh at rainbolthampton.net Thu Apr 14 21:36:01 2005 From: hampton-rh at rainbolthampton.net (David Hampton) Date: Thu, 14 Apr 2005 17:36:01 -0400 Subject: Updates to dcc [patch] Message-ID: <1113514561.6056.41.camel@hampton-pc.rainbolthampton.net> The attached patch updates the (unused) dcc policy to work with the changes in the FC strict/1.23.10-2 policy. It also makes a couple of tweaks to the policy David -------------- next part -------------- A non-text attachment was scrubbed... Name: UDiffs.dcc Type: text/x-patch Size: 1234 bytes Desc: not available URL: From hampton-rh at rainbolthampton.net Thu Apr 14 21:35:58 2005 From: hampton-rh at rainbolthampton.net (David Hampton) Date: Thu, 14 Apr 2005 17:35:58 -0400 Subject: Updates to clamav [patch] Message-ID: <1113514558.6056.40.camel@hampton-pc.rainbolthampton.net> The attached patch updates the (unused) clamav policy to work with the changes in the FC strict/1.23.10-2 policy. It also fixes an access problem with the clamd socket. David -------------- next part -------------- A non-text attachment was scrubbed... Name: UDiffs.clamav Type: text/x-patch Size: 1501 bytes Desc: not available URL: From sds at tycho.nsa.gov Thu Apr 14 21:31:16 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 14 Apr 2005 17:31:16 -0400 Subject: Limiting IPC with SELinux? In-Reply-To: <60D45469A1AAD311A04C009027B6BF6804FCF092@server20.inside.oracorp.com> References: <60D45469A1AAD311A04C009027B6BF6804FCF092@server20.inside.oracorp.com> Message-ID: <1113514276.2123.102.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-04-14 at 16:33 -0400, Steve Brueckner wrote: > I need to lock down the local interprocess communications (sockets, pipes, > shared memory...) for a few untrusted applications under the targeted > policy. For example, I want to write policies for Mozilla and Eclipse such > that Eclipse may connect to Mozilla's tcp socket 80 via loopback, but > Eclipse may not connect to any other process's tcp socket 80 via loopback. > Same thing goes for other methods of IPC. You mean apache rather than mozilla, right? > I suspect this means I have to figure out how to label sockets and the like > with special contexts as they are created. Am I on the right track here? > If so, how would I adjust my policies to label these IPC resources on a > per-process basis? Or is this not do-able with SELinux? You can control network communication (loopback or otherwise) via the permission checks between the sending socket security context and the security contexts of the network interface, the destination host, and the destination port. These are the netif and node tcp_send permissions and the tcp_socket send_msg permission. Sockets are labeled in accordance with the creating process, so you just need to define a domain for eclipse. > What I'm proposing here is a little more involved than most of the SELinux > documentation I've found online, so any good resources would be appreciated. > Of course, the more that is spelled out for me in a direct reply the bigger > my head start > will be. At this point I don't even know where to begin. Possible resources: The RHEL4 SELinux Guide, http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ - Understanding and Customizing the Apache HTTP SELinux Policy, http://fedora.redhat.com/docs/selinux-apache-fc3/ - Sourceforge SELinux HOWTOs http://sourceforge.net/docman/?group_id=21266 - SELinux: NSA's Open Source Security Enhanced Linux by Bill McCarty, http://www.oreilly.com/catalog/selinux/ - Tresys Technology Policy Writing Course Slides, http://www.tresys.com/selinux/selinux-course-outline.html - Configuring the SELinux Policy, http://www.nsa.gov/selinux/papers/policy2-abs.cfm -- Stephen Smalley National Security Agency From hampton-rh at rainbolthampton.net Thu Apr 14 22:15:34 2005 From: hampton-rh at rainbolthampton.net (David Hampton) Date: Thu, 14 Apr 2005 18:15:34 -0400 Subject: Webalizer [patch] Message-ID: <1113516934.6056.44.camel@hampton-pc.rainbolthampton.net> Webalizer seems to have lost its fc file somewhere along the way. The attached patch supplies a file context that works on FC3/strict/1.23.10-2, and also allows access to the nscd service. David -------------- next part -------------- A non-text attachment was scrubbed... Name: UDiffs.webalizer Type: text/x-patch Size: 1155 bytes Desc: not available URL: From hampton-rh at rainbolthampton.net Thu Apr 14 22:15:36 2005 From: hampton-rh at rainbolthampton.net (David Hampton) Date: Thu, 14 Apr 2005 18:15:36 -0400 Subject: Updates to yam [patch] Message-ID: <1113516936.6056.45.camel@hampton-pc.rainbolthampton.net> The attached patch updates the (unused) yam policy to work with the changes in the FC strict/1.23.10-2 policy. It also fixes httpd access the the files yam distributes, and suppresses an access denied error message when webalizer runs. David -------------- next part -------------- A non-text attachment was scrubbed... Name: UDiffs.yam Type: text/x-patch Size: 1741 bytes Desc: not available URL: From sds at tycho.nsa.gov Fri Apr 15 12:25:27 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 15 Apr 2005 08:25:27 -0400 Subject: Limiting IPC with SELinux? In-Reply-To: <1113514276.2123.102.camel@moss-spartans.epoch.ncsc.mil> References: <60D45469A1AAD311A04C009027B6BF6804FCF092@server20.inside.oracorp.com> <1113514276.2123.102.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1113567927.3810.19.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-04-14 at 17:31 -0400, Stephen Smalley wrote: > You can control network communication (loopback or otherwise) via the > permission checks between the sending socket security context and the > security contexts of the network interface, the destination host, and > the destination port. These are the netif and node tcp_send permissions > and the tcp_socket send_msg permission. Sockets are labeled in > accordance with the creating process, so you just need to define a > domain for eclipse. BTW, these outbound network permission checks are described in http://www.nsa.gov/selinux/papers/module/x2324.html And going back to your original question, for INET communication, you can't truly do process-to-process permission checks (or even socket-to- peersocket permission checks) because we don't presently have labeled networking support (i.e. labeled network buffers and packets). There was experimental support for such labeled networking in the older SELinux (courtesy of James Morris), but the necessary hooks and security fields to support it were not accepted into Linux 2.6. Trent Jaeger of IBM has more recently implemented implicit packet labeling via IPSEC security associations for SELinux, but I don't think you need that for what you describe; the existing permission checks based on network interface, host, and port should be sufficient. -- Stephen Smalley National Security Agency From hampton-rh at rainbolthampton.net Fri Apr 15 16:39:24 2005 From: hampton-rh at rainbolthampton.net (David Hampton) Date: Fri, 15 Apr 2005 12:39:24 -0400 Subject: Prelink fails under strict/enforcing Message-ID: <1113583164.17176.12.camel@hampton-pc.rainbolthampton.net> I'm having problems with the prelink command on my system running the latest FC3/strict/1.23.11-1 policy. Running in enforcing mode, when I run 'prelink -a' after updating glibc, I get a single "avc: denied { relabelto }" error message and prelink bails out. Running tripwire immediately before and after the prelink command show no changes to any files on the system. Running the same scenario in permissive mode, I get a series of 100 or more relabelto denied error messages. The tripwire runs show over 1000 modified files, which is par for the course after updating glibc. Here's one of the error messages in full: Apr 15 10:36:08 starfury kernel: audit(1113575768.487:0): avc: denied { relabelto } for pid=22291 exe=/usr/sbin/prelink name=refer.#prelink#.SULAFf dev=dm-0 ino=13717061 scontext=root:system_r:prelink_t tcontext=system_u:object_r:bin_t tclass=file As far as I can tell from looking at the policy sources, I shouldn't be getting any of these errors. There is a (long) line in prelink.te that explicitly allows relabelto. Wrapped for clarity, it is: allow prelink_t { ifdef(`amanda.te', `amanda_usr_lib_t') admin_passwd_exec_t ifdef(`apache.te', `httpd_modules_t') ifdef(`xserver.te', `xkb_var_lib_t') ld_so_t su_exec_t texrel_shlib_t shlib_t sbin_t bin_t lib_t exec_type }:file { create_file_perms execute relabelto relabelfrom }; This line explicitly allows prelink the relabelto permission for bin_t files, which is what the avc message I copied is complaining about. I've spot checked some of the other 100 error messages. The majority of them have a target context of xxx_exec_t and the declaration of the xxx_exec_t type includes the exec_type attribute, which means the operation should be allowed based on the policy line above. Any suggestions on where to go from here to track down this problem? David From selinux at gmail.com Fri Apr 15 17:33:17 2005 From: selinux at gmail.com (Tom London) Date: Fri, 15 Apr 2005 10:33:17 -0700 Subject: cups: unconfined_t:dbus... Message-ID: <4c4ba1530504151033469554f@mail.gmail.com> Running targeted/enforcing, 1.23.10-5, rawhide. When I disconnected a USB printer, got the following: Apr 15 09:56:51 localhost kernel: usb 2-1: USB disconnect, address 2 Apr 15 09:56:51 localhost kernel: drivers/usb/class/usblp.c: usblp0: removed Apr 15 09:56:55 localhost dbus: avc: denied { send_msg } for msgtype=signal interface=com.redhat.PrinterSpooler member=PrinterRemoved dest=org.freedesktop.DBus spid=2634 tpid=3592 scontext=user_u:system_r:cupsd_t tcontext=user_u:system_r:unconfined_t tclass=dbus Apr 15 09:56:55 localhost last message repeated 2 times Apr 15 09:56:55 localhost dbus: avc: denied { send_msg } for msgtype=signal interface=com.redhat.PrinterSpooler member=PrinterAdded dest=org.freedesktop.DBus spid=2634 tpid=3592 scontext=user_u:system_r:cupsd_t tcontext=user_u:system_r:unconfined_t tclass=dbus Apr 15 09:56:55 localhost dbus: avc: denied { send_msg } for msgtype=signal interface=com.redhat.PrinterSpooler member=PrinterAdded dest=org.freedesktop.DBus spid=2634 tpid=3592 scontext=user_u:system_r:cupsd_t tcontext=user_u:system_r:unconfined_t tclass=dbus audit2allow says: allow cupsd_t unconfined_t:dbus send_msg; That right? tom -- Tom London From steve at atc-nycorp.com Fri Apr 15 17:47:00 2005 From: steve at atc-nycorp.com (Steve Brueckner) Date: Fri, 15 Apr 2005 13:47:00 -0400 Subject: Limiting IPC with SELinux? Message-ID: <60D45469A1AAD311A04C009027B6BF6804FCF096@server20.inside.oracorp.com> Stephen Smalley wrote: > On Thu, 2005-04-14 at 16:33 -0400, Steve Brueckner wrote: >> I need to lock down the local interprocess communications (sockets, >> pipes, shared memory...) for a few untrusted applications under the >> targeted policy. For example, I want to write policies for Mozilla >> and Eclipse such that Eclipse may connect to Mozilla's tcp socket 80 >> via loopback, but Eclipse may not connect to any other process's tcp >> socket 80 via loopback. Same thing goes for other methods of IPC. > > You mean apache rather than mozilla, right? I actually do mean Mozilla, but I guess I don't mean port 80 (it's some other high port number). Eclipse's help system launches Mozilla to access the help docs on the local hard drive, and they communicate via loopback. The problem for me is how to allow this, but not allow Eclipse to communicate with any other local processes via loopback. The hard part is that I can't make this decision based on port number; it has to be based on the actual processes involved. >> I suspect this means I have to figure out how to label sockets and >> the like with special contexts as they are created. Am I on the >> right track here? If so, how would I adjust my policies to label >> these IPC resources on a per-process basis? Or is this not do-able >> with SELinux? > > You can control network communication (loopback or otherwise) via the > permission checks between the sending socket security context and the > security contexts of the network interface, the destination host, and > the destination port. These are the netif and node tcp_send > permissions and the tcp_socket send_msg permission. Sockets are > labeled in accordance with the creating process, so you just need to > define a domain for eclipse. Since I can't statically define security contexts for specific port numbers in my policy, I may have a problem. I think my first example above illustrates this: either Mozilla or a hostile process could be listening on the port, so Eclipse needs to know which process is listening on that port. For my application, I can't deny any process the right to bind to whatever port it wants. Keep in mind that this is all happening on the local machine, so I also can't use network interface or destination host to differentiate, either. >> What I'm proposing here is a little more involved than most of the >> SELinux documentation I've found online, so any good resources would >> be appreciated. Of course, the more that is spelled out for me in a >> direct reply the bigger my head start will be. At this point I don't >> even know where to begin. > > Possible resources: > (...lots of good links listed here...) Thanks for the links. I reviewed most of them a while back, but I just refreshed myself on the networking portions. > And going back to your original question, for INET communication, you > can't truly do process-to-process permission checks (or even > socket-to- peersocket permission checks) because we don't presently > have labeled networking support (i.e. labeled network buffers and > packets). There was experimental support for such labeled networking > in the older SELinux (courtesy of James Morris), but the necessary > hooks and security fields to support it were not accepted into Linux > 2.6. Trent Jaeger of IBM has more recently implemented implicit > packet labeling via IPSEC security associations for SELinux, but I > don't think you need that for what you describe; the existing > permission checks based on network interface, host, and port should > be sufficient. Ah, so maybe I can't do exactly what I want to do using SELinux. My network interface and host will always be the same, so no help there. And I can't a priori decide which ports to allow or disallow. I think what I need is the ability to say "eclipse_t may connect only to a socket belonging to mozilla_t," where the socket gets labeled as belonging to mozilla_t when Mozilla first calls socket() or bind(). Also, this is not just about networking. I need to make the same process-to-process decision for other types of IPC, such as shared memory. However, this may be possible: I assume that unlike a socket, a shared memory segment gets labeled with the context of the domain that created it? So I could write a rule such as "allow eclipse_t mozilla_t:shm {read write}" to allow Eclipse and Mozilla to share memory with each other but nobody else? (of course now I'm just using Eclipse and Mozilla as examples; these could be any programs). So, based on my clarifications above, what are my chances of pulling this off? I'm afraid that unless my understanding is fundamentally flawed, I may be goind beyond what SELinux can currently support. A shame about the labeled networking support being shot down by the kernel folks. Thanks, - Steve Brueckner, ATC-NY From sds at tycho.nsa.gov Fri Apr 15 17:55:16 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 15 Apr 2005 13:55:16 -0400 Subject: Limiting IPC with SELinux? In-Reply-To: <60D45469A1AAD311A04C009027B6BF6804FCF096@server20.inside.oracorp.com> References: <60D45469A1AAD311A04C009027B6BF6804FCF096@server20.inside.oracorp.com> Message-ID: <1113587716.3810.138.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-04-15 at 13:47 -0400, Steve Brueckner wrote: > I actually do mean Mozilla, but I guess I don't mean port 80 (it's some > other high port number). Eclipse's help system launches Mozilla to access > the help docs on the local hard drive, and they communicate via loopback. > The problem for me is how to allow this, but not allow Eclipse to > communicate with any other local processes via loopback. The hard part is > that I can't make this decision based on port number; it has to be based on > the actual processes involved. Well, SELinux does allow you to limit what processes can bind to what ports, so if the port falls within a well-defined range and you can exclude others from that port range without breaking functionality, you can indirectly achieve the process-to-process relationship in that manner. If not, then I guess you need labeled networking. Note btw that the targeted policy doesn't presently define domains for user applications like mozilla or eclipse; it is focused on a subset of the daemon domains and leaves users and user applications running unconfined. strict policy includes domains for users and their applications, although most user applications still run in the base user domain (mozilla is an exception). > For my application, I can't deny any process the right to bind to whatever > port it wants. This seems to be the key limitation. The question is why? > And I can't a > priori decide which ports to allow or disallow. I think what I need is the > ability to say "eclipse_t may connect only to a socket belonging to > mozilla_t," where the socket gets labeled as belonging to mozilla_t when > Mozilla first calls socket() or bind(). The sockets are labeled (with the same label as the creating process). The problem is conveying that label on an INET communication so that the receiver can perform a socket-to-peersocket check, which is presently lacking due to the lack of labeled networking. But it can be done for PF_UNIX/LOCAL communication and for other forms of local IPC. > Also, this is not just about networking. I need to make the same > process-to-process decision for other types of IPC, such as shared memory. > However, this may be possible: I assume that unlike a socket, a shared > memory segment gets labeled with the context of the domain that created it? > So I could write a rule such as "allow eclipse_t mozilla_t:shm {read write}" > to allow Eclipse and Mozilla to share memory with each other but nobody > else? (of course now I'm just using Eclipse and Mozilla as examples; these > could be any programs). Yes. Look for example at policy/macros/program/x_client_macros.te, where the X client is allowed to communicate with the X server via shared memory. Note that this involves both rules on the "shm" object class and permissions on "tmpfs" files, because the kernel maintains an internal tmpfs mount representing shm objects. > So, based on my clarifications above, what are my chances of pulling this > off? I'm afraid that unless my understanding is fundamentally flawed, I may > be goind beyond what SELinux can currently support. A shame about the > labeled networking support being shot down by the kernel folks. Only for local communications (PF_UNIX/LOCAL, System V IPC, etc). For INET communications, you are limited to port-based controls, so you need to be able to establish control over the process-to-port bindings if you want to achieve process-to-process control. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Fri Apr 15 18:56:20 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 15 Apr 2005 14:56:20 -0400 Subject: cups: unconfined_t:dbus... In-Reply-To: <4c4ba1530504151033469554f@mail.gmail.com> References: <4c4ba1530504151033469554f@mail.gmail.com> Message-ID: <42600E54.7080706@redhat.com> Tom London wrote: >Running targeted/enforcing, 1.23.10-5, rawhide. > >When I disconnected a USB printer, got the following: >Apr 15 09:56:51 localhost kernel: usb 2-1: USB disconnect, address 2 >Apr 15 09:56:51 localhost kernel: drivers/usb/class/usblp.c: usblp0: removed >Apr 15 09:56:55 localhost dbus: avc: denied { send_msg } for >msgtype=signal interface=com.redhat.PrinterSpooler >member=PrinterRemoved dest=org.freedesktop.DBus spid=2634 tpid=3592 >scontext=user_u:system_r:cupsd_t tcontext=user_u:system_r:unconfined_t >tclass=dbus >Apr 15 09:56:55 localhost last message repeated 2 times >Apr 15 09:56:55 localhost dbus: avc: denied { send_msg } for >msgtype=signal interface=com.redhat.PrinterSpooler member=PrinterAdded >dest=org.freedesktop.DBus spid=2634 tpid=3592 >scontext=user_u:system_r:cupsd_t tcontext=user_u:system_r:unconfined_t >tclass=dbus >Apr 15 09:56:55 localhost dbus: avc: denied { send_msg } for >msgtype=signal interface=com.redhat.PrinterSpooler member=PrinterAdded >dest=org.freedesktop.DBus spid=2634 tpid=3592 >scontext=user_u:system_r:cupsd_t tcontext=user_u:system_r:unconfined_t >tclass=dbus > >audit2allow says: >allow cupsd_t unconfined_t:dbus send_msg; > >That right? > tom > > > Yes it will be in tomorrow's patch. I wonder if I should add userdomain and unpriv_userdomain attribute to unconfined_t for targeted. Probably to dangerous. typeattribute unconfined_t userdomain; typeattribute unconfined_t unpriv_userdomain; -- From dwalsh at redhat.com Fri Apr 15 19:37:04 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 15 Apr 2005 15:37:04 -0400 Subject: How to modify the policy? In-Reply-To: <3949.128.252.85.103.1113505533.squirrel@morpheus.wustl.edu> References: <2197.128.252.85.103.1113490066.squirrel@morpheus.wustl.edu> <425EB689.1000008@redhat.com> <3949.128.252.85.103.1113505533.squirrel@morpheus.wustl.edu> Message-ID: <426017E0.1030501@redhat.com> Hongwei Li wrote: >>Hongwei Li wrote: >> >> >> >>>Hi, >>> >>>I have a fc3 linux (kernel 2.6.10-1.770_FC3) with selinux enforced, >>>targeted policy 1.17.30-2.96. I try to use squirrelmail's plugin >>>change_passwd, but got denied. The system log shows: >>> >>>Apr 14 09:42:59 pippo kernel: audit(1113489779.011:0): avc: denied { >>>search } for pid=13211 exe=/bin/bash name=src dev=hda6 ino=425174 >>>scontext=root:system_r:httpd_sys_script_t >>>tcontext=system_u:object_r:src_t >>>tclass=dir >>>Apr 14 09:42:59 pippo kernel: audit(1113489779.012:0): avc: denied { >>>setuid } for pid=13211 exe=/usr/bin/chpasswd capability=7 >>>scontext=root:system_r:httpd_sys_script_t >>>tcontext=root:system_r:httpd_sys_script_t tclass=capability >>> >>>I can use that plugin's command in ssh console, but just not from the >>>web. >>>Should I change the targeted policy to make it working? If yes, how to >>>modify the policy? >>> >>>Thanks a lot! >>> >>>Hongwei Li >>> >>>-- >>>fedora-selinux-list mailing list >>>fedora-selinux-list at redhat.com >>>http://www.redhat.com/mailman/listinfo/fedora-selinux-list >>> >>> >>> >>> >>The only way to do this currently is to install >>selinux-policy-targeted-sources. >> >>Then you can edit apache rules to allow this priv. The problem with >>this is priv is that >>it will allow Any cgi script to execute setuid applications. The best >>solution would be >>to write policy for change_passwd and then have a domain transfer to >>this application. >> >>-- >> >> >> > >I am new to selinux, especially for policy editing/writing. Could you >please tell me how to do it in each way (I have installed the sources): > >1. how to edit apache rules to allow this priv? > > Simple fix is to edit /etc/selinux/targeted/src/policy/domains/program/apache.te Add allow httpd_sys_script_t self:capability setuid; allow httpd_sys_script_t src_t:dir search; >2. how to write a policy for change_passwd and then have a domain transfer >to it? > > A better solution would be to create a new policy file /etc/selinux/targeted/src/policy/domains/program/chpasswd.te and a new policy file context file /etc/selinux/targeted/src/policy/file_context/program/chpasswd.fc You might want to look at the passwd.te file from strict policy as an example. Another option might be to just relabel this policy as httpd_unconfined_script_t since allowing sys_script to run chpasswd is pretty dangerous. And can circumvent most SELinux controls. >I appreciate your help! > >Hongwei > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- From dwalsh at redhat.com Fri Apr 15 21:06:32 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 15 Apr 2005 17:06:32 -0400 Subject: Prelink fails under strict/enforcing In-Reply-To: <1113583164.17176.12.camel@hampton-pc.rainbolthampton.net> References: <1113583164.17176.12.camel@hampton-pc.rainbolthampton.net> Message-ID: <42602CD8.2050209@redhat.com> David Hampton wrote: >I'm having problems with the prelink command on my system running the >latest FC3/strict/1.23.11-1 policy. > >Running in enforcing mode, when I run 'prelink -a' after updating glibc, >I get a single "avc: denied { relabelto }" error message and prelink >bails out. Running tripwire immediately before and after the prelink >command show no changes to any files on the system. > >Running the same scenario in permissive mode, I get a series of 100 or >more relabelto denied error messages. The tripwire runs show over 1000 >modified files, which is par for the course after updating glibc. >Here's one of the error messages in full: > > Apr 15 10:36:08 starfury kernel: audit(1113575768.487:0): avc: > denied { relabelto } for pid=22291 exe=/usr/sbin/prelink > name=refer.#prelink#.SULAFf dev=dm-0 ino=13717061 > scontext=root:system_r:prelink_t tcontext=system_u:object_r:bin_t > tclass=file > >As far as I can tell from looking at the policy sources, I shouldn't be >getting any of these errors. There is a (long) line in prelink.te that >explicitly allows relabelto. Wrapped for clarity, it is: > > allow prelink_t { > ifdef(`amanda.te', `amanda_usr_lib_t') > admin_passwd_exec_t > ifdef(`apache.te', `httpd_modules_t') > ifdef(`xserver.te', `xkb_var_lib_t') > ld_so_t su_exec_t texrel_shlib_t > shlib_t sbin_t bin_t lib_t exec_type > }:file { create_file_perms execute relabelto relabelfrom }; > >This line explicitly allows prelink the relabelto permission for bin_t >files, which is what the avc message I copied is complaining about. >I've spot checked some of the other 100 error messages. The majority of >them have a target context of xxx_exec_t and the declaration of the >xxx_exec_t type includes the exec_type attribute, which means the >operation should be allowed based on the policy line above. > >Any suggestions on where to go from here to track down this problem? > >David > > > > This is a bug. I have no idea why it is happening. Steven do you know why? Dan >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- From sds at tycho.nsa.gov Fri Apr 15 21:13:20 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 15 Apr 2005 17:13:20 -0400 Subject: Prelink fails under strict/enforcing In-Reply-To: <42602CD8.2050209@redhat.com> References: <1113583164.17176.12.camel@hampton-pc.rainbolthampton.net> <42602CD8.2050209@redhat.com> Message-ID: <1113599600.3810.167.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-04-15 at 17:06 -0400, Daniel J Walsh wrote: > This is a bug. I have no idea why it is happening. > > Steven do you know why? Per his audit message, prelink is running under "root" identity; file is labeled with "system_u" identity. prelink needs "privowner" attribute. Automated runs of prelink from cron don't have this problem because they run under the system_u identity. -- Stephen Smalley National Security Agency From himainu-ynakam at miomio.jp Mon Apr 18 02:59:45 2005 From: himainu-ynakam at miomio.jp (Yuichi Nakamura) Date: Sun, 17 Apr 2005 22:59:45 -0400 Subject: How can I view logs by dmesg ? Message-ID: <200504180259.j3I2xsie011548@mms-r01.iijmio.jp> Hello. I am trying Fedora Core4 test2. I could not view denied & granted logs by dmesg. After I stopped auditd, I could. Can I view logs by dmesg with auditd running? I like dmesg because it is handy, but I want to use auditd too. --- Yuichi Nakamura Hitachi Software http://www.selinux.hitachi-sk.co.jp/en Japan SELinux Users Group(JSELUG) http://www.selinux.gr.jp/ Japan Open Source Advocacy Organization(JOSAO) http://www.josao.jp/ The George Washington University From jckyau at cs.hku.hk Thu Apr 14 00:43:35 2005 From: jckyau at cs.hku.hk (jckyau at cs.hku.hk) Date: Thu, 14 Apr 2005 08:43:35 +0800 (HKT) Subject: Problem with installing a new harddisk... In-Reply-To: from "jckyau" at Apr 13, 2005 03:04:39 PM Message-ID: <200504140043.j3E0hZa01083@faith.cs.hku.hk> Hello Daniel, dwalsh at redhat.com wrote: > > jckyau cs hku hk wrote: > > > > Hi, > > > > I am very new to SELinux, so, please bear with my ignorance. > > > > I have installed a Fedora Core 3 with SELinux enabled. The system > > has been running pretty stable until I tried to installed a new harddisk > > to my system. The system fails during the booting process if I have my > > new harddisk installed. It stops booting whenever I reach the point of > > setting up the ppp (I rely on a PPPoE line to connect to the Internet). > > But it boots smoothly when I have the new harddisk removed. I think it > > is a problem with SELinux (though I am not sure) as it gives me all > > kinds of complains regarding permissions. > > > > I am pretty sure that it isn't a problem with the harddisk, as this > > harddisk works fine when installed into another computer. I've also > > tried to install another harddisk to my SELinux box, and got the same > > result. Any clue?? > > > > Many thanx in advance! > > > > > > > > It needs to be labeled. > > touch /.autorelabel > shutdown machine > add disk > boot machine > > > -- > Thank you for your reply. However, it didn't work for me. With "/.autorelabel" and my new harddisk installed, the system took a very long time to "relabel" the filesystem at the booting phase (I guess it was my original root filesystem that it was relabeling), and continued with the booting afterwards. But the booting was done (took a very long time), my root filesystem (which is the only filesystem on my original harddisk) was mounted as readonly. Certainly, a system with a readonly root filesystem doesn't do me any good. More suggestions? Thanx! -- Joe Yau.....The Natural Born Uncle!!! +---------------------------------------------------------------------+ | Email: jckyau at cs.hku.hk WWW: http://www.cs.hku.hk/~jckyau | | | | First they ignore you... Then they ridicule at you... | | Then they fight you... Then you win!!! | | -- Mahatma Gandhi | +---------------------------------------------------------------------+ From jckyau at cs.hku.hk Thu Apr 14 19:41:05 2005 From: jckyau at cs.hku.hk (jckyau at cs.hku.hk) Date: Fri, 15 Apr 2005 03:41:05 +0800 (HKT) Subject: Problem with installing a new harddisk... In-Reply-To: <425E5385.1040807@redhat.com> from "Daniel J Walsh" at Apr 14, 2005 07:27:01 AM Message-ID: <200504141941.j3EJf5M12687@faith.cs.hku.hk> On Thu Apr 14 19:27:01 2005, Daniel J Walsh wrote: > > jckyau at cs.hku.hk wrote: > > >Hello Daniel, > > > >dwalsh at redhat.com wrote: > > > > > >>jckyau cs hku hk wrote: > >> > >> > >>>Hi, > >>> > >>>I am very new to SELinux, so, please bear with my ignorance. > >>> > >>>I have installed a Fedora Core 3 with SELinux enabled. The system > >>>has been running pretty stable until I tried to installed a new harddisk > >>>to my system. The system fails during the booting process if I have my > >>>new harddisk installed. It stops booting whenever I reach the point of > >>>setting up the ppp (I rely on a PPPoE line to connect to the Internet). > >>>But it boots smoothly when I have the new harddisk removed. I think it > >>>is a problem with SELinux (though I am not sure) as it gives me all > >>>kinds of complains regarding permissions. > >>> > >>>I am pretty sure that it isn't a problem with the harddisk, as this > >>>harddisk works fine when installed into another computer. I've also > >>>tried to install another harddisk to my SELinux box, and got the same > >>>result. Any clue?? > >>> > >>>Many thanx in advance! > >>> > >>> > >>> > >>> > >>> > >>It needs to be labeled. > >> > >>touch /.autorelabel > >>shutdown machine > >>add disk > >>boot machine > >> > >> > >>-- > >> > >> > >> > > Thank you for your reply. However, it didn't work for me. With > > "/.autorelabel" and my new harddisk installed, the system took a > > very long time to "relabel" the filesystem at the booting phase > > (I guess it was my original root filesystem that it was relabeling), > > and continued with the booting afterwards. But the booting was done > > (took a very long time), my root filesystem (which is the only > > filesystem on my original harddisk) was mounted as readonly. > > Certainly, a system with a readonly root filesystem doesn't do me any > > good. More suggestions? > > > > Thanx! > > > > > > > What kind of log messages are you getting? What file system are you using? > Can you boot successfully with enfocing=0 on the kernel line? > > Dan > > -- > > Thank you, Dan, for your prompt reply. "Lonely Wolf" is correct. It was a problem of the "labeling" of filesystems. My "new" harddisk was an old one which has a copy of linux from years ago. After playing around with the fstab and the boot up options, I can finally get the thing to boot. Many thx to both of you. Regards, -- Joe Yau.....The Natural Born Uncle!!! +---------------------------------------------------------------------+ | Email: jckyau at cs.hku.hk WWW: http://www.cs.hku.hk/~jckyau | | | | First they ignore you... Then they ridicule at you... | | Then they fight you... Then you win!!! | | -- Mahatma Gandhi | +---------------------------------------------------------------------+ From sds at tycho.nsa.gov Mon Apr 18 12:09:08 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 18 Apr 2005 08:09:08 -0400 Subject: How can I view logs by dmesg ? In-Reply-To: <200504180259.j3I2xsie011548@mms-r01.iijmio.jp> References: <200504180259.j3I2xsie011548@mms-r01.iijmio.jp> Message-ID: <1113826148.28051.18.camel@moss-spartans.epoch.ncsc.mil> On Sun, 2005-04-17 at 22:59 -0400, Yuichi Nakamura wrote: > Hello. > I am trying Fedora Core4 test2. > > I could not view denied & granted logs by dmesg. > After I stopped auditd, I could. > Can I view logs by dmesg with auditd running? > > I like dmesg because it is handy, but I want to use auditd too. With auditd running, audit messages are directed to /var/log/audit/audit.log or whatever file is specified by /etc/auditd.conf. -- Stephen Smalley National Security Agency From russell at coker.com.au Mon Apr 18 10:36:40 2005 From: russell at coker.com.au (Russell Coker) Date: Mon, 18 Apr 2005 20:36:40 +1000 Subject: Experiences with selinux enabled targetted on Fedora Core 3 In-Reply-To: <200502220115.j1M1Fn7i013604@turing-police.cc.vt.edu> References: <20050221160539.6aba22bd.r.godzilla@comcast.net> <200502220115.j1M1Fn7i013604@turing-police.cc.vt.edu> Message-ID: <200504182036.42642.russell@coker.com.au> On Tuesday 22 February 2005 12:15, Valdis.Kletnieks at vt.edu wrote: > At least at one point in time, I was seeing random avc errors on mount > points that made absolutely no sense - I'd do an 'ls -Z' and it would look > OK. Finally twigged in that I needed to unmount the file system, relabel > the *directory*, and then remount. Seem to remember /usr/share and > /usr/local biting me that way (/, /usr, /usr/local, and /usr/share are 4 > different file systems on my box). In those cases a dontaudit rule will usually do the job. If the file system is not mounted then there's nothing that the application can usefully do under the mount point and usually ENOENT and EACCESS usually get the same code paths in most applications that try to open files. grep dontaudit.*file_t.dir policy.conf The above grep command will show you some of the dontaudit rules that have already been put in place to deal with this. If there are more domains that may get used early in the boot process to get such errors then let us know and we'll write dontaudit rules. -- 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 Valdis.Kletnieks at vt.edu Tue Apr 19 02:25:58 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 18 Apr 2005 22:25:58 -0400 Subject: Experiences with selinux enabled targetted on Fedora Core 3 In-Reply-To: Your message of "Mon, 18 Apr 2005 20:36:40 +1000." <200504182036.42642.russell@coker.com.au> References: <20050221160539.6aba22bd.r.godzilla@comcast.net> <200502220115.j1M1Fn7i013604@turing-police.cc.vt.edu> <200504182036.42642.russell@coker.com.au> Message-ID: <200504190226.j3J2Q41S008297@turing-police.cc.vt.edu> On Mon, 18 Apr 2005 20:36:40 +1000, Russell Coker said: > On Tuesday 22 February 2005 12:15, Valdis.Kletnieks at vt.edu wrote: > > At least at one point in time, I was seeing random avc errors on mount > > points that made absolutely no sense - I'd do an 'ls -Z' and it would look > > OK. Finally twigged in that I needed to unmount the file system, relabel > > the *directory*, and then remount. Seem to remember /usr/share and > > /usr/local biting me that way (/, /usr, /usr/local, and /usr/share are 4 > > different file systems on my box). > > In those cases a dontaudit rule will usually do the job. If the file system > is not mounted then there's nothing that the application can usefully do > under the mount point and usually ENOENT and EACCESS usually get the same > code paths in most applications that try to open files. In my case, actually labelling the directories correctly was the better fix. What I got bit by was that all previous relabels had happened with filesystems mounted - so (for instance) the directory seen as /usr got labelled as usr_t. During early boot, I'd have a complaint about it being something else, I'd go back and check it, and it was usr_t. Finally brought the box up in very single-user, unmounted /usr - and the underlying directory *wasn't* usr_t... ;) Found out /boot and /var had similar issues, cleared up by relabelling the mountpoint directories... Not sure if/how to fix this for the general case - it almost requires multiple passes - first labelling / (so mountpoint dirs like /boot and /usr and /var get labelled), then mounting those filesystems and labelling them, then repeating for any subdirs (on my laptop, /usr/share and /usr/local bit me, on another box that hosts a database it's /var/lib/mysql). (For all I know, the current 'filesystems' RPM gets this all correct for new systems and boot-from-CD based upgrades, and I got bit only because I've just 'rpm -Fvh'-ed all the way along, and not done a clean install). Personally, I'm not thrilled by the idea of sticking in dontaudit rules to quiet complaints at boot time that are caused by directories that are mislabelled. Thoughts? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From russell at coker.com.au Tue Apr 19 04:20:58 2005 From: russell at coker.com.au (Russell Coker) Date: Tue, 19 Apr 2005 14:20:58 +1000 Subject: Experiences with selinux enabled targetted on Fedora Core 3 In-Reply-To: <200504190226.j3J2Q41S008297@turing-police.cc.vt.edu> References: <20050221160539.6aba22bd.r.godzilla@comcast.net> <200504182036.42642.russell@coker.com.au> <200504190226.j3J2Q41S008297@turing-police.cc.vt.edu> Message-ID: <200504191421.01381.russell@coker.com.au> On Tuesday 19 April 2005 12:25, Valdis.Kletnieks at vt.edu wrote: > > In those cases a dontaudit rule will usually do the job. If the file > > system is not mounted then there's nothing that the application can > > usefully do under the mount point and usually ENOENT and EACCESS usually > > get the same code paths in most applications that try to open files. > > In my case, actually labelling the directories correctly was the better > fix. For you maybe. In a general sense it isn't. We have no automatic system for using umount or mount --bind to allow labelling of such mount points and we can't expect most users to be able to do it. > Personally, I'm not thrilled by the idea of sticking in dontaudit rules to > quiet complaints at boot time that are caused by directories that are > mislabelled. Why not? -- 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 christofer.c.bell at gmail.com Tue Apr 19 13:07:40 2005 From: christofer.c.bell at gmail.com (Christofer C. Bell) Date: Tue, 19 Apr 2005 08:07:40 -0500 Subject: Experiences with selinux enabled targetted on Fedora Core 3 In-Reply-To: <200504191421.01381.russell@coker.com.au> References: <20050221160539.6aba22bd.r.godzilla@comcast.net> <200504182036.42642.russell@coker.com.au> <200504190226.j3J2Q41S008297@turing-police.cc.vt.edu> <200504191421.01381.russell@coker.com.au> Message-ID: <143f0f6c050419060714ce0f8d@mail.gmail.com> On 4/18/05, Russell Coker wrote: > On Tuesday 19 April 2005 12:25, Valdis.Kletnieks at vt.edu wrote: > > > Personally, I'm not thrilled by the idea of sticking in dontaudit rules to > > quiet complaints at boot time that are caused by directories that are > > mislabelled. > > Why not? I can't speak for Valdis, but for me the word "kludge" comes to mind. -- Chris () ASCII Ribbon Campaign! /\ Say NO to HTML in Mail and News! From satchmomc at verizon.net Wed Apr 20 01:59:36 2005 From: satchmomc at verizon.net (Seth Chambers) Date: Tue, 19 Apr 2005 21:59:36 -0400 Subject: Sound difficulties. Message-ID: <1113962376.5780.9.camel@localhost.localdomain> I am a new Linux user, having installed FC 3 one week ago. Im having difficulty getting my sound card to work. FC 3 comes with Alsa pre- installed, and it does detect the card, and the driver, snd-emu10k1, has been installed. The sound card is a Soundblaster Live 5.1 by Creative Labs. The error message that I receive when I use aumix is error: error opening mixer. The error message I receive when I try using alsamixer isalsamixer: function snd_ctl_open failed for default: No such device. Any help with this problem would be much appreciated. Also, the device does work in XP. Thanks in advance. From russell at coker.com.au Wed Apr 20 06:21:43 2005 From: russell at coker.com.au (Russell Coker) Date: Wed, 20 Apr 2005 16:21:43 +1000 Subject: Experiences with selinux enabled targetted on Fedora Core 3 In-Reply-To: <143f0f6c050419060714ce0f8d@mail.gmail.com> References: <20050221160539.6aba22bd.r.godzilla@comcast.net> <200504191421.01381.russell@coker.com.au> <143f0f6c050419060714ce0f8d@mail.gmail.com> Message-ID: <200504201621.46953.russell@coker.com.au> On Tuesday 19 April 2005 23:07, "Christofer C. Bell" wrote: > On 4/18/05, Russell Coker wrote: > > On Tuesday 19 April 2005 12:25, Valdis.Kletnieks at vt.edu wrote: > > > Personally, I'm not thrilled by the idea of sticking in dontaudit rules > > > to quiet complaints at boot time that are caused by directories that > > > are mislabelled. > > > > Why not? > > I can't speak for Valdis, but for me the word "kludge" comes to mind. It's not a kludge. The purpose of dontaudit rules is to prevent auditing of operations that are not permitted, not interesting, and expected to happen. This is exactly the situation. Using dontaudit rules for such things also gives correct behavior in situations where relabelling will not. As an example there is the following rule: dontaudit lvm_t file_t:dir search; Without this rule the lvm utilities when run before /var is mounted would create the /var/lock directory on the mount-point. This is not desired functionality, the machine is in single-user mode at the time (so the lack of locking is not a problem) and creating directories that later get hidden by mounting a file system is not desirable. So far no-one has provided any reasons not to use dontaudit rules. Accusations of kludging don't count as a reason. I don't consider file_t labelling for a mount point as "mislabelling". The mount point directory is expected to be hidden, so generally only mount needs to access 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 rhally at mindspring.com Wed Apr 20 09:22:49 2005 From: rhally at mindspring.com (Richard Hally) Date: Wed, 20 Apr 2005 05:22:49 -0400 Subject: Experiences with selinux enabled targetted on Fedora Core 3 In-Reply-To: <200504201621.46953.russell@coker.com.au> References: <20050221160539.6aba22bd.r.godzilla@comcast.net> <200504191421.01381.russell@coker.com.au> <143f0f6c050419060714ce0f8d@mail.gmail.com> <200504201621.46953.russell@coker.com.au> Message-ID: <42661F69.30102@mindspring.com> Russell Coker wrote: >On Tuesday 19 April 2005 23:07, "Christofer C. Bell" > wrote: > > >>On 4/18/05, Russell Coker wrote: >> >> >>>On Tuesday 19 April 2005 12:25, Valdis.Kletnieks at vt.edu wrote: >>> >>> >>>>Personally, I'm not thrilled by the idea of sticking in dontaudit rules >>>>to quiet complaints at boot time that are caused by directories that >>>>are mislabelled. >>>> >>>> >>>Why not? >>> >>> >>I can't speak for Valdis, but for me the word "kludge" comes to mind. >> >> > >It's not a kludge. The purpose of dontaudit rules is to prevent auditing of >operations that are not permitted, not interesting, and expected to happen. >This is exactly the situation. > >Using dontaudit rules for such things also gives correct behavior in >situations where relabelling will not. As an example there is the following >rule: >dontaudit lvm_t file_t:dir search; > >Without this rule the lvm utilities when run before /var is mounted would >create the /var/lock directory on the mount-point. This is not desired >functionality, the machine is in single-user mode at the time (so the lack of >locking is not a problem) and creating directories that later get hidden by >mounting a file system is not desirable. > >So far no-one has provided any reasons not to use dontaudit rules. >Accusations of kludging don't count as a reason. > >I don't consider file_t labelling for a mount point as "mislabelling". The >mount point directory is expected to be hidden, so generally only mount needs >to access it. > > > I for one consider the use of "dontaudit" to be unethical but that is just my opinion. Think about preventing someone's software from doing what was designed and implemented to do. Shouldn't you at least notify the developer/maintainer that there is a problem with their software? That seems to be the correct thing to do in the open source community. If there is a actual security problem shouldn't there be some notification of the vulnerability as a minimum? If it is not an actual security vulnerability but perhaps a theoretical one, a proof of concept is usually appropriate. If it is a violation of some generally accepted standard, isn't a bugzilla the right thing to do? If it is a "bad idea" according to some peculiar distro's group-think approach to Linux, isn't the thing to do, let the developer know what you think as a minimum? If you have to use dontaudit rules to get "correct" behavior from some software doesn't that indicated that the software needs to be changed(better design or better implementation or RFE)? If some software contains some "not desired functionality", isn't it incumbent upon the person that makes that assertion to at least explain the situation to the developer/maintainer so that they have the opportunity to make a change or refute the assertion? If some action by the software is "uninteresting" shouldn't it be allowed absent some reason that makes it in fact "interesting"? Then there is the "conspiracy theory" point of view where someone says "Hey, NSA is using that SELinux to change the behavior of programs and not telling anyone that they are doing it." I would like to hear what others think of this "dontaudit considered harmful" idea. I understand the use of dontaudit as a temporary expedient but other than that it seem that there should be more done about the situations where it is used at least in terms of notifying the developers/maintainers of the software involved. Richard Hally From christofer.c.bell at gmail.com Wed Apr 20 18:50:07 2005 From: christofer.c.bell at gmail.com (Christofer C. Bell) Date: Wed, 20 Apr 2005 13:50:07 -0500 Subject: Experiences with selinux enabled targetted on Fedora Core 3 In-Reply-To: <200504201621.46953.russell@coker.com.au> References: <20050221160539.6aba22bd.r.godzilla@comcast.net> <200504191421.01381.russell@coker.com.au> <143f0f6c050419060714ce0f8d@mail.gmail.com> <200504201621.46953.russell@coker.com.au> Message-ID: <143f0f6c050420115054e903a5@mail.gmail.com> On 4/20/05, Russell Coker wrote: > On Tuesday 19 April 2005 23:07, "Christofer C. Bell" > wrote: > > On 4/18/05, Russell Coker wrote: > > > On Tuesday 19 April 2005 12:25, Valdis.Kletnieks at vt.edu wrote: > > > > Personally, I'm not thrilled by the idea of sticking in dontaudit rules > > > > to quiet complaints at boot time that are caused by directories that > > > > are mislabelled. > > > > > > Why not? > > > > I can't speak for Valdis, but for me the word "kludge" comes to mind. > > It's not a kludge. The purpose of dontaudit rules is to prevent auditing of > operations that are not permitted, not interesting, and expected to happen. > This is exactly the situation. You say that dontaudit rules are to cover the following circumstances: 1. Not permitted. 2. Not interesting. 3. Expected to happen. That's not what's going on here and using dontaudit is a kludge. The OP is stating that *mount points* for /usr, /usr/local, and /usr/share are generating complaints because they're not properly labled prior to being mounted. These are the directories themselves and not directories that are hidden by the mount. This is "interesting" and "not expected to happen," failing points 2 and 3. Regardless if the fix can be automated or not, telling the system to "just ignore it" is inappropriate IMO. -- Chris () ASCII Ribbon Campaign! /\ Say NO to HTML in Mail and News! From mike at flyn.org Wed Apr 20 19:10:44 2005 From: mike at flyn.org (W. Michael Petullo) Date: Wed, 20 Apr 2005 14:10:44 -0500 Subject: Experiences with selinux enabled targetted on Fedora Core 3 In-Reply-To: <143f0f6c050420115054e903a5@mail.gmail.com> References: <20050221160539.6aba22bd.r.godzilla@comcast.net> <200504191421.01381.russell@coker.com.au> <143f0f6c050419060714ce0f8d@mail.gmail.com> <200504201621.46953.russell@coker.com.au> <143f0f6c050420115054e903a5@mail.gmail.com> Message-ID: <20050420191044.GA16126@imp.flyn.org> >>>>> Personally, I'm not thrilled by the idea of sticking in dontaudit rules >>>>> to quiet complaints at boot time that are caused by directories that >>>>> are mislabelled. >>>> Why not? >>> I can't speak for Valdis, but for me the word "kludge" comes to mind. >> It's not a kludge. The purpose of dontaudit rules is to prevent auditing of >> operations that are not permitted, not interesting, and expected to happen. >> This is exactly the situation. > You say that dontaudit rules are to cover the following circumstances: > > 1. Not permitted. > 2. Not interesting. > 3. Expected to happen. > > That's not what's going on here and using dontaudit is a kludge. The > OP is stating that *mount points* for /usr, /usr/local, and > /usr/share are generating complaints because they're not properly > labled prior to being mounted. These are the directories themselves > and not directories that are hidden by the mount. This is > "interesting" and "not expected to happen," failing points 2 and 3. > > Regardless if the fix can be automated or not, telling the system to > "just ignore it" is inappropriate IMO. One thing I have noticed is that dontaudit messages occasionally get in the way when trying to modify the policy. When using the strict policy, I've had a few situations where something was denied by SELinux but not audited and I had trouble determining what rules where blocking the operation. -- Mike :wq From dwalsh at redhat.com Wed Apr 20 19:59:31 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 20 Apr 2005 15:59:31 -0400 Subject: Experiences with selinux enabled targetted on Fedora Core 3 In-Reply-To: <20050420191044.GA16126@imp.flyn.org> References: <20050221160539.6aba22bd.r.godzilla@comcast.net> <200504191421.01381.russell@coker.com.au> <143f0f6c050419060714ce0f8d@mail.gmail.com> <200504201621.46953.russell@coker.com.au> <143f0f6c050420115054e903a5@mail.gmail.com> <20050420191044.GA16126@imp.flyn.org> Message-ID: <4266B4A3.3070101@redhat.com> W. Michael Petullo wrote: >>>>>>Personally, I'm not thrilled by the idea of sticking in dontaudit rules >>>>>>to quiet complaints at boot time that are caused by directories that >>>>>>are mislabelled. >>>>>> >>>>>> > > > >>>>>Why not? >>>>> >>>>> > > > >>>>I can't speak for Valdis, but for me the word "kludge" comes to mind. >>>> >>>> > > > >>>It's not a kludge. The purpose of dontaudit rules is to prevent auditing of >>>operations that are not permitted, not interesting, and expected to happen. >>>This is exactly the situation. >>> >>> > > > >>You say that dontaudit rules are to cover the following circumstances: >> >>1. Not permitted. >>2. Not interesting. >>3. Expected to happen. >> >>That's not what's going on here and using dontaudit is a kludge. The >>OP is stating that *mount points* for /usr, /usr/local, and >>/usr/share are generating complaints because they're not properly >>labled prior to being mounted. These are the directories themselves >>and not directories that are hidden by the mount. This is >>"interesting" and "not expected to happen," failing points 2 and 3. >> >>Regardless if the fix can be automated or not, telling the system to >>"just ignore it" is inappropriate IMO. >> >> > >One thing I have noticed is that dontaudit messages occasionally get in >the way when trying to modify the policy. When using the strict policy, >I've had a few situations where something was denied by SELinux but >not audited and I had trouble determining what rules where blocking >the operation. > > > You can turn off the dontaudit rules by executing in the policy src dir make enableaudit make load -- From russell at coker.com.au Wed Apr 20 23:27:06 2005 From: russell at coker.com.au (Russell Coker) Date: Thu, 21 Apr 2005 09:27:06 +1000 Subject: Experiences with selinux enabled targetted on Fedora Core 3 In-Reply-To: <42661F69.30102@mindspring.com> References: <20050221160539.6aba22bd.r.godzilla@comcast.net> <200504201621.46953.russell@coker.com.au> <42661F69.30102@mindspring.com> Message-ID: <200504210927.10015.russell@coker.com.au> On Wednesday 20 April 2005 19:22, Richard Hally wrote: > >Using dontaudit rules for such things also gives correct behavior in > >situations where relabelling will not. As an example there is the > > following rule: > >dontaudit lvm_t file_t:dir search; > > > >Without this rule the lvm utilities when run before /var is mounted would > >create the /var/lock directory on the mount-point. This is not desired > >functionality, the machine is in single-user mode at the time (so the lack > > of locking is not a problem) and creating directories that later get > > hidden by mounting a file system is not desirable. > > > >So far no-one has provided any reasons not to use dontaudit rules. > >Accusations of kludging don't count as a reason. > > > >I don't consider file_t labelling for a mount point as "mislabelling". > > The mount point directory is expected to be hidden, so generally only > > mount needs to access it. > > I for one consider the use of "dontaudit" to be unethical but that is > just my opinion. Why is it unethical to make software perform correctly even when it is not written to? > Think about preventing someone's software from doing what was designed > and implemented to do. Shouldn't you at least notify the > developer/maintainer that there is a problem with their software? That Yes, I do that. I don't always notify them first. The first priority is to get the policy fixed, if I don't do it then someone else may do it and do it badly (see this thread as an example). > seems to be the correct thing to do in the open source community. > If there is a actual security problem shouldn't there be some > notification of the vulnerability as a minimum? If it is not an actual > security vulnerability but perhaps a theoretical one, a proof of concept > is usually appropriate. If it's a functionality issue such as creating a directory /var/lock on the root file system when /var is a mount point then it's not such a big deal. > If it is a violation of some generally accepted standard, isn't a > bugzilla the right thing to do? Yes. Of course there are other considerations. Sometimes I already have some open bug reports and don't feel inclined to make minor bug reports when more serious bugs are open. > If some action by the software is "uninteresting" shouldn't it be > allowed absent some reason that makes it in fact "interesting"? Searching a directory of type file_t that is an empty mount point isn't interesting. If however a directory that shouldn't be accessed by the program in question gets type file_t through file system corruption or other errors then we do not want to allow such access. > I would like to hear what others think of this "dontaudit considered > harmful" idea. I understand the use of dontaudit as a temporary > expedient but other than that it seem that there should be more done > about the situations where it is used at least in terms of notifying the > developers/maintainers of the software involved. Why don't you go through the policy, remove a bunch of dontaudit rules and see what happens. -- 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 russell at coker.com.au Thu Apr 21 04:13:29 2005 From: russell at coker.com.au (Russell Coker) Date: Thu, 21 Apr 2005 14:13:29 +1000 Subject: Experiences with selinux enabled targetted on Fedora Core 3 In-Reply-To: <143f0f6c050420115054e903a5@mail.gmail.com> References: <20050221160539.6aba22bd.r.godzilla@comcast.net> <200504201621.46953.russell@coker.com.au> <143f0f6c050420115054e903a5@mail.gmail.com> Message-ID: <200504211413.32072.russell@coker.com.au> On Thursday 21 April 2005 04:50, "Christofer C. Bell" wrote: > > > I can't speak for Valdis, but for me the word "kludge" comes to mind. > > > > It's not a kludge. The purpose of dontaudit rules is to prevent auditing > > of operations that are not permitted, not interesting, and expected to > > happen. This is exactly the situation. > > You say that dontaudit rules are to cover the following circumstances: > > 1. Not permitted. > 2. Not interesting. > 3. Expected to happen. > > That's not what's going on here and using dontaudit is a kludge. The > OP is stating that *mount points* for /usr, /usr/local, and > /usr/share are generating complaints because they're not properly > labled prior to being mounted. These are the directories themselves > and not directories that are hidden by the mount. This is > "interesting" and "not expected to happen," failing points 2 and 3. It is not interesting that programs try to access files under mount points early in the boot process before the file systems are mounted. It happens on every boot. It is expected to happen, it happens on every boot. > Regardless if the fix can be automated or not, telling the system to > "just ignore it" is inappropriate IMO. The alternatives are as follows: 1) Have the users manually relabel. But this requires that they have the skill needed to use mount --bind or single user mode. 2) Have more error messages in the logs. This leads to users ignoring the more important AVC messages which is a security issue. 3) Have more complex code in rc.sysinit for relabeling file systems (which is therefore more error prone) and also remove the possibility of running "fixfiles relabel" as administrator and forcing a reboot with /.autorelabel . All the options have disadvantages that I consider to be more serious than the reasons that make you dislike the dontaudit rule. Option 3 is the only remotely viable option. That requires implementing shell code equivalent for "mount -a -t nonfs,nfs4,smbfs,ncpfs,cifs,gfs -O no_netdev" to allow running setfiles between mounts. I don't think that we want to do this. Feel free to disbelieve me, but if so spend a month writing policy in the manner you advocate and see where it gets you. If that doesn't convince you then spend a year or two writing policy and see if your opinion changes. -- 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 mroselinux at eastgranby.k12.ct.us Thu Apr 21 14:54:38 2005 From: mroselinux at eastgranby.k12.ct.us (mroselinux at eastgranby.k12.ct.us) Date: Thu, 21 Apr 2005 10:54:38 -0400 (EDT) Subject: Backup server question In-Reply-To: <200504211413.32072.russell@coker.com.au> References: <20050221160539.6aba22bd.r.godzilla@comcast.net> <200504201621.46953.russell@coker.com.au> <143f0f6c050420115054e903a5@mail.gmail.com> <200504211413.32072.russell@coker.com.au> Message-ID: <1930.24.2.210.202.1114095278.squirrel@mail.eastgranby.k12.ct.us> We have a FC3 server running samba, dhcpd, and named (for internal names only). Each night, a backup server to the primary runs rsync to download changed/new files. This is a vacation week at our high school and I tried our backup plan for the first time since upgrading to FC3. When bringing up the backup server as primary, I ran into a security problem with dhcpd (dhcpd: Can't open lease database /var/lib/dhcp/dhcpd.leases: Permission denied). I issued a setforce 0 command and restarted dhcpd and all was ok. I then again stopped dhcpd, issued a setenforce 1 command, restarted dhcpd and again all was ok. So, should I be running fixfiles each night at the end of the rsync script? Or is there a better solution that someone with expertise can suggest? Mark Orenstein East Granby, CT School System From sds at tycho.nsa.gov Thu Apr 21 14:55:42 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 21 Apr 2005 10:55:42 -0400 Subject: Backup server question In-Reply-To: <1930.24.2.210.202.1114095278.squirrel@mail.eastgranby.k12.ct.us> References: <20050221160539.6aba22bd.r.godzilla@comcast.net> <200504201621.46953.russell@coker.com.au> <143f0f6c050420115054e903a5@mail.gmail.com> <200504211413.32072.russell@coker.com.au> <1930.24.2.210.202.1114095278.squirrel@mail.eastgranby.k12.ct.us> Message-ID: <1114095342.4054.145.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-04-21 at 10:54 -0400, mroselinux at eastgranby.k12.ct.us wrote: > We have a FC3 server running samba, dhcpd, and named (for internal names > only). Each night, a backup server to the primary runs rsync to download > changed/new files. > > This is a vacation week at our high school and I tried our backup plan for > the first time since upgrading to FC3. When bringing up the backup server > as primary, I ran into a security problem with dhcpd (dhcpd: Can't open > lease database /var/lib/dhcp/dhcpd.leases: Permission denied). I issued a > setforce 0 command and restarted dhcpd and all was ok. I then again > stopped dhcpd, issued a setenforce 1 command, restarted dhcpd and again > all was ok. > > So, should I be running fixfiles each night at the end of the rsync > script? Or is there a better solution that someone with expertise can > suggest? I think that the FC4/development tree includes a patch to rsync to allow preservation of extended attributes (which would include the SELinux attributes). Hence, you might try building the development rsync SRPM on FC3 and trying it there (using the -X option). You need the updated rsync on both the client and server. Naturally, you'd want to test it out somewhere other than your production machine first. -- Stephen Smalley National Security Agency From bench at silentmedia.com Thu Apr 21 17:02:02 2005 From: bench at silentmedia.com (Ben) Date: Thu, 21 Apr 2005 10:02:02 -0700 (PDT) Subject: targeted policy and apache(?) Message-ID: I'm seeing avc errors, and it's pretty unclear to me what's causing them. What's being complained about, here? 1 Time(s): audit(1113980474.264:0): avc: denied { search } for pid=7148 exe=/bin/bash name=log dev=md0 ino=3260417 scontext=root:system_r:httpd_sys_script_t tcontext=system_u:object_r:var_log_t tclass=dir I would guess that some script is trying to list a log directory on /dev/md0, but that's about all I can guess from this and it doesn't help me track it down to a useful level anyway. From sds at tycho.nsa.gov Thu Apr 21 17:00:58 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 21 Apr 2005 13:00:58 -0400 Subject: targeted policy and apache(?) In-Reply-To: References: Message-ID: <1114102858.4054.187.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-04-21 at 10:02 -0700, Ben wrote: > I'm seeing avc errors, and it's pretty unclear to me what's causing them. > What's being complained about, here? > > 1 Time(s): audit(1113980474.264:0): avc: denied { search } for pid=7148 > exe=/bin/bash name=log dev=md0 ino=3260417 > scontext=root:system_r:httpd_sys_script_t > tcontext=system_u:object_r:var_log_t tclass=dir > > > I would guess that some script is trying to list a log directory on > /dev/md0, but that's about all I can guess from this and it doesn't help > me track it down to a useful level anyway. Not list, just perform a lookup, e.g a CGI script is attempting to access something under /var/log (requiring search access to the log directory), and this is denied in the policy. Note that you can sometimes get more information by enabling system call auditing, e.g. use auditctl -e 1 or boot your kernel with audit=1; the audit framework will then output a separate syscall audit record upon syscall exit after any such avc messages with the relevant syscall and arguments. Likely your script wants to append to log files under /var/log/httpd. Looks like the current policy allows httpd itself to do this, but not CGI scripts. -- Stephen Smalley National Security Agency From tdiehl at rogueind.com Thu Apr 21 18:27:13 2005 From: tdiehl at rogueind.com (Tom Diehl) Date: Thu, 21 Apr 2005 14:27:13 -0400 (EDT) Subject: Rawhide avc messages Message-ID: Hi all, I have a laptop that I have installed rawhide on. For the last few days I have been getting the following avc messages: Apr 21 11:38:36 bullwinkle kernel: audit(1114097912.824:0): avc: denied { sys_admin } for pid=1878 exe=/sbin/consoletype capability=21 scontext=user_u:system_r:dhcpc_t tcontext=user_u:system_r:dhcpc_t tclass=capability Apr 21 11:38:36 bullwinkle kernel: audit(1114097914.047:0): avc: denied { sys_admin } for pid=1907 exe=/sbin/consoletype capability=21 scontext=user_u:system_r:dhcpc_t tcontext=user_u:system_r:dhcpc_t tclass=capability Apr 21 11:38:36 bullwinkle kernel: audit(1114097914.302:0): avc: denied { rename } for pid=1952 exe=/bin/mv name=ntp.conf dev=dm-0 ino=102686 scontext=user_u:system_r:dhcpc_t tcontext=user_u:object_r:etc_t tclass=file Apr 21 11:38:36 bullwinkle kernel: audit(1114097914.305:0): avc: denied { append } for pid=1905 exe=/bin/bash name=ntp.conf dev=dm-0 ino=102686 scontext=user_u:system_r:dhcpc_t tcontext=user_u:object_r:etc_t tclass=file Apr 21 11:38:36 bullwinkle kernel: audit(1114097914.305:0): avc: denied { append } for pid=1905 exe=/bin/bash name=ntp.conf dev=dm-0 ino=102686 scontext=user_u:system_r:dhcpc_t tcontext=user_u:object_r:etc_t tclass=file Apr 21 11:38:36 bullwinkle kernel: audit(1114097914.311:0): avc: denied { append } for pid=1905 exe=/bin/bash name=ntp.conf dev=dm-0 ino=102686 scontext=user_u:system_r:dhcpc_t tcontext=user_u:object_r:etc_t tclass=file Apr 21 11:38:36 bullwinkle kernel: audit(1114097914.312:0): avc: denied { append } for pid=1905 exe=/bin/bash name=ntp.conf dev=dm-0 ino=102686 scontext=user_u:system_r:dhcpc_t tcontext=user_u:object_r:etc_t tclass=file Apr 21 11:38:36 bullwinkle last message repeated 2 times Apr 21 11:38:36 bullwinkle kernel: audit(1114097914.495:0): avc: denied { sys_admin } for pid=1965 exe=/sbin/consoletype capability=21 scontext=user_u:system_r:dhcpc_t tcontext=user_u:system_r:dhcpc_t tclass=capability Apr 21 11:38:36 bullwinkle kernel: audit(1114097916.060:0): avc: denied { setsched } for pid=2048 exe=/sbin/auditd scontext=user_u:system_r:auditd_t tcontext=user_u:system_r:auditd_t tclass=process Apr 21 11:38:36 bullwinkle kernel: SELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses genfs_contexts Can someone if this should be in bugzilla or what to do to fix this? (bullwinkle pts10) # rpm -qa | grep selinux selinux-policy-targeted-1.23.12-1 libselinux-1.23.7-2 libselinux-devel-1.23.7-2 (bullwinkle pts10) # rpm -qa | grep audit audit-libs-0.6.12-1 audit-0.6.12-1 (bullwinkle pts10) # Regards, Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From gamcgee6019 at verizon.net Thu Apr 21 19:22:07 2005 From: gamcgee6019 at verizon.net (Gary A. McGee) Date: Thu, 21 Apr 2005 14:22:07 -0500 Subject: Rawhide avc messages In-Reply-To: References: Message-ID: <4267FD5F.8070503@verizon.net> Tom Diehl wrote: > Hi all, > > I have a laptop that I have installed rawhide on. For the last few days I have been > getting the following avc messages: > > Apr 21 11:38:36 bullwinkle kernel: audit(1114097912.824:0): avc: denied { sys_admin } for pid=1878 exe=/sbin/consoletype capability=21 scontext=user_u:system_r:dhcpc_t tcontext=user_u:system_r:dhcpc_t tclass=capability > Apr 21 11:38:36 bullwinkle kernel: audit(1114097914.047:0): avc: denied { sys_admin } for pid=1907 exe=/sbin/consoletype capability=21 scontext=user_u:system_r:dhcpc_t tcontext=user_u:system_r:dhcpc_t tclass=capability > Apr 21 11:38:36 bullwinkle kernel: audit(1114097914.302:0): avc: denied { rename } for pid=1952 exe=/bin/mv name=ntp.conf dev=dm-0 ino=102686 scontext=user_u:system_r:dhcpc_t tcontext=user_u:object_r:etc_t tclass=file > Apr 21 11:38:36 bullwinkle kernel: audit(1114097914.305:0): avc: denied { append } for pid=1905 exe=/bin/bash name=ntp.conf dev=dm-0 ino=102686 scontext=user_u:system_r:dhcpc_t tcontext=user_u:object_r:etc_t tclass=file > Apr 21 11:38:36 bullwinkle kernel: audit(1114097914.305:0): avc: denied { append } for pid=1905 exe=/bin/bash name=ntp.conf dev=dm-0 ino=102686 scontext=user_u:system_r:dhcpc_t tcontext=user_u:object_r:etc_t tclass=file > Apr 21 11:38:36 bullwinkle kernel: audit(1114097914.311:0): avc: denied { append } for pid=1905 exe=/bin/bash name=ntp.conf dev=dm-0 ino=102686 scontext=user_u:system_r:dhcpc_t tcontext=user_u:object_r:etc_t tclass=file > Apr 21 11:38:36 bullwinkle kernel: audit(1114097914.312:0): avc: denied { append } for pid=1905 exe=/bin/bash name=ntp.conf dev=dm-0 ino=102686 scontext=user_u:system_r:dhcpc_t tcontext=user_u:object_r:etc_t tclass=file > Apr 21 11:38:36 bullwinkle last message repeated 2 times > Apr 21 11:38:36 bullwinkle kernel: audit(1114097914.495:0): avc: denied { sys_admin } for pid=1965 exe=/sbin/consoletype capability=21 scontext=user_u:system_r:dhcpc_t tcontext=user_u:system_r:dhcpc_t tclass=capability > Apr 21 11:38:36 bullwinkle kernel: audit(1114097916.060:0): avc: denied { setsched } for pid=2048 exe=/sbin/auditd scontext=user_u:system_r:auditd_t tcontext=user_u:system_r:auditd_t tclass=process > Apr 21 11:38:36 bullwinkle kernel: SELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses genfs_contexts > > Can someone if this should be in bugzilla or what to do to fix this? > > (bullwinkle pts10) # rpm -qa | grep selinux > selinux-policy-targeted-1.23.12-1 > libselinux-1.23.7-2 > libselinux-devel-1.23.7-2 > (bullwinkle pts10) # rpm -qa | grep audit > audit-libs-0.6.12-1 > audit-0.6.12-1 > (bullwinkle pts10) # > > Regards, > > Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > Here is one that I filed. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155400 Regards, Gary From hongwei at wustl.edu Thu Apr 21 21:13:55 2005 From: hongwei at wustl.edu (Hongwei Li) Date: Thu, 21 Apr 2005 16:13:55 -0500 (CDT) Subject: How to modify the policy? In-Reply-To: <426017E0.1030501@redhat.com> References: <2197.128.252.85.103.1113490066.squirrel@morpheus.wustl.edu> <425EB689.1000008@redhat.com><3949.128.252.85.103.1113505533.squirrel@morpheus.wustl.edu> <426017E0.1030501@redhat.com> Message-ID: <4903.128.252.85.103.1114118035.squirrel@morpheus.wustl.edu> > Hongwei Li wrote: > >>>Hongwei Li wrote: >>> >>> >>> >>>>Hi, >>>> >>>>I have a fc3 linux (kernel 2.6.10-1.770_FC3) with selinux enforced, >>>>targeted policy 1.17.30-2.96. I try to use squirrelmail's plugin >>>>change_passwd, but got denied. The system log shows: >>>> >>>>Apr 14 09:42:59 pippo kernel: audit(1113489779.011:0): avc: denied { >>>>search } for pid=13211 exe=/bin/bash name=src dev=hda6 ino=425174 >>>>scontext=root:system_r:httpd_sys_script_t >>>>tcontext=system_u:object_r:src_t >>>>tclass=dir >>>>Apr 14 09:42:59 pippo kernel: audit(1113489779.012:0): avc: denied { >>>>setuid } for pid=13211 exe=/usr/bin/chpasswd capability=7 >>>>scontext=root:system_r:httpd_sys_script_t >>>>tcontext=root:system_r:httpd_sys_script_t tclass=capability >>>> >>>>I can use that plugin's command in ssh console, but just not from the >>>>web. >>>>Should I change the targeted policy to make it working? If yes, how to >>>>modify the policy? >>>> >>>>Thanks a lot! >>>> >>>>Hongwei Li >>>> ... >> >> > A better solution would be to create a new policy file > /etc/selinux/targeted/src/policy/domains/program/chpasswd.te > and a new policy file context file > /etc/selinux/targeted/src/policy/file_context/program/chpasswd.fc > > You might want to look at the passwd.te file from strict policy as an > example. After playing around, I created chpasswd.te and chpasswd.fc, and it is working now. In chpasswd.te, I have: allow httpd_sys_script_t self:capability setuid; allow httpd_sys_script_t shadow_t:file read; ... > > Another option might be to just relabel this policy as > httpd_unconfined_script_t since allowing > sys_script to run chpasswd is pretty dangerous. And can circumvent most > SELinux controls. > Now, my question is: since I use httpd_sys_script_t, is it still dangerous even I created my own domain? how to relable this policy as httpd_unconfined_script_t? I tried to use httpd_unconfined_script_t in chpasswd.te, but got error when I run make load: ERROR 'unknown type httpd_unconfined_script_t' I geately appreciate your help! Hongwei From russell at coker.com.au Thu Apr 21 15:04:42 2005 From: russell at coker.com.au (Russell Coker) Date: Fri, 22 Apr 2005 01:04:42 +1000 Subject: New policy for Pop-before-smtp daemon In-Reply-To: <1110979147.20316.22.camel@hampton-pc.rainbolthampton.net> References: <1110979147.20316.22.camel@hampton-pc.rainbolthampton.net> Message-ID: <200504220104.46432.russell@coker.com.au> On Thursday 17 March 2005 00:19, David Hampton wrote: > Here's a new policy to support the pop-before-smtp daemon from > http://people.FreeBSD.org/~sheldonh/popb4smtp-nodb.tar.gz . I'd > appreciate any feedback on these files or tips on how to write better > policies. Thanks. All policy that you publish should use the proper locations of files as used in packaged software. /usr/local is only for things that the administrator compiles themself and generally shouldn't appear in .fc files. daemon_domain() has the domain_auto_trans() rule to allow running from initrc_t. This daemon does not need two domains, just give it one, things will be a lot easier and no less secure. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: pop.diff Type: text/x-diff Size: 992 bytes Desc: not available URL: From russell at coker.com.au Thu Apr 21 15:14:33 2005 From: russell at coker.com.au (Russell Coker) Date: Fri, 22 Apr 2005 01:14:33 +1000 Subject: New policy for tripwire In-Reply-To: <1110671445.7641.16.camel@hampton-pc.rainbolthampton.net> References: <1110671445.7641.16.camel@hampton-pc.rainbolthampton.net> Message-ID: <200504220114.37898.russell@coker.com.au> On Sunday 13 March 2005 10:50, David Hampton wrote: > This is written on an FC3 base system using the selinux-policy-strict- > sources-1.22.1-2 policy from March 11th. These are the first policies > I've submitted so I'd appreciate any comments on how to write better > policies. Executable types in .fc files should be marked with --. It makes setfiles run faster and also avoids bad policy being written when the executable gets replaced with a symlink or something else strange happens. Labelling a binary in /usr/sbin as bin_t makes no sense. I don't think that there's any need for so many domains. Also tripwire domains probably don't make any sense. If you are serious about tripwire then you should boot from removable media to run it. Anyone who can crack a SE Linux system can surely sort out the tripwire database. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: tripwire.diff Type: text/x-diff Size: 824 bytes Desc: not available URL: From russell at coker.com.au Thu Apr 21 15:18:33 2005 From: russell at coker.com.au (Russell Coker) Date: Fri, 22 Apr 2005 01:18:33 +1000 Subject: New policy for yam In-Reply-To: <1110671442.7641.15.camel@hampton-pc.rainbolthampton.net> References: <1110671442.7641.15.camel@hampton-pc.rainbolthampton.net> Message-ID: <200504220118.36773.russell@coker.com.au> On Sunday 13 March 2005 10:50, David Hampton wrote: > This is written on an FC3 base system using the selinux-policy-strict- > sources-1.22.1-2 policy from March 11th. These are the first policies > I've submitted so I'd appreciate any comments on how to write better > policies. Any reference to user_t, user_home_t, user_home_dir_t etc in policy is a bug. Running such a program from user_t (or some other unprivileged domain) will be better for overall security than having a domain that you can transition to from sysadm_t. -- 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 russell at coker.com.au Thu Apr 21 15:09:31 2005 From: russell at coker.com.au (Russell Coker) Date: Fri, 22 Apr 2005 01:09:31 +1000 Subject: New policy for pyzor In-Reply-To: <1111454594.18940.54.camel@hampton-pc.rainbolthampton.net> References: <1111454594.18940.54.camel@hampton-pc.rainbolthampton.net> Message-ID: <200504220109.35116.russell@coker.com.au> On Tuesday 22 March 2005 12:23, David Hampton wrote: > This is a new strict policy for the pyzor spam filter. It is based on > the selinux-policy-strict-sources-1.23.2-1 fedora RPM. This policy > requires the definition of a pyzor reserved port that was in the > net_contexts diff I sent last Wednesday. Please let me know if there > are any problems with or changes needed to this policy. Attached a patch to allow it to work from console logins. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: pyzor.diff Type: text/x-diff Size: 435 bytes Desc: not available URL: From russell at coker.com.au Thu Apr 21 14:54:18 2005 From: russell at coker.com.au (Russell Coker) Date: Fri, 22 Apr 2005 00:54:18 +1000 Subject: New policy for DCC In-Reply-To: <1111454598.18940.57.camel@hampton-pc.rainbolthampton.net> References: <1111454598.18940.57.camel@hampton-pc.rainbolthampton.net> Message-ID: <200504220054.22405.russell@coker.com.au> On Tuesday 22 March 2005 12:23, David Hampton wrote: > This is a new strict policy for the DCC spam filter. It is based on the > selinux-policy-strict-sources-1.23.2-1 fedora RPM. This policy requires > the definition of dcc reserved ports that were in the net_contexts diff > I sent last Wednesday. Please let me know if there are any problems > with or changes needed to this policy. Firstly daemons should not be started with su. For correct handling of terminal file handles you should use /sbin/runuser to change the UID, it also requires less policy which makes things easier. Why do you use init_service_domain() and domain_auto_trans(initrc_t, dcc_script_exec_t, dcc_script_t)? Surely the daemon is to be started either from inittab or from an /etc/init.d script but not both. Putting a unix domain socket in /etc is wrong. Among other things it will probably break things for anyone who wants to run with a read-only root file system. Types used under the /var/run directory generally should have the pidfile attribute so that they can be cleaned up by boot scripts if necessary. There is a type dccm_sock_t defined which is not in the .fc file. Allowing access to sshd_t:fd is not what you want, you want to use privfd:fd to allow the administrator to use a console login. Also you want to use admin_tty_type:chr_file instead of sysadm_devpts_t:chr_file for the same reason. I have attached some patches, but I think that more will need to be done. For starters I don't think that there is a good cause for seven domains. Postfix has the current record with 13 domains and I believe that Postfix has too many, one of the reasons why I asked Tresys to add a feature to apol to compare the access granted to domains was to determine which domains of Postfix are not needed. Without even knowing what DCC does I feel confident in guessing that it's not nearly half as complex as Postfix and doesn't need so many domains. Excessive domains makes the policy difficult to analyse. For starters dccifd_t and dccm_t can be merged. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: fc.diff Type: text/x-diff Size: 1530 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: te.diff Type: text/x-diff Size: 4759 bytes Desc: not available URL: From mroselinux at eastgranby.k12.ct.us Fri Apr 22 00:31:15 2005 From: mroselinux at eastgranby.k12.ct.us (mroselinux at eastgranby.k12.ct.us) Date: Thu, 21 Apr 2005 20:31:15 -0400 (EDT) Subject: Backup server question In-Reply-To: <1114095342.4054.145.camel@moss-spartans.epoch.ncsc.mil> References: <20050221160539.6aba22bd.r.godzilla@comcast.net> <200504201621.46953.russell@coker.com.au> <143f0f6c050420115054e903a5@mail.gmail.com> <200504211413.32072.russell@coker.com.au> <1930.24.2.210.202.1114095278.squirrel@mail.eastgranby.k12.ct.us> <1114095342.4054.145.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1540.24.2.210.202.1114129875.squirrel@mail.eastgranby.k12.ct.us> > On Thu, 2005-04-21 at 10:54 -0400, mroselinux at eastgranby.k12.ct.us > wrote: >> We have a FC3 server running samba, dhcpd, and named (for internal names >> only). Each night, a backup server to the primary runs rsync to >> download >> changed/new files. >> >> This is a vacation week at our high school and I tried our backup plan >> for >> the first time since upgrading to FC3. When bringing up the backup >> server >> as primary, I ran into a security problem with dhcpd (dhcpd: Can't open >> lease database /var/lib/dhcp/dhcpd.leases: Permission denied). I issued >> a >> setforce 0 command and restarted dhcpd and all was ok. I then again >> stopped dhcpd, issued a setenforce 1 command, restarted dhcpd and again >> all was ok. >> >> So, should I be running fixfiles each night at the end of the rsync >> script? Or is there a better solution that someone with expertise can >> suggest? > > I think that the FC4/development tree includes a patch to rsync to allow > preservation of extended attributes (which would include the SELinux > attributes). Hence, you might try building the development rsync SRPM > on FC3 and trying it there (using the -X option). You need the updated > rsync on both the client and server. Naturally, you'd want to test it > out somewhere other than your production machine first. > > -- > Stephen Smalley > National Security Agency > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > Stephen - Thanks for the info, but I don't think that I have the capability to build rsync. I will look forward to it. But in the meantime, is running fixfiles at the end of the rsync script an ok approach? Mark From dwalsh at redhat.com Fri Apr 22 01:28:54 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 21 Apr 2005 21:28:54 -0400 Subject: Backup server question In-Reply-To: <1540.24.2.210.202.1114129875.squirrel@mail.eastgranby.k12.ct.us> References: <20050221160539.6aba22bd.r.godzilla@comcast.net> <200504201621.46953.russell@coker.com.au> <143f0f6c050420115054e903a5@mail.gmail.com> <200504211413.32072.russell@coker.com.au> <1930.24.2.210.202.1114095278.squirrel@mail.eastgranby.k12.ct.us> <1114095342.4054.145.camel@moss-spartans.epoch.ncsc.mil> <1540.24.2.210.202.1114129875.squirrel@mail.eastgranby.k12.ct.us> Message-ID: <42685356.1030207@redhat.com> mroselinux at eastgranby.k12.ct.us wrote: >>On Thu, 2005-04-21 at 10:54 -0400, mroselinux at eastgranby.k12.ct.us >>wrote: >> >> >>>We have a FC3 server running samba, dhcpd, and named (for internal names >>>only). Each night, a backup server to the primary runs rsync to >>>download >>>changed/new files. >>> >>>This is a vacation week at our high school and I tried our backup plan >>>for >>>the first time since upgrading to FC3. When bringing up the backup >>>server >>>as primary, I ran into a security problem with dhcpd (dhcpd: Can't open >>>lease database /var/lib/dhcp/dhcpd.leases: Permission denied). I issued >>>a >>>setforce 0 command and restarted dhcpd and all was ok. I then again >>>stopped dhcpd, issued a setenforce 1 command, restarted dhcpd and again >>>all was ok. >>> >>>So, should I be running fixfiles each night at the end of the rsync >>>script? Or is there a better solution that someone with expertise can >>>suggest? >>> >>> >>I think that the FC4/development tree includes a patch to rsync to allow >>preservation of extended attributes (which would include the SELinux >>attributes). Hence, you might try building the development rsync SRPM >>on FC3 and trying it there (using the -X option). You need the updated >>rsync on both the client and server. Naturally, you'd want to test it >>out somewhere other than your production machine first. >> >>-- >>Stephen Smalley >>National Security Agency >> >>-- >>fedora-selinux-list mailing list >>fedora-selinux-list at redhat.com >>http://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >> >> >Stephen - Thanks for the info, but I don't think that I have the >capability to build rsync. I will look forward to it. But in the >meantime, is running fixfiles at the end of the rsync script an ok >approach? > >Mark > > > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Yes. -- From russell at coker.com.au Fri Apr 22 08:05:24 2005 From: russell at coker.com.au (Russell Coker) Date: Fri, 22 Apr 2005 18:05:24 +1000 Subject: Updates to clamav [patch] In-Reply-To: <1113514558.6056.40.camel@hampton-pc.rainbolthampton.net> References: <1113514558.6056.40.camel@hampton-pc.rainbolthampton.net> Message-ID: <200504221805.28505.russell@coker.com.au> On Friday 15 April 2005 07:35, David Hampton wrote: > The attached patch updates the (unused) clamav policy to work with the > changes in the FC strict/1.23.10-2 policy. It also fixes an access > problem with the clamd socket. +allow freshclam_t http_port_t:tcp_socket name_connect; The attribute web_client_domain should grant such access. Probably the policy related to the web_client_domain attribute hasn't been updated. +# Pid files for freshclam +allow initrc_t clamd_var_run_t:file { create setattr }; What's happening there? Is the initrc script trying to create and chown the file and then setuid to the clamav user before starting the daemon? While we're at it we should rename clamd_sock_t to clamd_var_run_t. -- 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 russell at coker.com.au Fri Apr 22 08:21:23 2005 From: russell at coker.com.au (Russell Coker) Date: Fri, 22 Apr 2005 18:21:23 +1000 Subject: Tweaks to the clamav policy In-Reply-To: <1110979071.20316.17.camel@hampton-pc.rainbolthampton.net> References: <1110979071.20316.17.camel@hampton-pc.rainbolthampton.net> Message-ID: <200504221821.27714.russell@coker.com.au> On Thursday 17 March 2005 00:17, David Hampton wrote: > I've added support to the (unused) clamav policy to allow listening for > service requests on a TCP socket, and for interacting with amavis. I > also made some tweaks that tighten up the network access allowed by > freshclam, split the freshclam and spamd log files into two different > types, and make the clamd control socket a unique type. Thanks. +can_network_client_tcp(freshclam_t, http_port_t); This should be replaced by web_client_domain (the policy for which may need to be adjusted). Among other things the above policy doesn't work for http_cache_port_t. -- 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 russell at coker.com.au Fri Apr 22 08:09:27 2005 From: russell at coker.com.au (Russell Coker) Date: Fri, 22 Apr 2005 18:09:27 +1000 Subject: Updates to amavisd [patch] In-Reply-To: <1113514551.6056.38.camel@hampton-pc.rainbolthampton.net> References: <1113514551.6056.38.camel@hampton-pc.rainbolthampton.net> Message-ID: <200504221809.30984.russell@coker.com.au> On Friday 15 April 2005 07:35, David Hampton wrote: > The attached patch updates the (unused) amavisd policy to work with the > changes in the FC strict/1.23.10-2 policy. It also fixes the access > needed by tmpreaper to delete files from the caught spam/virus > directory. +allow initrc_t amavisd_etc_t:file read; Generally it's a bad idea to grant read access without getattr. @@ -120,6 +122,6 @@ # Tmp reaper ifdef(`tmpreaper.te', ` -allow tmpreaper_t amavisd_quarantine_t:dir { read search getattr setattr unlink }; -allow tmpreaper_t amavisd_quarantine_t:file getattr; +allow tmpreaper_t amavisd_quarantine_t:dir create_dir_perms; +allow tmpreaper_t amavisd_quarantine_t:file link_file_perms; ') tmpreaper_t shouldn't be creating directories. For the file access { getattr unlink } should be sufficient. The following should do: allow tmpreaper_t amavisd_quarantine_t:dir { rw_dir_perms unlink }; allow tmpreaper_t amavisd_quarantine_t:file { getattr unlink }; -- 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 russell at coker.com.au Fri Apr 22 08:23:32 2005 From: russell at coker.com.au (Russell Coker) Date: Fri, 22 Apr 2005 18:23:32 +1000 Subject: Tweaks to the clamav policy In-Reply-To: <1110979071.20316.17.camel@hampton-pc.rainbolthampton.net> References: <1110979071.20316.17.camel@hampton-pc.rainbolthampton.net> Message-ID: <200504221823.35789.russell@coker.com.au> On Thursday 17 March 2005 00:17, David Hampton wrote: > I've added support to the (unused) clamav policy to allow listening for > service requests on a TCP socket, and for interacting with amavis. I > also made some tweaks that tighten up the network access allowed by > freshclam, split the freshclam and spamd log files into two different > types, and make the clamd control socket a unique type. Thanks. Another thing, please don't add new _sock_t types. Among other things you didn't give it the pidfile attribute to mark it as something that init scripts can unlink. -- 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 russell at coker.com.au Fri Apr 22 08:00:44 2005 From: russell at coker.com.au (Russell Coker) Date: Fri, 22 Apr 2005 18:00:44 +1000 Subject: Updates to dcc [patch] In-Reply-To: <1113514561.6056.41.camel@hampton-pc.rainbolthampton.net> References: <1113514561.6056.41.camel@hampton-pc.rainbolthampton.net> Message-ID: <200504221800.47811.russell@coker.com.au> On Friday 15 April 2005 07:36, David Hampton wrote: > The attached patch updates the (unused) dcc policy to work with the > changes in the FC strict/1.23.10-2 policy. It also makes a couple of > tweaks to the policy +allow initrc_t dcc_var_run_t:dir rw_dir_perms; Use the pidfile attribute for dcc_var_run_t and you won't need that. -- 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 russell at coker.com.au Fri Apr 22 08:19:46 2005 From: russell at coker.com.au (Russell Coker) Date: Fri, 22 Apr 2005 18:19:46 +1000 Subject: Tweaks to the amavis policy In-Reply-To: <1110979100.20316.18.camel@hampton-pc.rainbolthampton.net> References: <1110979100.20316.18.camel@hampton-pc.rainbolthampton.net> Message-ID: <200504221819.49152.russell@coker.com.au> On Thursday 17 March 2005 00:18, David Hampton wrote: > I've added support to the (unused) amavis policy to allow interaction > with additional mail filters, and added a new type specifically for > quarantined spam and viruses. I also tweaked the network access to > limit ports that can be used by amavisd. I'd appreciate any feedback on > these changes or tips on how to write better policies. Thanks. +# Tmp reaper +ifdef(`tmpreaper.te', ` +allow tmpreaper_t amavisd_quarantine_t:dir { read search getattr setattr unlink }; +allow tmpreaper_t amavisd_quarantine_t:file getattr; +') tmpreaper_t should not need setattr access to the directory. To perform any useful function tmpreaper_t will need read/write access to the directory and unlink access to the file such as the following: allow tmpreaper_t amavisd_quarantine_t:dir { rw_dir_perms unlink }; allow tmpreaper_t amavisd_quarantine_t:file { getattr unlink }; -- 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 dwalsh at redhat.com Fri Apr 22 11:08:15 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 22 Apr 2005 07:08:15 -0400 Subject: Tweaks to the amavis policy In-Reply-To: <200504221819.49152.russell@coker.com.au> References: <1110979100.20316.18.camel@hampton-pc.rainbolthampton.net> <200504221819.49152.russell@coker.com.au> Message-ID: <4268DB1F.80409@redhat.com> Russell Coker wrote: >On Thursday 17 March 2005 00:18, David Hampton > wrote: > > >>I've added support to the (unused) amavis policy to allow interaction >>with additional mail filters, and added a new type specifically for >>quarantined spam and viruses. I also tweaked the network access to >>limit ports that can be used by amavisd. I'd appreciate any feedback on >>these changes or tips on how to write better policies. Thanks. >> >> > >+# Tmp reaper >+ifdef(`tmpreaper.te', ` >+allow tmpreaper_t amavisd_quarantine_t:dir { read search getattr setattr >unlink }; >+allow tmpreaper_t amavisd_quarantine_t:file getattr; >+') > >tmpreaper_t should not need setattr access to the directory. > >To perform any useful function tmpreaper_t will need read/write access to the >directory and unlink access to the file such as the following: > >allow tmpreaper_t amavisd_quarantine_t:dir { rw_dir_perms unlink }; >allow tmpreaper_t amavisd_quarantine_t:file { getattr unlink }; > > > Why not add the attribute tmpfile to amavisd_quarantine_t and you get this for free. Dan -- From steve at atc-nycorp.com Fri Apr 22 17:01:29 2005 From: steve at atc-nycorp.com (Steve Brueckner) Date: Fri, 22 Apr 2005 13:01:29 -0400 Subject: Limiting IPC with SELinux? Message-ID: <60D45469A1AAD311A04C009027B6BF6804FCF0AB@server20.inside.oracorp.com> I've been experimenting with the SELinux networking permissions, based on last week's emails on this topic. I've run into a problem: Stephen Smalley wrote: > Well, SELinux does allow you to limit what processes can bind to what > ports, so if the port falls within a well-defined range and you can > exclude others from that port range without breaking functionality, > you can indirectly achieve the process-to-process relationship in > that manner. If not, then I guess you need labeled networking. > >> On Fri, 2005-04-15 at 13:47 -0400, Steve Brueckner wrote: >> For my application, I can't deny any process the right to bind to >> whatever port it wants. > > This seems to be the key limitation. The question is why? My application is trying to segregate the machine into two protection domains, and I don't have control over the programs that may run in either domain. I need to allow processes to communicate via loopback networking intra-domain but not inter-domain. Let's look at the cases of (1) tcp and (2) udp: (1) For tcp, this domain segregation would seem to be possible using the name_bind and (forthcoming with 2.6.12) name_connect permissions. I could allow processes in each domain to bind and connect only to ports defined as belonging to that domain. The ports from which connections originate will likely be ephemeral ports issued by the kernel, but that's OK: I can allow send to and recv from all ports as long as the name_bind and name_connect are enforced. By loosening the requirements of my application, I can indeed set aside port ranges for each domain. However, I still don't have control over applications' internals. And some applications are troublemakers in that they bind not to a port specified in their configuration, but to an ephemeral port handed to them by the kernel. Such applications (e.g. passive FTP) will simply break when the kernel hands them a port that is not within their domain, and cannot easily be fixed. (2) For udp, things break even more easily. I could allow processes in each domain to bind only to ports belonging to their domain. But since udp doesn't connect, I'd have to limit the send and recv ports. Limiting send and recv to ports belonging to a domain works for clients trying to talk to a bound server, but not for the bound server itself. Bound servers would break since they would be trying to send to and receive from clients using ephemeral ports that may be outside their domain. It seems to me that this is a problem for anyone wanting to use SELinux or SELinux with MLS in such a way. I don't think it's a stretch to imagine that some folks will desire the ability to enforce domain separation without shutting down loopback networking. If this can't be done now, is there a chance it will be addressed in the future? What appears to be needed is some way to make the kernel security context-aware when assigning ephemeral ports. My temporary solution may be to wrap or hack the kernel calls that return ephemeral ports. Or is there a chance of re-visiting the idea of getting labeled networking into the kernel? Stephen Brueckner, ATC-NY From bleher at informatik.uni-muenchen.de Fri Apr 22 18:46:20 2005 From: bleher at informatik.uni-muenchen.de (Thomas Bleher) Date: Fri, 22 Apr 2005 20:46:20 +0200 Subject: Limiting IPC with SELinux? In-Reply-To: <60D45469A1AAD311A04C009027B6BF6804FCF0AB@server20.inside.oracorp.com> References: <60D45469A1AAD311A04C009027B6BF6804FCF0AB@server20.inside.oracorp.com> Message-ID: <20050422184620.GA13859@thorium.jmh.mhn.de> * Steve Brueckner [2005-04-22 19:01]: > I've been experimenting with the SELinux networking permissions, based on > last week's emails on this topic. I've run into a problem: > > Stephen Smalley wrote: > > Well, SELinux does allow you to limit what processes can bind to what > > ports, so if the port falls within a well-defined range and you can > > exclude others from that port range without breaking functionality, > > you can indirectly achieve the process-to-process relationship in > > that manner. If not, then I guess you need labeled networking. > > > >> On Fri, 2005-04-15 at 13:47 -0400, Steve Brueckner wrote: > >> For my application, I can't deny any process the right to bind to > >> whatever port it wants. > > > > This seems to be the key limitation. The question is why? > > My application is trying to segregate the machine into two protection > domains, and I don't have control over the programs that may run in either > domain. I need to allow processes to communicate via loopback networking > intra-domain but not inter-domain. [ lots of good observations snipped ] I had an idea a while ago which may help you. I wanted to implement it myself but don't have time to do any kernel-hacking currently, so if you want to try it, feel free. My idea was to build an iptables modules similar to the "Owner match" module which matches locally generated packets against a specific domain. That way you could probably achieve most of what you want. One problem here is: how do we cleanly match on security context? All the logic should be in the security server and controllable by policy. The most sane way I came up with is this: Declare a new class "iptables" (or "netfilter") with one permission "match". Then put this into policy: allow domain self:iptables match; The usermode iptables code passes a complete security context into the kernel which is converted into a sid internally. Now everytime the iptables module is called on a packet it asks the avc if ::IPTABLES__MATCH is allowed in the policy. I do not know if this is the best approach but it does allow matching on specific domains, on specific contexts (if the constraints are adjusted) or on a group of domains (you could add a dummy type all_userdomains_t and add "allow userdomain all_userdomains_t:iptables match;" or something like that and then match on all_userdomains_t in the iptables rule) I think such a module would be very useful. For example, the admin may want to specify that mozilla may only talk to the internal proxy server. Of course, this depends on the fact that such a module is actually doable and sane. I looked at the code but I am no kernel hacker so I would appreciate any insight/ideas. Thomas -- http://www.cip.ifi.lmu.de/~bleher/selinux/ - my SELinux pages GPG-Fingerprint: BC4F BB16 30D6 F253 E3EA D09E C562 2BAE B2F4 ABE7 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From jmorris at redhat.com Fri Apr 22 18:58:50 2005 From: jmorris at redhat.com (James Morris) Date: Fri, 22 Apr 2005 14:58:50 -0400 (EDT) Subject: Limiting IPC with SELinux? In-Reply-To: <60D45469A1AAD311A04C009027B6BF6804FCF0AB@server20.inside.oracorp.com> Message-ID: On Fri, 22 Apr 2005, Steve Brueckner wrote: > return ephemeral ports. Or is there a chance of re-visiting the idea of > getting labeled networking into the kernel? Work is being done on labeled networking via IPsec, see Trent Jaeger's paper at http://www.selinux-symposium.org/2005/agenda.php - James -- James Morris From russell at coker.com.au Fri Apr 22 23:54:19 2005 From: russell at coker.com.au (Russell Coker) Date: Sat, 23 Apr 2005 09:54:19 +1000 Subject: Tweaks to the amavis policy In-Reply-To: <4268DB1F.80409@redhat.com> References: <1110979100.20316.18.camel@hampton-pc.rainbolthampton.net> <200504221819.49152.russell@coker.com.au> <4268DB1F.80409@redhat.com> Message-ID: <200504230954.23278.russell@coker.com.au> On Friday 22 April 2005 21:08, Daniel J Walsh wrote: > >allow tmpreaper_t amavisd_quarantine_t:dir { rw_dir_perms unlink }; > >allow tmpreaper_t amavisd_quarantine_t:file { getattr unlink }; > > Why not add the attribute tmpfile to amavisd_quarantine_t and you get > this for free. True. tmpfile does grant access to the initrc_t domain, but that shouldn't be a problem in this case (and I can imagine a start script for amavis wanting to do such things). -- 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 christofer.c.bell at gmail.com Sat Apr 23 00:53:33 2005 From: christofer.c.bell at gmail.com (Christofer C. Bell) Date: Fri, 22 Apr 2005 19:53:33 -0500 Subject: Serving a loopback mounted ISO with Apache Message-ID: <143f0f6c05042217536d1f0c10@mail.gmail.com> I'm running Fedora Core 3 with selinux-policy-targeted-1.17.30-2.96 and I'd like to serve an ISO file I've mounted (the contents of the ISO, I don't care about the ISO itself). I've mounted it thusly: # mount -t iso9660 -o,loop PG2003-08.ISO gutenberg And I show that it's mounted properly: /var/www/html/PG2003-08.ISO on /var/www/html/gutenberg type iso9660 (rw,loop=/dev/loop0) Trying to read this content using a web-browser (via apache) gives me a 403 Forbidden. The reason is an avc denied: Apr 22 19:48:43 circe kernel: audit(1114217323.877:0): avc: denied { getattr } for pid=14889 exe=/usr/sbin/httpd path=/var/www/html/gutenberg dev=loop0 ino=1792 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:iso9660_t tclass=dir Unfortunately, I'm unable to relabel this content because the iso9660 filesystem does not support extended attributes: restorecon get context on /var/www/html/gutenberg/etext03/vbgle11h/images/pl41.jpg failed: 'Operation not supported' [ and so on ] I have relabeled the mountpoint itself without the ISO mounted. Is there a workaround or something I'm missing that I can do to make this content readable by apache? Thanks! -- Chris () ASCII Ribbon Campaign! /\ Say NO to HTML in Mail and News! From russell at coker.com.au Sat Apr 23 02:18:27 2005 From: russell at coker.com.au (Russell Coker) Date: Sat, 23 Apr 2005 12:18:27 +1000 Subject: Serving a loopback mounted ISO with Apache In-Reply-To: <143f0f6c05042217536d1f0c10@mail.gmail.com> References: <143f0f6c05042217536d1f0c10@mail.gmail.com> Message-ID: <200504231218.30801.russell@coker.com.au> On Saturday 23 April 2005 10:53, "Christofer C. Bell" wrote: > Apr 22 19:48:43 circe kernel: audit(1114217323.877:0): avc: denied { > getattr } for pid=14889 exe=/usr/sbin/httpd > path=/var/www/html/gutenberg dev=loop0 ino=1792 > scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:iso9660_t > tclass=dir You could add the following policy: r_dir_file(httpd_t, iso9660_t) > Unfortunately, I'm unable to relabel this content because the iso9660 > filesystem does not support extended attributes: Use the context option to mount. Put context=system_u:object_r:httpd_sys_content_t in the options file of /etc/fstab for example. -- 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 russell at coker.com.au Sat Apr 23 02:54:48 2005 From: russell at coker.com.au (Russell Coker) Date: Sat, 23 Apr 2005 12:54:48 +1000 Subject: Rawhide avc messages In-Reply-To: References: Message-ID: <200504231254.50952.russell@coker.com.au> On Friday 22 April 2005 04:27, Tom Diehl wrote: > kernel: audit(1114097914.302:0): avc: denied { rename } for pid=1952 > exe=/bin/mv name=ntp.conf dev=dm-0 ino=102686 > scontext=user_u:system_r:dhcpc_t tcontext=user_u:object_r:etc_t tclass=file Your /etc/ntp.conf is mislabelled. The others are minor errors, the machine should work fine even before we fix 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 russell at coker.com.au Sat Apr 23 02:56:28 2005 From: russell at coker.com.au (Russell Coker) Date: Sat, 23 Apr 2005 12:56:28 +1000 Subject: Problems with Mailman under strict In-Reply-To: <1113370808.5926.19.camel@hampton-pc.rainbolthampton.net> References: <1113370808.5926.19.camel@hampton-pc.rainbolthampton.net> Message-ID: <200504231256.31383.russell@coker.com.au> On Wednesday 13 April 2005 15:40, David Hampton wrote: > This prevents the domain_auto_trans rule in mailman.te from switching > domains from initrc_t to mailman_mail_t. Fixing the mailman init file > has solved my problem for now, but this will just reappear with every > upgrade to the mailman package. Any chance of fixing the mailman > package? Yes, if this is in rawhide then please file a bugzilla. -- 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 lkml at mac.com Sat Apr 23 09:32:03 2005 From: lkml at mac.com (Felipe Alfaro Solana) Date: Sat, 23 Apr 2005 11:32:03 +0200 Subject: avc: denied { search } for smbd Message-ID: <27467a812dd6a2424dcc9705d5f25720@mac.com> Hello, I have just installed FC4t2 on a new system with SELinux enabled. SAMBA complains with the following avc when trying to mount a shared resource named XEN whose path is /home/user: audit(1114248344.419:0): avc: denied { search } for pid=3329 exe=/usr/sbin/smbd name=home dev=dm-0 ino=196609 scontext=root:system_r:smbd_t tcontext=system_u:object_r:home_root_t tclass=dir audit(1114248344.425:0): avc: denied { search } for pid=3329 exe=/usr/sbin/smbd name=home dev=dm-0 ino=196609 scontext=root:system_r:smbd_t tcontext=system_u:object_r:home_root_t tclass=dir # tail /etc/samba/smb.conf [XEN] comment = Data placeholder path = /home/user public = yes browseable = yes writable = yes # ls -ldZ /home drwxr-xr-x root root system_u:object_r:home_root_t /home # grep smbd_t /etc/selinux/targeted/src/policy/policy.conf | head -1 allow smbd_t home_root_t:dir { read getattr lock search ioctl }; So I don't understand what's going on: the policy explicitly allows domain smbd_t to perform search on home_root_t:dir and /home is already labeled home_root_t. Any ideas? From ivg2 at cornell.edu Sat Apr 23 12:25:19 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Sat, 23 Apr 2005 08:25:19 -0400 Subject: avc: denied { search } for smbd In-Reply-To: <27467a812dd6a2424dcc9705d5f25720@mac.com> References: <27467a812dd6a2424dcc9705d5f25720@mac.com> Message-ID: <1114259119.3496.0.camel@localhost.localdomain> > So I don't understand what's going on: the policy explicitly allows > domain smbd_t to perform search on home_root_t:dir and /home is already > labeled home_root_t. Yes, but it only does this when samba_enable_home_dirs is on. Toggle the boolean. -- Ivan Gyurdiev Cornell University From lkml at mac.com Sat Apr 23 16:00:12 2005 From: lkml at mac.com (Felipe Alfaro Solana) Date: Sat, 23 Apr 2005 18:00:12 +0200 Subject: avc: denied { search } for smbd In-Reply-To: <1114259119.3496.0.camel@localhost.localdomain> References: <27467a812dd6a2424dcc9705d5f25720@mac.com> <1114259119.3496.0.camel@localhost.localdomain> Message-ID: On 23 Apr 2005, at 14:25, Ivan Gyurdiev wrote: > >> So I don't understand what's going on: the policy explicitly allows >> domain smbd_t to perform search on home_root_t:dir and /home is >> already >> labeled home_root_t. > > Yes, but it only does this when samba_enable_home_dirs is on. > > Toggle the boolean. Thanks. I have manually added the following line to /etc/selinux/targeted/booleans.local samba_enable_home_dirs=1 but now, I'm getting these avc's: audit(1114271834.460:0): avc: denied { getattr } for path=/dev/pts dev=devpts ino=1 scontext=user_u:system_r:smbd_t tcontext=user_u:object_r:devpts_t tclass=dir More ideas? From selinux at gmail.com Sat Apr 23 20:24:33 2005 From: selinux at gmail.com (Tom London) Date: Sat, 23 Apr 2005 13:24:33 -0700 Subject: selinux-policy-targeted-1.23.12-4: /proc {search} failures ? Message-ID: <4c4ba153050423132430522156@mail.gmail.com> Running targeted/enforcing, latest rawhide. Rebooting after today's updates (including .1261 and selinux-policy-targeted-1.23.12-4), graphical logins fail. Looks like search access to /proc/PROCESS-ID directories are failing. (Also show an early hotplug attempt at writing to sysfs_t). I worked around this by doing an 'ALT-CTL-F2', and logging in on the text console, and doing a 'setenforce 0'. Reverting to graphical via 'ALT-CTL-F7' now allows login. /var/log messages show a very large number of avcs, including many that look like: Apr 23 13:04:18 localhost dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67 Apr 23 13:04:18 localhost dhclient: DHCPACK from 10.10.192.1 Apr 23 13:04:18 localhost kernel: audit(1114286658.747:0): avc: denied { write } for name=vcs7 dev=sysfs ino=6997 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:sysfs_t tclass=dir Apr 23 13:04:18 localhost kernel: audit(1114286658.747:0): avc: denied { write } for name=vcsa7 dev=sysfs ino=7003 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:sysfs_t tclass=dir Apr 23 13:04:19 localhost NET[2301]: /sbin/dhclient-script : updated /etc/resolv.conf and Apr 23 13:05:15 localhost kernel: audit(1114286715.636:0): avc: denied { search } for name=2 dev=proc ino=131074 scontext=system_u:system_r:init_t tcontext=system_u:system_r:kernel_t tclass=dir Apr 23 13:05:15 localhost kernel: audit(1114286715.636:0): avc: denied { search } for name=3 dev=proc ino=196610 scontext=system_u:system_r:init_t tcontext=system_u:system_r:kernel_t tclass=dir Apr 23 13:05:15 localhost kernel: audit(1114286715.636:0): avc: denied { search } for name=4 dev=proc ino=262146 scontext=system_u:system_r:init_t tcontext=system_u:system_r:kernel_t tclass=dir <<<>>> Apr 23 13:05:16 localhost kernel: audit(1114286715.638:0): avc: denied { search } for name=2103 dev=proc ino=137822210 scontext=system_u:system_r:init_t tcontext=system_u:system_r:initrc_t tclass=dir Apr 23 13:05:16 localhost kernel: audit(1114286715.638:0): avc: denied { search } for name=2111 dev=proc ino=138346498 scontext=system_u:system_r:init_t tcontext=system_u:system_r:initrc_t tclass=dir Apr 23 13:05:16 localhost kernel: audit(1114286715.638:0): avc: denied { search } for name=2303 dev=proc ino=150929410 scontext=system_u:system_r:init_t tcontext=system_u:system_r:dhcpc_t tclass=dir Apr 23 13:05:16 localhost kernel: audit(1114286715.638:0): avc: denied { search } for name=2476 dev=proc ino=162267138 scontext=system_u:system_r:init_t tcontext=system_u:system_r:initrc_t tclass=dir Apr 23 13:05:16 localhost kernel: audit(1114286715.638:0): avc: denied { search } for name=2530 dev=proc ino=165806082 scontext=system_u:system_r:init_t tcontext=system_u:system_r:portmap_t tclass=dir Apr 23 13:05:16 localhost kernel: audit(1114286715.638:0): avc: denied { search } for name=2548 dev=proc ino=166985730 scontext=system_u:system_r:init_t tcontext=system_u:system_r:rpcd_t tclass=dir Apr 23 13:05:16 localhost kernel: audit(1114286715.638:0): avc: denied { search } for name=2575 dev=proc ino=168755202 scontext=system_u:system_r:init_t tcontext=system_u:system_r:rpcd_t tclass=dir <<<>>> etc. etc. Is this a policy change, or did something else change? Or, did I just botch it again? thanks, tom -- Tom London From selinux at gmail.com Sat Apr 23 20:54:46 2005 From: selinux at gmail.com (Tom London) Date: Sat, 23 Apr 2005 13:54:46 -0700 Subject: avc messages corrupted? Message-ID: <4c4ba15305042313542a3ab454@mail.gmail.com> Running targeted/enforcing, latest rawhide (.1261) Examining /var/log/messages, I notice some 'corrupted' avc messages, e.g.: Apr 23 13:05:33 localhost kernel: audit(1114286729.835:0): avc: denied { search } for name=3228 dev=proc ino=211550210 scontext=system_u:system_r:initss=dir Apr 23 13:06:31 localhost kernel: audit(1114286790.120:0): avc: denied { search } for name=3228 dev=proc ino=211550210 scontext=system_u:system_r:i127:0): avc: denied { search } for name=1780 dev=proc ino=116654082 scontext=system_u:system_r:init_t tcontext=system_u:system_r:kernel_t tclass=dir Apr 23 13:06:41 localhost kernel: audit(1114286800.202:0): avc: denied { search } for name=3 dev=proc ino=196610 scontext=system_u:system_r:inystem_r:init_t tcontext=system_u:system_r:kernel_t tclass=dir [initss? i127? inystem? there are more....] Is there a lock problem with auditing? tom -- Tom London From ivg2 at cornell.edu Sun Apr 24 02:14:25 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Sat, 23 Apr 2005 22:14:25 -0400 Subject: avc: denied { search } for smbd In-Reply-To: References: <27467a812dd6a2424dcc9705d5f25720@mac.com> <1114259119.3496.0.camel@localhost.localdomain> Message-ID: <1114308865.11286.8.camel@localhost.localdomain> > > audit(1114271834.460:0): avc: denied { getattr } for path=/dev/pts > dev=devpts ino=1 scontext=user_u:system_r:smbd_t > tcontext=user_u:object_r:devpts_t tclass=dir Yeah, I get those too, when doing df with a mounted samba share. See bug here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=147659 This particular denial you can get if smbd_t tries to access the terminal, but I get it for df (in smbd_t), which is weird. -- Ivan Gyurdiev Cornell University From stuart at jamesnet.ca Sun Apr 24 04:44:33 2005 From: stuart at jamesnet.ca (stuart) Date: Sun, 24 Apr 2005 00:44:33 -0400 Subject: Adding Raid 5 partition Message-ID: <426B2431.5040004@jamesnet.ca> I have added 3 extra disks to my system, which i have created a new raid5 device on /dev/md0. I wish to use this device to serve webpages, but when i change the document root directive in my httpd.conf, and restart the httpd server, i get the error that this directory does not exist. I have properly labeled md0 with "e2label" command and added the approriate stanza in my "/etc/fstab" to mount the directory automatically on boot. I have Selinux running on targeted policy and i have attempted to use "fixfiles" and "restorecon" so that Selinux recoginizes it.. But i am yet to have success. I have also tried just using a normal ext3 partition, that i created after installation, and i get the same error. Stuart James From christofer.c.bell at gmail.com Sun Apr 24 06:58:41 2005 From: christofer.c.bell at gmail.com (Christofer C. Bell) Date: Sun, 24 Apr 2005 01:58:41 -0500 Subject: Adding Raid 5 partition In-Reply-To: <426B2431.5040004@jamesnet.ca> References: <426B2431.5040004@jamesnet.ca> Message-ID: <143f0f6c050423235860dab6dc@mail.gmail.com> On 4/23/05, stuart wrote: > I have added 3 extra disks to my system, which i have created a new > raid5 device on /dev/md0. I wish to use this device to serve webpages, > but when i change the document root directive in my httpd.conf, and > restart the httpd server, i get the error that this directory does not > exist. I have properly labeled md0 with "e2label" command and added the > approriate stanza in my "/etc/fstab" to mount the directory > automatically on boot. I have Selinux running on targeted policy and i > have attempted to use "fixfiles" and "restorecon" so that Selinux > recoginizes it.. But i am yet to have success. I have also tried just > using a normal ext3 partition, that i created after installation, and i > get the same error. /dev/md0 is a metadevice that describes a raid5 disk volume, it's not a directory. While I'm not clear on what exactly you're doing from your post, I have a sneaking suspicion that you've not mounted the device anywhere. What I believe you want to do is something akin to the following: # mkfs -t ext3 /dev/md0 # mount -t ext3 /mnt # service stop httpd # cp -a /var/www/html/* /mnt # rm -rf /var/www/html/* # umount /mnt # mount -t ext3 /dev/md0 /var/www/html # restorecon -R -v /var/www/html # service httpd start This creates an extended 3 filesystem on the new raid device, mounts it in a temporary location, copies your existing web content to it, removes the web content from the old location, and the replaces it with the new raid device. The restorecon is self-explanitory as are the service commands. If this isn't the issue, can you please give some more detail on the problem you're experiencing? -- Chris () ASCII Ribbon Campaign! /\ Say NO to HTML in Mail and News! From Valdis.Kletnieks at vt.edu Sun Apr 24 08:40:07 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 24 Apr 2005 04:40:07 -0400 Subject: Experiences with selinux enabled targetted on Fedora Core 3 In-Reply-To: Your message of "Thu, 21 Apr 2005 14:13:29 +1000." <200504211413.32072.russell@coker.com.au> References: <20050221160539.6aba22bd.r.godzilla@comcast.net> <200504201621.46953.russell@coker.com.au> <143f0f6c050420115054e903a5@mail.gmail.com> <200504211413.32072.russell@coker.com.au> Message-ID: <200504240840.j3O8e8nh014705@turing-police.cc.vt.edu> On Thu, 21 Apr 2005 14:13:29 +1000, Russell Coker said: > On Thursday 21 April 2005 04:50, "Christofer C. Bell" > It is not interesting that programs try to access files under mount points > early in the boot process before the file systems are mounted. It happens on > every boot. > > It is expected to happen, it happens on every boot. Right - my objection is that we're putting in dontaudit rules to shut stuff up during boot - but if the same thing happens *later*, we won't hear about it (I know that *I* would certainly want to know if an access was denied because /usr wasn't a usr_t once we got up in multiuser, if only because at that point, a *lot* of stuff would break with absolutely no indication of why. Certainly a violation of the "expected to happen" rule once we're out of rc.sysinit... Similarly, if anything managed to trigger that dontaudit rule *after* we booted, by virtue of some access *elsewhere* in the file system, I'd want to know about that as well. > > Regardless if the fix can be automated or not, telling the system to > > "just ignore it" is inappropriate IMO. Unfortunately, there's no "just ignore it while we get our act together" for the weirdness that happens during system boot. And we're talking about something that if it ever actually happens after we've gotten out of rc.sysinit, we *do* want to know about it... > The alternatives are as follows: > > 1) Have the users manually relabel. But this requires that they have the > skill needed to use mount --bind or single user mode. Relabelling the /dev mountpoint is quite non-trivial, because booting to single-user in Fedora still gets udev started and a tmpfs mounted over /dev. I ended up having to boot from the rescue disk and having to do something like: chroot /mnt/sysimage mount -t selinux /selinux restorecon /dev > 2) Have more error messages in the logs. This leads to users ignoring the > more important AVC messages which is a security issue. Quite right - my concern was that we're trying to silence a few msgs at boot and thus *forcing* the user to ignore the same message during normal operations, when it *would* be a "more important" message... > 3) Have more complex code in rc.sysinit for relabeling file systems (which is > therefore more error prone) and also remove the possibility of running > "fixfiles relabel" as administrator and forcing a reboot with /.autorelabel . Unfortunately, the /.autorelabel trick happens too late - it's done right *after* we've mounted all the filesystems and enabled disk quotas. The checking would need to be *really* early in rc.sysinit - like before start_udev gets called. Remember - what got me started on this was the 'mount -t tmpfs /dev' issuing a message because it was trying to mount onto a mislabeled /dev... > All the options have disadvantages that I consider to be more serious than the > reasons that make you dislike the dontaudit rule. > > Option 3 is the only remotely viable option. That requires implementing shell > code equivalent for > "mount -a -t nonfs,nfs4,smbfs,ncpfs,cifs,gfs -O no_netdev" to allow running > setfiles between mounts. I don't think that we want to do this. Actually, there's another option: 4) Add code to 'anaconda' (or whatever your distro uses) to do the appropriate 'restorecon' for the mount points for file systems created during system install. It knows (or can be taught) what directories in / (/dev, /proc, /sys, and /selinux) will have pseudo file systems mounted on them, and what directories will have file systems mounted over them (/var, /tmp, /usr/local, / usr/share, /home, /opt, and so on). After the install, if /usr was a single filesystem, and the admin decides that they want /usr/local and /usr/share to be 2 new file systems, that's OK, because the first 'fixfiles relabel' will have set the right settings on the 'local' and 'share' directories that will now be mount points... That still has issues with an admin creating a /foo filesystem, mounting it, and later on we decide to add a special context for /foo - but as long as /foo doesn't become required to get to multiuser mode, the admin can just 'umount /foo; restorecon /foo; mount /foo; restorecon -R foo' and be done. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From stuart at jamesnet.ca Sun Apr 24 13:25:12 2005 From: stuart at jamesnet.ca (stuart) Date: Sun, 24 Apr 2005 09:25:12 -0400 Subject: Adding Raid 5 partition In-Reply-To: <143f0f6c050423235860dab6dc@mail.gmail.com> References: <426B2431.5040004@jamesnet.ca> <143f0f6c050423235860dab6dc@mail.gmail.com> Message-ID: <426B9E38.6060004@jamesnet.ca> Christofer C. Bell wrote: >On 4/23/05, stuart wrote: > > >>I have added 3 extra disks to my system, which i have created a new >>raid5 device on /dev/md0. I wish to use this device to serve webpages, >>but when i change the document root directive in my httpd.conf, and >>restart the httpd server, i get the error that this directory does not >>exist. I have properly labeled md0 with "e2label" command and added the >>approriate stanza in my "/etc/fstab" to mount the directory >>automatically on boot. I have Selinux running on targeted policy and i >>have attempted to use "fixfiles" and "restorecon" so that Selinux >>recoginizes it.. But i am yet to have success. I have also tried just >>using a normal ext3 partition, that i created after installation, and i >>get the same error. >> >> > >/dev/md0 is a metadevice that describes a raid5 disk volume, it's not >a directory. While I'm not clear on what exactly you're doing from >your post, I have a sneaking suspicion that you've not mounted the >device anywhere. What I believe you want to do is something akin to >the following: > ># mkfs -t ext3 /dev/md0 ># mount -t ext3 /mnt ># service stop httpd ># cp -a /var/www/html/* /mnt ># rm -rf /var/www/html/* ># umount /mnt ># mount -t ext3 /dev/md0 /var/www/html ># restorecon -R -v /var/www/html ># service httpd start > >This creates an extended 3 filesystem on the new raid device, mounts >it in a temporary location, copies your existing web content to it, >removes the web content from the old location, and the replaces it >with the new raid device. The restorecon is self-explanitory as are >the service commands. > >If this isn't the issue, can you please give some more detail on the >problem you're experiencing? > > > Hey Chris thanks for the help, that is essentialy what i had done, the directory was mounted, but i had mounted it on a new partition directory named "/www" and then had changed my "/etc/httpd/conf/httpd.conf" to reflect the new document root settings, i ran the "restorecon -R -v /www" and then reloaded the HTTPD server, the error i received was that none of my new directory structure existed. I then tried as you posted, to mount my new MD0 device in its the position "/var/www" , "mount -t ext3 /dev/md0 /var/www" and ran "restorecon -R -v /var/www" this seems to work as Apache loaded fine, where as me labeling "/dev/md0" as "/www" and running "restorecon -R -v /www" didn't seem work for me. I know by default of course Apache has its core directory stored in "/var/www" -- RHCE - RHEL4 CERT# 804005316914471 https://www.redhat.com/training/certification/verify -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart at jamesnet.ca Sun Apr 24 14:17:10 2005 From: stuart at jamesnet.ca (stuart) Date: Sun, 24 Apr 2005 10:17:10 -0400 Subject: Adding Raid 5 partition In-Reply-To: <426B9E38.6060004@jamesnet.ca> References: <426B2431.5040004@jamesnet.ca> <143f0f6c050423235860dab6dc@mail.gmail.com> <426B9E38.6060004@jamesnet.ca> Message-ID: <426BAA66.9090306@jamesnet.ca> stuart wrote: > Christofer C. Bell wrote: > >>On 4/23/05, stuart wrote: >> >> >>>I have added 3 extra disks to my system, which i have created a new >>>raid5 device on /dev/md0. I wish to use this device to serve webpages, >>>but when i change the document root directive in my httpd.conf, and >>>restart the httpd server, i get the error that this directory does not >>>exist. I have properly labeled md0 with "e2label" command and added the >>>approriate stanza in my "/etc/fstab" to mount the directory >>>automatically on boot. I have Selinux running on targeted policy and i >>>have attempted to use "fixfiles" and "restorecon" so that Selinux >>>recoginizes it.. But i am yet to have success. I have also tried just >>>using a normal ext3 partition, that i created after installation, and i >>>get the same error. >>> >>> >> >>/dev/md0 is a metadevice that describes a raid5 disk volume, it's not >>a directory. While I'm not clear on what exactly you're doing from >>your post, I have a sneaking suspicion that you've not mounted the >>device anywhere. What I believe you want to do is something akin to >>the following: >> >># mkfs -t ext3 /dev/md0 >># mount -t ext3 /mnt >># service stop httpd >># cp -a /var/www/html/* /mnt >># rm -rf /var/www/html/* >># umount /mnt >># mount -t ext3 /dev/md0 /var/www/html >># restorecon -R -v /var/www/html >># service httpd start >> >>This creates an extended 3 filesystem on the new raid device, mounts >>it in a temporary location, copies your existing web content to it, >>removes the web content from the old location, and the replaces it >>with the new raid device. The restorecon is self-explanitory as are >>the service commands. >> >>If this isn't the issue, can you please give some more detail on the >>problem you're experiencing? >> >> >> > Hey Chris thanks for the help, that is essentialy what i had done, the > directory was mounted, but i had mounted it on a new partition > directory named "/www" and then had changed my > "/etc/httpd/conf/httpd.conf" to reflect the new document root > settings, i ran the "restorecon -R -v /www" and then reloaded the > HTTPD server, the error i received was that none of my new directory > structure existed. I then tried as you posted, to mount my new MD0 > device in its the position "/var/www" , "mount -t ext3 /dev/md0 > /var/www" and ran "restorecon -R -v /var/www" this seems to work as > Apache loaded fine, where as me labeling "/dev/md0" as "/www" and > running "restorecon -R -v /www" didn't seem work for me. I know by > default of course Apache has its core directory stored in "/var/www" I have since found another directive in my "httpd.conf" that i had overlooked, the directive "" which i found i needed to also set to "/www/html". Once i changed this, all was well with either mounting my new "md0" in "/www" or "/var/www" with the approriate changes in "httpd.conf" -- RHCE - RHEL4 CERT# 804005316914471 https://www.redhat.com/training/certification/verify -------------- next part -------------- An HTML attachment was scrubbed... URL: From selinux at gmail.com Sun Apr 24 17:38:11 2005 From: selinux at gmail.com (Tom London) Date: Sun, 24 Apr 2005 10:38:11 -0700 Subject: avc messages corrupted? In-Reply-To: <4c4ba15305042313542a3ab454@mail.gmail.com> References: <4c4ba15305042313542a3ab454@mail.gmail.com> Message-ID: <4c4ba15305042410381e78eb59@mail.gmail.com> On 4/23/05, Tom London wrote: > Running targeted/enforcing, latest rawhide (.1261) > > Examining /var/log/messages, I notice some 'corrupted' avc messages, e.g.: > > Apr 23 13:05:33 localhost kernel: audit(1114286729.835:0): avc: > denied { search } for name=3228 dev=proc ino=211550210 > scontext=system_u:system_r:initss=dir > > Apr 23 13:06:31 localhost kernel: audit(1114286790.120:0): avc: > denied { search } for name=3228 dev=proc ino=211550210 > scontext=system_u:system_r:i127:0): avc: denied { search } for > name=1780 dev=proc ino=116654082 scontext=system_u:system_r:init_t > tcontext=system_u:system_r:kernel_t tclass=dir > > Apr 23 13:06:41 localhost kernel: audit(1114286800.202:0): avc: > denied { search } for name=3 dev=proc ino=196610 > scontext=system_u:system_r:inystem_r:init_t > tcontext=system_u:system_r:kernel_t tclass=dir > > [initss? i127? inystem? there are more....] > > Is there a lock problem with auditing? > tom Hmmm, is this an instance of this problem in audit? tom --------------------------------------------------------------------- This sounds like an old kernel bug. There was a patch on the audit mail list that fixes it. It is pending being merged in the mm kernel. It only affects syslog messages. If you use the audit daemon, you won't see the problem. -Steve Grubb --- linux/kernel/audit.c.orig 2005-02-16 13:49:28.839925080 -0500 +++ linux/kernel/audit.c 2005-02-16 13:53:24.757060224 -0500 @@ -513,8 +513,8 @@ if (!audit_pid) { /* No daemon */ int offset = ab->nlh ? NLMSG_SPACE(0) : 0; int len = skb->len - offset; - printk(KERN_ERR "%*.*s\n", - len, len, skb->data + offset); + skb->data[offset + len] = '\0'; + printk(KERN_ERR "%s\n", skb->data + offset); } kfree_skb(skb); ab->nlh = NULL; -- Tom London From selinux at gmail.com Sun Apr 24 17:45:08 2005 From: selinux at gmail.com (Tom London) Date: Sun, 24 Apr 2005 10:45:08 -0700 Subject: selinux-policy-targeted-1.23.12-4: /proc {search} failures ? In-Reply-To: <4c4ba153050423132430522156@mail.gmail.com> References: <4c4ba153050423132430522156@mail.gmail.com> Message-ID: <4c4ba15305042410456a67a5a@mail.gmail.com> Booting w/ enforcing=0 produces the attached log file. My guess is that this happens when init is checking to see if gdm is up (I boot with 'early-login'). Sound reasonable? tom -- Tom London -------------- next part -------------- A non-text attachment was scrubbed... Name: log2 Type: application/octet-stream Size: 50644 bytes Desc: not available URL: From tdiehl at rogueind.com Mon Apr 25 03:48:24 2005 From: tdiehl at rogueind.com (Tom Diehl) Date: Sun, 24 Apr 2005 23:48:24 -0400 (EDT) Subject: Rawhide avc messages In-Reply-To: <200504231254.50952.russell@coker.com.au> References: <200504231254.50952.russell@coker.com.au> Message-ID: On Sat, 23 Apr 2005, Russell Coker wrote: > On Friday 22 April 2005 04:27, Tom Diehl wrote: > > kernel: audit(1114097914.302:0): avc: denied { rename } for pid=1952 > > exe=/bin/mv name=ntp.conf dev=dm-0 ino=102686 > > scontext=user_u:system_r:dhcpc_t tcontext=user_u:object_r:etc_t tclass=file > > Your /etc/ntp.conf is mislabelled. Is it normal to have to relabel individual files like this or is this indicative of something not being setup correctly at install time? This error appeared on the first boot after the install. > > The others are minor errors, the machine should work fine even before we fix > them. The machine does in fact work fine. After the latest update from rawhide today, the messages are gone. Thanks for the fixes. Regards, Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From russell at coker.com.au Mon Apr 25 04:09:04 2005 From: russell at coker.com.au (Russell Coker) Date: Mon, 25 Apr 2005 14:09:04 +1000 Subject: Experiences with selinux enabled targetted on Fedora Core 3 In-Reply-To: <200504240840.j3O8e8nh014705@turing-police.cc.vt.edu> References: <20050221160539.6aba22bd.r.godzilla@comcast.net> <200504211413.32072.russell@coker.com.au> <200504240840.j3O8e8nh014705@turing-police.cc.vt.edu> Message-ID: <200504251409.05673.russell@coker.com.au> On Sunday 24 April 2005 18:40, Valdis.Kletnieks at vt.edu wrote: > > The alternatives are as follows: > > > > 1) Have the users manually relabel. But this requires that they have > > the skill needed to use mount --bind or single user mode. > > Relabelling the /dev mountpoint is quite non-trivial, because booting to > single-user in Fedora still gets udev started and a tmpfs mounted over > /dev. I ended up having to boot from the rescue disk and having to do > something like: Here you are just proving my point about the operation being overly difficult. mount --bind / /mnt ; chcon /mnt ... But there's lots of potential for things to go spectacularly wrong when you do a bind mount (think about what would happen if you ran "fixfiles relabel"). > chroot /mnt/sysimage > mount -t selinux /selinux > restorecon /dev We could of course have the rescue disk contain scripts to manage such things, but again it's really painful, it would require changing code in several packages. > > 2) Have more error messages in the logs. This leads to users ignoring > > the more important AVC messages which is a security issue. > > Quite right - my concern was that we're trying to silence a few msgs at > boot and thus *forcing* the user to ignore the same message during normal > operations, when it *would* be a "more important" message... dontaudit pam_console_t file_t:dir search; dontaudit dmesg_t file_t:dir search; dontaudit hostname_t file_t:dir search; dontaudit hotplug_t file_t:dir { search getattr }; dontaudit hwclock_t file_t:dir search; dontaudit kudzu_t file_t:dir search; dontaudit lvm_t file_t:dir search; dontaudit insmod_t file_t:dir search; dontaudit mrtg_t { boot_t device_t file_t lost_found_t }:dir getattr; dontaudit sulogin_t file_t:dir search; dontaudit syslogd_t file_t:dir search; dontaudit udev_t file_t:dir search; According to a quick grep the above are the domains that have such dontaudit rules. Note that for some it doesn't matter at all, the system is in permissive mode for sulogin_t, mrtg does an operation equivalent to "ls -l /" without any good cause, etc. > > 3) Have more complex code in rc.sysinit for relabeling file systems > > (which is therefore more error prone) and also remove the possibility of > > running "fixfiles relabel" as administrator and forcing a reboot with > > /.autorelabel . > > Unfortunately, the /.autorelabel trick happens too late - it's done right > *after* we've mounted all the filesystems and enabled disk quotas. The > checking would need to be *really* early in rc.sysinit - like before > start_udev gets called. Remember - what got me started on this was the > 'mount -t tmpfs /dev' issuing a message because it was trying to mount onto > a mislabeled /dev... We could change the .autorelabel code to be more complex, use bind mounts, etc. But that also means more failure conditions. Note that there is an opportunity cost to everything we do. There are lots of features that I would like to get in that require more work from the maintainers of such packages. Is it worth delaying work on SE-X, crypto-root, and other security features to remove a few dontaudit rules? > 4) Add code to 'anaconda' (or whatever your distro uses) to do the > appropriate 'restorecon' for the mount points for file systems created > during system install. It knows (or can be taught) what directories in / > (/dev, /proc, /sys, and /selinux) will have pseudo file systems mounted on > them, and what directories will have file systems mounted over them (/var, > /tmp, /usr/local, / usr/share, /home, /opt, and so on). > > After the install, if /usr was a single filesystem, and the admin decides > that they want /usr/local and /usr/share to be 2 new file systems, that's > OK, because the first 'fixfiles relabel' will have set the right settings > on the 'local' and 'share' directories that will now be mount points... > > That still has issues with an admin creating a /foo filesystem, mounting > it, and later on we decide to add a special context for /foo - but as long > as /foo doesn't become required to get to multiuser mode, the admin can > just 'umount /foo; restorecon /foo; mount /foo; restorecon -R foo' and be > done. That also has issues related to fsck removing xattrs on corrupted filesystems, administrators converting non-SE systems to SE Linux, administrators booting machines with selinux=0 while they repartition disks, and all manner of other potential problems. The /.autorelabel file MUST do everything that we require in terms of fixing file labels. We can't rely on anaconda or anything else to fix things up. -- 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 russell at coker.com.au Mon Apr 25 06:10:25 2005 From: russell at coker.com.au (Russell Coker) Date: Mon, 25 Apr 2005 16:10:25 +1000 Subject: selinux-policy-targeted-1.23.12-4: /proc {search} failures ? In-Reply-To: <4c4ba15305042410456a67a5a@mail.gmail.com> References: <4c4ba153050423132430522156@mail.gmail.com> <4c4ba15305042410456a67a5a@mail.gmail.com> Message-ID: <200504251610.29638.russell@coker.com.au> On Monday 25 April 2005 03:45, Tom London wrote: > Booting w/ enforcing=0 produces the attached log file. > > My guess is that this happens when init is checking to see if gdm is > up (I boot with 'early-login'). Sound reasonable? early-login is implemented in /etc/rc.sysinit so it should be running as initrc_t not init_t. avc: denied { write } for name=vcs7 dev=sysfs ino=5938 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:sysfs_t tclass=dir This seems like a bug in hotplug to me. AFAIK it's not valid to create a file under /sys/class/vc/vcs7 or do anything else that requires write access to the directory. Could you please try and track down what is happening and file a bugzilla? avc: denied { read } for name=config dev=dm-0 ino=1275872 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:selinux_config_t tclass=file Is dhclient trying to run restorecon? At one stage it was trying to run restorecon which could result in such access. Please find out what it's doing, presumably it's something from /sbin/dhclient-script that's doing this. As for init_t trying to do something like "ps", could you find out what exactly it's trying to do? Also it would be best if you posted the logs of running with enforcing=0, if nothing else it will give more terse logs that are easier to interpret. -- 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 russell at coker.com.au Mon Apr 25 07:32:16 2005 From: russell at coker.com.au (Russell Coker) Date: Mon, 25 Apr 2005 17:32:16 +1000 Subject: Rawhide avc messages In-Reply-To: References: <200504231254.50952.russell@coker.com.au> Message-ID: <200504251732.20180.russell@coker.com.au> On Monday 25 April 2005 13:48, Tom Diehl wrote: > On Sat, 23 Apr 2005, Russell Coker wrote: > > On Friday 22 April 2005 04:27, Tom Diehl wrote: > > > kernel: audit(1114097914.302:0): avc: denied { rename } for pid=1952 > > > exe=/bin/mv name=ntp.conf dev=dm-0 ino=102686 > > > scontext=user_u:system_r:dhcpc_t tcontext=user_u:object_r:etc_t > > > tclass=file > > > > Your /etc/ntp.conf is mislabelled. > > Is it normal to have to relabel individual files like this or is this > indicative of something not being setup correctly at install time? This > error appeared on the first boot after the install. Until fairly recently it has been "normal" as it has been expected. But of course this is not desired and we have been working hard to fix all such issues. I have just done a test install of FC4T2 and the /etc/ntp.conf file had the correct context. If you can reproduce this then please tell me exactly what you have to do. -- 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 hburde at t-online.de Mon Apr 25 08:24:49 2005 From: hburde at t-online.de (Holger Burde) Date: Mon, 25 Apr 2005 10:24:49 +0200 Subject: apache cron job Message-ID: <1114417489.6180.2.camel@marvin.hb-consult.de> Hi; I run a FC3 System with the rawhide strict Policy. I have a cron script (apache) that needs to read/write files under /var/www/ { httpd_sys_content_t }. Any idea whats the best (= secure) way to do so ? audit2allow suggests this : allow system_crond_t httpd_sys_content_t:file write; - maybe there isa better solution? PS These Scripts update some contents - fetch data from the net and 'rebuild' some pages. That way i do not need SSI .. -- Holger Burde From linux_4ever at yahoo.com Mon Apr 25 10:49:19 2005 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 25 Apr 2005 03:49:19 -0700 (PDT) Subject: avc messages corrupted? In-Reply-To: 6667 Message-ID: <20050425104919.33702.qmail@web51501.mail.yahoo.com> >Hmmm, is this an instance of this problem in audit? Most likely. We are trying to get 7-8 audit kernel patches into FC4 and new kernels should be released later this week. This problem only affects syslog avc messages and not messages captured by the audit daemon. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ From russell at coker.com.au Mon Apr 25 10:59:04 2005 From: russell at coker.com.au (Russell Coker) Date: Mon, 25 Apr 2005 20:59:04 +1000 Subject: apache cron job In-Reply-To: <1114417489.6180.2.camel@marvin.hb-consult.de> References: <1114417489.6180.2.camel@marvin.hb-consult.de> Message-ID: <200504252059.07630.russell@coker.com.au> On Monday 25 April 2005 18:24, Holger Burde wrote: > I run a FC3 System with the rawhide strict Policy. I have a cron script > (apache) that needs to read/write files under /var/www/ > { httpd_sys_content_t }. Any idea whats the best (= secure) way to do > so ? audit2allow suggests this : allow system_crond_t > httpd_sys_content_t:file write; - maybe there isa better solution? Cron jobs that deal with data from the net are a risk, potentially if an attacker controlled the remote data source they could make repeated attempts at manipulating the data to exploit your machine without you realising. Having a separate domain for the cron job may be best. But this would require writing more policy. -- 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 hampton-rh at rainbolthampton.net Mon Apr 25 11:14:41 2005 From: hampton-rh at rainbolthampton.net (David Hampton) Date: Mon, 25 Apr 2005 07:14:41 -0400 Subject: New policy for DCC In-Reply-To: <200504220054.22405.russell@coker.com.au> References: <1111454598.18940.57.camel@hampton-pc.rainbolthampton.net> <200504220054.22405.russell@coker.com.au> Message-ID: <1114427681.13081.24.camel@hampton-pc.rainbolthampton.net> On Fri, 2005-04-22 at 00:54 +1000, Russell Coker wrote: > Firstly daemons should not be started with su. Agreed, but thats how the designer of DCC implemented it. > Why do you use init_service_domain() and domain_auto_trans(initrc_t, > dcc_script_exec_t, dcc_script_t)? > > Surely the daemon is to be started either from inittab or from an /etc/init.d > script but not both. Its started from /etc/init.d or by hand. I'll correct the policy to remove init_service_domain. > Putting a unix domain socket in /etc is wrong. Among other things it will > probably break things for anyone who wants to run with a read-only root file > system. Agreed. This was moved from /var/dcc to /etc by the packager. I've submitted a patch to restore it to the /var/dcc directory. In the mean time I wrote the policy to work with either location. > Types used under the /var/run directory generally should have the pidfile > attribute so that they can be cleaned up by boot scripts if necessary. Thanks, will do. > There is a type dccm_sock_t defined which is not in the .fc file. I missed this in my initial submission. > Allowing access to sshd_t:fd is not what you want, you want to use privfd:fd > to allow the administrator to use a console login. Also you want to use > admin_tty_type:chr_file instead of sysadm_devpts_t:chr_file for the same > reason. Will do. I'll update this in all my policies. > Without even knowing what DCC does Spam filtering based upon message checksums. > I feel confident in guessing that it's not > nearly half as complex as Postfix and doesn't need so many domains. > Excessive domains makes the policy difficult to analyse. For starters > dccifd_t and dccm_t can be merged. I have no problem reducing the number of domains. I got the impression somewhere that each executable should be its own domain. Would three domains be reasonable (the server, clients that connect to the server, everything else), or just two (executables that access the network and the utility programs)? David From hburde at t-online.de Mon Apr 25 10:48:22 2005 From: hburde at t-online.de (Holger Burde) Date: Mon, 25 Apr 2005 12:48:22 +0200 Subject: apache cron job In-Reply-To: <200504252059.07630.russell@coker.com.au> References: <1114417489.6180.2.camel@marvin.hb-consult.de> <200504252059.07630.russell@coker.com.au> Message-ID: <1114426103.6180.18.camel@marvin.hb-consult.de> hi; The data is checked before any processing takes place (src, length, a parser goes over it,..). If it does not meet the criteria its thrown away. I'll take a look at the 'separate domain' approach .. thx ... hb Am Montag, den 25.04.2005, 20:59 +1000 schrieb Russell Coker: > On Monday 25 April 2005 18:24, Holger Burde wrote: > > I run a FC3 System with the rawhide strict Policy. I have a cron script > > (apache) that needs to read/write files under /var/www/ > > { httpd_sys_content_t }. Any idea whats the best (= secure) way to do > > so ? audit2allow suggests this : allow system_crond_t > > httpd_sys_content_t:file write; - maybe there isa better solution? > > Cron jobs that deal with data from the net are a risk, potentially if an > attacker controlled the remote data source they could make repeated attempts > at manipulating the data to exploit your machine without you realising. > > Having a separate domain for the cron job may be best. But this would require > writing more policy. > -- Holger Burde From sds at tycho.nsa.gov Mon Apr 25 12:35:47 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 25 Apr 2005 08:35:47 -0400 Subject: Limiting IPC with SELinux? In-Reply-To: <20050422184620.GA13859@thorium.jmh.mhn.de> References: <60D45469A1AAD311A04C009027B6BF6804FCF0AB@server20.inside.oracorp.com> <20050422184620.GA13859@thorium.jmh.mhn.de> Message-ID: <1114432547.27036.55.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-04-22 at 20:46 +0200, Thomas Bleher wrote: > I had an idea a while ago which may help you. I wanted to implement it > myself but don't have time to do any kernel-hacking currently, so if you > want to try it, feel free. > My idea was to build an iptables modules similar to the "Owner match" > module which matches locally generated packets against a specific domain. > That way you could probably achieve most of what you want. > One problem here is: how do we cleanly match on security context? All > the logic should be in the security server and controllable by policy. > The most sane way I came up with is this: > Declare a new class "iptables" (or "netfilter") with one permission > "match". Then put this into policy: > allow domain self:iptables match; > The usermode iptables code passes a complete security context into the > kernel which is converted into a sid internally. Now everytime the > iptables module is called on a packet it asks the avc if packet>::IPTABLES__MATCH is allowed in the > policy. > I do not know if this is the best approach but it does allow matching on > specific domains, on specific contexts (if the constraints are adjusted) > or on a group of domains (you could add a dummy type all_userdomains_t > and add "allow userdomain all_userdomains_t:iptables match;" or > something like that and then match on all_userdomains_t in the iptables > rule) > > I think such a module would be very useful. For example, the admin may > want to specify that mozilla may only talk to the internal proxy server. > > Of course, this depends on the fact that such a module is actually > doable and sane. I looked at the code but I am no kernel hacker so I > would appreciate any insight/ideas. LIDS seems to have supported something similar at one time using the iptables MARK module: http://www.lids.org/document/lids_worm.html -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Mon Apr 25 12:38:11 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 25 Apr 2005 08:38:11 -0400 Subject: Limiting IPC with SELinux? In-Reply-To: References: Message-ID: <1114432691.27036.59.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-04-22 at 14:58 -0400, James Morris wrote: > On Fri, 22 Apr 2005, Steve Brueckner wrote: > > > return ephemeral ports. Or is there a chance of re-visiting the idea of > > getting labeled networking into the kernel? > > Work is being done on labeled networking via IPsec, see Trent Jaeger's > paper at http://www.selinux-symposium.org/2005/agenda.php True, but I don't think this will help much in this particular case, as the original poster wants to control information flow via loopback and you aren't likely to be using IPSEC on such traffic. In the absence of a sk_buff security field and associated hooks for lifecycle management, I think that we'd have to go with something like the iptables MARK module, ala LIDS. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Mon Apr 25 12:56:32 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 25 Apr 2005 08:56:32 -0400 Subject: avc messages corrupted? In-Reply-To: <4c4ba15305042410381e78eb59@mail.gmail.com> References: <4c4ba15305042313542a3ab454@mail.gmail.com> <4c4ba15305042410381e78eb59@mail.gmail.com> Message-ID: <1114433792.27036.81.camel@moss-spartans.epoch.ncsc.mil> On Sun, 2005-04-24 at 10:38 -0700, Tom London wrote: > On 4/23/05, Tom London wrote: > > Running targeted/enforcing, latest rawhide (.1261) > > > > Examining /var/log/messages, I notice some 'corrupted' avc messages, e.g.: > > > > Apr 23 13:05:33 localhost kernel: audit(1114286729.835:0): avc: > > denied { search } for name=3228 dev=proc ino=211550210 > > scontext=system_u:system_r:initss=dir > > > > Apr 23 13:06:31 localhost kernel: audit(1114286790.120:0): avc: > > denied { search } for name=3228 dev=proc ino=211550210 > > scontext=system_u:system_r:i127:0): avc: denied { search } for > > name=1780 dev=proc ino=116654082 scontext=system_u:system_r:init_t > > tcontext=system_u:system_r:kernel_t tclass=dir > > > > Apr 23 13:06:41 localhost kernel: audit(1114286800.202:0): avc: > > denied { search } for name=3 dev=proc ino=196610 > > scontext=system_u:system_r:inystem_r:init_t > > tcontext=system_u:system_r:kernel_t tclass=dir > > > > [initss? i127? inystem? there are more....] > > > > Is there a lock problem with auditing? > > tom > > Hmmm, is this an instance of this problem in audit? Yes, looks like it, and the bug goes back to when SELinux was first converted to using the 2.6 audit framework; people were seeing it back in FC2 times. Note btw that the absence of the pid= and exe= information is a separate issue; that is due to the patch that moved that logging to the audit framework, so you need to enable syscall auditing to retain it. Boot your kernel with audit=1 or use auditctl -e 1 to enable. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Mon Apr 25 13:00:43 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 25 Apr 2005 09:00:43 -0400 Subject: Limiting IPC with SELinux? In-Reply-To: <1114432691.27036.59.camel@moss-spartans.epoch.ncsc.mil> References: <1114432691.27036.59.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1114434043.27036.84.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-04-25 at 08:38 -0400, Stephen Smalley wrote: > On Fri, 2005-04-22 at 14:58 -0400, James Morris wrote: > > On Fri, 22 Apr 2005, Steve Brueckner wrote: > > > > > return ephemeral ports. Or is there a chance of re-visiting the idea of > > > getting labeled networking into the kernel? > > > > Work is being done on labeled networking via IPsec, see Trent Jaeger's > > paper at http://www.selinux-symposium.org/2005/agenda.php > > True, but I don't think this will help much in this particular case, as > the original poster wants to control information flow via loopback and > you aren't likely to be using IPSEC on such traffic. In the absence of > a sk_buff security field and associated hooks for lifecycle management, > I think that we'd have to go with something like the iptables MARK > module, ala LIDS. Actually, Thomas Bleher's suggestion of extending the ipt owner module might be better. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Mon Apr 25 15:14:10 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 25 Apr 2005 11:14:10 -0400 Subject: avc: denied { search } for smbd In-Reply-To: References: <27467a812dd6a2424dcc9705d5f25720@mac.com> <1114259119.3496.0.camel@localhost.localdomain> Message-ID: <426D0942.6000206@redhat.com> Felipe Alfaro Solana wrote: > On 23 Apr 2005, at 14:25, Ivan Gyurdiev wrote: > >> >>> So I don't understand what's going on: the policy explicitly allows >>> domain smbd_t to perform search on home_root_t:dir and /home is already >>> labeled home_root_t. >> >> >> Yes, but it only does this when samba_enable_home_dirs is on. >> >> Toggle the boolean. > > > Thanks. > I have manually added the following line to > /etc/selinux/targeted/booleans.local > > samba_enable_home_dirs=1 > > but now, I'm getting these avc's: > > audit(1114271834.460:0): avc: denied { getattr } for path=/dev/pts > dev=devpts ino=1 scontext=user_u:system_r:smbd_t > tcontext=user_u:object_r:devpts_t tclass=dir > Is this causing it to fail or is this just being reported in the log files and ignored? > More ideas? > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list -- From jmorris at redhat.com Mon Apr 25 15:39:35 2005 From: jmorris at redhat.com (James Morris) Date: Mon, 25 Apr 2005 11:39:35 -0400 (EDT) Subject: Limiting IPC with SELinux? In-Reply-To: <1114432691.27036.59.camel@moss-spartans.epoch.ncsc.mil> Message-ID: On Mon, 25 Apr 2005, Stephen Smalley wrote: > True, but I don't think this will help much in this particular case, as > the original poster wants to control information flow via loopback and > you aren't likely to be using IPSEC on such traffic. You could use null encryption and null authentication. Another possibility is to implement SO_PEERSEC for loopback TCP, although I think it requires more LSM hooks. > In the absence of a sk_buff security field and associated hooks for > lifecycle management, I think that we'd have to go with something like > the iptables MARK module, ala LIDS. I think this is at the wrong layer; how would you query the socket for peer security information? - James -- James Morris From jmorris at redhat.com Mon Apr 25 15:46:54 2005 From: jmorris at redhat.com (James Morris) Date: Mon, 25 Apr 2005 11:46:54 -0400 (EDT) Subject: Limiting IPC with SELinux? In-Reply-To: <1114434043.27036.84.camel@moss-spartans.epoch.ncsc.mil> Message-ID: On Mon, 25 Apr 2005, Stephen Smalley wrote: > Actually, Thomas Bleher's suggestion of extending the ipt owner module > might be better. The upstream module only works for outgoing packets, and also imposes some heavy locking. For outgoing packets we already have the security context via the owning socket, and for incoming packets we probably need to hook sock_rcv_skb. In any case, I didn't understand the idea of adding a permission for all matches, when the SELinux code doesn't understand why the packet was being matched or what is supposed to happen to it. - James -- James Morris From himainu-ynakam at miomio.jp Mon Apr 25 16:22:31 2005 From: himainu-ynakam at miomio.jp (Yuichi Nakamura) Date: Mon, 25 Apr 2005 12:22:31 -0400 Subject: Webalizer [patch] In-Reply-To: <1113516934.6056.44.camel@hampton-pc.rainbolthampton.net> References: <1113516934.6056.44.camel@hampton-pc.rainbolthampton.net> Message-ID: <200504251623.j3PGN52v025608@mms-r01.iijmio.jp> David Hampton wrote: > Webalizer seems to have lost its fc file somewhere along the way. The > attached patch supplies a file context that works on > FC3/strict/1.23.10-2, and also allows access to the nscd service. I tried FC3 strict policy, I found /etc/cron.daily/00webalizer does not work. Patch from David is necessary. Why was webalizer.fc dropped when I submitted webalizer.te and .fc before? --- Yuichi Nakamura Hitachi Software http://www.selinux.hitachi-sk.co.jp/en Japan SELinux Users Group(JSELUG) http://www.selinux.gr.jp/ Japan Open Source Advocacy Organization(JOSAO) http://www.josao.jp/ The George Washington University From ivg2 at cornell.edu Mon Apr 25 19:08:39 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Mon, 25 Apr 2005 15:08:39 -0400 Subject: avc: denied { search } for smbd In-Reply-To: <426D0942.6000206@redhat.com> References: <27467a812dd6a2424dcc9705d5f25720@mac.com> <1114259119.3496.0.camel@localhost.localdomain> <426D0942.6000206@redhat.com> Message-ID: <1114456120.10747.2.camel@localhost.localdomain> > Is this causing it to fail or is this just being reported in the log > files and ignored? It seems to work fine - it's just audit noise. For some reason samba does a stat() on all mounted filesystems when queried about the filesystem size - couldn't find the code that actually does this though. -- Ivan Gyurdiev Cornell University From lfarkas at bppiac.hu Mon Apr 25 19:43:08 2005 From: lfarkas at bppiac.hu (Farkas Levente) Date: Mon, 25 Apr 2005 21:43:08 +0200 Subject: proper samba labeling Message-ID: <426D484C.3050508@bppiac.hu> hi, we just upgrade some of our server to selinux enabled kernel. but the date files are on a raid array which just remounted. this samba server's files are also on that array and they are not labeled at all. what is the right labeling for samba shares? i look trough policy source files but i can't find any proper type for samba. or it's the right way to not label sabma files at all? yours. -- Levente "Si vis pacem para bellum!" From ivg2 at cornell.edu Mon Apr 25 19:50:09 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Mon, 25 Apr 2005 15:50:09 -0400 Subject: proper samba labeling In-Reply-To: <426D484C.3050508@bppiac.hu> References: <426D484C.3050508@bppiac.hu> Message-ID: <1114458609.10969.0.camel@localhost.localdomain> On Mon, 2005-04-25 at 21:43 +0200, Farkas Levente wrote: > hi, > we just upgrade some of our server to selinux enabled kernel. but the > date files are on a raid array which just remounted. this samba server's > files are also on that array and they are not labeled at all. what is > the right labeling for samba shares? i look trough policy source files > but i can't find any proper type for samba. or it's the right way to not > label sabma files at all? I think it's samba_share_t. -- Ivan Gyurdiev Cornell University From russell at coker.com.au Mon Apr 25 20:39:33 2005 From: russell at coker.com.au (Russell Coker) Date: Tue, 26 Apr 2005 06:39:33 +1000 Subject: New policy for DCC In-Reply-To: <1114427681.13081.24.camel@hampton-pc.rainbolthampton.net> References: <1111454598.18940.57.camel@hampton-pc.rainbolthampton.net> <200504220054.22405.russell@coker.com.au> <1114427681.13081.24.camel@hampton-pc.rainbolthampton.net> Message-ID: <200504260639.37371.russell@coker.com.au> On Monday 25 April 2005 21:14, David Hampton wrote: > On Fri, 2005-04-22 at 00:54 +1000, Russell Coker wrote: > > Firstly daemons should not be started with su. > > Agreed, but thats how the designer of DCC implemented it. So it's up to the distribution maintainers (people such as us) to correct this mistake. > > Why do you use init_service_domain() and domain_auto_trans(initrc_t, > > dcc_script_exec_t, dcc_script_t)? > > > > Surely the daemon is to be started either from inittab or from an > > /etc/init.d script but not both. > > Its started from /etc/init.d or by hand. I'll correct the policy to > remove init_service_domain. OK, then daemon_base_domain() or daemon_domain() is what you want. > > Putting a unix domain socket in /etc is wrong. Among other things it > > will probably break things for anyone who wants to run with a read-only > > root file system. > > Agreed. This was moved from /var/dcc to /etc by the packager. I've > submitted a patch to restore it to the /var/dcc directory. In the mean > time I wrote the policy to work with either location. OK, but when you publish policy please publish it to work with the fixed package. > > I feel confident in guessing that it's not > > nearly half as complex as Postfix and doesn't need so many domains. > > Excessive domains makes the policy difficult to analyse. For starters > > dccifd_t and dccm_t can be merged. > > I have no problem reducing the number of domains. I got the impression > somewhere that each executable should be its own domain. Would three > domains be reasonable (the server, clients that connect to the server, > everything else), or just two (executables that access the network and > the utility programs)? Try it with three. Once I see working policy for three domains I can make a better judgement as to whether it would be best expressed as two domains. -- 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 lfarkas at bppiac.hu Mon Apr 25 21:03:31 2005 From: lfarkas at bppiac.hu (Farkas Levente) Date: Mon, 25 Apr 2005 23:03:31 +0200 Subject: awstats Message-ID: <426D5B23.4060403@bppiac.hu> hi, we use http://awstats.sourceforge.net/ to generate http web statistics. in order to generate date there is a hourly cron job which collect the statistics from the webserver's log file. but this scripts use the same collection of perl scripts which generates the web pages. how can i solve it? i found this description: http://yanbaru.dyndns.org/linux/fedora2awstats.html although i don't realy like local.te. is there any 'default' settings for awstats? i wish we has some kind of default policy which include rules for awstats too:-0 yours. -- Levente "Si vis pacem para bellum!" From lfarkas at bppiac.hu Mon Apr 25 21:12:47 2005 From: lfarkas at bppiac.hu (Farkas Levente) Date: Mon, 25 Apr 2005 23:12:47 +0200 Subject: proper samba labeling In-Reply-To: <1114458609.10969.0.camel@localhost.localdomain> References: <426D484C.3050508@bppiac.hu> <1114458609.10969.0.camel@localhost.localdomain> Message-ID: <426D5D4F.7090806@bppiac.hu> Ivan Gyurdiev wrote: > On Mon, 2005-04-25 at 21:43 +0200, Farkas Levente wrote: > >>hi, >>we just upgrade some of our server to selinux enabled kernel. but the >>date files are on a raid array which just remounted. this samba server's >>files are also on that array and they are not labeled at all. what is >>the right labeling for samba shares? i look trough policy source files >>but i can't find any proper type for samba. or it's the right way to not >>label sabma files at all? > > > I think it's samba_share_t. > i can't find such type:-( -- Levente "Si vis pacem para bellum!" From ivg2 at cornell.edu Mon Apr 25 21:22:52 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Mon, 25 Apr 2005 17:22:52 -0400 Subject: proper samba labeling In-Reply-To: <426D5D4F.7090806@bppiac.hu> References: <426D484C.3050508@bppiac.hu> <1114458609.10969.0.camel@localhost.localdomain> <426D5D4F.7090806@bppiac.hu> Message-ID: <1114464172.11049.3.camel@localhost.localdomain> On Mon, 2005-04-25 at 23:12 +0200, Farkas Levente wrote: > Ivan Gyurdiev wrote: > > On Mon, 2005-04-25 at 21:43 +0200, Farkas Levente wrote: > > > >>hi, > >>we just upgrade some of our server to selinux enabled kernel. but the > >>date files are on a raid array which just remounted. this samba server's > >>files are also on that array and they are not labeled at all. what is > >>the right labeling for samba shares? i look trough policy source files > >>but i can't find any proper type for samba. or it's the right way to not > >>label sabma files at all? > > > > > > I think it's samba_share_t. > > > > i can't find such type:-( It's in src/policy/domains/program/samba.te in both the targeted and strict policy on my computer. However, this is rawhide. Is yours running the FC3 policy, perhaps? I can't remember if FC3 had a policy for samba in targeted. -- Ivan Gyurdiev Cornell University From hburde at t-online.de Tue Apr 26 08:05:12 2005 From: hburde at t-online.de (Holger Burde) Date: Tue, 26 Apr 2005 10:05:12 +0200 Subject: rawhide strict & crond Message-ID: <1114502712.5760.9.camel@marvin.hb-consult.de> Hi; I tried to run a cron job from the apache account but nothing happends beside a entry in /var/log/cron : Apr 26 10:51:49 dragon crond[4284]: (CRON) STARTUP (V5.0) Apr 26 10:51:49 dragon crond[4284]: (apache) ENTRYPOINT FAILED (cron/apache) (wrong context? ) audit2allow -i /var/log/messages -l nothing ... I tried some relabeling but nothing seems to help. Any insight into this? Place for scripts is /var/www/scripts/bin, context is default. Do i have to add apache to selinux/.... /users ? and which roles ? System is FC3 with rawhide.strict (almost up2date). -- Holger Burde From russell at coker.com.au Tue Apr 26 11:11:59 2005 From: russell at coker.com.au (Russell Coker) Date: Tue, 26 Apr 2005 21:11:59 +1000 Subject: udev SE Linux policy Message-ID: <200504262112.02638.russell@coker.com.au> udev.fc needs the following addition to work with yesterday's rawhide: /dev/\.udevdb(/.*)? -- system_u:object_r:udev_tdb_t We're now on the third naming for this data store, hopefully it will remain at this name for a while... -- 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 sds at tycho.nsa.gov Tue Apr 26 11:35:21 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 26 Apr 2005 07:35:21 -0400 Subject: rawhide strict & crond In-Reply-To: <1114502712.5760.9.camel@marvin.hb-consult.de> References: <1114502712.5760.9.camel@marvin.hb-consult.de> Message-ID: <1114515321.30521.18.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-04-26 at 10:05 +0200, Holger Burde wrote: > I tried to run a cron job from the apache account but nothing happends > beside a entry in /var/log/cron : > > Apr 26 10:51:49 dragon crond[4284]: (CRON) STARTUP (V5.0) > Apr 26 10:51:49 dragon crond[4284]: (apache) ENTRYPOINT FAILED > (cron/apache) > > (wrong context? ) Yes; crond applies an entrypoint permission check of its own between the security context for the cron job process and the security context on the crontab file to prevent tricking a more trusted cron job process (e.g. root's cron jobs) from running untrustworthy input. What does ls -Z /var/spool/cron/ show? In the absence of an explicit user identity for apache in the SELinux policy, I'd expect the apache crontab to be labeled :object_r:user_cron_spool_t (the doesn't matter; could be system_u or user_u or root). > audit2allow -i /var/log/messages -l > nothing ... Yes, it isn't a kernel denial; it is a check by crond. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Tue Apr 26 11:55:55 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 26 Apr 2005 07:55:55 -0400 Subject: proper samba labeling In-Reply-To: <426D484C.3050508@bppiac.hu> References: <426D484C.3050508@bppiac.hu> Message-ID: <426E2C4B.5040703@redhat.com> Farkas Levente wrote: > hi, > we just upgrade some of our server to selinux enabled kernel. but the > date files are on a raid array which just remounted. this samba > server's files are also on that array and they are not labeled at all. > what is the right labeling for samba shares? i look trough policy > source files but i can't find any proper type for samba. or it's the > right way to not label sabma files at all? > yours. > Depends on what you want to do with the files. You might not want to label it at all. Is your server mounting files from a samba server? If yes, those files will automatically be mounted as cifs_t. If this machine is a samba server and you want to share those files, then it should be able to just do it. Are you seeing a problem sharing the files? If you want to provide general access to users you could use a mount option and mount them as nfs_t or user_home_t. samba_share_t is in Rawhide/FC4 and is for the server side. These are files to be shared. Dan -- From lfarkas at bppiac.hu Tue Apr 26 12:38:42 2005 From: lfarkas at bppiac.hu (Farkas Levente) Date: Tue, 26 Apr 2005 14:38:42 +0200 Subject: proper samba labeling In-Reply-To: <426E2C4B.5040703@redhat.com> References: <426D484C.3050508@bppiac.hu> <426E2C4B.5040703@redhat.com> Message-ID: <426E3652.9040808@bppiac.hu> Daniel J Walsh wrote: > Farkas Levente wrote: > >> hi, >> we just upgrade some of our server to selinux enabled kernel. but the >> date files are on a raid array which just remounted. this samba >> server's files are also on that array and they are not labeled at all. >> what is the right labeling for samba shares? i look trough policy >> source files but i can't find any proper type for samba. or it's the >> right way to not label sabma files at all? >> yours. >> > Depends on what you want to do with the files. You might not want to > label it at all. Is your server mounting files from a samba server? If > yes, those files will automatically be mounted as cifs_t. > > If this machine is a samba server and you want to share those files, > then it should be able to just do it. Are you seeing a problem sharing > the files? no, i asked it, since i just recognized these files are not labeled and may be it cause problems later. > If you want to provide general access to users you could use a mount > option and mount them as nfs_t or user_home_t. > > samba_share_t is in Rawhide/FC4 and is for the server side. These are > files to be shared. thanks. anyway is there any docs about nfs_home_dirs, etc? -- Levente "Si vis pacem para bellum!" From hburde at t-online.de Tue Apr 26 12:05:50 2005 From: hburde at t-online.de (Holger Burde) Date: Tue, 26 Apr 2005 14:05:50 +0200 Subject: rawhide strict & crond In-Reply-To: <1114515321.30521.18.camel@moss-spartans.epoch.ncsc.mil> References: <1114502712.5760.9.camel@marvin.hb-consult.de> <1114515321.30521.18.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1114517150.6522.5.camel@marvin.hb-consult.de> Hi; It looked that way : [root at dragon bin]# ls -lZ /var/spool/cron/ -rw------- root root root:object_r:sysadm_cron_spool_t apache I created the cron entry as root/sysadm_r with the -u flag for user apache. After i changed it to root:object_r:user_cron_spool_t it worked ! THX hb Am Dienstag, den 26.04.2005, 07:35 -0400 schrieb Stephen Smalley: > On Tue, 2005-04-26 at 10:05 +0200, Holger Burde wrote: > > I tried to run a cron job from the apache account but nothing happends > > beside a entry in /var/log/cron : > > > > Apr 26 10:51:49 dragon crond[4284]: (CRON) STARTUP (V5.0) > > Apr 26 10:51:49 dragon crond[4284]: (apache) ENTRYPOINT FAILED > > (cron/apache) > > > > (wrong context? ) > > Yes; crond applies an entrypoint permission check of its own between the > security context for the cron job process and the security context on > the crontab file to prevent tricking a more trusted cron job process > (e.g. root's cron jobs) from running untrustworthy input. What does ls > -Z /var/spool/cron/ show? In the absence of an explicit user identity > for apache in the SELinux policy, I'd expect the apache crontab to be > labeled :object_r:user_cron_spool_t (the doesn't matter; > could be system_u or user_u or root). > > > audit2allow -i /var/log/messages -l > > nothing ... > > Yes, it isn't a kernel denial; it is a check by crond. > -- Holger Burde From lfarkas at bppiac.hu Tue Apr 26 13:59:19 2005 From: lfarkas at bppiac.hu (Farkas Levente) Date: Tue, 26 Apr 2005 15:59:19 +0200 Subject: nagios_log_t missing Message-ID: <426E4937.7000604@bppiac.hu> hi, there is a nagios_log_t and used in nagios.fc but never defined (missing). so when we try to apply it we got these errors: --------------------------------------------- # chcon -R -t nagios_log_t /var/log/nagios chcon: failed to change context of /var/log/nagios to system_u:object_r:nagios_log_t: Invalid argument chcon: failed to change context of /var/log/nagios/rw to system_u:object_r:nagios_log_t: Invalid argument chcon: failed to change context of /var/log/nagios/archives to system_u:object_r:nagios_log_t: Invalid argument chcon: failed to change context of /var/log/nagios/.bash_history to user_u:object_r:nagios_log_t: Invalid argument --------------------------------------------- how can i fix it? dan could you create updated rpms which fix it in ftp://people.redhat.com/dwalsh/SELinux/RHEL4/ ?:-) yours. -- Levente "Si vis pacem para bellum!" From dwalsh at redhat.com Tue Apr 26 15:14:15 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 26 Apr 2005 11:14:15 -0400 Subject: nagios_log_t missing In-Reply-To: <426E4937.7000604@bppiac.hu> References: <426E4937.7000604@bppiac.hu> Message-ID: <426E5AC7.2020703@redhat.com> Farkas Levente wrote: > hi, > there is a nagios_log_t and used in nagios.fc but never defined > (missing). so when we try to apply it we got these errors: > --------------------------------------------- > # chcon -R -t nagios_log_t /var/log/nagios > chcon: failed to change context of /var/log/nagios to > system_u:object_r:nagios_log_t: Invalid argument > chcon: failed to change context of /var/log/nagios/rw to > system_u:object_r:nagios_log_t: Invalid argument > chcon: failed to change context of /var/log/nagios/archives to > system_u:object_r:nagios_log_t: Invalid argument > chcon: failed to change context of /var/log/nagios/.bash_history to > user_u:object_r:nagios_log_t: Invalid argument > --------------------------------------------- > how can i fix it? > dan could you create updated rpms which fix it in > ftp://people.redhat.com/dwalsh/SELinux/RHEL4/ ?:-) > yours. > nagios policy is not used in RHEL4. It should run unconfined_t. We are only supporting the subset of network daemons in targeted policy. Using strict or other policies in RHEL4 requires a separate support contract, professional services engagement. Dan -- From steve at atc-nycorp.com Tue Apr 26 19:07:45 2005 From: steve at atc-nycorp.com (Steve Brueckner) Date: Tue, 26 Apr 2005 15:07:45 -0400 Subject: Rawhide update gone awry Message-ID: <60D45469A1AAD311A04C009027B6BF6804FCF0BD@server20.inside.oracorp.com> I appear to have borked my SELinux installation. I wanted to experiment with the new name_connect permission, which I read was available with the latest rawhide kernel and selinux policy. So, in my first-ever attempt to use rawhide, I enabled my /etc/yum.repos.d/fedora-devel.repo file and then yum updated to the following: kernel.i686 2.6.11-1.1267_FC4 installed selinux-policy-targeted.noarch 1.23.12-4 installed selinux-policy-targeted-sources.noarch 1.23.12-4 installed selinux-policy-strict.noarch 1.23.12-4 installed selinux-policy-strict-sources.noarch 1.23.12-4 installed libselinux.i386 1.23.7-3 installed libselinux-devel.i386 1.23.7-3 installed libselinux-debuginfo.i386 1.23.7-3 installed libsepol.i386 1.5.5-2 installed policycoreutils.i386 1.23.6-1 installed checkpolicy.i386 1.23.1-1 installed setools.i386 2.1.0-2 installed selinux-doc.noarch 1.19.5-1 installed I then did a touch /.autorelabel; reboot, then after rebooting a make reload. I'm using the targeted policy in permissive mode (things freeze up when I setenforce 1). Policy version is 19. I get a lot of avc denied messages on boot; enough to make me think I did something wrong with my policy update or kernel update. Did I even go about this the right way? Is there anything obviously wrong with the steps I took? I'm running FC3, and I wasn't certain about updating to an FC4 kernel but yum seemed to think it was OK so I went for it. I get the same errors when I revert to 2.6.11-1.14_FC3. Thanks for any ideas. My boot log is included below, with anything non-SELinux related snipped out. - Steve Brueckner, ATC-NY $ dmesg Linux version 2.6.11-1.1267_FC4 (bhcompile at porky.build.redhat.com) (gcc version 4.0.0 20050423 (Red Hat 4.0.0-1)) #1 Mon Apr 25 19:22:44 EDT 2005 ... Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary ... audit: initializing netlink socket (disabled) audit(1114514592.659:0): initialized ... SELinux: Registering netfilter hooks ... security: 3 users, 6 roles, 684 types, 75 bools security: 55 classes, 126760 rules SELinux: Completing initialization. SELinux: Setting up existing superblocks. SELinux: initialized (dev dm-0, type ext3), uses xattr SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts SELinux: initialized (dev mqueue, type mqueue), not configured for labeling SELinux: initialized (dev hugetlbfs, type hugetlbfs), not configured for labeling SELinux: initialized (dev devpts, type devpts), uses transition SIDs SELinux: initialized (dev eventpollfs, type eventpollfs), uses genfs_contexts SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts SELinux: initialized (dev pipefs, type pipefs), uses task SIDs SELinux: initialized (dev sockfs, type sockfs), uses task SIDs SELinux: initialized (dev proc, type proc), uses genfs_contexts SELinux: initialized (dev bdev, type bdev), uses genfs_contexts SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts audit(1114514601.951:0): avc: denied { use } for path=/init dev=rootfs ino=8 scontext=system_u:system_r:syslogd_t tcontext=system_u:system_r:kernel_t tclass=fd ... SELinux: initialized (dev ramfs, type ramfs), uses genfs_contexts ... SELinux: initialized (dev hda1, type ext3), uses xattr SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs Adding 2031608k swap on /dev/VolGroup00/LogVol01. Priority:-1 extents:1 SELinux: initialized (dev binfmt_misc, type binfmt_misc), uses genfs_contexts ... audit(1114529038.066:0): avc: denied { read } for name=config dev=dm-0 ino=3837327 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:selinux_config_t tclass=file audit(1114529038.066:0): avc: denied { getattr } for path=/etc/selinux/config dev=dm-0 ino=3837327 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:selinux_config_t tclass=file audit(1114529038.092:0): avc: denied { execute } for name=restorecon dev=dm-0 ino=1802308 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:restorecon_exec_t tclass=file audit(1114529038.092:0): avc: denied { execute_no_trans } for path=/sbin/restorecon dev=dm-0 ino=1802308 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:restorecon_exec_t tclass=file audit(1114529038.092:0): avc: denied { read } for path=/sbin/restorecon dev=dm-0 ino=1802308 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:restorecon_exec_t tclass=file audit(1114529038.093:0): avc: denied { search } for name=contexts dev=dm-0 ino=3834258 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:default_context_t tclass=dir audit(1114529038.093:0): avc: denied { search } for name=files dev=dm-0 ino=3834262 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:file_context_t tclass=dir audit(1114529038.093:0): avc: denied { read } for name=file_contexts dev=dm-0 ino=3834260 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:file_context_t tclass=file audit(1114529038.093:0): avc: denied { getattr } for path=/etc/selinux/targeted/contexts/files/file_contexts dev=dm-0 ino=3834260 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:file_context_t tclass=file audit(1114529038.096:0): avc: denied { search } for name=/ dev=selinuxfs ino=232 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:security_t tclass=dir audit(1114529038.096:0): avc: denied { read write } for name=context dev=selinuxfs ino=5 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:security_t tclass=file audit(1114529038.096:0): avc: denied { check_context } for scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:security_t tclass=security audit(1114529038.479:0): avc: denied { use } for path=/init dev=rootfs ino=8 scontext=system_u:system_r:named_t tcontext=system_u:system_r:kernel_t tclass=fdSELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses genfs_contexts audit(1114529040.947:0): avc: denied { use } for path=/init dev=rootfs ino=8 scontext=system_u:system_r:howl_t tcontext=system_u:system_r:kernel_t tclass=fd audit(1114529043.069:0): avc: denied { use } for path=/init dev=rootfs ino=8 scontext=system_u:system_r:cupsd_config_t tcontext=system_u:system_r:kernel_t tclass=fd ... audit(1114529047.672:0): avc: denied { read } for path=/init dev=rootfs ino=8 scontext=system_u:system_r:restorecon_t tcontext=system_u:object_r:root_t tclass=file audit(1114529050.126:0): avc: denied { use } for path=/init dev=rootfs ino=8 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:kernel_t tclass=fdaudit(1114529052.770:0): avc: denied { write } for name=etc dev=dm-0 ino=3833857 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:etc_t tclass=dir audit(1114529052.770:0): avc: denied { add_name } for name=.fstab.hal.S scontext=system_u:system_r:hald_t tcontext=system_u:object_r:etc_t tclass=dir audit(1114529052.770:0): avc: denied { create } for name=.fstab.hal.S scontext=system_u:system_r:hald_t tcontext=system_u:object_r:etc_t tclass=file audit(1114529053.042:0): avc: denied { write } for name=media dev=dm-0 ino=8552449 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:mnt_t tclass=dir audit(1114529053.042:0): avc: denied { remove_name } for name=cdrecorder dev=dm-0 ino=8552450 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:mnt_t tclass=dir audit(1114529053.042:0): avc: denied { rmdir } for name=cdrecorder dev=dm-0 ino=8552450 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:mnt_t tclass=dir audit(1114529053.157:0): avc: denied { write } for path=/etc/.fstab.hal.S dev=dm-0 ino=3837358 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:etc_t tclass=file audit(1114529053.157:0): avc: denied { remove_name } for name=.fstab.hal.S dev=dm-0 ino=3837358 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:etc_t tclass=dir audit(1114529053.157:0): avc: denied { rename } for name=.fstab.hal.S dev=dm-0 ino=3837358 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:etc_t tclass=file audit(1114529053.157:0): avc: denied { unlink } for name=fstab dev=dm-0 ino=3834553 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:etc_t tclass=file audit(1114529053.179:0): avc: denied { write } for name=rhgb-socket dev=ramfs ino=4929 scontext=system_u:system_r:init_t tcontext=system_u:object_r:ramfs_t tclass=sock_file audit(1114529053.179:0): avc: denied { connectto } for path=/etc/rhgb/temp/rhgb-socket scontext=system_u:system_r:init_t tcontext=system_u:system_r:initrc_t tclass=unix_stream_socket audit(1114529053.577:0): avc: denied { getattr } for path=/dev/VolGroup00/LogVol00 dev=tmpfs ino=5807 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:device_t tclass=lnk_file audit(1114529053.653:0): avc: denied { add_name } for name=cdrecorder scontext=system_u:system_r:hald_t tcontext=system_u:object_r:mnt_t tclass=dir audit(1114529053.654:0): avc: denied { create } for name=cdrecorder scontext=system_u:system_r:hald_t tcontext=system_u:object_r:mnt_t tclass=dir audit(1114529053.674:0): avc: denied { getattr } for path=/dev/mapper/VolGroup00-LogVol00 dev=tmpfs ino=1128 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:device_t tclass=blk_file audit(1114529053.674:0): avc: denied { getattr } for path=/dev/pts dev=devpts ino=1 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:devpts_t tclass=dir ... audit(1114529081.451:0): avc: denied { getattr } for path=/dev/pts dev=devpts ino=1 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:devpts_t tclass=dir From dwalsh at redhat.com Tue Apr 26 19:18:42 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 26 Apr 2005 15:18:42 -0400 Subject: Rawhide update gone awry In-Reply-To: <60D45469A1AAD311A04C009027B6BF6804FCF0BD@server20.inside.oracorp.com> References: <60D45469A1AAD311A04C009027B6BF6804FCF0BD@server20.inside.oracorp.com> Message-ID: <426E9412.6040009@redhat.com> Steve Brueckner wrote: >I appear to have borked my SELinux installation. I wanted to experiment >with the new name_connect permission, which I read was available with the >latest rawhide kernel and selinux policy. So, in my first-ever attempt to >use rawhide, I enabled my /etc/yum.repos.d/fedora-devel.repo file and then >yum updated to the following: > > No you probably just picked the wrong day to update to rawhide. I have an updated policy on ftp://people.redhat.com/dwalsh/SELinux/Fedora. It will fix some of the problems. But you might want to do a complete yum update to get the latest stuff (FC4/Test2 plus updates). Dan >kernel.i686 2.6.11-1.1267_FC4 installed >selinux-policy-targeted.noarch 1.23.12-4 installed >selinux-policy-targeted-sources.noarch 1.23.12-4 installed >selinux-policy-strict.noarch 1.23.12-4 installed >selinux-policy-strict-sources.noarch 1.23.12-4 installed >libselinux.i386 1.23.7-3 installed >libselinux-devel.i386 1.23.7-3 installed >libselinux-debuginfo.i386 1.23.7-3 installed >libsepol.i386 1.5.5-2 installed >policycoreutils.i386 1.23.6-1 installed >checkpolicy.i386 1.23.1-1 installed >setools.i386 2.1.0-2 installed >selinux-doc.noarch 1.19.5-1 installed > >I then did a touch /.autorelabel; reboot, then after rebooting a make >reload. I'm using the targeted policy in permissive mode (things freeze up >when I setenforce 1). Policy version is 19. > >I get a lot of avc denied messages on boot; enough to make me think I did >something wrong with my policy update or kernel update. Did I even go about >this the right way? Is there anything obviously wrong with the steps I >took? I'm running FC3, and I wasn't certain about updating to an FC4 kernel >but yum seemed to think it was OK so I went for it. I get the same errors >when I revert to 2.6.11-1.14_FC3. > >Thanks for any ideas. My boot log is included below, with anything >non-SELinux related snipped out. > > - Steve Brueckner, ATC-NY > > > >$ dmesg >Linux version 2.6.11-1.1267_FC4 (bhcompile at porky.build.redhat.com) (gcc >version 4.0.0 20050423 (Red Hat 4.0.0-1)) #1 Mon Apr 25 19:22:44 EDT 2005 >... >Security Framework v1.0.0 initialized >SELinux: Initializing. >SELinux: Starting in permissive mode >selinux_register_security: Registering secondary module capability >Capability LSM initialized as secondary >... >audit: initializing netlink socket (disabled) >audit(1114514592.659:0): initialized >... >SELinux: Registering netfilter hooks >... >security: 3 users, 6 roles, 684 types, 75 bools >security: 55 classes, 126760 rules >SELinux: Completing initialization. >SELinux: Setting up existing superblocks. >SELinux: initialized (dev dm-0, type ext3), uses xattr >SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs >SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts >SELinux: initialized (dev mqueue, type mqueue), not configured for labeling >SELinux: initialized (dev hugetlbfs, type hugetlbfs), not configured for >labeling >SELinux: initialized (dev devpts, type devpts), uses transition SIDs >SELinux: initialized (dev eventpollfs, type eventpollfs), uses >genfs_contexts >SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs >SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts >SELinux: initialized (dev pipefs, type pipefs), uses task SIDs >SELinux: initialized (dev sockfs, type sockfs), uses task SIDs >SELinux: initialized (dev proc, type proc), uses genfs_contexts >SELinux: initialized (dev bdev, type bdev), uses genfs_contexts >SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts >SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts >SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts >audit(1114514601.951:0): avc: denied { use } for path=/init dev=rootfs >ino=8 scontext=system_u:system_r:syslogd_t >tcontext=system_u:system_r:kernel_t tclass=fd >... >SELinux: initialized (dev ramfs, type ramfs), uses genfs_contexts >... >SELinux: initialized (dev hda1, type ext3), uses xattr >SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs >Adding 2031608k swap on /dev/VolGroup00/LogVol01. Priority:-1 extents:1 >SELinux: initialized (dev binfmt_misc, type binfmt_misc), uses >genfs_contexts >... >audit(1114529038.066:0): avc: denied { read } for name=config dev=dm-0 >ino=3837327 scontext=system_u:system_r:dhcpc_t >tcontext=system_u:object_r:selinux_config_t tclass=file >audit(1114529038.066:0): avc: denied { getattr } for >path=/etc/selinux/config dev=dm-0 ino=3837327 >scontext=system_u:system_r:dhcpc_t >tcontext=system_u:object_r:selinux_config_t tclass=file >audit(1114529038.092:0): avc: denied { execute } for name=restorecon >dev=dm-0 ino=1802308 scontext=system_u:system_r:dhcpc_t >tcontext=system_u:object_r:restorecon_exec_t tclass=file >audit(1114529038.092:0): avc: denied { execute_no_trans } for >path=/sbin/restorecon dev=dm-0 ino=1802308 >scontext=system_u:system_r:dhcpc_t >tcontext=system_u:object_r:restorecon_exec_t tclass=file >audit(1114529038.092:0): avc: denied { read } for path=/sbin/restorecon >dev=dm-0 ino=1802308 scontext=system_u:system_r:dhcpc_t >tcontext=system_u:object_r:restorecon_exec_t tclass=file >audit(1114529038.093:0): avc: denied { search } for name=contexts >dev=dm-0 ino=3834258 scontext=system_u:system_r:dhcpc_t >tcontext=system_u:object_r:default_context_t tclass=dir >audit(1114529038.093:0): avc: denied { search } for name=files dev=dm-0 >ino=3834262 scontext=system_u:system_r:dhcpc_t >tcontext=system_u:object_r:file_context_t tclass=dir >audit(1114529038.093:0): avc: denied { read } for name=file_contexts >dev=dm-0 ino=3834260 scontext=system_u:system_r:dhcpc_t >tcontext=system_u:object_r:file_context_t tclass=file >audit(1114529038.093:0): avc: denied { getattr } for >path=/etc/selinux/targeted/contexts/files/file_contexts dev=dm-0 ino=3834260 >scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:file_context_t >tclass=file >audit(1114529038.096:0): avc: denied { search } for name=/ dev=selinuxfs >ino=232 scontext=system_u:system_r:dhcpc_t >tcontext=system_u:object_r:security_t tclass=dir >audit(1114529038.096:0): avc: denied { read write } for name=context >dev=selinuxfs ino=5 scontext=system_u:system_r:dhcpc_t >tcontext=system_u:object_r:security_t tclass=file >audit(1114529038.096:0): avc: denied { check_context } for >scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:security_t >tclass=security >audit(1114529038.479:0): avc: denied { use } for path=/init dev=rootfs >ino=8 scontext=system_u:system_r:named_t tcontext=system_u:system_r:kernel_t >tclass=fdSELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses >genfs_contexts >audit(1114529040.947:0): avc: denied { use } for path=/init dev=rootfs >ino=8 scontext=system_u:system_r:howl_t tcontext=system_u:system_r:kernel_t >tclass=fd >audit(1114529043.069:0): avc: denied { use } for path=/init dev=rootfs >ino=8 scontext=system_u:system_r:cupsd_config_t >tcontext=system_u:system_r:kernel_t tclass=fd >... >audit(1114529047.672:0): avc: denied { read } for path=/init dev=rootfs >ino=8 scontext=system_u:system_r:restorecon_t >tcontext=system_u:object_r:root_t tclass=file >audit(1114529050.126:0): avc: denied { use } for path=/init dev=rootfs >ino=8 scontext=system_u:system_r:getty_t tcontext=system_u:system_r:kernel_t >tclass=fdaudit(1114529052.770:0): avc: denied { write } for name=etc >dev=dm-0 ino=3833857 scontext=system_u:system_r:hald_t >tcontext=system_u:object_r:etc_t tclass=dir >audit(1114529052.770:0): avc: denied { add_name } for name=.fstab.hal.S >scontext=system_u:system_r:hald_t tcontext=system_u:object_r:etc_t >tclass=dir >audit(1114529052.770:0): avc: denied { create } for name=.fstab.hal.S >scontext=system_u:system_r:hald_t tcontext=system_u:object_r:etc_t >tclass=file >audit(1114529053.042:0): avc: denied { write } for name=media dev=dm-0 >ino=8552449 scontext=system_u:system_r:hald_t >tcontext=system_u:object_r:mnt_t tclass=dir >audit(1114529053.042:0): avc: denied { remove_name } for name=cdrecorder >dev=dm-0 ino=8552450 scontext=system_u:system_r:hald_t >tcontext=system_u:object_r:mnt_t tclass=dir >audit(1114529053.042:0): avc: denied { rmdir } for name=cdrecorder >dev=dm-0 ino=8552450 scontext=system_u:system_r:hald_t >tcontext=system_u:object_r:mnt_t tclass=dir >audit(1114529053.157:0): avc: denied { write } for path=/etc/.fstab.hal.S >dev=dm-0 ino=3837358 scontext=system_u:system_r:hald_t >tcontext=system_u:object_r:etc_t tclass=file >audit(1114529053.157:0): avc: denied { remove_name } for >name=.fstab.hal.S dev=dm-0 ino=3837358 scontext=system_u:system_r:hald_t >tcontext=system_u:object_r:etc_t tclass=dir >audit(1114529053.157:0): avc: denied { rename } for name=.fstab.hal.S >dev=dm-0 ino=3837358 scontext=system_u:system_r:hald_t >tcontext=system_u:object_r:etc_t tclass=file >audit(1114529053.157:0): avc: denied { unlink } for name=fstab dev=dm-0 >ino=3834553 scontext=system_u:system_r:hald_t >tcontext=system_u:object_r:etc_t tclass=file >audit(1114529053.179:0): avc: denied { write } for name=rhgb-socket >dev=ramfs ino=4929 scontext=system_u:system_r:init_t >tcontext=system_u:object_r:ramfs_t tclass=sock_file >audit(1114529053.179:0): avc: denied { connectto } for >path=/etc/rhgb/temp/rhgb-socket scontext=system_u:system_r:init_t >tcontext=system_u:system_r:initrc_t tclass=unix_stream_socket >audit(1114529053.577:0): avc: denied { getattr } for >path=/dev/VolGroup00/LogVol00 dev=tmpfs ino=5807 >scontext=system_u:system_r:hald_t tcontext=system_u:object_r:device_t >tclass=lnk_file >audit(1114529053.653:0): avc: denied { add_name } for name=cdrecorder >scontext=system_u:system_r:hald_t tcontext=system_u:object_r:mnt_t >tclass=dir >audit(1114529053.654:0): avc: denied { create } for name=cdrecorder >scontext=system_u:system_r:hald_t tcontext=system_u:object_r:mnt_t >tclass=dir >audit(1114529053.674:0): avc: denied { getattr } for >path=/dev/mapper/VolGroup00-LogVol00 dev=tmpfs ino=1128 >scontext=system_u:system_r:hald_t tcontext=system_u:object_r:device_t >tclass=blk_file >audit(1114529053.674:0): avc: denied { getattr } for path=/dev/pts >dev=devpts ino=1 scontext=system_u:system_r:hald_t >tcontext=system_u:object_r:devpts_t tclass=dir >... >audit(1114529081.451:0): avc: denied { getattr } for path=/dev/pts >dev=devpts ino=1 scontext=system_u:system_r:hald_t >tcontext=system_u:object_r:devpts_t tclass=dir > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- From sds at tycho.nsa.gov Tue Apr 26 19:20:52 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 26 Apr 2005 15:20:52 -0400 Subject: Rawhide update gone awry In-Reply-To: <60D45469A1AAD311A04C009027B6BF6804FCF0BD@server20.inside.oracorp.com> References: <60D45469A1AAD311A04C009027B6BF6804FCF0BD@server20.inside.oracorp.com> Message-ID: <1114543252.30521.65.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-04-26 at 15:07 -0400, Steve Brueckner wrote: > I then did a touch /.autorelabel; reboot, then after rebooting a make > reload. I'm using the targeted policy in permissive mode (things freeze up > when I setenforce 1). Policy version is 19. > > I get a lot of avc denied messages on boot; enough to make me think I did > something wrong with my policy update or kernel update. It looks like a number of the avc denied messages are just noise; normally hidden by enforcing mode (because an earlier denial that has a dontaudit rule would have prevented the program from attempting the later access that you see being denied). Only ones that I saw that looked worrisome were the dhcpc attempt to run restorecon and the hald attempt to update fstab without transitioning into updfstab_t. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Tue Apr 26 19:45:02 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 26 Apr 2005 15:45:02 -0400 Subject: Rawhide update gone awry In-Reply-To: <1114543252.30521.65.camel@moss-spartans.epoch.ncsc.mil> References: <60D45469A1AAD311A04C009027B6BF6804FCF0BD@server20.inside.oracorp.com> <1114543252.30521.65.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <426E9A3E.70205@redhat.com> Stephen Smalley wrote: >On Tue, 2005-04-26 at 15:07 -0400, Steve Brueckner wrote: > > >>I then did a touch /.autorelabel; reboot, then after rebooting a make >>reload. I'm using the targeted policy in permissive mode (things freeze up >>when I setenforce 1). Policy version is 19. >> >>I get a lot of avc denied messages on boot; enough to make me think I did >>something wrong with my policy update or kernel update. >> >> > >It looks like a number of the avc denied messages are just noise; >normally hidden by enforcing mode (because an earlier denial that has a >dontaudit rule would have prevented the program from attempting the >later access that you see being denied). Only ones that I saw that >looked worrisome were the dhcpc attempt to run restorecon and the hald >attempt to update fstab without transitioning into updfstab_t. > > > I think the restorecon is removed from the latest dhclient, updfstab is in policy as up 1.23-13-3, available on people. Dan -- From sds at tycho.nsa.gov Tue Apr 26 19:40:36 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 26 Apr 2005 15:40:36 -0400 Subject: Rawhide update gone awry In-Reply-To: <426E9A3E.70205@redhat.com> References: <60D45469A1AAD311A04C009027B6BF6804FCF0BD@server20.inside.oracorp.com> <1114543252.30521.65.camel@moss-spartans.epoch.ncsc.mil> <426E9A3E.70205@redhat.com> Message-ID: <1114544436.30521.70.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-04-26 at 15:45 -0400, Daniel J Walsh wrote: > I think the restorecon is removed from the latest dhclient, updfstab is > in policy as up 1.23-13-3, available on people. Ok, so he might need to remove that from his dhclient since he is using FC3 and just pulling SELinux-related bits from rawhide. -- Stephen Smalley National Security Agency From eparis at parisplace.org Wed Apr 27 00:39:20 2005 From: eparis at parisplace.org (Eric Paris) Date: Tue, 26 Apr 2005 20:39:20 -0400 Subject: Policy for ntp using nonstandard clock device links Message-ID: <1114562361.5087.15.camel@dhcp3-100.jstarr.org> Some ntp clocks like the the wwvb1 which are configured with a line like server 127.127.4.1 minpoll 3 maxpoll 4 in ntp.conf will need to talk to a "clock device" at /dev/wwvb1. In reality the clock is connected to something like /dev/ttyS0 where ntpd would normally have permissions. But for these types of clocks we have to create a sym link ln -s /dev/ttyS0 /dev/wwvb1 because ntp recognizes the clock as being at /dev/wwvb1. We get denials like audit(1114388976.276:0): avc: denied { read } for pid=23691 exe=/usr/sbin/ntpd name=wwvb1 dev=tmpfs ino=148116 scontext=root:system_r:ntpd_t tcontext=root:object_r:device_t tclass=lnk_file which can be fixed with allow ntpd_t device_t:lnk_file read; It might also want write permission, I'm not sure right now. I'm looking for comments on the right way to fix this. Is adding this or maybe rw_file_perms the way we really should go about this? Eric From brett at eecs.tufts.edu Wed Apr 27 03:09:56 2005 From: brett at eecs.tufts.edu (brett) Date: Tue, 26 Apr 2005 23:09:56 -0400 (EDT) Subject: gpg through apache and php? Message-ID: Hi, I had to disable SELinux on my apache httpd in order to get my php scripts to work. They proc_open() gpg and SELinux didn't like that. Is there anyway to allow gpg to get through proc_open() so i can still have SELinux checking up on my webserver? Thanks in advance, -brett From ivg2 at cornell.edu Wed Apr 27 05:17:16 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Wed, 27 Apr 2005 01:17:16 -0400 Subject: Home Dir labels (manifested as a failed Flash install) In-Reply-To: References: Message-ID: <1114579036.18640.13.camel@localhost.localdomain> > -rw-r--r-- smearp smearp user_u:object_r:user_home_t flashplayer.xpt > -rwxr-xr-x smearp smearp user_u:object_r:texrel_shlib_t This is correct, but it's not done automatically, because /home is entirely skipped when changing the contexts after a policy upgrade. Personally, I think this is a major problem, but Daniel Walsh points out that (1) automatic restorecon on /home presents a security risk of mislabeled files ( like gpg keys and such in the wrong place), and (2) automatic restorecon on /home might take a very long time. I think if we are to introduce more fine-grained labeling of "$HOME" in the future (which we should), this problem needs to be solved somehow. -- Ivan Gyurdiev Cornell University From lfarkas at bppiac.hu Wed Apr 27 09:21:33 2005 From: lfarkas at bppiac.hu (Farkas Levente) Date: Wed, 27 Apr 2005 11:21:33 +0200 Subject: nagios_log_t missing In-Reply-To: <426E5AC7.2020703@redhat.com> References: <426E4937.7000604@bppiac.hu> <426E5AC7.2020703@redhat.com> Message-ID: <426F599D.4000506@bppiac.hu> Daniel J Walsh wrote: > Farkas Levente wrote: > >> hi, >> there is a nagios_log_t and used in nagios.fc but never defined >> (missing). so when we try to apply it we got these errors: >> --------------------------------------------- >> # chcon -R -t nagios_log_t /var/log/nagios >> chcon: failed to change context of /var/log/nagios to >> system_u:object_r:nagios_log_t: Invalid argument >> chcon: failed to change context of /var/log/nagios/rw to >> system_u:object_r:nagios_log_t: Invalid argument >> chcon: failed to change context of /var/log/nagios/archives to >> system_u:object_r:nagios_log_t: Invalid argument >> chcon: failed to change context of /var/log/nagios/.bash_history to >> user_u:object_r:nagios_log_t: Invalid argument >> --------------------------------------------- >> how can i fix it? >> dan could you create updated rpms which fix it in >> ftp://people.redhat.com/dwalsh/SELinux/RHEL4/ ?:-) >> yours. >> > nagios policy is not used in RHEL4. It should run unconfined_t. We are > only supporting the subset of network daemons in targeted policy. > > Using strict or other policies in RHEL4 requires a separate support > contract, professional services engagement. ok. i only think that if nagios_log_t used in the current selinux-policy-targeted than (in nagios.fc) than it should have to be defined also. but it's definition currently missing from selinux-policy-targeted, which is imho a bug. that's what i'd like to report. another thing even if nagios run in unconfined_t is ok since the log files can be generated and the daemon is running, but the web interface of nagios not working since it's try to read it's log files under /var/log/nagios which is currently var_log_t (inherited from it's parent). so currently i've a few options: - add a local.te as: allow httpd_sys_script_t var_log_t:dir search; allow httpd_sys_script_t var_log_t:file { getattr read }; - change /var/log/nagios to httpd_sys_content_t and add only allow httpd_sys_script_t var_log_t:dir search; - change /var/log/nagios to nagios_log_t and add allow httpd_sys_script_t var_log_t:dir search; allow httpd_sys_script_t nagios_log_t:file { getattr read }; and imho the best solution would be to add this last one to the global policy. yours. just my 2c. -- Levente "Si vis pacem para bellum!" From maillist at jed.id.au Wed Apr 27 11:14:09 2005 From: maillist at jed.id.au (John Dean) Date: Wed, 27 Apr 2005 21:14:09 +1000 Subject: Policy files Message-ID: <426F7401.9060208@jed.id.au> I've been reading the FAQ for selinux, and it refers to policy files under /etc/selinux/policy/scr. Looking at the policy directory on my system, there is only one file under there called policy.18. I'm trying to get the squirrelmail module called change_passwd to work but not sure how too. From sds at tycho.nsa.gov Wed Apr 27 11:17:21 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 27 Apr 2005 07:17:21 -0400 Subject: Policy files In-Reply-To: <426F7401.9060208@jed.id.au> References: <426F7401.9060208@jed.id.au> Message-ID: <1114600641.4115.6.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-04-27 at 21:14 +1000, John Dean wrote: > I've been reading the FAQ for selinux, and it refers to policy files > under /etc/selinux/policy/scr. > Looking at the policy directory on my system, there is only one file > under there called policy.18. > > I'm trying to get the squirrelmail module called change_passwd to work > but not sure how too. /etc/selinux/$SELINUXTYPE/src/policy is where the policy sources live, if you have them installed (SELINUXTYPE is defined by /etc/selinux/config). But the policy sources aren't installed by default as you only need them if you have to customize your policy. yum install selinux-policy-targeted-sources should install them for you if you don't have that directory already (assuming you are running with the default targeted policy). -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Wed Apr 27 11:23:20 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 27 Apr 2005 07:23:20 -0400 Subject: Policy for ntp using nonstandard clock device links In-Reply-To: <1114562361.5087.15.camel@dhcp3-100.jstarr.org> References: <1114562361.5087.15.camel@dhcp3-100.jstarr.org> Message-ID: <1114601000.4115.13.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-04-26 at 20:39 -0400, Eric Paris wrote: > Some ntp clocks like the the wwvb1 which are configured with a line like > > server 127.127.4.1 minpoll 3 maxpoll 4 > > in ntp.conf will need to talk to a "clock device" at /dev/wwvb1. In > reality the clock is connected to something like /dev/ttyS0 where ntpd > would normally have permissions. But for these types of clocks we have > to create a sym link ln -s /dev/ttyS0 /dev/wwvb1 because ntp recognizes > the clock as being at /dev/wwvb1. > > We get denials like > > audit(1114388976.276:0): avc: denied { read } for pid=23691 > exe=/usr/sbin/ntpd name=wwvb1 dev=tmpfs ino=148116 > scontext=root:system_r:ntpd_t tcontext=root:object_r:device_t > tclass=lnk_file > > which can be fixed with > > allow ntpd_t device_t:lnk_file read; > > It might also want write permission, I'm not sure right now. I'm > looking for comments on the right way to fix this. Is adding this or > maybe rw_file_perms the way we really should go about this? Write permission wouldn't make sense for a symlink. It might need create permission if it is responsible for creating the symlink, but hopefully not, as that would also require write and add_name permission to the /dev directory. Hence, I'd go with the allow rule you listed above. BTW, if we ever want to introduce a distinction between following symlinks during pathname lookup vs. just reading their content via readlink(2), then we need to start introducing macros to distinguish those uses and using those macros pervasively rather than directly writing allow rules on lnk_file. I posted a trivial patch to the SELinux module a while back that used a separate permission for following symlinks in response to discussion by Russell Coker (so that you can prevent an admin from following an untrustworthy and potentially malicious symlink while still allowing him to see what it references via ls -l), but incorporating that change would require a thorough audit of policy to update all existing lnk_file references, and no one has undertaken that work to date. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Wed Apr 27 11:48:07 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 27 Apr 2005 07:48:07 -0400 Subject: gpg through apache and php? In-Reply-To: References: Message-ID: <1114602487.4115.39.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-04-26 at 23:09 -0400, brett wrote: > Hi, > > I had to disable SELinux on my apache httpd in order to get my php scripts > to work. They proc_open() gpg and SELinux didn't like that. Is there > anyway to allow gpg to get through proc_open() so i can still have SELinux > checking up on my webserver? Details, please: - what policy are you running: strict or targeted, FC3 or FC4/devel? - what httpd_* booleans do you have enabled? - where have you placed the keyring for gpg that you want accessible via httpd? - what avc denials did you get in /var/log/messages (FC3) or /var/log/audit/audit.log (FC4)? -- Stephen Smalley National Security Agency From db-fedora at 3di.it Wed Apr 27 12:53:25 2005 From: db-fedora at 3di.it (Davide Bolcioni) Date: Wed, 27 Apr 2005 14:53:25 +0200 Subject: Is there a SELinux tutorial for ISVs ? Message-ID: <426F8B45.8070509@3di.it> Greetings, I was looking for directions about how would an ISV rool own policy for the packages it ships. A very basic and step-by-step tutorial, for tiny minds :-) Thank you for your consideration, Davide Bolcioni From dwalsh at redhat.com Wed Apr 27 14:52:42 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 27 Apr 2005 10:52:42 -0400 Subject: nagios_log_t missing In-Reply-To: <426F599D.4000506@bppiac.hu> References: <426E4937.7000604@bppiac.hu> <426E5AC7.2020703@redhat.com> <426F599D.4000506@bppiac.hu> Message-ID: <426FA73A.1070609@redhat.com> Farkas Levente wrote: > Daniel J Walsh wrote: > >> Farkas Levente wrote: >> >>> hi, >>> there is a nagios_log_t and used in nagios.fc but never defined >>> (missing). so when we try to apply it we got these errors: >>> --------------------------------------------- >>> # chcon -R -t nagios_log_t /var/log/nagios >>> chcon: failed to change context of /var/log/nagios to >>> system_u:object_r:nagios_log_t: Invalid argument >>> chcon: failed to change context of /var/log/nagios/rw to >>> system_u:object_r:nagios_log_t: Invalid argument >>> chcon: failed to change context of /var/log/nagios/archives to >>> system_u:object_r:nagios_log_t: Invalid argument >>> chcon: failed to change context of /var/log/nagios/.bash_history to >>> user_u:object_r:nagios_log_t: Invalid argument >>> --------------------------------------------- >>> how can i fix it? >>> dan could you create updated rpms which fix it in >>> ftp://people.redhat.com/dwalsh/SELinux/RHEL4/ ?:-) >>> yours. >>> >> nagios policy is not used in RHEL4. It should run unconfined_t. We >> are only supporting the subset of network daemons in targeted policy. >> >> Using strict or other policies in RHEL4 requires a separate support >> contract, professional services engagement. > > > ok. i only think that if nagios_log_t used in the current > selinux-policy-targeted than (in nagios.fc) than it should have to be > defined also. but it's definition currently missing from > selinux-policy-targeted, which is imho a bug. that's what i'd like to > report. We do not strip out fc files that we do not support. The way the make file and hence the RPM works is it looks for *.te files in the domains/program directory and uses those names to choose the file_context files. We want to use the same policy source pool to supoort targeted, strict, mls ... policy. And therefore get the best bang for the buck from the open source community. So think of the policy-src files like you do kernel sources. Just because there is stuff in there does not mean we support them. > another thing even if nagios run in unconfined_t is ok since the log > files can be generated and the daemon is running, but the web > interface of nagios not working since it's try to read it's log files > under /var/log/nagios which is currently var_log_t (inherited from > it's parent). so currently i've a few options: > - add a local.te as: > allow httpd_sys_script_t var_log_t:dir search; > allow httpd_sys_script_t var_log_t:file { getattr read }; > - change /var/log/nagios to httpd_sys_content_t and add only > allow httpd_sys_script_t var_log_t:dir search; > - change /var/log/nagios to nagios_log_t and add > allow httpd_sys_script_t var_log_t:dir search; > allow httpd_sys_script_t nagios_log_t:file { getattr read }; > and imho the best solution would be to add this last one to the global > policy. > yours. > How about adding chcon -R -t httpd_sys_script_ro_t /var/log/nagios Then you don't need to change policy at all > just my 2c. > -- From mike at navi.cx Wed Apr 27 23:10:30 2005 From: mike at navi.cx (Mike Hearn) Date: Thu, 28 Apr 2005 00:10:30 +0100 Subject: Is there a SELinux tutorial for ISVs ? References: <426F8B45.8070509@3di.it> Message-ID: On Wed, 27 Apr 2005 14:53:25 +0200, Davide Bolcioni wrote: > Greetings, > I was looking for directions about how would an ISV rool own policy for > the packages it ships. A very basic and step-by-step tutorial, for tiny > minds :-) I don't think there is any such document. Right now you can't distribute policy anyway: - The binary policy modules framework isn't fully deployed yet, or at least that's the impression I got last time I talked to the author - There are no formal policy compatibility ... er ... policies, between distributions as far as I'm aware. So the meaning of a given bit of policy might change depending on the distributions specific implementation. What exactly are your goals? Do you want to lock down your own program or is this more about compatibility? I'm pretty interested in letting Linux software developers ship policy as part of their own binary packages to allow for better lockdown/least priv on systems that support it but I don't think the technology is there yet. thanks -mike From brett at eecs.tufts.edu Thu Apr 28 02:09:31 2005 From: brett at eecs.tufts.edu (brett) Date: Wed, 27 Apr 2005 22:09:31 -0400 (EDT) Subject: gpg through apache and php? In-Reply-To: <1114602487.4115.39.camel@moss-spartans.epoch.ncsc.mil> Message-ID: Thanks Stephen. See answers below. -brett > On Tue, 2005-04-26 at 23:09 -0400, brett wrote: > > Hi, > > > > I had to disable SELinux on my apache httpd in order to get my php scripts > > to work. They proc_open() gpg and SELinux didn't like that. Is there > > anyway to allow gpg to get through proc_open() so i can still have SELinux > > checking up on my webserver? > > Details, please: > - what policy are you running: strict or targeted, FC3 or FC4/devel? targeted. FC3 > - what httpd_* booleans do you have enabled? httpd_disable_trans active httpd_enable_cgi active httpd_enable_homedirs active httpd_ssi_exec active httpd_tty_comm inactive httpd_unified active > - where have you placed the keyring for gpg that you want accessible via > httpd? /home/test/.gnupg test is a user. Also, i plan on using symmetric encryption so i don't think it needs the keyring file. > - what avc denials did you get in /var/log/messages (FC3) > or /var/log/audit/audit.log (FC4)? Apr 24 22:29:06 razorfold kernel: audit(1114396146.398:0): avc: denied { execute } for pid=6266 comm=gpg path=/etc/ld.so.cache dev=dm-0 ino=3919093 scontext=user_u:system_r:httpd_sys_script_t tcontext=system_u:object_r:ld_so_cache_t tclass=file Apr 24 22:29:06 razorfold kernel: audit(1114396146.398:0): avc: denied { execmod } for pid=6266 comm=gpg path=/usr/bin/gpg dev=dm-0 ino=4972274 scontext=user_u:system_r:httpd_sys_script_t tcontext=system_u:object_r:bin_t tclass=file From db-fedora at 3di.it Thu Apr 28 08:20:55 2005 From: db-fedora at 3di.it (Davide Bolcioni) Date: Thu, 28 Apr 2005 10:20:55 +0200 Subject: Is there a SELinux tutorial for ISVs ? In-Reply-To: References: <426F8B45.8070509@3di.it> Message-ID: <42709CE7.6060002@3di.it> Mike Hearn wrote: > I don't think there is any such document. Right now you can't distribute > policy anyway: > > - The binary policy modules framework isn't fully deployed yet, or at > least that's the impression I got last time I talked to the author Maybe I'm so badly in need of a tutorial as to be unable to express my question, see below. > - There are no formal policy compatibility ... er ... policies, between > distributions as far as I'm aware. So the meaning of a given bit of > policy might change depending on the distributions specific > implementation. That's part of what I would be looking for. How would I find out about the policies in effect ? > What exactly are your goals? Do you want to lock down your own program or > is this more about compatibility? The initial goal is compatibility: ship a possibly distribution-specific package which works regardless of whether the customer uses no selinux, the targeted policy or the strict policy. Making it policy-specific would be ugly, as I would get a combinatorial explosion of .rpm packages to ship. I realize that it might not be possible to do that just at the packaging level, i.e. that changes might be necessary upstream, but I am currently unable to tell which changes are appropriate for the packaging stage and which would impact the code. Once that goal is achieved, being able to lock down the software would be the next step; I guess that a less than cursory knowledge of SELinux would be necessary to do that, however. > I'm pretty interested in letting Linux software developers ship policy as > part of their own binary packages to allow for better lockdown/least priv > on systems that support it but I don't think the technology is there yet. Well, maybe the technology is not there but it hurts already: we currently have code which does not work because of selinux. It is old code which we are more interested in phasing out than supporting, but we would like not to get bitten in the future. Thank you for your consideration, Davide Bolcioni From sds at tycho.nsa.gov Thu Apr 28 11:57:10 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 28 Apr 2005 07:57:10 -0400 Subject: gpg through apache and php? In-Reply-To: References: Message-ID: <1114689430.6708.40.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-04-27 at 22:09 -0400, brett wrote: > httpd_disable_trans active What? That should have disabled all protection on httpd, i.e. the transition into httpd_t in the first place. Or did you just make that change after being unable to get it to work? > httpd_enable_homedirs active Allows access to user home directories. For better security, disable. > httpd_unified active This folds together the distinct types of web content; preferable to disable it if possible. > /home/test/.gnupg > > test is a user. Also, i plan on using symmetric encryption so i don't > think it needs the keyring file. Why isn't it just part of the web tree under /var/www so that you can prohibit access to user home directories entirely? > Apr 24 22:29:06 razorfold kernel: audit(1114396146.398:0): avc: denied { > execute } for pid=6266 comm=gpg path=/etc/ld.so.cache dev=dm-0 > ino=3919093 scontext=user_u:system_r:httpd_sys_script_t > tcontext=system_u:object_r:ld_so_cache_t tclass=file > Apr 24 22:29:06 razorfold kernel: audit(1114396146.398:0): avc: denied { > execmod } for pid=6266 comm=gpg path=/usr/bin/gpg dev=dm-0 ino=4972274 > scontext=user_u:system_r:httpd_sys_script_t > tcontext=system_u:object_r:bin_t tclass=file This is a result of gpg being marked as requiring an executable stack (and still looks that way in FC4/devel - execstack -q /usr/bin/gpg reports X - Dan?). With a newer kernel (>= 2.6.12-rc2, also included in FC4/devel kernels), you'd at least avoid the noise on ld.so.cache due to the checkreqprot compatibility support. But you would still need execmod on the gpg binary; under strict policy, gpg has its own separate executable type (gpg_exec_t) and domain (gpg_t), so we only need to allow execmod for that particular case. What's suggested for FC3 targeted policy, Dan? -- Stephen Smalley National Security Agency From ronny at spacenet.co.ug Thu Apr 28 13:40:26 2005 From: ronny at spacenet.co.ug (Ronny) Date: Thu, 28 Apr 2005 16:40:26 +0300 Subject: Starting Linux in Single mode with selinux=enforcing Message-ID: <4270E7CA.20004@spacenet.co.ug> Hi all I have enabled selinux to enforcing mode but when I rebooted I get Kernel Panic I know I made a mistake didn't create policies.So how do I boot in sinlge mode to edit the line back to its original. Am using Fedora Core 3 with grub but can't go to single mode. Thanks in advance Ronny -- *************************************************************************** / ''We can't become what we need to be by remaining what we are''\ \ ,, ,,/ *************************************************************************** From mike at navi.cx Thu Apr 28 13:54:41 2005 From: mike at navi.cx (Mike Hearn) Date: Thu, 28 Apr 2005 14:54:41 +0100 Subject: Is there a SELinux tutorial for ISVs ? References: <426F8B45.8070509@3di.it> <42709CE7.6060002@3di.it> Message-ID: On Thu, 28 Apr 2005 10:20:55 +0200, Davide Bolcioni wrote: > That's part of what I would be looking for. How would I find out about the > policies in effect ? You can review their sources. > The initial goal is compatibility: ship a possibly distribution-specific > package which works regardless of whether the customer uses no selinux, > the targeted policy or the strict policy. Making it policy-specific > would be ugly, as I would get a combinatorial explosion of .rpm packages > to ship. OK. What exactly broke your app? Targetted isn't supposed to interfere with most programs (except that sometimes that doesn't seem to be the case, I'm still researching this too!). So you should be able to ignore that. It may be that the shlib_textrel_t thing got you, so far that's the only part of targetted I know about which isn't actually backwards compatible. As for strict policy, well I don't know what the default there is. I guess the default is "deny everything" so every program needs policy to work but I don't know for sure. I don't think many people run strict right now though. Until binary policy is implemented though I am not sure you can ship policy in RPMs. It has to be in the central policy as a patch and you can then mark the files with the right contexts. You (hopefully) shouldn't need any custom policy though. thanks -mike From sds at tycho.nsa.gov Thu Apr 28 14:09:23 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 28 Apr 2005 10:09:23 -0400 Subject: Is there a SELinux tutorial for ISVs ? In-Reply-To: <426F8B45.8070509@3di.it> References: <426F8B45.8070509@3di.it> Message-ID: <1114697363.6708.116.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-04-27 at 14:53 +0200, Davide Bolcioni wrote: > Greetings, > I was looking for directions about how would an ISV rool own policy for > the packages it ships. A very basic and step-by-step tutorial, for tiny > minds :-) Nothing quite fits the bill as you describe it, but nonetheless have a look at the links under 'Documentation' at: http://selinux.sourceforge.net/resources.php3 In particular: 1) There are some (outdated) HOWTOs on the sourceforge site, http://sourceforge.net/docman/?group_id=21266 2) There is a RHEL4 SELinux Guide, http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ 3) There is a NSA technical report, http://www.nsa.gov/selinux/papers/policy2/t1.html 4) There is a published book, http://www.oreilly.com/catalog/selinux/ 5) There is a course, http://www.tresys.com/selinux/selinux-course-outline.html Of course, as others have noted, we don't yet have the infrastructure in place for distributing package policies effectively. Binary policy module support should be in FC5 (not FC4). -- Stephen Smalley National Security Agency From dwalsh at redhat.com Thu Apr 28 14:24:12 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 28 Apr 2005 10:24:12 -0400 Subject: Starting Linux in Single mode with selinux=enforcing In-Reply-To: <4270E7CA.20004@spacenet.co.ug> References: <4270E7CA.20004@spacenet.co.ug> Message-ID: <4270F20C.5050600@redhat.com> Ronny wrote: > Hi all I have enabled selinux to enforcing mode but when I rebooted I > get Kernel Panic I know I made a mistake didn't create policies.So how > do I boot in sinlge mode to edit the line back to its original. > Am using Fedora Core 3 with grub but can't go to single mode. > Thanks in advance > Ronny Add "enforcing=0 s" to boot line. -- From db-fedora at 3di.it Thu Apr 28 14:33:27 2005 From: db-fedora at 3di.it (Davide Bolcioni) Date: Thu, 28 Apr 2005 16:33:27 +0200 Subject: Is there a SELinux tutorial for ISVs ? In-Reply-To: References: <426F8B45.8070509@3di.it> <42709CE7.6060002@3di.it> Message-ID: <4270F437.7030602@3di.it> Mike Hearn wrote: > You can review their sources. I meant programmatically but never mind, I got the message that we're not quite there yet. > OK. What exactly broke your app? Targetted isn't supposed to interfere > with most programs (except that sometimes that doesn't seem to be the > case, I'm still researching this too!). So you should be able to ignore > that. It may be that the shlib_textrel_t thing got you, so far that's the > only part of targetted I know about which isn't actually backwards > compatible. The app is a Web application which includes a proprietary CGI executable, but in the targeted policy only appropriately-labeled CGI get run. Having the CGI not sit in cgi-bin probably adds to the pain, I guess. I found out how to disable SELinux protection for Apache, but that kind of defeats the purpose and does not help customer relationships. > Until binary policy is implemented though I am not sure you can ship > policy in RPMs. It has to be in the central policy as a patch and you can > then mark the files with the right contexts. You (hopefully) shouldn't > need any custom policy though. Another message suggested that FC5 is likely to be the target for the stuff I am grasping at. Thank you for your consideration, Davide Bolcioni -- There is no place like /home. From dbolcioni at 3di.it Wed Apr 27 12:46:51 2005 From: dbolcioni at 3di.it (Davide Bolcioni) Date: Wed, 27 Apr 2005 14:46:51 +0200 Subject: Is there a SELinux tutorial for ISVs ? Message-ID: <426F89BB.80504@3di.it> Greetings, I was looking for directions about how would an ISV rool own policy for the packages it ships. A very basic and step-by-step tutorial, for tiny minds :-) Thank you for your consideration, Davide Bolcioni -- There is no place like /home. From dbolcioni at 3di.it Thu Apr 28 08:14:44 2005 From: dbolcioni at 3di.it (Davide Bolcioni) Date: Thu, 28 Apr 2005 10:14:44 +0200 Subject: Is there a SELinux tutorial for ISVs ? In-Reply-To: References: <426F8B45.8070509@3di.it> Message-ID: <42709B74.4000508@3di.it> Mike Hearn wrote: > I don't think there is any such document. Right now you can't distribute > policy anyway: > > - The binary policy modules framework isn't fully deployed yet, or at > least that's the impression I got last time I talked to the author Maybe I'm so badly in need of a tutorial as to be unable to express my question, see below. > - There are no formal policy compatibility ... er ... policies, between > distributions as far as I'm aware. So the meaning of a given bit of > policy might change depending on the distributions specific > implementation. That's part of what I would be looking for. How would I find out about the policies in effect ? > What exactly are your goals? Do you want to lock down your own program or > is this more about compatibility? The initial goal is compatibility: ship a possibly distribution-specific package which works regardless of whether the customer uses no selinux, the targeted policy or the strict policy. Making it policy-specific would be ugly, as I would get a combinatorial explosion of .rpm packages to ship. I realize that it might not be possible to do that just at the packaging level, i.e. that changes might be necessary upstream, but I am currently unable to tell which changes are appropriate for the packaging stage and which would impact the code. Once that goal is achieved, being able to lock down the software would be the next step; I guess that a less than cursory knowledge of SELinux would be necessary to do that, however. > I'm pretty interested in letting Linux software developers ship policy as > part of their own binary packages to allow for better lockdown/least priv > on systems that support it but I don't think the technology is there yet. Well, maybe the technology is not there but it hurts already: we currently have code which does not work because of selinux. It is old code which we are more interested in phasing out than supporting, but we would like not to get bitten in the future. Thank you for your consideration, Davide Bolcioni -- There is no place like /home. From selinux at gmail.com Thu Apr 28 15:47:18 2005 From: selinux at gmail.com (Tom London) Date: Thu, 28 Apr 2005 08:47:18 -0700 Subject: hald_t self:unix_stream_socket connectto? Message-ID: <4c4ba153050428084761e577b6@mail.gmail.com> Running targeted/permissive; today's Rawhide. I get the following when inserting a USB device: Apr 28 08:04:02 localhost kernel: usb 3-2: new full speed USB device using uhci_hcd and address 4 Apr 28 08:04:02 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 4 if 0 alt 1 proto 2 vid 0x03F0 pid 0x1E11 Apr 28 08:04:03 localhost kernel: audit(1114700643.013:0): avc: denied { connectto } for path=@ /tmp/hald-local/dbus-DX2FiLUq6n scontext=system_u:system_r:hald_t tcontext=system_u:system_r:hald_t tclass=unix_stream_socket I get this running either permissive or enforcing. Is allow hald_t self:unix_stream_socket connectto; appropriate? tom -- Tom London From dwalsh at redhat.com Thu Apr 28 15:54:30 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 28 Apr 2005 11:54:30 -0400 Subject: Is there a SELinux tutorial for ISVs ? In-Reply-To: <42709B74.4000508@3di.it> References: <426F8B45.8070509@3di.it> <42709B74.4000508@3di.it> Message-ID: <42710736.2020001@redhat.com> This string of messages brings up something I wanted to get a conversation going on how to handle non OS Provided policy. We all know we need a better mechanism for handling "binary" policy in the future. ( I think the future is now.) I see three people providing policy. 1. OS Provider with base policy. (It would also be nice if the base policy got broken into several policies and only the policy of the running service would be loaded. If we got to this state we would need a new mechanism for restoring file context since file_context might not meet the currently loaded policy. 2. Third Party application developers. As the use of targeted policy has begun to take off, Third Party ISV have started to question how they can play in this world. I see Tresys Stuff solving the problems of both of the above. 3 Local User customization and minor policies. Currently we have people using audit2allow creating files in domains/misc and then reloading policy. We need a mechanism for users to be able to do this without recompiling policy. Also more significantly how do we handle the small diffed apache_domain stuff. A couple of months ago I redesigned apache policy to have a macro called apache_domain. A user could create a new apache_XYZ.te file with apache_domain(XYZ) Followed by a few allow rules and be able to get their cgi scripts working without turning off apache protection or running their script in httpd_unconfined_script_t. The problem is the only way to do this is to install policy sources and muck around. I think we to have some shared library mechanism where a few well known macros could be defined and users could easily build their own custom policy. Anyways I think we need more discussion on handling third party and user customization of policy outside of the current make tree stuff. Dan Dan -- From steve at atc-nycorp.com Thu Apr 28 16:32:36 2005 From: steve at atc-nycorp.com (Steve Brueckner) Date: Thu, 28 Apr 2005 12:32:36 -0400 Subject: selinux_socket_bind hook Message-ID: <60D45469A1AAD311A04C009027B6BF6804FCF0C3@server20.inside.oracorp.com> In trying to segment networking into two domains I seem to have overlooked that name_bind doesn't get enforced for ports within the machine's local port range (i.e. ports assigned by the kernel). I suppose I could try to hack the LSM selinux_socket_bind hook to enforce name_bind for all ports; would that be possible? I'd rather not, though, since I've never ventured deeper than SELinux policy, and delving into the mechanism scares me. Is it possible to somehow implement a boolean that would toggle whether name_bind was enforced for all ports or just for ports outside the local port range? Thanks, - Steve Brueckner, ATC-NY From sds at tycho.nsa.gov Thu Apr 28 16:49:47 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 28 Apr 2005 12:49:47 -0400 Subject: selinux_socket_bind hook In-Reply-To: <60D45469A1AAD311A04C009027B6BF6804FCF0C3@server20.inside.oracorp.com> References: <60D45469A1AAD311A04C009027B6BF6804FCF0C3@server20.inside.oracorp.com> Message-ID: <1114706987.6708.211.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-04-28 at 12:32 -0400, Steve Brueckner wrote: > In trying to segment networking into two domains I seem to have overlooked > that name_bind doesn't get enforced for ports within the machine's local > port range (i.e. ports assigned by the kernel). I suppose I could try to > hack the LSM selinux_socket_bind hook to enforce name_bind for all ports; > would that be possible? I'd rather not, though, since I've never ventured > deeper than SELinux policy, and delving into the mechanism scares me. Is it > possible to somehow implement a boolean that would toggle whether name_bind > was enforced for all ports or just for ports outside the local port range? That hook is only applied for explicit bind(2) calls by applications. auto-binding of unbound sockets by the kernel (e.g. when sending on an unbound socket) will never hit that hook at all. You would need to modify udp_v4_get_port and tcp_v4_get_port to check permission and keep scanning for another available port until one is allowed. Not likely to make much headway upstream. -- Stephen Smalley National Security Agency From steve at atc-nycorp.com Thu Apr 28 17:49:22 2005 From: steve at atc-nycorp.com (Steve Brueckner) Date: Thu, 28 Apr 2005 13:49:22 -0400 Subject: selinux_socket_bind hook Message-ID: <60D45469A1AAD311A04C009027B6BF6804FCF0C4@server20.inside.oracorp.com> Stephen Smalley wrote: > On Thu, 2005-04-28 at 12:32 -0400, Steve Brueckner wrote: >> In trying to segment networking into two domains I seem to have >> overlooked that name_bind doesn't get enforced for ports within the >> machine's local port range (i.e. ports assigned by the kernel). I >> suppose I could try to hack the LSM selinux_socket_bind hook to >> enforce name_bind for all ports; would that be possible? I'd rather >> not, though, since I've never ventured deeper than SELinux policy, >> and delving into the mechanism scares me. Is it possible to somehow >> implement a boolean that would toggle whether name_bind was enforced >> for all ports or just for ports outside the local port range? > > That hook is only applied for explicit bind(2) calls by applications. > auto-binding of unbound sockets by the kernel (e.g. when sending on > an unbound socket) will never hit that hook at all. You would need > to modify udp_v4_get_port and tcp_v4_get_port to check permission and > keep scanning for another available port until one is allowed. Not > likely to make much headway upstream. Darn. But thank you for the clarification. - Steve Brueckner, ATC-NY From sds at tycho.nsa.gov Thu Apr 28 17:51:33 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 28 Apr 2005 13:51:33 -0400 Subject: Is there a SELinux tutorial for ISVs ? In-Reply-To: <1114709532.8548.69.camel@localhost.localdomain> References: <426F8B45.8070509@3di.it> <42709B74.4000508@3di.it> <42710736.2020001@redhat.com> <1114709532.8548.69.camel@localhost.localdomain> Message-ID: <1114710693.6708.237.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-04-28 at 19:32 +0200, Lorenzo Hern?ndez Garc?a-Hierro wrote: > I've been thinking on it when working on the SELinux deployment within > Ubuntu Linux, and binary policies are something pretty handy for binary > packages-based distributions, among the general benefit they provide. > > I might be able to work on something, but I would like to know first how > many people is interested in this and how many of them would be able to > contribute to it in the long term. Tresys Technology already has a working implementation of binary policy modules, including a module abstraction with a dependency model, a compiler for generating such modules, and a linker for linking them together with a "base module". Planned for upstreaming after FC4. See their prior posts to the selinux list or their web site for info. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Thu Apr 28 18:54:52 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 28 Apr 2005 14:54:52 -0400 Subject: gpg through apache and php? In-Reply-To: <1114689430.6708.40.camel@moss-spartans.epoch.ncsc.mil> References: <1114689430.6708.40.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4271317C.9020909@redhat.com> Stephen Smalley wrote: >On Wed, 2005-04-27 at 22:09 -0400, brett wrote: > > >>httpd_disable_trans active >> >> > >What? That should have disabled all protection on httpd, i.e. the >transition into httpd_t in the first place. Or did you just make that >change after being unable to get it to work? > > > >>httpd_enable_homedirs active >> >> > >Allows access to user home directories. For better security, disable. > > > >>httpd_unified active >> >> > >This folds together the distinct types of web content; preferable to >disable it if possible. > > > >>/home/test/.gnupg >> >>test is a user. Also, i plan on using symmetric encryption so i don't >>think it needs the keyring file. >> >> > >Why isn't it just part of the web tree under /var/www so that you can >prohibit access to user home directories entirely? > > > >>Apr 24 22:29:06 razorfold kernel: audit(1114396146.398:0): avc: denied { >>execute } for pid=6266 comm=gpg path=/etc/ld.so.cache dev=dm-0 >>ino=3919093 scontext=user_u:system_r:httpd_sys_script_t >>tcontext=system_u:object_r:ld_so_cache_t tclass=file >>Apr 24 22:29:06 razorfold kernel: audit(1114396146.398:0): avc: denied { >>execmod } for pid=6266 comm=gpg path=/usr/bin/gpg dev=dm-0 ino=4972274 >>scontext=user_u:system_r:httpd_sys_script_t >>tcontext=system_u:object_r:bin_t tclass=file >> >> > >This is a result of gpg being marked as requiring an executable stack >(and still looks that way in FC4/devel - execstack -q /usr/bin/gpg >reports X - Dan?). > Hopefully fixed again in tomorrow's rawhide. > With a newer kernel (>= 2.6.12-rc2, also included in >FC4/devel kernels), you'd at least avoid the noise on ld.so.cache due to >the checkreqprot compatibility support. But you would still need >execmod on the gpg binary; under strict policy, gpg has its own separate >executable type (gpg_exec_t) and domain (gpg_t), so we only need to >allow execmod for that particular case. What's suggested for FC3 >targeted policy, Dan? > > Fix takes care of the problem. -- From sds at tycho.nsa.gov Thu Apr 28 19:14:45 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 28 Apr 2005 15:14:45 -0400 Subject: gpg through apache and php? In-Reply-To: <4271317C.9020909@redhat.com> References: <1114689430.6708.40.camel@moss-spartans.epoch.ncsc.mil> <4271317C.9020909@redhat.com> Message-ID: <1114715685.6708.301.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-04-28 at 14:54 -0400, Daniel J Walsh wrote: > Hopefully fixed again in tomorrow's rawhide. You mean a fixed gpg that isn't marked as requiring an executable stack, or a "fixed" targeted policy to workaround it? > Fix takes care of the problem. For FC4, possibly. But the original poster is running FC3+targeted policy. -- Stephen Smalley National Security Agency From lorenzo at gnu.org Thu Apr 28 17:32:11 2005 From: lorenzo at gnu.org (Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?= =?ISO-8859-1?Q?Garc=EDa-Hierro?=) Date: Thu, 28 Apr 2005 19:32:11 +0200 Subject: Is there a SELinux tutorial for ISVs ? In-Reply-To: <42710736.2020001@redhat.com> References: <426F8B45.8070509@3di.it> <42709B74.4000508@3di.it> <42710736.2020001@redhat.com> Message-ID: <1114709532.8548.69.camel@localhost.localdomain> El jue, 28-04-2005 a las 11:54 -0400, Daniel J Walsh escribi?: > The problem is the only way to do this is to install policy sources and > muck around. I think we to have some shared library mechanism > where a few well known macros could be defined and users could easily > build their own custom policy. > > Anyways I think we need more discussion on handling third party and user > customization of policy outside of the current make tree stuff. I've been thinking on it when working on the SELinux deployment within Ubuntu Linux, and binary policies are something pretty handy for binary packages-based distributions, among the general benefit they provide. I might be able to work on something, but I would like to know first how many people is interested in this and how many of them would be able to contribute to it in the long term. The idea I thought about is something like the one shown in the diagram at http://pearls.tuxedo-es.org/selinux/diagrams/selinux-binary-policies-1.png Cheers, -- Lorenzo Hern?ndez Garc?a-Hierro [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] -------------- 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 chanson at TrustedCS.com Thu Apr 28 18:29:11 2005 From: chanson at TrustedCS.com (Chad Hanson) Date: Thu, 28 Apr 2005 14:29:11 -0400 Subject: Is there a SELinux tutorial for ISVs ? Message-ID: <36282A1733C57546BE392885C06185928E2A19@chaos.tcs.tcs-sec.com> > > This string of messages brings up something I wanted to get a > conversation going on how to handle non OS Provided policy. > > We all know we need a better mechanism for handling "binary" > policy in > the future. ( I think the future is now.) > I see three people providing policy. > I agree, as an ISV we need a way to add custom policy to support our applications. We currently use a processed version to the policy to have source modules until the binary modules are part of Fedora. > 1. OS Provider with base policy. (It would also be nice if the base > policy got broken into several policies and only the policy > of the running service would be loaded. If we got to this state we > would need a new mechanism for restoring file context since > file_context might not meet the currently loaded policy. > > 2. Third Party application developers. As the use of targeted policy > has begun to take off, Third Party ISV have started to question > how they can play in this world. > Exactly, see statement above. > I see Tresys Stuff solving the problems of both of the above. > > 3 Local User customization and minor policies. Currently we > have people Along with local user policy, there needs to be local network policy customizations as well. This is required from an MLS perspective and I would think be useful for TE network restrictions as well. From kmacmillan at tresys.com Thu Apr 28 20:32:36 2005 From: kmacmillan at tresys.com (Karl MacMillan) Date: Thu, 28 Apr 2005 16:32:36 -0400 Subject: Is there a SELinux tutorial for ISVs ? In-Reply-To: <36282A1733C57546BE392885C06185928E2A19@chaos.tcs.tcs-sec.com> Message-ID: <200504282033.j3SKWa8R030518@gotham.columbia.tresys.com> > -----Original Message----- > From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux-list- > bounces at redhat.com] On Behalf Of Chad Hanson > Sent: Thursday, April 28, 2005 2:29 PM > To: Daniel J Walsh; Davide Bolcioni > Cc: SELinux; fedora-selinux-list at redhat.com > Subject: RE: Is there a SELinux tutorial for ISVs ? > > > I see Tresys Stuff solving the problems of both of the above. > > > > 3 Local User customization and minor policies. Currently we > > have people > > Along with local user policy, there needs to be local network policy > customizations as well. This is required from an MLS perspective and I would > think be useful for TE network restrictions as well. > Definitely - users might want to only allow apache to serve pages to one netif for example. Also, when the remaining network functionality is finished there will be much more need to customize the network policy. Karl --- Karl MacMillan Tresys Technology http://www.tresys.com (410) 290-1411 ext 134 > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From kmacmillan at tresys.com Thu Apr 28 20:38:04 2005 From: kmacmillan at tresys.com (Karl MacMillan) Date: Thu, 28 Apr 2005 16:38:04 -0400 Subject: Is there a SELinux tutorial for ISVs ? In-Reply-To: <1114710693.6708.237.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200504282038.j3SKc48R030556@gotham.columbia.tresys.com> > -----Original Message----- > From: owner-selinux at tycho.nsa.gov [mailto:owner-selinux at tycho.nsa.gov] On > Behalf Of Stephen Smalley > Sent: Thursday, April 28, 2005 1:52 PM > To: Lorenzo Hern?ndez Garc?a-Hierro > Cc: Daniel J Walsh; Davide Bolcioni; fedora-selinux-list at redhat.com; SELinux > Subject: Re: Is there a SELinux tutorial for ISVs ? > > On Thu, 2005-04-28 at 19:32 +0200, Lorenzo Hern?ndez Garc?a-Hierro > wrote: > > I've been thinking on it when working on the SELinux deployment within > > Ubuntu Linux, and binary policies are something pretty handy for binary > > packages-based distributions, among the general benefit they provide. > > > > I might be able to work on something, but I would like to know first how > > many people is interested in this and how many of them would be able to > > contribute to it in the long term. > > Tresys Technology already has a working implementation of binary policy > modules, including a module abstraction with a dependency model, a > compiler for generating such modules, and a linker for linking them > together with a "base module". Planned for upstreaming after FC4. See > their prior posts to the selinux list or their web site for info. > This and the reference policy work I just mentioned in another email. As we work on upstreaming the binary modules we are going to need feedback / testing - if you are interested in this area I would greatly appreciate any help you can give. Thanks, Karl --- Karl MacMillan Tresys Technology http://www.tresys.com (410) 290-1411 ext 134 > -- > Stephen Smalley > National Security Agency > > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to majordomo at tycho.nsa.gov with > the words "unsubscribe selinux" without quotes as the message. From kmacmillan at tresys.com Thu Apr 28 20:29:24 2005 From: kmacmillan at tresys.com (Karl MacMillan) Date: Thu, 28 Apr 2005 16:29:24 -0400 Subject: Is there a SELinux tutorial for ISVs ? In-Reply-To: <42710736.2020001@redhat.com> Message-ID: <200504282029.j3SKTO8R030496@gotham.columbia.tresys.com> > -----Original Message----- > From: owner-selinux at tycho.nsa.gov [mailto:owner-selinux at tycho.nsa.gov] On > Behalf Of Daniel J Walsh > Sent: Thursday, April 28, 2005 11:55 AM > To: Davide Bolcioni > Cc: fedora-selinux-list at redhat.com; SELinux > Subject: Re: Is there a SELinux tutorial for ISVs ? > > This string of messages brings up something I wanted to get a > conversation going on how to handle non OS Provided policy. > > We all know we need a better mechanism for handling "binary" policy in > the future. ( I think the future is now.) > I see three people providing policy. > > 1. OS Provider with base policy. (It would also be nice if the base > policy got broken into several policies and only the policy > of the running service would be loaded. If we got to this state we > would need a new mechanism for restoring file context since > file_context might not meet the currently loaded policy. > In the binary policy work, the base is simply a binary module that is fully self-contained to guarantee that there will be an internally consistent / coherent policy at all times. That policy can be arbitrarily small, however. As for only enabling policy for certain services I see three options: 1) Policy for all services is always loaded (current practice). 2) Policy for services that are installed is always loaded. 3) Policy for services that are installed is loaded on service start. 1 is obviously problematic because of wasted resources and privileged application domains being present when they should not be (not to mention 3rd party policy). We considered 3 when we started the binary module work, but decided that it was too complicated with little benefit. Additionally, I think that it is _very_ desirable to limit relabeling as much as possible. It is error prone and risky in terms of security. 2 is what we are targeting. The installation of a new service in the model I am proposing would 1) Install the binary policy module to a place on the filesystem managed by RPM (for example /etc/selinux/policy-name/installed-modules). 2) Load the policy by installing it with semodule (semodule -i policy.pp - .pp is for policy package which is the binary policy and file contexts). This will install the module into a managed location (for example /etc/selinux/policy-name/active-modules) and load it into the kernel. 3) RPM would then label files as it installs the application. The binary module infrastructure also always creates a complete file_context like the current system, so that can be used for whatever labeling needs to be done. > 2. Third Party application developers. As the use of targeted policy > has begun to take off, Third Party ISV have started to question > how they can play in this world. > > I see Tresys Stuff solving the problems of both of the above. > That is the plan - we are porting the recent changes to libsepol/libselinux/checkpolicy to our tree and will start upstreaming the binary policy work soon. I am targeting getting this integrated by June. > 3 Local User customization and minor policies. Currently we have people > using audit2allow creating files in domains/misc and then > reloading policy. We need a mechanism for users to be able to do this > without recompiling policy. Also more significantly how > do we handle the small diffed apache_domain stuff. A couple of months > ago I redesigned apache policy to have a macro called > apache_domain. A user could create a new apache_XYZ.te file with > > apache_domain(XYZ) > Followed by a few allow rules and be able to get their cgi scripts > working without turning off apache protection or running their script in > httpd_unconfined_script_t. > > The problem is the only way to do this is to install policy sources and > muck around. I think we to have some shared library mechanism > where a few well known macros could be defined and users could easily > build their own custom policy. > We are actively working on what we are calling reference policy. This attempts to create just such a 'shared library' mechanism among other goals. On the source level it creates abstractions in the form of layers and modules. Each module, which contains the policy for a well-defined functional area, exports a set of interfaces - macros that allow access to its resources. I have attached a presentation that we recently did on this project, which may give you an idea of what we are trying to accomplish. I will get this on our web page soon. Also, we are starting a sourceforge project for this that will be up soon. We are making rapid progress on this and can release the policies that we have done so far when the project set up. If anyone would like to see what we have let me know and I will get you a tarball off list. I think that the next step is to add the interface idea to the underlying binary module language so that external policies can start being dependent not on types but interfaces. If these stabilize enough it should be possible to write to this abstraction layer and have a single binary module work across many base policies. > > Anyways I think we need more discussion on handling third party and user > customization of policy outside of the current make tree stuff. > I agree. We are trying to tackle these problems, but need input about exactly what people need. --- Karl MacMillan Tresys Technology http://www.tresys.com (410) 290-1411 ext 134 > Dan > > Dan > > -- > > > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to majordomo at tycho.nsa.gov with > the words "unsubscribe selinux" without quotes as the message. -------------- next part -------------- A non-text attachment was scrubbed... Name: reference-policy.pdf Type: application/pdf Size: 80268 bytes Desc: not available URL: From ronny at spacenet.co.ug Fri Apr 29 05:32:43 2005 From: ronny at spacenet.co.ug (Ronny) Date: Fri, 29 Apr 2005 08:32:43 +0300 Subject: Starting Linux in Single mode with selinux=enforcing In-Reply-To: <4270F20C.5050600@redhat.com> References: <4270E7CA.20004@spacenet.co.ug> <4270F20C.5050600@redhat.com> Message-ID: <4271C6FB.8080809@spacenet.co.ug> Thanx Dan for that was about to retire ;-) Daniel J Walsh wrote: > Ronny wrote: > >> Hi all I have enabled selinux to enforcing mode but when I rebooted I >> get Kernel Panic I know I made a mistake didn't create policies.So >> how do I boot in sinlge mode to edit the line back to its original. >> Am using Fedora Core 3 with grub but can't go to single mode. >> Thanks in advance >> Ronny > > > Add "enforcing=0 s" to boot line. > -- *************************************************************************** / ''We can't become what we need to be by remaining what we are''\ \ ,, ,,/ *************************************************************************** From kmacmillan at tresys.com Fri Apr 29 13:02:11 2005 From: kmacmillan at tresys.com (Karl MacMillan) Date: Fri, 29 Apr 2005 09:02:11 -0400 Subject: Is there a SELinux tutorial for ISVs ? In-Reply-To: <42710736.2020001@redhat.com> Message-ID: <200504291302.j3TD2B8R003613@gotham.columbia.tresys.com> > -----Original Message----- > From: owner-selinux at tycho.nsa.gov [mailto:owner-selinux at tycho.nsa.gov] > On Behalf Of Daniel J Walsh > Sent: Thursday, April 28, 2005 11:55 AM > To: Davide Bolcioni > Cc: fedora-selinux-list at redhat.com; SELinux > Subject: Re: Is there a SELinux tutorial for ISVs ? > > This string of messages brings up something I wanted to get a > conversation going on how to handle non OS Provided policy. > > We all know we need a better mechanism for handling "binary" policy in > the future. ( I think the future is now.) I see three people > providing policy. > > 1. OS Provider with base policy. (It would also be nice if the base > policy got broken into several policies and only the policy of the > running service would be loaded. If we got to this state we would > need a new mechanism for restoring file context since file_context > might not meet the currently loaded policy. > In the binary policy work, the base is simply a binary module that is fully self-contained to guarantee that there will be an internally consistent / coherent policy at all times. That policy can be arbitrarily small, however. As for only enabling policy for certain services I see three options: 1) Policy for all services is always loaded (current practice). 2) Policy for services that are installed is always loaded. 3) Policy for services that are installed is loaded on service start. 1 is obviously problematic because of wasted resources and privileged application domains being present when they should not be (not to mention 3rd party policy). We considered 3 when we started the binary module work, but decided that it was too complicated with little benefit. Additionally, I think that it is _very_ desirable to limit relabeling as much as possible. It is error prone and risky in terms of security. 2 is what we are targeting. The installation of a new service in the model I am proposing would 1) Install the binary policy module to a place on the filesystem managed by RPM (for example /etc/selinux/policy-name/installed-modules). 2) Load the policy by installing it with semodule (semodule -i policy.pp - .pp is for policy package which is the binary policy and file contexts). This will install the module into a managed location (for example /etc/selinux/policy-name/active-modules) and load it into the kernel. 3) RPM would then label files as it installs the application. The binary module infrastructure also always creates a complete file_context like the current system, so that can be used for whatever labeling needs to be done. > 2. Third Party application developers. As the use of targeted policy > has begun to take off, Third Party ISV have started to question how > they can play in this world. > > I see Tresys Stuff solving the problems of both of the above. > That is the plan - we are porting the recent changes to libsepol/libselinux/checkpolicy to our tree and will start upstreaming the binary policy work soon. I am targeting getting this integrated by June. > 3 Local User customization and minor policies. Currently we have > people using audit2allow creating files in domains/misc and then > reloading policy. We need a mechanism for users to be able to do this > without recompiling policy. Also more significantly how > do we handle the small diffed apache_domain stuff. A couple of months > ago I redesigned apache policy to have a macro called apache_domain. > A user could create a new apache_XYZ.te file with > > apache_domain(XYZ) > Followed by a few allow rules and be able to get their cgi scripts > working without turning off apache protection or running their script > in httpd_unconfined_script_t. > > The problem is the only way to do this is to install policy sources and > muck around. I think we to have some shared library mechanism > where a few well known macros could be defined and users could easily > build their own custom policy. > We are actively working on what we are calling reference policy. This attempts to create just such a 'shared library' mechanism among other goals. On the source level it creates abstractions in the form of layers and modules. Each module, which contains the policy for a well-defined functional area, exports a set of interfaces - macros that allow access to its resources. There is a presentation that we did on this work available at http://tresys.com/Downloads/selinux_dev/reference-policy.pdf, which may give you an idea of what we are trying to accomplish. Also, we are starting a sourceforge project for this that will be up soon. We are making rapid progress on this and can release the policies that we have done so far when the project set up. If anyone would like to see what we have let me know and I will get you a tarball off list. I think that the next step is to add the interface idea to the underlying binary module language so that external policies can start being dependent not on types but interfaces. If these stabilize enough it should be possible to write to this abstraction layer and have a single binary module work across many base policies. > > Anyways I think we need more discussion on handling third party and > user customization of policy outside of the current make tree stuff. > I agree. We are trying to tackle these problems, but need input about exactly what people need. --- Karl MacMillan Tresys Technology http://www.tresys.com (410) 290-1411 ext 134 > Dan > > Dan > > -- > > > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to > majordomo at tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From robackja at cs.arizona.edu Fri Apr 29 07:33:02 2005 From: robackja at cs.arizona.edu (Joe Roback) Date: Fri, 29 Apr 2005 00:33:02 -0700 Subject: apache + mod_perl + sendmail - FC3 SELinux Message-ID: <4271E32E.90006@cs.arizona.edu> FC3 2.6.11-1.14_FC3 SELinux related rpms: libselinux-1.19.1-8 libselinux-devel-1.19.1-8 selinux-policy-targeted-1.17.30-2.96 perl-5.8.5-9 sendmail-8.13.1-2 httpd-2.0.52-3.1 I am using software from http://software.eprints.org. Web application that uses mod_perl. It sends emails for registering users and forgotten passwords. Anything an email is fired off syslog shows this: Apr 28 21:48:23 dlist kernel: audit(1114750103.574:0): avc: denied { read } for pid=25276 exe=/usr/sbin/httpd name=sendmail dev=dm-0 ino=368559 scontext=root:system_r:httpd_t tcontext=system_u:object_r:sbin_t tclass=lnk_file I have also tried sending email with PHP's mail() call and it resulted in: Apr 28 21:48:23 dlist kernel: audit(1114750103.679:0): avc: denied { write } for pid=25276 exe=/usr/sbin/sendmail.sendmail name=clientmqueue dev=dm-0 ino=2310265 scontext=root:system_r:system_mail_t tcontext=system_u:object_r:var_spool_t tclass=dir Apr 28 21:48:23 dlist kernel: audit(1114750103.679:0): avc: denied { add_name } for pid=25276 exe=/usr/sbin/sendmail.sendmail name=dfj3T4mNH8025276 scontext=root:system_r:system_mail_t tcontext=system_u:object_r:var_spool_t tclass=dir Apr 28 21:48:23 dlist kernel: audit(1114750103.679:0): avc: denied { create } for pid=25276 exe=/usr/sbin/sendmail.sendmail name=dfj3T4mNH8025276 scontext=root:system_r:system_mail_t tcontext=root:object_r:var_spool_t tclass=file Apr 28 21:48:23 dlist kernel: audit(1114750103.680:0): avc: denied { getattr } for pid=25276 exe=/usr/sbin/sendmail.sendmail path=/var/spool/clientmqueue/dfj3T4mNH8025276 dev=dm-0 ino=2311458 scontext=root:system_r:system_mail_t tcontext=root:object_r:var_spool_t tclass=file Apr 28 21:48:23 dlist kernel: audit(1114750103.680:0): avc: denied { lock } for pid=25276 exe=/usr/sbin/sendmail.sendmail path=/var/spool/clientmqueue/dfj3T4mNH8025276 dev=dm-0 ino=2311458 scontext=root:system_r:system_mail_t tcontext=root:object_r:var_spool_t tclass=file Apr 28 21:48:23 dlist kernel: audit(1114750103.680:0): avc: denied { write } for pid=25276 exe=/usr/sbin/sendmail.sendmail path=/var/spool/clientmqueue/dfj3T4mNH8025276 dev=dm-0 ino=2311458 scontext=root:system_r:system_mail_t tcontext=root:object_r:var_spool_t tclass=file Apr 28 21:48:23 dlist kernel: audit(1114750103.687:0): avc: denied { read } for pid=25276 exe=/usr/sbin/sendmail.sendmail name=dfj3T4mNH8025276 dev=dm-0 ino=2311458 scontext=root:system_r:system_mail_t tcontext=root:object_r:var_spool_t tclass=file Apr 28 21:48:23 dlist kernel: audit(1114750103.696:0): avc: denied { remove_name } for pid=25276 exe=/usr/sbin/sendmail.sendmail name=tfj3T4mNH8025276 dev=dm-0 ino=2311462 scontext=root:system_r:system_mail_t tcontext=system_u:object_r:var_spool_t tclass=dir Apr 28 21:48:23 dlist kernel: audit(1114750103.696:0): avc: denied { rename } for pid=25276 exe=/usr/sbin/sendmail.sendmail name=tfj3T4mNH8025276 dev=dm-0 ino=2311462 scontext=root:system_r:system_mail_t tcontext=root:object_r:var_spool_t tclass=file Apr 28 21:48:23 dlist kernel: audit(1114750103.696:0): avc: denied { unlink } for pid=25276 exe=/usr/sbin/sendmail.sendmail name=qfj3T4mNH8025276 dev=dm-0 ino=2311461 scontext=root:system_r:system_mail_t tcontext=root:object_r:var_spool_t tclass=file Apr 28 21:48:23 dlist kernel: audit(1114750103.696:0): avc: denied { read } for pid=25276 exe=/usr/sbin/sendmail.sendmail name=clientmqueue dev=dm-0 ino=2310265 scontext=root:system_r:system_mail_t tcontext=system_u:object_r:var_spool_t tclass=dir Apr 28 21:48:23 dlist kernel: audit(1114750103.901:0): avc: denied { sigchld } for pid=1 exe=/sbin/init scontext=root:system_r:system_mail_t tcontext=user_u:system_r:unconfined_t tclass=process This is really troubling, since sending email through a CGI application is probably the most basic web application there is. Any help would be greatly appreciated. This is my first time dealing with SELinux, so I am newbie here. :) sestatus: SELinux status: enabled SELinuxfs mount: /selinux Current mode: permissive Mode from config file: disabled Policy version: 18 Policy from config file:targeted Policy booleans: allow_ypbind active dhcpd_disable_trans inactive httpd_disable_trans inactive httpd_enable_cgi active httpd_enable_homedirs active httpd_ssi_exec active httpd_tty_comm inactive httpd_unified active mysqld_disable_trans inactive named_disable_trans inactive named_write_master_zonesinactive nscd_disable_trans inactive ntpd_disable_trans inactive portmap_disable_trans inactive postgresql_disable_transinactive snmpd_disable_trans inactive squid_disable_trans inactive syslogd_disable_trans inactive use_nfs_home_dirs inactive use_samba_home_dirs inactive use_syslogng inactive winbind_disable_trans inactive ypbind_disable_trans inactive I am not sure what other information might be helpful, but ask and you shall receive. :) cheers, Joe Roback From mayerf at tresys.com Fri Apr 29 15:56:21 2005 From: mayerf at tresys.com (Frank Mayer) Date: Fri, 29 Apr 2005 11:56:21 -0400 Subject: MLS permission map Message-ID: <200504291556.j3TFuL8R005277@gotham.columbia.tresys.com> I've been working through the new MLS implementation (a nice improvement by the way). I see how the old method of mapping permissions to read or write is changed and instead these ideas are implemented in the constraints definitions. I like that too since a policy writer can tweak their notion of reads and writes (which given the volume of covert channels that will be present, will allow one to change how strict they want to be). My question is: although the mapping is not explicit, it is still there. In the current sample policy, has someone captured the justification for which permissions are restricted and which are not? Which are being treated as reads, writes, both or neither? Ultimately for any certifiable security policy we'll need to justify this mapping. I specially ask both to see if the model we have built into apol's permmap is consistent with the MLS mappings, as well as for the reference policy work we're doing that Karl mentioned earlier. Thanks Frank From carlos.pastorino at gmail.com Fri Apr 29 18:08:04 2005 From: carlos.pastorino at gmail.com (Carlos Pastorino) Date: Fri, 29 Apr 2005 15:08:04 -0300 Subject: snmpd proc monitoring problem Message-ID: Hello, I've inserted the following line on my /etc/snmpd.conf file: proc sshd Then I executed the following command: snmpwalk -On -v2c -c public localhost .1.3.6.1.4.1.2021.2.1 and got the answer: .1.3.6.1.4.1.2021.2.1.1.1 = INTEGER: 1 .1.3.6.1.4.1.2021.2.1.2.1 = STRING: sshd .1.3.6.1.4.1.2021.2.1.3.1 = INTEGER: 0 .1.3.6.1.4.1.2021.2.1.4.1 = INTEGER: 0 .1.3.6.1.4.1.2021.2.1.5.1 = INTEGER: 0 .1.3.6.1.4.1.2021.2.1.100.1 = INTEGER: 1 .1.3.6.1.4.1.2021.2.1.101.1 = STRING: No sshd process running. .1.3.6.1.4.1.2021.2.1.102.1 = INTEGER: 0 .1.3.6.1.4.1.2021.2.1.103.1 = STRING: But, if I execute the command below: setenforce 0 I get the correct answer: .1.3.6.1.4.1.2021.2.1.1.1 = INTEGER: 1 .1.3.6.1.4.1.2021.2.1.2.1 = STRING: sshd .1.3.6.1.4.1.2021.2.1.3.1 = INTEGER: 0 .1.3.6.1.4.1.2021.2.1.4.1 = INTEGER: 0 .1.3.6.1.4.1.2021.2.1.5.1 = INTEGER: 2 .1.3.6.1.4.1.2021.2.1.100.1 = INTEGER: 0 .1.3.6.1.4.1.2021.2.1.101.1 = STRING: .1.3.6.1.4.1.2021.2.1.102.1 = INTEGER: 0 .1.3.6.1.4.1.2021.2.1.103.1 = STRING: The problem is, nothing shows up on /var/log/messages to allow me to figure out how to tweak the /etc/selinux/targeted/src/policy/domains/program/snmpd.te file. Any hints? Regards, Carlos From kwade at redhat.com Fri Apr 29 18:36:18 2005 From: kwade at redhat.com (Karsten Wade) Date: Fri, 29 Apr 2005 11:36:18 -0700 Subject: apache + mod_perl + sendmail - FC3 SELinux In-Reply-To: <4271E32E.90006@cs.arizona.edu> References: <4271E32E.90006@cs.arizona.edu> Message-ID: <1114799778.6234.474.camel@erato.phig.org> On Fri, 2005-04-29 at 00:33 -0700, Joe Roback wrote: > I am using software from http://software.eprints.org. Web application > that uses mod_perl. It sends emails for registering users and forgotten > passwords. Anything an email is fired off syslog shows this: Did you catch this message yesterday: http://www.redhat.com/archives/fedora-selinux-list/2005-April/msg00247.html In it, Dan says: "3 Local User customization and minor policies. Currently we have people using audit2allow creating files in domains/misc and then reloading policy. We need a mechanism for users to be able to do this without recompiling policy. Also more significantly how do we handle the small diffed apache_domain stuff. A couple of months ago I redesigned apache policy to have a macro called apache_domain. A user could create a new apache_XYZ.te file with apache_domain(XYZ) Followed by a few allow rules and be able to get their cgi scripts working without turning off apache protection or running their script in httpd_unconfined_script_t." -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- 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 Fri Apr 29 19:39:40 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 29 Apr 2005 15:39:40 -0400 Subject: snmpd proc monitoring problem In-Reply-To: References: Message-ID: <42728D7C.9040302@redhat.com> Carlos Pastorino wrote: >Hello, > >I've inserted the following line on my /etc/snmpd.conf file: > > proc sshd > >Then I executed the following command: > >snmpwalk -On -v2c -c public localhost .1.3.6.1.4.1.2021.2.1 > >and got the answer: > >.1.3.6.1.4.1.2021.2.1.1.1 = INTEGER: 1 >.1.3.6.1.4.1.2021.2.1.2.1 = STRING: sshd >.1.3.6.1.4.1.2021.2.1.3.1 = INTEGER: 0 >.1.3.6.1.4.1.2021.2.1.4.1 = INTEGER: 0 >.1.3.6.1.4.1.2021.2.1.5.1 = INTEGER: 0 >.1.3.6.1.4.1.2021.2.1.100.1 = INTEGER: 1 >.1.3.6.1.4.1.2021.2.1.101.1 = STRING: No sshd process running. >.1.3.6.1.4.1.2021.2.1.102.1 = INTEGER: 0 >.1.3.6.1.4.1.2021.2.1.103.1 = STRING: > >But, if I execute the command below: > >setenforce 0 > >I get the correct answer: > >.1.3.6.1.4.1.2021.2.1.1.1 = INTEGER: 1 >.1.3.6.1.4.1.2021.2.1.2.1 = STRING: sshd >.1.3.6.1.4.1.2021.2.1.3.1 = INTEGER: 0 >.1.3.6.1.4.1.2021.2.1.4.1 = INTEGER: 0 >.1.3.6.1.4.1.2021.2.1.5.1 = INTEGER: 2 >.1.3.6.1.4.1.2021.2.1.100.1 = INTEGER: 0 >.1.3.6.1.4.1.2021.2.1.101.1 = STRING: >.1.3.6.1.4.1.2021.2.1.102.1 = INTEGER: 0 >.1.3.6.1.4.1.2021.2.1.103.1 = STRING: > >The problem is, nothing shows up on /var/log/messages to allow me to >figure out how to tweak the >/etc/selinux/targeted/src/policy/domains/program/snmpd.te file. > >Any hints? > >Regards, > >Carlos > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > You are being bitten by a dontaudit rule. To disable dont audits cd /etc/selinux/targeted/src/policy make enableaudit make load The culprit line is the following. dontaudit snmpd_t domain:dir { getattr search }; If you change this to allow you will get further. -- From dwalsh at redhat.com Fri Apr 29 20:02:18 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 29 Apr 2005 16:02:18 -0400 Subject: gpg through apache and php? In-Reply-To: <1114715685.6708.301.camel@moss-spartans.epoch.ncsc.mil> References: <1114689430.6708.40.camel@moss-spartans.epoch.ncsc.mil> <4271317C.9020909@redhat.com> <1114715685.6708.301.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <427292CA.9010308@redhat.com> Stephen Smalley wrote: >On Thu, 2005-04-28 at 14:54 -0400, Daniel J Walsh wrote: > > >>Hopefully fixed again in tomorrow's rawhide. >> >> > >You mean a fixed gpg that isn't marked as requiring an executable stack, >or a "fixed" targeted policy to workaround it? > > Fixed gpg to not require exec stack. > > >>Fix takes care of the problem. >> >> > >For FC4, possibly. But the original poster is running FC3+targeted >policy. > > > I don't know what to do then. Maybe we need to release a FC3 policy that just allows execmem/execmod for apache. Dan -- From carlos.pastorino at gmail.com Sat Apr 30 00:54:55 2005 From: carlos.pastorino at gmail.com (Carlos Pastorino) Date: Fri, 29 Apr 2005 21:54:55 -0300 Subject: snmpd proc monitoring problem In-Reply-To: <42728D7C.9040302@redhat.com> References: <42728D7C.9040302@redhat.com> Message-ID: On 4/29/05, Daniel J Walsh wrote: > Carlos Pastorino wrote: > > >Hello, > > > >I've inserted the following line on my /etc/snmpd.conf file: > > > > proc sshd > > > >Then I executed the following command: > > > >snmpwalk -On -v2c -c public localhost .1.3.6.1.4.1.2021.2.1 > > > >and got the answer: > > > >.1.3.6.1.4.1.2021.2.1.1.1 = INTEGER: 1 > >.1.3.6.1.4.1.2021.2.1.2.1 = STRING: sshd > >.1.3.6.1.4.1.2021.2.1.3.1 = INTEGER: 0 > >.1.3.6.1.4.1.2021.2.1.4.1 = INTEGER: 0 > >.1.3.6.1.4.1.2021.2.1.5.1 = INTEGER: 0 > >.1.3.6.1.4.1.2021.2.1.100.1 = INTEGER: 1 > >.1.3.6.1.4.1.2021.2.1.101.1 = STRING: No sshd process running. > >.1.3.6.1.4.1.2021.2.1.102.1 = INTEGER: 0 > >.1.3.6.1.4.1.2021.2.1.103.1 = STRING: > > > >But, if I execute the command below: > > > >setenforce 0 > > > >I get the correct answer: > > > >.1.3.6.1.4.1.2021.2.1.1.1 = INTEGER: 1 > >.1.3.6.1.4.1.2021.2.1.2.1 = STRING: sshd > >.1.3.6.1.4.1.2021.2.1.3.1 = INTEGER: 0 > >.1.3.6.1.4.1.2021.2.1.4.1 = INTEGER: 0 > >.1.3.6.1.4.1.2021.2.1.5.1 = INTEGER: 2 > >.1.3.6.1.4.1.2021.2.1.100.1 = INTEGER: 0 > >.1.3.6.1.4.1.2021.2.1.101.1 = STRING: > >.1.3.6.1.4.1.2021.2.1.102.1 = INTEGER: 0 > >.1.3.6.1.4.1.2021.2.1.103.1 = STRING: > > > >The problem is, nothing shows up on /var/log/messages to allow me to > >figure out how to tweak the > >/etc/selinux/targeted/src/policy/domains/program/snmpd.te file. > > > >Any hints? > > > >Regards, > > > >Carlos > > > >-- > >fedora-selinux-list mailing list > >fedora-selinux-list at redhat.com > >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > You are being bitten by a dontaudit rule. To disable dont audits > cd /etc/selinux/targeted/src/policy > > make enableaudit > make load > > The culprit line is the following. > > dontaudit snmpd_t domain:dir { getattr search }; > > If you change this to allow you will get further. > > -- Hi Daniel, On the snmpd.te file, I've changed the line above to: allow snmpd_t domain:dir { getattr search }; Then I executed "make load", and got the error: assertion on line 21719 violated by allow snmpd_t unconfined_t:dir { getattr search }; make: *** [/etc/selinux/targeted/policy/policy.18] Error 1 Now I'm stuck again :) mainly because I don't know if it's a good idea to change the rule on line 21719, namely: # Confined domains must never see unconfined domain's /proc/pid entries. neverallow { domain -unrestricted } unconfined_t:dir { getattr search }; Any advices? Many thanks, Carlos From selinux at gmail.com Sat Apr 30 21:16:51 2005 From: selinux at gmail.com (Tom London) Date: Sat, 30 Apr 2005 14:16:51 -0700 Subject: selinux-policy-strict-1.23.13-4: suggestions? Message-ID: <4c4ba1530504301416344ce68e@mail.gmail.com> Running strict/enforcing, latest rawhide. I finally got around to 'blowing the dust off' of my strict PC. I updated to latest rawhide, did a 'fixfiles relabel', and rebooted. Graphical login failed. Appears that xdm is failing on creating a sem: Apr 30 13:20:44 fedora kernel: audit(1114892386.776:0): avc: denied { create } for key=1417649221 scontext=system_u:system_r:xdm_t tcontext=system_u:system_r:xdm_t tclass=sem Apr 30 13:25:35 fedora kernel: audit(1114892735.514:0): avc: denied { unix_read unix_write } for key=199061348 scontext=system_u:system_r:xdm_t tcontext=system_u:system_r:xdm_t tclass=sem Adding: allow xdm_t self:sem { create unix_read unix_write }; to xdm.te seems to fix this. That OK? Also, running firefox proxied through privoxy generates: Apr 30 13:48:23 fedora kernel: audit(1114894103.357:0): avc: denied { name_connect } for dest=8118 scontext=user_u:user_r:user_mozilla_t tcontext=system_u:object_r:port_t tclass=tcp_socket or allow user_mozilla_t port_t:tcp_socket name_connect; That right? Going through /var/log/messages: Early on, I get this: Apr 30 13:27:05 fedora kernel: SELinux: Completing initialization. Apr 30 13:27:05 fedora kernel: SELinux: Setting up existing superblocks. Apr 30 13:27:05 fedora kernel: audit(1114867589.097:0): avc: denied { write } for path=pipe:[1886] dev=pipefs ino=1886 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=fifo_file Apr 30 13:27:05 fedora kernel: SELinux: initialized (dev hda2, type ext3), uses xattr Apr 30 13:27:06 fedora kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs and Apr 30 13:27:06 fedora kernel: SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts Apr 30 13:27:06 fedora kernel: SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts Apr 30 13:27:06 fedora kernel: audit(1114867589.937:0): avc: denied { read } for name=class at vc@vcsa1 dev=tmpfs ino=1836 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:tmpfs_t tclass=file Apr 30 13:27:06 fedora kernel: audit(1114867589.939:0): avc: denied { read } for name=class at vc@vcs1 dev=tmpfs ino=1830 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:tmpfs_t tclass=file Apr 30 13:27:06 fedora kernel: SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts Apr 30 13:27:06 fedora kernel: audit(1114867590.492:0): avc: denied { create } for name=input scontext=system_u:system_r:udev_t tcontext=system_u:object_r:tmpfs_t tclass=dir Apr 30 13:27:06 fedora kernel: audit(1114867590.494:0): avc: denied { create } for name=input scontext=system_u:system_r:udev_t tcontext=system_u:object_r:tmpfs_t tclass=dir Apr 30 13:27:06 fedora kernel: audit(1114867591.604:0): avc: denied { write } for name=class at vc@vcs1 dev=tmpfs ino=1830 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:tmpfs_t tclass=file Apr 30 13:27:06 fedora kernel: audit(1114867591.627:0): avc: denied { write } for name=class at vc@vcsa1 dev=tmpfs ino=1836 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:tmpfs_t tclass=file Apr 30 13:27:06 fedora kernel: audit(1114867591.754:0): avc: denied { read } for name=class at vc@vcs1 dev=tmpfs ino=1830 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:tmpfs_t tclass=file Apr 30 13:27:06 fedora kernel: audit(1114867591.764:0): avc: denied { read } for name=class at vc@vcsa1 dev=tmpfs ino=1836 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:tmpfs_t tclass=file Apr 30 13:27:06 fedora kernel: audit(1114867592.051:0): avc: denied { write } for name=class at vc@vcsa1 dev=tmpfs ino=1836 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:tmpfs_t tclass=file <<<>>> Apr 30 13:27:06 fedora kernel: audit(1114867595.180:0): avc: denied { search } for name=485 dev=proc ino=31784962 scontext=system_u:system_r:kernel_t tcontext=system_u:system_r:init_t tclass=dir Apr 30 13:27:06 fedora kernel: audit(1114867595.180:0): avc: denied { search } for name=494 dev=proc ino=32374786 scontext=system_u:system_r:kernel_t tcontext=system_u:system_r:initrc_t tclass=dir Apr 30 13:27:06 fedora kernel: audit(1114867595.180:0): avc: denied { search } for name=545 dev=proc ino=35717122 scontext=system_u:system_r:kernel_t tcontext=system_u:system_r:hotplug_t tclass=dir and Apr 30 13:27:08 fedora kernel: ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[11] MMIO=[ed100000-ed1007ff] Max Packet=[2048] Apr 30 13:27:08 fedora kernel: audit(1114867609.739:0): avc: denied { getattr } for path=/etc/hotplug dev=hda2 ino=4472955 scontext=system_u:system_r:insmod_t tcontext=system_u:object_r:hotplug_etc_t tclass=dir Apr 30 13:27:09 fedora kernel: audit(1114867609.739:0): avc: denied { search } for name=hotplug dev=hda2 ino=4472955 scontext=system_u:system_r:insmod_t tcontext=system_u:object_r:hotplug_etc_t tclass=dir and Apr 30 13:27:10 fedora kernel: audit(1114892828.091:0): avc: denied { execute } for name=auto.net dev=hda2 ino=4474546 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:automount_etc_t tclass=file Apr 30 13:27:10 fedora kernel: audit(1114892828.595:0): avc: denied { write } for name=/ dev=hda2 ino=2 scontext=system_u:system_r:automount_t tcontext=system_u:object_r:root_t tclass=dir Apr 30 13:27:10 fedora kernel: audit(1114892828.677:0): avc: denied { dac_override } for capability=1 scontext=system_u:system_r:automount_t tcontext=system_u:system_r:automount_t tclass=capability Apr 30 13:27:10 fedora kernel: audit(1114892828.787:0): avc: denied { write } for name=/ dev=hda2 ino=2 scontext=system_u:system_r:automount_t tcontext=system_u:object_r:root_t tclass=dir Sorry if these are already fixed. tom -- Tom London