From giuseppe.greco at agamura.com Sat Jan 1 14:35:32 2005 From: giuseppe.greco at agamura.com (Giuseppe Greco) Date: Sat, 01 Jan 2005 15:35:32 +0100 Subject: Still svc: denied { getattr }... Message-ID: <1104590132.5351.7.camel@gonzo.agamura.com> Hi all, I've just updated my SELinux policies, but I still get the following error messages when restarting squid: audit(1104589130.341:0): avc: denied { getattr } for pid=2759 exe=/usr/sbin/squid path=/boot dev=hda1 ino=2 scontext=root:system_r:squid_t tcontext=system_u:object_r:boot_t tclass=dir audit(1104589130.342:0): avc: denied { getattr } for pid=2759 exe=/usr/sbin/squid path=/tmp dev=hda1 ino=2 scontext=root:system_r:squid_t tcontext=system_u:object_r:tmp_t tclass=dir Shouldn't these rules already been fixed? What can I do to get squid finally working without complying? Thanks, j3d. -- ---------------------------------------- Giuseppe Greco ::agamura:: phone: +41 (0)91 604 67 65 mobile: +41 (0)79 602 99 27 email: giuseppe.greco at agamura.com web: www.agamura.com ---------------------------------------- From russell at coker.com.au Sun Jan 2 21:01:46 2005 From: russell at coker.com.au (Russell Coker) Date: Mon, 3 Jan 2005 08:01:46 +1100 Subject: What to do after building a kernel. In-Reply-To: <1098731034.18825.5.camel@decepticon.boston.redhat.com> References: <1098731034.18825.5.camel@decepticon.boston.redhat.com> Message-ID: <200501030801.49437.russell@coker.com.au> On Tuesday 26 October 2004 05:03, Colin Walters wrote: > On Mon, 2004-10-25 at 13:49 -0500, Justin Conover wrote: > > After I built a new kernel based of of ck-overloaded, I rebooted and a > > ton of SELinux errors/messages, kept comeing across the screen? Without seeing a sample of the messages it's difficult to guess at what the problem might be. I'm sure that you've fixed your problem by now, but for future reference please keep in mind that we need those messages to identify and fix problems. They will be stored in /var/log/messages. If your machine is too messed up to allow logging then boot with "enforcing=0". > I recommend you don't rebuild arbitrary kernel versions and patch sets > with SELinux enabled. The security of the system depends on tight > coordination between the kernel, policy, and various packages. In > Fedora we do the integration ensure that this all just works. We recommend that Fedora users don't rebuild kernels etc. But if you want to get involved with development then rebuilding a kernel is something that may be worth doing. Breaking your system is always the best way to start in development... -- 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 Mon Jan 3 15:26:19 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 03 Jan 2005 10:26:19 -0500 Subject: syslog-ng non-standard install generating AVC In-Reply-To: <1104519010.29100.50.camel@erato.phig.org> References: <41D4CAFA.2040601@redhat.com> <1104519010.29100.50.camel@erato.phig.org> Message-ID: <41D9641B.7050302@redhat.com> Karsten Wade wrote: >On Thu, 2004-12-30 at 22:43 -0500, Daniel J Walsh wrote: > > >>You could add these lines to syslog.te >> >> > >Will it work to add them to local.te? > > > Yes >>can_exec(syslog_t, { bin_t shell_exec_t } ) >>allow syslogd_t etc_runtime_t:file { getattr read }; >>allow syslogd_t proc_kmsg_t:file write; >>allow syslogd_t proc_t:file { getattr read }; >>allow syslogd_t sbin_t:dir search; >>allow syslogd_t self:capability { chown fowner fsetid sys_admin }; >> >> > >I see these and a few more from using audit2allow. How did you decide >which to use? Does can_exec() replace some of the rules? These ones, >at least: > >allow syslogd_t bin_t:file { execute execute_no_trans getattr read }; >allow syslogd_t shell_exec_t:file { execute execute_no_trans getattr >read }; > > > > Yes, Seeing the execute priv, I relized what it is trying to do. So just adding can_exec is usually better than trying to explicitely give individual privs. Also some times audit2allow will tell you some process wants read privs, invariably it will ask for getattr as soon as I grant read, so we usually give both privs right away. >>There is some directory in /usr that needs to be relabeled >>syslogd_var_run_t to eliminate the following >> >>allow syslogd_t usr_t:dir { add_name remove_name write }; >>allow syslogd_t usr_t:file { append create getattr read setattr unlink >>write }; >> >> > >In other words, relabel the directory in /usr so that these rules are >not needed? > > Yes, not knowing which directory this is, but say their is a /usr/syslog directory, relabel it via chcon chcon -R -t syslogd_var_run_t /usr/syslog You would also want to add an entry under file contexts for /usr/syslog(/.*)? system_u:object_r:syslogd_var_run_t in either in policy/file_contexts/program/syslog.fc or in policy/file_contexts/misc/misc.fc >thx - Karsten > > From dwalsh at redhat.com Mon Jan 3 15:31:13 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 03 Jan 2005 10:31:13 -0500 Subject: SELinux and third party installers In-Reply-To: References: <41D4CCE2.4030200@redhat.com> Message-ID: <41D96541.5070802@redhat.com> Mike Hearn wrote: >On Thu, 30 Dec 2004 22:52:02 -0500, Daniel J Walsh wrote: > > >>The problem is that sometimes file like share libraries need a different >>file context (shlib_t) >>than the directory they are being copied to (lib_t). RPM and now >>install have the smarts to handle this. mv and cp do not. >> >> > >I see. What happens if you create a file in a lib_t directory using the >standard POSIX APIs? I looked at the Loki setup sources and it doesn't use >"cp" directly of course, it just opens files and copies them using a >read/write loop. > >What happens if a library is put in a directory that isn't lib_t, and the >DSO is not marked as shlib_t? Does the linker refuse to link it? Or is it >just that ldconfig cannot read them. > The file will get recieve the context of the parent directory. Linker is probably running in unconfined_t so it will not any problem. >I have a game here where it uses libraries marked as file_t, and it seems >to work when using LD_LIBRARY_PATH which makes me happier :) > >Most third party programs do not rely on the linker cache anyway, so I >suppose this is a good thing. > > > You should not have anything marked file_t unless they were created on a machine that was not running SELinux. This indicates that you need a relabel. >>What do you base this on? Fedora is where most of the SELinux >>development has been going on. >> >> > >Yes, I mean it's hard to find out how Fedora differs from Debian or Gentoo >SELinux-wise. If I use "install" does this only work on Fedora? Or is this >something that will eventually be merged into other distributions too. > > Hopefully, good ideas usually get picked up by other distributions, of course they might not think this is a good idea. :^) Of course you could say that generally about differences between distributions. >What about the pam_selinux module, is that used elsewhere or on other >distros must I remember to use the SELinux su equivalent as well? (I >forgot it's name ...) > > > I believe pam_selinux is being used elsewhere. >thanks -mike > >-- >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 Mon Jan 3 15:39:26 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 03 Jan 2005 10:39:26 -0500 Subject: Still svc: denied { getattr }... In-Reply-To: <1104590132.5351.7.camel@gonzo.agamura.com> References: <1104590132.5351.7.camel@gonzo.agamura.com> Message-ID: <41D9672E.3010005@redhat.com> Giuseppe Greco wrote: >Hi all, > >I've just updated my SELinux policies, but I still get the >following error messages when restarting squid: > >audit(1104589130.341:0): avc: denied { getattr } for pid=2759 > exe=/usr/sbin/squid path=/boot dev=hda1 ino=2 > scontext=root:system_r:squid_t tcontext=system_u:object_r:boot_t > tclass=dir >audit(1104589130.342:0): avc: denied { getattr } for pid=2759 > exe=/usr/sbin/squid path=/tmp dev=hda1 ino=2 > scontext=root:system_r:squid_t tcontext=system_u:object_r:tmp_t > tclass=dir > > > You can add these as dontaudit rules to policy. Looks like squid is just looking for what is in the / directory. adding the following to policy will eliminate these messages. (BTW they are harmless). dontaudit squid_t { boot_t tmp_t }:dir getattr; I will add these rules in selinux-policy-targeted-1.17.30-2.63 Dan >Shouldn't these rules already been fixed? What can I do to get >squid finally working without complying? > >Thanks, >j3d. > > From sds at epoch.ncsc.mil Mon Jan 3 15:42:45 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 03 Jan 2005 10:42:45 -0500 Subject: Head-banging targets, please In-Reply-To: <1104455021.29100.30.camel@erato.phig.org> References: <1104445584.3312.100.camel@Eng-Lab-002> <1104455021.29100.30.camel@erato.phig.org> Message-ID: <1104766965.16598.108.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-12-30 at 20:03, Karsten Wade wrote: > aiui, this is just /var/log/messages. > > Flask is a framework, and the documentation tends to be vague about > particulars like where you choose to put audit logs. SELinux, the > implementation of Flask, generally uses /var/log/messages, but I'm sure > even that could be different if you wanted. By default, SELinux (via the kernel audit framework) logs using the normal kernel logging facility, i.e. kernel -> klogd -> syslogd, and then syslogd dispatches based on /etc/syslog.conf, typically to /var/log/messages. However, the kernel audit framework will instead dispatch the audit messages to an audit daemon if one is present; work on an audit daemon is ongoing - see the linux-audit mailing list. -- Stephen Smalley National Security Agency From mike at navi.cx Mon Jan 3 16:08:21 2005 From: mike at navi.cx (Mike Hearn) Date: Mon, 03 Jan 2005 16:08:21 +0000 Subject: SELinux and third party installers References: <41D4CCE2.4030200@redhat.com> <41D96541.5070802@redhat.com> Message-ID: On Mon, 03 Jan 2005 10:31:13 -0500, Daniel J Walsh wrote: > The file will get recieve the context of the parent directory. Linker > is probably running in unconfined_t so it will not any problem. ldconfig doesn't though. Hmm. > You should not have anything marked file_t unless they were created on a > machine that was not running > SELinux. This indicates that you need a relabel. They're in my home directory. I did a "make relabel" when I enabled the targetted policy. Is that not enough? > Hopefully, good ideas usually get picked up by other distributions, of > course they might not think this is a good idea. :^) Yeah this makes it rather hard for 3rd parties to track what's going on here. Why can this stuff not all be done upstream and just merged with Fedora at regular intervals? > Of course you could say that generally about differences between > distributions. I could, and I do. It's a major pain for all concerned. thanks -mike From dwalsh at redhat.com Mon Jan 3 16:07:27 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 03 Jan 2005 11:07:27 -0500 Subject: SELinux and third party installers In-Reply-To: References: <41D4CCE2.4030200@redhat.com> <41D96541.5070802@redhat.com> Message-ID: <41D96DBF.2060300@redhat.com> Mike Hearn wrote: >On Mon, 03 Jan 2005 10:31:13 -0500, Daniel J Walsh wrote: > > >>The file will get recieve the context of the parent directory. Linker >>is probably running in unconfined_t so it will not any problem. >> >> > >ldconfig doesn't though. Hmm. > > > ldconfig transitions to ldconfig_t and is only allowed to read certain files. >>You should not have anything marked file_t unless they were created on a >>machine that was not running >>SELinux. This indicates that you need a relabel. >> >> > >They're in my home directory. I did a "make relabel" when I enabled the >targetted policy. Is that not enough? > > > relabel should have been enough, what kind of file system is your homedirectory? >>Hopefully, good ideas usually get picked up by other distributions, of >>course they might not think this is a good idea. :^) >> >> > >Yeah this makes it rather hard for 3rd parties to track what's going on >here. Why can this stuff not all be done upstream and just merged with >Fedora at regular intervals? > > > Because we have a chicken and the egg problem. Upstream does not care for SELinux until people start to use it. So why would they put SELinux changes in, if know one was using SELinux. Also upstream does not always accept changes from the distros, so either the distro is forced to carry that patch or drop the functionality. >> Of course you could say that generally about differences between >>distributions. >> >> > >I could, and I do. It's a major pain for all concerned. > >thanks -mike > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From sds at epoch.ncsc.mil Mon Jan 3 16:08:56 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 03 Jan 2005 11:08:56 -0500 Subject: SELinux and third party installers In-Reply-To: References: <41D4CCE2.4030200@redhat.com> <41D96541.5070802@redhat.com> Message-ID: <1104768536.16598.120.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-01-03 at 11:08, Mike Hearn wrote: > Yeah this makes it rather hard for 3rd parties to track what's going on > here. Why can this stuff not all be done upstream and just merged with > Fedora at regular intervals? Fedora Core is the de facto "upstream" as far as SELinux modifications to userland are concerned. Red Hat took over maintaining the SELinux userspace patches back in early 2003 when Dan Walsh ported them to the 2.6 SELinux API and started expanding them to more programs to provide better integration into the distribution. NSA is only maintaining the core SELinux code now, i.e. the SELinux kernel code and the core set of new SELinux userland packages (libsepol, libselinux, checkpolicy, policycoreutils, policy). Information about patched userland for other distros is at the selinux sourceforge site, http://selinux.sf.net. I'd expect that the SELinux userland patches will eventually go into the upstream packages (in cases where there is still an upstream maintainer), but that wasn't likely to happen before the Fedora integration. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Mon Jan 3 16:21:17 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 03 Jan 2005 11:21:17 -0500 Subject: SELinux error with yum --installroot In-Reply-To: <1104380829.3448.15.camel@chaucer> References: <1104380829.3448.15.camel@chaucer> Message-ID: <1104769277.16598.127.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-12-29 at 23:27, Bob Kashani wrote: > When I run: > > yum -y --installroot=/testroot groupinstall "Base" > > I get all kinds of errors like this: > > error: %post(libuser-0.52.5-1.i386) scriptlet failed, exit status 255 > error: %post(gnupg-1.2.6-1.i386) scriptlet failed, exit status 255 > > If I turn selinux off there are no errors. Any ideas why this is > happening? > > FC3 fully updated. > > yum-2.1.12-0.fc3 > libselinux-1.19.1-8 > selinux-policy-targeted-1.17.30-2.58 What audit messages do you see in /var/log/messages upon attempting this yum install? -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Mon Jan 3 16:28:58 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 03 Jan 2005 11:28:58 -0500 Subject: SELinux and third party installers In-Reply-To: References: Message-ID: <1104769738.16598.135.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-12-30 at 16:05, Mike Hearn wrote: > I have a couple of questions. The first is that in the FC3 targetted > policy, it appears that ldconfig cannot write to user_home_t directories. > Why is this? It appears to be a restriction with no purpose, and some > programs rely on this to work. In fact I see from the archives that > ldconfig not being able to write or search certain directories has come up > before. Principle of least privilege; only allow a program to do what it requires for its legitimate purpose. If it truly requires such access for legitimate purposes, then you can certainly propose adding those permissions, but be aware of potential ramifications, e.g. mis-use of permissions by the caller, corruption of ldconfig via untrustworthy input, etc. > The second question is what impact SELinux will have on third party > installers. It seems from the nVidia thread that currently if you copy > files onto the system using "cp", this is the wrong way to do it and it > will break peoples SELinux setups. This surely cannot be correct: that'd > break every pretty much every third party installer (eg Loki Setup, > etc) out there! cp only explicitly sets the security context if you pass one of the relevant options to it. Otherwise, it just follows the default behavior of creating the new file based on the domain of the creating process and the type of the parent directory (which falls back to inheriting the type on the parent directory in the absence of an explicit rule). Having cp automatically try to preserve or set context has been discussed previously, but is often not what you want and may often run into permissions problems for unprivileged callers. -- Stephen Smalley National Security Agency From pnasrat at redhat.com Mon Jan 3 16:41:32 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Mon, 3 Jan 2005 11:41:32 -0500 Subject: SELinux error with yum --installroot In-Reply-To: <1104380829.3448.15.camel@chaucer> References: <1104380829.3448.15.camel@chaucer> Message-ID: <20050103164131.GA9027@minimumble.lab.boston.redhat.com> On Wed, Dec 29, 2004 at 08:27:09PM -0800, Bob Kashani wrote: > When I run: > > yum -y --installroot=/testroot groupinstall "Base" Do you have /selinux /proc and /sys mounted in your chroot? mount --bind /proc /testroot/proc/ mount --bind /selinux /testroot/selinux/ mount --bind /sys /testroot/sys/ Paul From linux_4ever at yahoo.com Mon Jan 3 16:52:21 2005 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 3 Jan 2005 08:52:21 -0800 (PST) Subject: Head-banging targets, please In-Reply-To: <1104766965.16598.108.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20050103165222.99088.qmail@web50605.mail.yahoo.com> >However, the kernel audit framework will instead dispatch >the audit messages to an audit daemon if one is present; This is good to know. I am working on the audit daemon and noticed that avc messages usually wind up in syslog *even if* the audit daemon is running. I see "real" audit messages going to /var/log/audit.log and scrolling dbus avc messages in /var/log/messages both at the same time. Not sure how the kernel decides where to send each of these...but they do go to different places on my machine. -Steve Grubb __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com From sds at epoch.ncsc.mil Mon Jan 3 17:01:36 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 03 Jan 2005 12:01:36 -0500 Subject: Head-banging targets, please In-Reply-To: <20050103165222.99088.qmail@web50605.mail.yahoo.com> References: <20050103165222.99088.qmail@web50605.mail.yahoo.com> Message-ID: <1104771696.16598.146.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-01-03 at 11:52, Steve G wrote: > This is good to know. I am working on the audit daemon and noticed that avc > messages usually wind up in syslog *even if* the audit daemon is running. I see > "real" audit messages going to /var/log/audit.log and scrolling dbus avc messages > in /var/log/messages both at the same time. > > Not sure how the kernel decides where to send each of these...but they do go to > different places on my machine. dbusd avc audit messages are generated by libselinux using a callback function provided by dbusd, and dbusd likely is just using syslog() rather than communicating with the audit daemon. The kernel audit framework isn't involved in that path. You'll need to change the callback function provided by dbusd to instead send an AUDIT_USER message with the audit data (or alternatively, have it talk directly to the audit daemon). For the kernel, the relevant code is audit_log_drain() in kernel/audit.c. That checks whether audit_pid has been set, and if so, it sends the audit message to that process; otherwise, it ends up calling printk to send via klogd. -- Stephen Smalley National Security Agency From walters at redhat.com Mon Jan 3 17:49:05 2005 From: walters at redhat.com (Colin Walters) Date: Mon, 03 Jan 2005 12:49:05 -0500 Subject: SELinux and third party installers In-Reply-To: References: Message-ID: <1104774545.3145.24.camel@nexus.verbum.private> On Thu, 2004-12-30 at 21:05 +0000, Mike Hearn wrote: > Hi, > > I have a couple of questions. The first is that in the FC3 targetted > policy, it appears that ldconfig cannot write to user_home_t directories. > Why is this? It appears to be a restriction with no purpose, and some > programs rely on this to work. In fact I see from the archives that > ldconfig not being able to write or search certain directories has come up > before. Can you explain why you have ldconfig writing to a home directory? Are you doing the equivalent of "ldconfig > ~/install.log"? > The second question is what impact SELinux will have on third party > installers. It seems from the nVidia thread that currently if you copy > files onto the system using "cp", this is the wrong way to do it and it > will break peoples SELinux setups. This surely cannot be correct: that'd > break every pretty much every third party installer (eg Loki Setup, > etc) out there! My hope was that by modifying "install", we'd minimize the breakage. At least all of the Automake-generated packages should work. I had a quick look at two other ISV installers; HelixPlayer and Mozilla. It appears neither uses "install", they both do the equivalent of cp. The route we may need to go down is having a relabeling daemon that monitors /usr/lib/, /usr/local/lib, etc. and fixes file contexts. From bobk at ocf.berkeley.edu Tue Jan 4 06:18:05 2005 From: bobk at ocf.berkeley.edu (Bob Kashani) Date: Mon, 03 Jan 2005 22:18:05 -0800 Subject: SELinux error with yum --installroot In-Reply-To: <1104769277.16598.127.camel@moss-spartans.epoch.ncsc.mil> References: <1104380829.3448.15.camel@chaucer> <1104769277.16598.127.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1104819485.4044.3.camel@chaucer> On Mon, 2005-01-03 at 11:21 -0500, Stephen Smalley wrote: > What audit messages do you see in /var/log/messages upon attempting this > yum install? I get no audit messages. I tried running tail -f during the install and it logged nothing. I'm assuming that it's not logging anything since it's installing in a chroot and all the commands that are being executed are in the chroot. Bob -- Bob Kashani http://www.ocf.berkeley.edu/~bobk/garnome From bobk at ocf.berkeley.edu Tue Jan 4 06:38:08 2005 From: bobk at ocf.berkeley.edu (Bob Kashani) Date: Mon, 03 Jan 2005 22:38:08 -0800 Subject: SELinux error with yum --installroot In-Reply-To: <20050103164131.GA9027@minimumble.lab.boston.redhat.com> References: <1104380829.3448.15.camel@chaucer> <20050103164131.GA9027@minimumble.lab.boston.redhat.com> Message-ID: <1104820688.4044.19.camel@chaucer> On Mon, 2005-01-03 at 11:41 -0500, Paul Nasrat wrote: > On Wed, Dec 29, 2004 at 08:27:09PM -0800, Bob Kashani wrote: > > When I run: > > > > yum -y --installroot=/testroot groupinstall "Base" > > Do you have /selinux /proc and /sys mounted in your chroot? > > mount --bind /proc /testroot/proc/ > mount --bind /selinux /testroot/selinux/ > mount --bind /sys /testroot/sys/ Thanks Paul. That was it. I was only mounting /proc...so when I mounted /selinux & /sys almost all of my errors went away. The only two errors that I haven't been able to fix are: /sbin/ldconfig: Can't open configuration file /etc/ld.so.conf: Permission denied /sbin/ldconfig: Can't remove old temporary cache file /etc/ld.so.cache~: Permission denied and Installing: kernel 100 % done 101/111 ls: readlink:: No such file or directory ls: file: No such file or directory ls: expected: No such file or directory Installing: selinux-policy-targeted 100 % done 102/111 coreutils and file are being installed early on so readlink and file should be available by the time the kernel is installed. I have no idea what 'expected' is? Is this just some random output since something failed? Bob -- Bob Kashani http://www.ocf.berkeley.edu/~bobk/garnome From bobk at ocf.berkeley.edu Tue Jan 4 06:57:22 2005 From: bobk at ocf.berkeley.edu (Bob Kashani) Date: Mon, 03 Jan 2005 22:57:22 -0800 Subject: SELinux error with yum --installroot In-Reply-To: <1104819485.4044.3.camel@chaucer> References: <1104380829.3448.15.camel@chaucer> <1104769277.16598.127.camel@moss-spartans.epoch.ncsc.mil> <1104819485.4044.3.camel@chaucer> Message-ID: <1104821842.4044.24.camel@chaucer> On Mon, 2005-01-03 at 22:18 -0800, Bob Kashani wrote: > On Mon, 2005-01-03 at 11:21 -0500, Stephen Smalley wrote: > > What audit messages do you see in /var/log/messages upon attempting this > > yum install? > > I get no audit messages. I tried running tail -f during the install and > it logged nothing. I'm assuming that it's not logging anything since > it's installing in a chroot and all the commands that are being executed > are in the chroot. Sorry, Stephen!!! I was wrong. I actually do get messages. But Paul's suggestion fixed everything with the exception of these messages: ls: readlink:: No such file or directory ls: file: No such file or directory ls: expected: No such file or directory Bob -- Bob Kashani http://www.ocf.berkeley.edu/~bobk/garnome From bobk at ocf.berkeley.edu Tue Jan 4 07:05:51 2005 From: bobk at ocf.berkeley.edu (Bob Kashani) Date: Mon, 03 Jan 2005 23:05:51 -0800 Subject: SELinux error with yum --installroot In-Reply-To: <1104820688.4044.19.camel@chaucer> References: <1104380829.3448.15.camel@chaucer> <20050103164131.GA9027@minimumble.lab.boston.redhat.com> <1104820688.4044.19.camel@chaucer> Message-ID: <1104822351.4044.32.camel@chaucer> On Mon, 2005-01-03 at 22:38 -0800, Bob Kashani wrote: > /sbin/ldconfig: Can't open configuration file /etc/ld.so.conf: > Permission denied > /sbin/ldconfig: Can't remove old temporary cache file /etc/ld.so.cache~: > Permission denied Just to clarify...I was running the wrong script when I got these messages. When I install in /testroot I don't get them. But I do get them when I try to install in my home dir. So why does this happen when I try to install in /home and how can I fix it? > and > > Installing: kernel 100 % done 101/111 > ls: readlink:: No such file or directory > ls: file: No such file or directory > ls: expected: No such file or directory > Installing: selinux-policy-targeted 100 % done 102/111 I still get these messages but I'm not all that concerned about them since I'm not going to be doing anything kernel related in the chroot. But it would be nice to find out what's going on. :) Bob -- Bob Kashani http://www.ocf.berkeley.edu/~bobk/garnome From bobk at ocf.berkeley.edu Tue Jan 4 07:14:58 2005 From: bobk at ocf.berkeley.edu (Bob Kashani) Date: Mon, 03 Jan 2005 23:14:58 -0800 Subject: SELinux error with yum --installroot In-Reply-To: <1104822351.4044.32.camel@chaucer> References: <1104380829.3448.15.camel@chaucer> <20050103164131.GA9027@minimumble.lab.boston.redhat.com> <1104820688.4044.19.camel@chaucer> <1104822351.4044.32.camel@chaucer> Message-ID: <1104822899.4044.39.camel@chaucer> On Mon, 2005-01-03 at 23:05 -0800, Bob Kashani wrote: > On Mon, 2005-01-03 at 22:38 -0800, Bob Kashani wrote: > > /sbin/ldconfig: Can't open configuration file /etc/ld.so.conf: > > Permission denied > > /sbin/ldconfig: Can't remove old temporary cache file /etc/ld.so.cache~: > > Permission denied > > Just to clarify...I was running the wrong script when I got these > messages. When I install in /testroot I don't get them. But I do get > them when I try to install in my home dir. So why does this happen when > I try to install in /home and how can I fix it? Sorry about all the posts. But here is the log message that I get when ldconfig fails in /home (as requested by Stephen). Jan 3 22:44:05 chaucer kernel: audit(1104821045.640:0): avc: denied { search } for pid=4960 exe=/sbin/ldconfig name=bob-chroot dev=hdb1 ino=855792 scontext=root:system_r:ldconfig_t tcontext=user_u:object_r:file_t tclass=dir Jan 3 22:44:05 chaucer kernel: audit(1104821045.641:0): avc: denied { search } for pid=4960 exe=/sbin/ldconfig name=bob-chroot dev=hdb1 ino=855792 scontext=root:system_r:ldconfig_t tcontext=user_u:object_r:file_t tclass=dir Bob -- Bob Kashani http://www.ocf.berkeley.edu/~bobk/garnome From russell at coker.com.au Tue Jan 4 09:38:57 2005 From: russell at coker.com.au (Russell Coker) Date: Tue, 4 Jan 2005 20:38:57 +1100 Subject: syslog-ng non-standard install generating AVC In-Reply-To: References: Message-ID: <200501042038.59908.russell@coker.com.au> On Friday 31 December 2004 03:03, Steve Friedman wrote: > I recently installed FC3 on a machine (we had previously been using FC1), > so this is my first exposure to selinux. Consequently, we are running > the targeted policy in permissive mode. We use syslog-ng (rather than > sysklogd) and have updated the syslog-ng.conf to monitor/log/distribute > log events on a number of other ports beyond the standard syslog > distribution. > > Among other things that we do in syslog-ng include: > - open non-standard UDP/TCP ports > - open non-standard files > - call non-standard routines > > As a complete newbie to selinux, I don't know whether it is > easier/simpler/better/(or even how) to modify the syslog policy or the > attributes of the executables/files/directories that it touches. I would > appreciate some advice and guidance. > > AVC log events: > > Dec 27 04:02:17 gsi10 kernel: audit(1104138137.142:0): avc: denied { > write } for pid=16201 exe=/sbin/syslog-ng name=kmsg dev=proc > ino=-268435446 scontext=system_u:system_r:syslogd_t > tcontext=system_u:object_r:proc_kmsg_t tclass=file Dec 27 04:02:17 gsi10 If you remove klogd.te from the policy source then that access will be allowed. I guess we could just assume that syslog-ng is being used if there is no klogd.te and put the necessary rules for TCP access in the same section. -- 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 Tue Jan 4 13:43:01 2005 From: russell at coker.com.au (Russell Coker) Date: Wed, 5 Jan 2005 00:43:01 +1100 Subject: Head-banging targets, please In-Reply-To: References: <1104445584.3312.100.camel@Eng-Lab-002> Message-ID: <200501050043.03173.russell@coker.com.au> On Friday 31 December 2004 09:43, Mike Hearn wrote: > It also doesn't help that Fedora have patched upstream SElinux extensively > in the process of actually making it usable, for instance they've made a > lot of stuff more automatic. I believe these patches are being folded back > in upstream, but the problem with doing it "upside down" like this is > that the official docs which most people find first do not correspond to > an actual FC3 installation, which is what most people are actually playing > with SELinux on. > > I do not know why these patches weren't developed upstream then pulled > down as they became ready. I guess there are good reasons. The patches are developed by the people who have the time and skills necessary. Some of those people are Red Hat employees (including me). Code that is developed by Red Hat employees generally goes into Red Hat first before going upstream. But that isn't the reason that the documentation lags behind development. The reason is that a lot of work is being done on developing the code and policy, but little time is available for documentation. I think that things are improving in this regard, but there is a lot of documentation work to be done. -- 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 mjc at avtechpulse.com Tue Jan 4 14:59:51 2005 From: mjc at avtechpulse.com (Dr. Michael J. Chudobiak) Date: Tue, 04 Jan 2005 09:59:51 -0500 Subject: postgresql pg_dump won't run In-Reply-To: <41D4CEBB.7070600@redhat.com> References: <41D42072.2090304@avtechpulse.com> <41D4CEBB.7070600@redhat.com> Message-ID: <41DAAF67.2090908@avtechpulse.com> Daniel J Walsh wrote: >> >> Is there a way of running pg_dump and pg_dumpall under selinux, >> without abandoning or rewriting the targeted policy? > > Grab selinux-policy-targeted-1.17.30-2.62 off of I still get errors. I can't run pg_dumpall as root or postgres: [root at server2 log]# rpm -qa selinux-policy-targeted selinux-policy-targeted-1.17.30-2.62 [root at server2 log]# grep pg_dumpall messages Jan 4 09:50:13 server2 kernel: audit(1104850213.722:0): avc: denied { write } for pid=16053 exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 scontext=user_u:system_r:postgresql_t tcontext=root:object_r:tmp_t tclass=sock_file Jan 4 09:50:17 server2 kernel: audit(1104850217.630:0): avc: denied { write } for pid=16057 exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 scontext=user_u:system_r:postgresql_t tcontext=root:object_r:tmp_t tclass=sock_file Jan 4 09:50:29 server2 kernel: audit(1104850229.137:0): avc: denied { write } for pid=16133 exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 scontext=root:system_r:postgresql_t tcontext=root:object_r:tmp_t tclass=sock_file Jan 4 09:50:37 server2 kernel: audit(1104850237.546:0): avc: denied { write } for pid=16166 exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 scontext=user_u:system_r:postgresql_t tcontext=root:object_r:tmp_t tclass=sock_file Any suggestions? - Mike From mike at navi.cx Tue Jan 4 15:21:37 2005 From: mike at navi.cx (Mike Hearn) Date: Tue, 04 Jan 2005 15:21:37 +0000 Subject: SELinux and third party installers References: <1104774545.3145.24.camel@nexus.verbum.private> Message-ID: On Mon, 03 Jan 2005 12:49:05 -0500, Colin Walters wrote: > Can you explain why you have ldconfig writing to a home directory? Are > you doing the equivalent of "ldconfig > ~/install.log"? cp *.so.* ~/.local/lib /sbin/ldconfig -n ~/.local/lib # generate the symlinks That's pseudocode lifted from autopackage, but other scripts and programs do similar stuff. There are other ways to generate the symlinks of course, it's a simple enough operation, but it seems unintuitive that this API would not work anymore for your home directory. > My hope was that by modifying "install", we'd minimize the breakage. At > least all of the Automake-generated packages should work. > > I had a quick look at two other ISV installers; HelixPlayer and Mozilla. > It appears neither uses "install", they both do the equivalent of cp. > > The route we may need to go down is having a relabeling daemon that > monitors /usr/lib/, /usr/local/lib, etc. and fixes file contexts. Hmm, OK. I have to admit I never saw a third party installer that uses "install" so that is probably not enough. A daemon that fixes contexts as files are added feels rather racy. I'm sure I'm missing a lot of context from previous discussions on the matter here, but perhaps the kernel should set the context automatically when a new file is created in certain directories that are marked as "autofix". OK so then we have the problem that the context setting code is all done in userspace with regexs and other un-kernely things. Maybe there needs to be a framework in the kernel where a thread that does a file creation can be suspended and the kernel invokes a user-space program with the file path to figure out what the context should be. Once the process returns with the answer the file can be atomically created/set and the original thread resumes. thanks -mike From sds at epoch.ncsc.mil Tue Jan 4 15:18:42 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Tue, 04 Jan 2005 10:18:42 -0500 Subject: SELinux error with yum --installroot In-Reply-To: <1104822899.4044.39.camel@chaucer> References: <1104380829.3448.15.camel@chaucer> <20050103164131.GA9027@minimumble.lab.boston.redhat.com> <1104820688.4044.19.camel@chaucer> <1104822351.4044.32.camel@chaucer> <1104822899.4044.39.camel@chaucer> Message-ID: <1104851922.20724.8.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-01-04 at 02:14, Bob Kashani wrote: > But here is the log message that I get when ldconfig fails in /home (as > requested by Stephen). > > Jan 3 22:44:05 chaucer kernel: audit(1104821045.640:0): avc: denied > { search } for pid=4960 exe=/sbin/ldconfig name=bob-chroot dev=hdb1 > ino=855792 scontext=root:system_r:ldconfig_t > tcontext=user_u:object_r:file_t tclass=dir > Jan 3 22:44:05 chaucer kernel: audit(1104821045.641:0): avc: denied > { search } for pid=4960 exe=/sbin/ldconfig name=bob-chroot dev=hdb1 > ino=855792 scontext=root:system_r:ldconfig_t > tcontext=user_u:object_r:file_t tclass=dir First, I'd suggest relabeling /home, as there shouldn't be any file_t files there. restorecon -R /home. Was /home inherited from a prior install, or did you run a non-SELinux kernel while creating files there? Second, ldconfig is normally restricted in the set of types it can access; see the "SELinux and third party installers" thread. This can be changed in the policy if necesssary, but understand that there are implications. -- Stephen Smalley National Security Agency From linux_4ever at yahoo.com Tue Jan 4 14:42:06 2005 From: linux_4ever at yahoo.com (Steve G) Date: Tue, 4 Jan 2005 06:42:06 -0800 (PST) Subject: Head-banging targets, please In-Reply-To: <1104771696.16598.146.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20050104144207.86690.qmail@web50606.mail.yahoo.com> >dbusd avc audit messages are generated by libselinux using a callback >function provided by dbusd, and dbusd likely is just using syslog() >rather than communicating with the audit daemon. I traced through the code and created a patch for dbus to use libaudit. It now works fine. But, I noticed the kernel generated messages have more information in them. I guess that's what the audit hook (avc_func_audit) was for. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail From selinux at gmail.com Tue Jan 4 15:24:22 2005 From: selinux at gmail.com (Tom London) Date: Tue, 4 Jan 2005 07:24:22 -0800 Subject: kudzu: needs 'allow kudzu_t self:unix_stream_socket connectto;' ? Message-ID: <4c4ba15305010407247286e8b7@mail.gmail.com> Running strict/enforcing, today's rawhide. Get this avc from the 'new' kudzu: Jan 4 07:16:00 fedora kernel: microcode: CPU0 updated from revision 0x33 to 0x37, date = 06042003 Jan 4 07:16:00 fedora kernel: audit(1104851744.414:0): avc: denied { connectto } for pid=2336 exe=/usr/sbin/kudzupath=@ kudzu_config_socket scontext=system_u:system_r:kudzu_t tcontext=system_u:system_r:kudzu_t tclass=unix_stream_socket Jan 4 07:16:00 fedora kernel: parport_pc: Ignoring new-style parameters in presence of obsolete ones tom [Amazing.... this is the only avc with today's updates!!!!] -- Tom London From sds at epoch.ncsc.mil Tue Jan 4 15:40:59 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Tue, 04 Jan 2005 10:40:59 -0500 Subject: SELinux and third party installers In-Reply-To: References: <1104774545.3145.24.camel@nexus.verbum.private> Message-ID: <1104853259.20724.32.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-01-04 at 10:21, Mike Hearn wrote: > A daemon that fixes contexts as files are added feels rather racy. I'm > sure I'm missing a lot of context from previous discussions on the matter > here, but perhaps the kernel should set the context automatically when a > new file is created in certain directories that are marked as "autofix". > > OK so then we have the problem that the context setting code is all done > in userspace with regexs and other un-kernely things. Maybe there needs to > be a framework in the kernel where a thread that does a file creation can > be suspended and the kernel invokes a user-space program with the file > path to figure out what the context should be. Once the process returns > with the answer the file can be atomically created/set and the original > thread resumes. To clarify, the file_contexts configuration is only really intended to initialize the security contexts for a filesystem at install-time. After that point, you shouldn't be setting file contexts based on pathnames, as they don't convey the desired information about the real security properties of the object. Instead, you want the file to be labeled based on the creating process domain and parent directory type (which is what the kernel does), and allow security-aware applications to further customize the context if necessary for finer-grained labeling (which is already supported via the libselinux API). Pathname-based security considered harmful. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Tue Jan 4 15:47:08 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Tue, 04 Jan 2005 10:47:08 -0500 Subject: Head-banging targets, please In-Reply-To: <20050104144207.86690.qmail@web50606.mail.yahoo.com> References: <20050104144207.86690.qmail@web50606.mail.yahoo.com> Message-ID: <1104853628.20724.39.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-01-04 at 09:42, Steve G wrote: > I traced through the code and created a patch for dbus to use libaudit. It now > works fine. But, I noticed the kernel generated messages have more information in > them. I guess that's what the audit hook (avc_func_audit) was for. I'd suggest coordinating with Colin, as he knows the dbus SELinux code well. Yes, the libselinux AVC constructs a buffer containing the information it knows plus any supplementary information provided by the audit callback (e.g. information known only to the caller, in this case dbusd) and then calls the log callback with the resulting buffer. -- Stephen Smalley National Security Agency From n3npq at nc.rr.com Tue Jan 4 16:06:41 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Tue, 04 Jan 2005 11:06:41 -0500 Subject: SELinux and third party installers In-Reply-To: <1104853259.20724.32.camel@moss-spartans.epoch.ncsc.mil> References: <1104774545.3145.24.camel@nexus.verbum.private> <1104853259.20724.32.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <41DABF11.7050208@nc.rr.com> Stephen Smalley wrote: >On Tue, 2005-01-04 at 10:21, Mike Hearn wrote: > > >>A daemon that fixes contexts as files are added feels rather racy. I'm >>sure I'm missing a lot of context from previous discussions on the matter >>here, but perhaps the kernel should set the context automatically when a >>new file is created in certain directories that are marked as "autofix". >> >>OK so then we have the problem that the context setting code is all done >>in userspace with regexs and other un-kernely things. Maybe there needs to >>be a framework in the kernel where a thread that does a file creation can >>be suspended and the kernel invokes a user-space program with the file >>path to figure out what the context should be. Once the process returns >>with the answer the file can be atomically created/set and the original >>thread resumes. >> >> > >To clarify, the file_contexts configuration is only really intended to >initialize the security contexts for a filesystem at install-time. >After that point, you shouldn't be setting file contexts based on >pathnames, as they don't convey the desired information about the real >security properties of the object. Instead, you want the file to be >labeled based on the creating process domain and parent directory type >(which is what the kernel does), and allow security-aware applications >to further customize the context if necessary for finer-grained labeling >(which is already supported via the libselinux API). Pathname-based >security considered harmful. > > > But inode based automagic labeling is gonna be needed, and the aliasing problems due to path in order to accomplish same can be handled. JMHO, policy still congealing. 73 de Jeff From mike at navi.cx Tue Jan 4 16:25:39 2005 From: mike at navi.cx (Mike Hearn) Date: Tue, 04 Jan 2005 16:25:39 +0000 Subject: SELinux and third party installers References: <1104774545.3145.24.camel@nexus.verbum.private> <1104853259.20724.32.camel@moss-spartans.epoch.ncsc.mil> Message-ID: On Tue, 04 Jan 2005 10:40:59 -0500, Stephen Smalley wrote: > To clarify, the file_contexts configuration is only really intended to > initialize the security contexts for a filesystem at install-time. OK, so what would Colins proposed daemon actually do then? Is kernel-level context propagation enough and if so why does install have to be modified? I'm a little confused now and feel I'm missing some key bit of understanding ... From sds at epoch.ncsc.mil Tue Jan 4 16:25:31 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Tue, 04 Jan 2005 11:25:31 -0500 Subject: SELinux and third party installers In-Reply-To: References: <1104774545.3145.24.camel@nexus.verbum.private> <1104853259.20724.32.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1104855931.20724.46.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-01-04 at 11:25, Mike Hearn wrote: > OK, so what would Colins proposed daemon actually do then? Is kernel-level > context propagation enough and if so why does install have to be modified? > > I'm a little confused now and feel I'm missing some key bit of > understanding ... I'm not in favor of the daemon idea. "install" is akin to "rpm" in the sense of installing a file, so it may make sense to initialize its security context based on pathname at that time, because we have no real runtime knowledge of its security properties and have presumably checked its integrity in some manner prior to installation. But for normal day-to-day file copying, the kernel (or some daemon) has no way of knowing whether: a) the context of the original should be preserved (e.g. making a backup copy of /etc/shadow), b) the context of the target location should be used (e.g. copying a file from /home to /var/www to export it via apache), c) the context should factor in information about the copying process, reflecting its own confidentiality or integrity properties. Hence, any "automagic" technique based on pathname is not suitable. -- Stephen Smalley National Security Agency From selinux at gmail.com Tue Jan 4 16:30:55 2005 From: selinux at gmail.com (Tom London) Date: Tue, 4 Jan 2005 08:30:55 -0800 Subject: cron/init leaking file descriptor? Message-ID: <4c4ba15305010408301480ad2b@mail.gmail.com> Running strict/enforcing, latest Rawhide. Started getting these avcs today. Jan 4 08:21:28 fedora kernel: audit(1104855688.541:0): avc: denied { use } for pid=5131 exe=/usr/sbin/sendmail.sendmail path=/null dev=selinuxfs ino=254 scontext=system_u:system_r:system_mail_t tcontext=system_u:system_r:init_t tclass=fd Jan 4 08:22:21 fedora kernel: audit(1104855741.192:0): avc: denied { use } for pid=5286 exe=/usr/sbin/logrotate path=/null dev=selinuxfs ino=254 scontext=system_u:system_r:logrotate_t tcontext=system_u:system_r:init_t tclass=fd My naive reading of this indicates that someone is leaving a open file descriptor (to /selinux/null ?) tom -- Tom London From dwalsh at redhat.com Tue Jan 4 16:47:21 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 04 Jan 2005 11:47:21 -0500 Subject: postgresql pg_dump won't run In-Reply-To: <41DAAF67.2090908@avtechpulse.com> References: <41D42072.2090304@avtechpulse.com> <41D4CEBB.7070600@redhat.com> <41DAAF67.2090908@avtechpulse.com> Message-ID: <41DAC899.3050606@redhat.com> Dr. Michael J. Chudobiak wrote: > Daniel J Walsh wrote: > >>> >>> Is there a way of running pg_dump and pg_dumpall under selinux, >>> without abandoning or rewriting the targeted policy? >> >> >> Grab selinux-policy-targeted-1.17.30-2.62 off of > > > I still get errors. I can't run pg_dumpall as root or postgres: > > [root at server2 log]# rpm -qa selinux-policy-targeted > selinux-policy-targeted-1.17.30-2.62 > > [root at server2 log]# grep pg_dumpall messages > Jan 4 09:50:13 server2 kernel: audit(1104850213.722:0): avc: denied > { write } for pid=16053 > exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 > scontext=user_u:system_r:postgresql_t > tcontext=root:object_r:tmp_t tclass=sock_file > Jan 4 09:50:17 server2 kernel: audit(1104850217.630:0): avc: denied > { write } for pid=16057 > exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 > scontext=user_u:system_r:postgresql_t > tcontext=root:object_r:tmp_t tclass=sock_file > Jan 4 09:50:29 server2 kernel: audit(1104850229.137:0): avc: denied > { write } for pid=16133 > exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 > scontext=root:system_r:postgresql_t > tcontext=root:object_r:tmp_t tclass=sock_file > Jan 4 09:50:37 server2 kernel: audit(1104850237.546:0): avc: denied > { write } for pid=16166 > exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 > scontext=user_u:system_r:postgresql_t > tcontext=root:object_r:tmp_t tclass=sock_file > > Looks like postgresql is running under the wrong context. Do a ps -eZ | grep postgres It should not be running unconfined_t. > Any suggestions? > > > - Mike From sds at epoch.ncsc.mil Tue Jan 4 16:42:12 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Tue, 04 Jan 2005 11:42:12 -0500 Subject: cron/init leaking file descriptor? In-Reply-To: <4c4ba15305010408301480ad2b@mail.gmail.com> References: <4c4ba15305010408301480ad2b@mail.gmail.com> Message-ID: <1104856932.20724.54.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-01-04 at 11:30, Tom London wrote: > Running strict/enforcing, latest Rawhide. > > Started getting these avcs today. > Jan 4 08:21:28 fedora kernel: audit(1104855688.541:0): avc: denied > { use } for pid=5131 exe=/usr/sbin/sendmail.sendmail path=/null > dev=selinuxfs ino=254 scontext=system_u:system_r:system_mail_t > tcontext=system_u:system_r:init_t tclass=fd > Jan 4 08:22:21 fedora kernel: audit(1104855741.192:0): avc: denied > { use } for pid=5286 exe=/usr/sbin/logrotate path=/null dev=selinuxfs > ino=254 scontext=system_u:system_r:logrotate_t > tcontext=system_u:system_r:init_t tclass=fd > > My naive reading of this indicates that someone is > leaving a open file descriptor (to /selinux/null ?) SELinux re-opens descriptors to /selinux/null if it closes them due to a lack of sufficient permissions by the new context upon a context-changing execve. Getting a denial to a /selinux/null descriptor itself suggests that there was an earlier denial to a real file (e.g. the console) that caused the descriptor to be re-opened to /selinux/null first, and that is now being checked on subsequent execs. From the audit message, the descriptor was created in init_t, so it was likely created when /sbin/init re-exec'd itself into init_t after loading policy. Possibly kernel leaking a descriptor again, e.g. to the initial console or to some file in the initramfs. -- Stephen Smalley National Security Agency From mike at navi.cx Tue Jan 4 17:06:01 2005 From: mike at navi.cx (Mike Hearn) Date: Tue, 04 Jan 2005 17:06:01 +0000 Subject: SELinux and third party installers References: <1104774545.3145.24.camel@nexus.verbum.private> <1104853259.20724.32.camel@moss-spartans.epoch.ncsc.mil> <1104855931.20724.46.camel@moss-spartans.epoch.ncsc.mil> Message-ID: On Tue, 04 Jan 2005 11:25:31 -0500, Stephen Smalley wrote: > I'm not in favor of the daemon idea. "install" is akin to "rpm" in the > sense of installing a file, so it may make sense to initialize its > security context based on pathname at that time, because we have no real > runtime knowledge of its security properties and have presumably checked > its integrity in some manner prior to installation. Alright. It seems to me then that files that are not copied in some SELinux aware matter from an installer (ie new files created in /usr/lib or whatever) should just be subject to normal UNIX security and SELinux should not control them. Supporting SELinux would then become a feature of newer installers, but older software would not break. I have a feeling you can't selectively opt files out of SELinux like that though. From giuseppe.greco at agamura.com Tue Jan 4 17:58:55 2005 From: giuseppe.greco at agamura.com (Giuseppe Greco) Date: Tue, 04 Jan 2005 18:58:55 +0100 Subject: crontab Message-ID: <1104861535.4244.10.camel@gonzo.agamura.com> Hi all, I've the following script under /root/cron: -rwxr-xr-x root root root:object_r:user_home_t checkconn This script just check whether or not pppd is running. If not, checkconn restarts pppd by invoking a script named adsl-start. adsl-start is located under /sbin: -rwxr-xr-x root root system_u:object_r:sbin_t /sbin/adsl-start I've added checkconn to crontab, but it doesn't work due to SELinux... Could you tell me which security context should I set for checkconn? Thanks, j3d. -- ---------------------------------------- Giuseppe Greco ::agamura:: phone: +41 (0)91 604 67 65 mobile: +41 (0)79 602 99 27 email: giuseppe.greco at agamura.com web: www.agamura.com ---------------------------------------- From walters at redhat.com Tue Jan 4 18:01:01 2005 From: walters at redhat.com (Colin Walters) Date: Tue, 04 Jan 2005 13:01:01 -0500 Subject: SELinux and third party installers In-Reply-To: <1104855931.20724.46.camel@moss-spartans.epoch.ncsc.mil> References: <1104774545.3145.24.camel@nexus.verbum.private> <1104853259.20724.32.camel@moss-spartans.epoch.ncsc.mil> <1104855931.20724.46.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1104861661.21468.18.camel@nexus.verbum.private> On Tue, 2005-01-04 at 11:25 -0500, Stephen Smalley wrote: > "install" is akin to "rpm" in the > sense of installing a file, so it may make sense to initialize its > security context based on pathname at that time, because we have no real > runtime knowledge of its security properties and have presumably checked > its integrity in some manner prior to installation. But for normal > day-to-day file copying, the kernel (or some daemon) has no way of > knowing whether: Let's not have this devolve into the general file-copying problem, which consensus seems to be is insoluble. Here we're talking about a very specific case of software installation to well-known directories such as /usr/local/bin and /usr/local/lib. In this case we can presume the caller is highly trusted; anything with write access to those directories has to be. What we want to happen is for the shared libraries to be labeled correctly. > I'm not in favor of the daemon idea. Well, it's not beautiful. But we need some solution. Even if we got changes into Mozilla, Helixplayer, etc. to use a restorecon equivalent tomorrow, all of their existing tarballs would be broken, forever. Actually I just saw in CVS that Dan added the following permission: allow ldconfig_t lib_t:file r_file_perms; So essentially in the targeted policy only the targeted daemons will be unable to read shared libraries not installed by RPM. But for strict policy the above permission doesn't help; we'd need to grant it to everything which reads shlib_t. One other option besides the daemon is to have ldconfig itself do an automatic restorecon. This is less efficient since it will do so for every shared library, but given that ldconfig has always been the magic command you run to make shared libraries work, it does seem somewhat of a logical place to solve this particular problem. Long term we can push 'install' at these ISVs, and maybe around FC5 or FC6 if we have enough success, say that that's the only supported way to install files to the system. From mike at navi.cx Tue Jan 4 19:43:31 2005 From: mike at navi.cx (Mike Hearn) Date: Tue, 04 Jan 2005 19:43:31 +0000 Subject: SELinux and third party installers References: <1104774545.3145.24.camel@nexus.verbum.private> <1104853259.20724.32.camel@moss-spartans.epoch.ncsc.mil> <1104855931.20724.46.camel@moss-spartans.epoch.ncsc.mil> <1104861661.21468.18.camel@nexus.verbum.private> Message-ID: On Tue, 04 Jan 2005 13:01:01 -0500, Colin Walters wrote: > Well, it's not beautiful. But we need some solution. Even if we got > changes into Mozilla, Helixplayer, etc. to use a restorecon equivalent > tomorrow, all of their existing tarballs would be broken, forever. > > Actually I just saw in CVS that Dan added the following permission: > allow ldconfig_t lib_t:file r_file_perms; Would that fix this? Jan 4 19:07:22 littlegreen kernel: audit(1104865642.095:0): avc: denied { read } for pid=25822 exe=/sbin /ldconfig name=libiculx.so.26.2 dev=hdd2 ino=2212143 scontext=root:system_r:ldconfig_t tcontext=root:object_ r:lib_t tclass=file This is actually from doing an "apt-get install mono" on FC3 + apt + SELinux enabled so RPM was involved. The result is that running mono fails: [root at littlegreen tmp]# mono mono: error while loading shared libraries: libmono.so.0: cannot open shared object file: No such file or directory > So essentially in the targeted policy only the targeted daemons will be > unable to read shared libraries not installed by RPM. But for strict > policy the above permission doesn't help; we'd need to grant it to > everything which reads shlib_t. That sounds a lot better :) > One other option besides the daemon is to have ldconfig itself do an > automatic restorecon. This is less efficient since it will do so for > every shared library, but given that ldconfig has always been the magic > command you run to make shared libraries work, it does seem somewhat of > a logical place to solve this particular problem. Yes that would help although unfortunately some (broken?) RPMs don't run ldconfig, on the grounds that /usr/lib is always scanned by the linker regardless of what the cache says. > Long term we can push 'install' at these ISVs, and maybe around FC5 or > FC6 if we have enough success, say that that's the only supported way to > install files to the system. I'm not keen on this line of thinking: it's the type that means many of my Linux-native games and demos no longer run without lots of hacking about. Is the the benefit of restricting 3rd party binaries that don't opt-in worth the cost? I tend to see SELinux as a tool to help enhance the security of programs that are explicitly interested in it, which goes hand in hand with a proper audit to flush out bad practice. Hopefully in future shipping policy with third party programs will become common. But I don't think it's wise to try and apply policy universally shot-gun style, especially not to legacy programs that don't expect it (which today, everything is). thanks -mike From dwalsh at redhat.com Tue Jan 4 19:48:21 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 04 Jan 2005 14:48:21 -0500 Subject: SELinux and third party installers In-Reply-To: References: <1104774545.3145.24.camel@nexus.verbum.private> <1104853259.20724.32.camel@moss-spartans.epoch.ncsc.mil> <1104855931.20724.46.camel@moss-spartans.epoch.ncsc.mil> <1104861661.21468.18.camel@nexus.verbum.private> Message-ID: <41DAF305.2080106@redhat.com> Mike Hearn wrote: >On Tue, 04 Jan 2005 13:01:01 -0500, Colin Walters wrote: > > >>Well, it's not beautiful. But we need some solution. Even if we got >>changes into Mozilla, Helixplayer, etc. to use a restorecon equivalent >>tomorrow, all of their existing tarballs would be broken, forever. >> >>Actually I just saw in CVS that Dan added the following permission: >>allow ldconfig_t lib_t:file r_file_perms; >> >> > >Would that fix this? > > > Yes >Jan 4 19:07:22 littlegreen kernel: audit(1104865642.095:0): avc: denied >{ read } for pid=25822 exe=/sbin /ldconfig name=libiculx.so.26.2 dev=hdd2 >ino=2212143 scontext=root:system_r:ldconfig_t tcontext=root:object_ >r:lib_t tclass=file > >This is actually from doing an "apt-get install mono" on FC3 + apt + >SELinux enabled so RPM was involved. > >The result is that running mono fails: > >[root at littlegreen tmp]# mono >mono: error while loading shared libraries: libmono.so.0: cannot open >shared object file: No such file or directory > > > >>So essentially in the targeted policy only the targeted daemons will be >>unable to read shared libraries not installed by RPM. But for strict >>policy the above permission doesn't help; we'd need to grant it to >>everything which reads shlib_t. >> >> > >That sounds a lot better :) > > > That is what we have with this change. >>One other option besides the daemon is to have ldconfig itself do an >>automatic restorecon. This is less efficient since it will do so for >>every shared library, but given that ldconfig has always been the magic >>command you run to make shared libraries work, it does seem somewhat of >>a logical place to solve this particular problem. >> >> > > > An intersting idea... >Yes that would help although unfortunately some (broken?) RPMs don't run >ldconfig, on the grounds that /usr/lib is always scanned by the linker >regardless of what the cache says. > > > >>Long term we can push 'install' at these ISVs, and maybe around FC5 or >>FC6 if we have enough success, say that that's the only supported way to >>install files to the system. >> >> > >I'm not keen on this line of thinking: it's the type that means >many of my Linux-native games and demos no longer run without lots of >hacking about. Is the the benefit of restricting 3rd party binaries >that don't opt-in worth the cost? > >I tend to see SELinux as a tool to help enhance the security of programs >that are explicitly interested in it, which goes hand in hand with >a proper audit to flush out bad practice. Hopefully in future shipping >policy with third party programs will become common. But I don't think >it's wise to try and apply policy universally shot-gun style, especially >not to legacy programs that don't expect it (which today, everything is). > >thanks -mike > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From walters at redhat.com Tue Jan 4 20:08:01 2005 From: walters at redhat.com (Colin Walters) Date: Tue, 04 Jan 2005 15:08:01 -0500 Subject: SELinux and third party installers In-Reply-To: References: <1104774545.3145.24.camel@nexus.verbum.private> <1104853259.20724.32.camel@moss-spartans.epoch.ncsc.mil> <1104855931.20724.46.camel@moss-spartans.epoch.ncsc.mil> <1104861661.21468.18.camel@nexus.verbum.private> Message-ID: <1104869281.21468.37.camel@nexus.verbum.private> On Tue, 2005-01-04 at 19:43 +0000, Mike Hearn wrote: > Yes that would help although unfortunately some (broken?) RPMs don't run > ldconfig, on the grounds that /usr/lib is always scanned by the linker > regardless of what the cache says. If it's installed via RPM it will be labeled automatically. > > Long term we can push 'install' at these ISVs, and maybe around FC5 or > > FC6 if we have enough success, say that that's the only supported way to > > install files to the system. > > I'm not keen on this line of thinking: it's the type that means > many of my Linux-native games and demos no longer run without lots of > hacking about. Is the the benefit of restricting 3rd party binaries > that don't opt-in worth the cost? I don't expect you to do this hacking; I'd expect the vendor to do it. > I tend to see SELinux as a tool to help enhance the security of programs > that are explicitly interested in it, That's what the targeted policy does essentially. But SELinux is capable of a lot more than that; e.g. giving the ability to define a "webmaster" role with only the access necessary to administer Apache. So it would be good to fix this problem in a generic way so it works in targeted and strict. If we can fix enough of these kinds of speedbumps, I feel that strict could be usable by a much wider range of people. > which goes hand in hand with > a proper audit to flush out bad practice. Hopefully in future shipping > policy with third party programs will become common. Mmm. I think the interesting question isn't where the policy binary bits are stored (in individual .rpm packages versus one big blob in selinux-policy-targeted RPM), but who writes the source. > But I don't think > it's wise to try and apply policy universally shot-gun style, especially > not to legacy programs that don't expect it (which today, everything is). I run strict policy (i.e. universally shot-gun style ;)) on my server, it works quite well. From walters at redhat.com Tue Jan 4 20:21:07 2005 From: walters at redhat.com (Colin Walters) Date: Tue, 04 Jan 2005 15:21:07 -0500 Subject: SELinux and third party installers In-Reply-To: References: <1104774545.3145.24.camel@nexus.verbum.private> Message-ID: <1104870067.21468.46.camel@nexus.verbum.private> On Tue, 2005-01-04 at 15:21 +0000, Mike Hearn wrote: > On Mon, 03 Jan 2005 12:49:05 -0500, Colin Walters wrote: > > Can you explain why you have ldconfig writing to a home directory? Are > > you doing the equivalent of "ldconfig > ~/install.log"? > > cp *.so.* ~/.local/lib > /sbin/ldconfig -n ~/.local/lib # generate the symlinks Hmm. This is actually something that should work in the strict policy, but not in targeted. The reason is that in targeted, we can't easily differentiate between the system and users. So in targeted, we transition to ldconfig_t, but in strict there should be no transition. I can't think of any good ideas on a solution for this one at the moment. Can you file a bugzilla? > Hmm, OK. I have to admit I never saw a third party installer that uses > "install" so that is probably not enough. Depends how you define third party, but I know what you mean. > A daemon that fixes contexts as files are added feels rather racy. It's just as racy as prelink; actually less so because it doesn't actually change file content. > I'm > sure I'm missing a lot of context from previous discussions on the matter > here, but perhaps the kernel should set the context automatically when a > new file is created in certain directories that are marked as "autofix". What specific race conditions do you see that we can't solve in userspace? From mike at navi.cx Tue Jan 4 22:46:52 2005 From: mike at navi.cx (Mike Hearn) Date: Tue, 04 Jan 2005 22:46:52 +0000 Subject: SELinux and third party installers References: <1104774545.3145.24.camel@nexus.verbum.private> <1104870067.21468.46.camel@nexus.verbum.private> Message-ID: On Tue, 04 Jan 2005 15:21:07 -0500, Colin Walters wrote: > I can't think of any good ideas on a solution for this one at the > moment. Can you file a bugzilla? Done: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144190 > Depends how you define third party, but I know what you mean. Well, Loki Setup, Mozilla installer, HelixPlayer, BitRock, Sun JVM scripts etc. Basically installers that are built once and shipped with the app so we can't really modify them later. autopackage kind of sits in the middle. It's mostly separate from the .package file itself and is downloaded automatically on first run. So it's more like source tarballs because they can be modified after the fact by rerunning the autotools chain. > It's just as racy as prelink; actually less so because it doesn't > actually change file content. Prelink is just an optimisation, it can't actually stop apps working. Whereas I think if libraries have the wrong context stuff will break. > What specific race conditions do you see that we can't solve in > userspace? User installs RPM, it runs a program contained in the payload that links to libraries also in the payload in a post-install script, that fails because the libraries haven't been fixed yet. IE there's a gap between the time the library becomes available to apps and the time at which the daemon gets around to fixing it. I may be horribly misunderstanding what you're proposing though ... thanks -mike From mike at navi.cx Tue Jan 4 22:51:40 2005 From: mike at navi.cx (Mike Hearn) Date: Tue, 04 Jan 2005 22:51:40 +0000 Subject: SELinux and third party installers References: <1104774545.3145.24.camel@nexus.verbum.private> <1104853259.20724.32.camel@moss-spartans.epoch.ncsc.mil> <1104855931.20724.46.camel@moss-spartans.epoch.ncsc.mil> <1104861661.21468.18.camel@nexus.verbum.private> <1104869281.21468.37.camel@nexus.verbum.private> Message-ID: On Tue, 04 Jan 2005 15:08:01 -0500, Colin Walters wrote: >> I'm not keen on this line of thinking: it's the type that means >> many of my Linux-native games and demos no longer run without lots of >> hacking about. Is the the benefit of restricting 3rd party binaries >> that don't opt-in worth the cost? > > I don't expect you to do this hacking; I'd expect the vendor to do it. That works when the vendor is around and keen to give you free bugfix updates, but often they're not, eg Loki (or if your support period expired). > > I tend to see SELinux as a tool to help enhance the security of > > programs that are explicitly interested in it, > > That's what the targeted policy does essentially. But SELinux is > capable of a lot more than that; e.g. giving the ability to define a > "webmaster" role with only the access necessary to administer Apache. Yep, that stuff is very cool. It doesn't affect application compatibility though so I don't have to worry about it :) > So it would be good to fix this problem in a generic way so it works in > targeted and strict. If we can fix enough of these kinds of speedbumps, > I feel that strict could be usable by a much wider range of people. Yes that'd be good although my understanding of strict is that programs without policy won't work, ie third party RPMs created before SELinux, games from Loki/GarageGames or whatever. Or at least won't work without a lot of tweaking. > Mmm. I think the interesting question isn't where the policy binary > bits are stored (in individual .rpm packages versus one big blob in > selinux-policy-targeted RPM), but who writes the source. Right, by "shipping policy with third party programs" I meant they write their own policy. I seem to remember arguing about this with Russell before though :) > I run strict policy (i.e. universally shot-gun style ;)) on my server, > it works quite well. Sure but that's a server, which I guess is fairly typical web+mail+ssh+a few other things, right? When you only run a relatively small set of programs all provided by a central source it's a lot easier to do that. I want to see SELinux on desktops, which means working with all the random software the user has :) thanks -mike From walters at redhat.com Tue Jan 4 23:46:27 2005 From: walters at redhat.com (Colin Walters) Date: Tue, 04 Jan 2005 18:46:27 -0500 Subject: SELinux and third party installers In-Reply-To: References: <1104774545.3145.24.camel@nexus.verbum.private> <1104853259.20724.32.camel@moss-spartans.epoch.ncsc.mil> <1104855931.20724.46.camel@moss-spartans.epoch.ncsc.mil> <1104861661.21468.18.camel@nexus.verbum.private> <1104869281.21468.37.camel@nexus.verbum.private> Message-ID: <1104882387.21468.69.camel@nexus.verbum.private> On Tue, 2005-01-04 at 22:51 +0000, Mike Hearn wrote: > On Tue, 04 Jan 2005 15:08:01 -0500, Colin Walters wrote: > >> I'm not keen on this line of thinking: it's the type that means > >> many of my Linux-native games and demos no longer run without lots of > >> hacking about. Is the the benefit of restricting 3rd party binaries > >> that don't opt-in worth the cost? > > > > I don't expect you to do this hacking; I'd expect the vendor to do it. > > That works when the vendor is around and keen to give you free bugfix > updates, but often they're not, eg Loki (or if your support period > expired). Ok. I don't think it would be a big deal to write this off in say two years, but that's just my opinion. > > So it would be good to fix this problem in a generic way so it works in > > targeted and strict. If we can fix enough of these kinds of speedbumps, > > I feel that strict could be usable by a much wider range of people. > > Yes that'd be good although my understanding of strict is that programs > without policy won't work, ie third party RPMs created before SELinux, The labeling happens at install time, so even RPMs created before SELinux will be labeled correctly, assuming that the files contained in the RPM are "typical" files such as shared libraries in /usr/lib or binaries in /usr/bin. > games from Loki/GarageGames or whatever. Or at least won't work without a > lot of tweaking. Well, it depends. System daemons will definitely require policy to run. But regular user binaries run unmodified; e.g. very little in all of GNOME was changed. > > Mmm. I think the interesting question isn't where the policy binary > > bits are stored (in individual .rpm packages versus one big blob in > > selinux-policy-targeted RPM), but who writes the source. > > Right, by "shipping policy with third party programs" I meant they write > their own policy. I seem to remember arguing about this with Russell > before though :) Yes, it's a whole other debate. > > I run strict policy (i.e. universally shot-gun style ;)) on my server, > > it works quite well. > > Sure but that's a server, which I guess is fairly typical web+mail+ssh+a > few other things, right? Right. > When you only run a relatively small set of > programs all provided by a central source it's a lot easier to do that. > I want to see SELinux on desktops, which means working with all the random > software the user has :) So do I, and I think we're actually a lot closer to that than some of the discussions here might make one think. Strict policy should work very well today on something like a kiosk, where the set of software is fixed in advance, tested, and users are tightly restricted in what they can do. A typical knowledge worker desktop should for the most part just work. But a developer workstation (what most of us on this list use) is far more difficult. Particularly for Fedora developers, because we're changing the base OS itself. Besides people doing various things with Apache, this shlib_t issue is probably the biggest problem we've seen, and I think we have a mostly acceptable workaround for now with Dan's latest policy. From bobk at ocf.berkeley.edu Wed Jan 5 07:21:24 2005 From: bobk at ocf.berkeley.edu (Bob Kashani) Date: Tue, 04 Jan 2005 23:21:24 -0800 Subject: SELinux error with yum --installroot In-Reply-To: <1104851922.20724.8.camel@moss-spartans.epoch.ncsc.mil> References: <1104380829.3448.15.camel@chaucer> <20050103164131.GA9027@minimumble.lab.boston.redhat.com> <1104820688.4044.19.camel@chaucer> <1104822351.4044.32.camel@chaucer> <1104822899.4044.39.camel@chaucer> <1104851922.20724.8.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1104909684.3391.39.camel@chaucer> On Tue, 2005-01-04 at 10:18 -0500, Stephen Smalley wrote: > On Tue, 2005-01-04 at 02:14, Bob Kashani wrote: > > But here is the log message that I get when ldconfig fails in /home (as > > requested by Stephen). > > > > Jan 3 22:44:05 chaucer kernel: audit(1104821045.640:0): avc: denied > > { search } for pid=4960 exe=/sbin/ldconfig name=bob-chroot dev=hdb1 > > ino=855792 scontext=root:system_r:ldconfig_t > > tcontext=user_u:object_r:file_t tclass=dir > > Jan 3 22:44:05 chaucer kernel: audit(1104821045.641:0): avc: denied > > { search } for pid=4960 exe=/sbin/ldconfig name=bob-chroot dev=hdb1 > > ino=855792 scontext=root:system_r:ldconfig_t > > tcontext=user_u:object_r:file_t tclass=dir > > First, I'd suggest relabeling /home, as there shouldn't be any file_t > files there. restorecon -R /home. Was /home inherited from a prior > install, or did you run a non-SELinux kernel while creating files there? Well, /home/gnome (my test user account) is actually a symbolic link to /mnt/hdb1/home/gnome (this way I can log into the same account from rawhide and FC3 without having to copy files around). /home is on hda3 and /home/gnome is on hdb1. hdb1 has rawhide installed on it and I had turned off selinux a long time ago since it was giving me problems. But all of the files in /home/gnome were created under FC3 w/ selinux. I booted into rawhide (hdb1) and enabled selinux and ran 'restorecon - R /'. Now when I'm in FC3 file_t is gone. :) > Second, ldconfig is normally restricted in the set of types it can > access; see the "SELinux and third party installers" thread. This can > be changed in the policy if necesssary, but understand that there are > implications. I read the thread and I seem to understand the technical reason behind why ldconfig is restricted in the way that it is (the security side of the issue). But is seems a little harsh from a usability point of view since for example, you can no longer run ldconfig in a chroot in your home dir. I like fine grained security but isn't the whole idea behind policy-targeted to enable security without restricting usability too much? I would understand not allowing ldconfig to execute in /home with policy-strict but shouldn't policy-targeted allow you to do this regardless of the potential security issues? Do the security concerns in this case outweigh the usability issues? Bob -- Bob Kashani http://www.ocf.berkeley.edu/~bobk/garnome From lang at ms.chinmin.edu.tw Wed Jan 5 09:09:45 2005 From: lang at ms.chinmin.edu.tw (Greg Matheson) Date: Wed, 5 Jan 2005 17:09:45 +0800 Subject: no selinux tab with non-GUI system-config-securitylevel Message-ID: <20050105090945.GA28629@ms.chinmin.edu.tw> The FAQ says: By default, SELinux enforcement for Apache HTTP is enabled. To verify this, run system-config-securitylevel, and view the SELinux tab. But I don't see any SELinux stuff with my non-GUI install of FC3. Is this right? -- Greg Matheson, Taiwan From dwalsh at redhat.com Wed Jan 5 13:07:59 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 05 Jan 2005 08:07:59 -0500 Subject: no selinux tab with non-GUI system-config-securitylevel In-Reply-To: <20050105090945.GA28629@ms.chinmin.edu.tw> References: <20050105090945.GA28629@ms.chinmin.edu.tw> Message-ID: <41DBE6AF.6070907@redhat.com> Greg Matheson wrote: >The FAQ says: > > By default, SELinux enforcement for Apache HTTP is > enabled. To verify this, run system-config-securitylevel, > and view the SELinux tab. > >But I don't see any SELinux stuff with my non-GUI install of FC3. >Is this right? > > > sestatus will also show this data at the command line From dwalsh at redhat.com Wed Jan 5 13:10:23 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 05 Jan 2005 08:10:23 -0500 Subject: SELinux error with yum --installroot In-Reply-To: <1104909684.3391.39.camel@chaucer> References: <1104380829.3448.15.camel@chaucer> <20050103164131.GA9027@minimumble.lab.boston.redhat.com> <1104820688.4044.19.camel@chaucer> <1104822351.4044.32.camel@chaucer> <1104822899.4044.39.camel@chaucer> <1104851922.20724.8.camel@moss-spartans.epoch.ncsc.mil> <1104909684.3391.39.camel@chaucer> Message-ID: <41DBE73F.6040902@redhat.com> Bob Kashani wrote: >On Tue, 2005-01-04 at 10:18 -0500, Stephen Smalley wrote: > > >>On Tue, 2005-01-04 at 02:14, Bob Kashani wrote: >> >> >>>But here is the log message that I get when ldconfig fails in /home (as >>>requested by Stephen). >>> >>>Jan 3 22:44:05 chaucer kernel: audit(1104821045.640:0): avc: denied >>>{ search } for pid=4960 exe=/sbin/ldconfig name=bob-chroot dev=hdb1 >>>ino=855792 scontext=root:system_r:ldconfig_t >>>tcontext=user_u:object_r:file_t tclass=dir >>>Jan 3 22:44:05 chaucer kernel: audit(1104821045.641:0): avc: denied >>>{ search } for pid=4960 exe=/sbin/ldconfig name=bob-chroot dev=hdb1 >>>ino=855792 scontext=root:system_r:ldconfig_t >>>tcontext=user_u:object_r:file_t tclass=dir >>> >>> >>First, I'd suggest relabeling /home, as there shouldn't be any file_t >>files there. restorecon -R /home. Was /home inherited from a prior >>install, or did you run a non-SELinux kernel while creating files there? >> >> > >Well, /home/gnome (my test user account) is actually a symbolic link >to /mnt/hdb1/home/gnome (this way I can log into the same account from >rawhide and FC3 without having to copy files around). /home is on hda3 >and /home/gnome is on hdb1. hdb1 has rawhide installed on it and I had >turned off selinux a long time ago since it was giving me problems. But >all of the files in /home/gnome were created under FC3 w/ selinux. I >booted into rawhide (hdb1) and enabled selinux and ran 'restorecon - >R /'. Now when I'm in FC3 file_t is gone. :) > > > >>Second, ldconfig is normally restricted in the set of types it can >>access; see the "SELinux and third party installers" thread. This can >>be changed in the policy if necesssary, but understand that there are >>implications. >> >> > >I read the thread and I seem to understand the technical reason behind >why ldconfig is restricted in the way that it is (the security side of >the issue). But is seems a little harsh from a usability point of view >since for example, you can no longer run ldconfig in a chroot in your >home dir. I like fine grained security but isn't the whole idea behind >policy-targeted to enable security without restricting usability too >much? I would understand not allowing ldconfig to execute in /home with >policy-strict but shouldn't policy-targeted allow you to do this >regardless of the potential security issues? Do the security concerns in >this case outweigh the usability issues? > >Bob > > > What AVC messages are you seeing. We can and probably should loosen up ldconfig policy for targeted. Dan From kwade at redhat.com Wed Jan 5 14:01:55 2005 From: kwade at redhat.com (Karsten Wade) Date: Wed, 05 Jan 2005 06:01:55 -0800 Subject: postgresql pg_dump won't run In-Reply-To: <41DAC899.3050606@redhat.com> References: <41D42072.2090304@avtechpulse.com> <41D4CEBB.7070600@redhat.com> <41DAAF67.2090908@avtechpulse.com> <41DAC899.3050606@redhat.com> Message-ID: <1104933716.9831.45.camel@erato.phig.org> On Tue, 2005-01-04 at 11:47 -0500, Daniel J Walsh wrote: > Dr. Michael J. Chudobiak wrote: > > > [root at server2 log]# grep pg_dumpall messages > > Jan 4 09:50:13 server2 kernel: audit(1104850213.722:0): avc: denied > > { write } for pid=16053 > > exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 > > scontext=user_u:system_r:postgresql_t > > tcontext=root:object_r:tmp_t tclass=sock_file > > Jan 4 09:50:17 server2 kernel: audit(1104850217.630:0): avc: denied > > { write } for pid=16057 > > exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 > > scontext=user_u:system_r:postgresql_t > > tcontext=root:object_r:tmp_t tclass=sock_file > > Jan 4 09:50:29 server2 kernel: audit(1104850229.137:0): avc: denied > > { write } for pid=16133 > > exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 > > scontext=root:system_r:postgresql_t > > tcontext=root:object_r:tmp_t tclass=sock_file > > Jan 4 09:50:37 server2 kernel: audit(1104850237.546:0): avc: denied > > { write } for pid=16166 > > exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 > > scontext=user_u:system_r:postgresql_t > > tcontext=root:object_r:tmp_t tclass=sock_file > > > > > Looks like postgresql is running under the wrong context. > > Do a ps -eZ | grep postgres > > It should not be running unconfined_t. I don't see unconfine_t in those log messages, just lots of postgresql_t as the source context. Can you tell me what you are seeing? thx - Karsten -- Karsten Wade, RHCE, Sr. Tech Writer a lemon is just a melon in disguise http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 From dwalsh at redhat.com Wed Jan 5 14:11:38 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 05 Jan 2005 09:11:38 -0500 Subject: postgresql pg_dump won't run In-Reply-To: <1104933716.9831.45.camel@erato.phig.org> References: <41D42072.2090304@avtechpulse.com> <41D4CEBB.7070600@redhat.com> <41DAAF67.2090908@avtechpulse.com> <41DAC899.3050606@redhat.com> <1104933716.9831.45.camel@erato.phig.org> Message-ID: <41DBF59A.2030806@redhat.com> Karsten Wade wrote: >On Tue, 2005-01-04 at 11:47 -0500, Daniel J Walsh wrote: > > >>Dr. Michael J. Chudobiak wrote: >> >> >> >>>[root at server2 log]# grep pg_dumpall messages >>>Jan 4 09:50:13 server2 kernel: audit(1104850213.722:0): avc: denied >>>{ write } for pid=16053 >>>exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 >>>scontext=user_u:system_r:postgresql_t >>>tcontext=root:object_r:tmp_t tclass=sock_file >>>Jan 4 09:50:17 server2 kernel: audit(1104850217.630:0): avc: denied >>>{ write } for pid=16057 >>>exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 >>>scontext=user_u:system_r:postgresql_t >>>tcontext=root:object_r:tmp_t tclass=sock_file >>>Jan 4 09:50:29 server2 kernel: audit(1104850229.137:0): avc: denied >>>{ write } for pid=16133 >>>exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 >>>scontext=root:system_r:postgresql_t >>>tcontext=root:object_r:tmp_t tclass=sock_file >>>Jan 4 09:50:37 server2 kernel: audit(1104850237.546:0): avc: denied >>>{ write } for pid=16166 >>>exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 >>>scontext=user_u:system_r:postgresql_t >>>tcontext=root:object_r:tmp_t tclass=sock_file >>> >>> >>> >>> >>Looks like postgresql is running under the wrong context. >> >>Do a ps -eZ | grep postgres >> >>It should not be running unconfined_t. >> >> > >I don't see unconfine_t in those log messages, just lots of postgresql_t >as the source context. Can you tell me what you are seeing? > >thx - Karsten > > I see that the sock_file was created under tmp_t which indicates a transition did not happen. Postgresql should have created the sock file under postgresql_tmp_t, so I surmized that the postgres daemon is running under unconfined_t. Dan From mike at navi.cx Wed Jan 5 15:12:51 2005 From: mike at navi.cx (Mike Hearn) Date: Wed, 05 Jan 2005 15:12:51 +0000 Subject: SELinux and third party installers References: <1104774545.3145.24.camel@nexus.verbum.private> <1104853259.20724.32.camel@moss-spartans.epoch.ncsc.mil> <1104855931.20724.46.camel@moss-spartans.epoch.ncsc.mil> <1104861661.21468.18.camel@nexus.verbum.private> <1104869281.21468.37.camel@nexus.verbum.private> <1104882387.21468.69.camel@nexus.verbum.private> Message-ID: On Tue, 04 Jan 2005 18:46:27 -0500, Colin Walters wrote: > Ok. I don't think it would be a big deal to write this off in say two > years, but that's just my opinion. It's a fair one. I'm coming from the perspective of competing with Windows, but there's a whole debate here you could have about the cost vs benefits of leaving people behind when introducing new technologies. Arguably we don't care that much about upgrade sales because it's free software :) so our value systems can be different. But should they be? I don't know. > The labeling happens at install time, so even RPMs created before > SELinux will be labeled correctly, assuming that the files contained in > the RPM are "typical" files such as shared libraries in /usr/lib or > binaries in /usr/bin. Hm, OK. I should investigate why the Mono RPMs I got via apt the other day didn't work correctly in enforcing/targetted. That sounds like a bug. > Well, it depends. System daemons will definitely require policy to run. > But regular user binaries run unmodified; e.g. very little in all of > GNOME was changed. OK, that sounds good. > > When you only run a relatively small set of programs all provided by a > > central source it's a lot easier to do that. I want to see SELinux on > > desktops, which means working with all the random software the user > > has :) > > So do I, and I think we're actually a lot closer to that than some of > the discussions here might make one think. > > Strict policy should work very well today on something like a kiosk, > where the set of software is fixed in advance, tested, and users are > tightly restricted in what they can do. A typical knowledge worker > desktop should for the most part just work. But a developer workstation > (what most of us on this list use) is far more difficult. Particularly > for Fedora developers, because we're changing the base OS itself. > > Besides people doing various things with Apache, this shlib_t issue is > probably the biggest problem we've seen, and I think we have a mostly > acceptable workaround for now with Dan's latest policy. Long term I certainly hope strict can be the default but it's going to be a lot of work, and it's going to raise interesting and difficult questions about backwards compatibility. That can wait for another day though. The ldconfig issue is fixed in CVS, third party installers are being looked at again and that means I'm happy :) thanks -mike From bagica at bitdefender.com Wed Jan 5 15:03:44 2005 From: bagica at bitdefender.com (Bogdan Agica) Date: Wed, 05 Jan 2005 17:03:44 +0200 Subject: /etc/init.d/ script Message-ID: <1104937424.10567.87.camel@bagica.dsd.ro> Hi again, everybody. I'm making quite a progress in developing the policy source for BitDefender, and I want to thank the list again for the tips given so far. I'm still running into this weird problem with the /etc/init.d/bd script. This, in essence, is a very common start/stop script, but with some functions like stats and info. These functions are trying to read data from directories labeled bitdefender_etc_t and bitdefender_lib_t. The problem is: should I want the script to do what it's supposed to do I have to either: 1. Relabel the script from initrd_exec_t to something else, in which case I'll run into problems starting / stopping the programs. 2. Give read access to initrd_t in bitdefender_etc_t and _lib_t, which I think is a stupid workaround, providing read access to all scripts in /etc/init.d to this dir. I know, the best idea would to leave the /etc/init.d/ script for starting and stopping the program, and to provide all the other functionality via other means, but that is not feasible in the short term. Is there any way to "inherit" a type (C++like inheritance), e.g. to create a type (say bitdefender_initrc_exec_t), which inherits all the attributes of it's successor, but adds new functionality? (Would be a nice idea if there isn't yet) TIA, -- Bogdan Agica BitDefender Internal Testing Engineer ------------------------------------- SOFTWIN Data Security Division ------------------------------------- email: bagica at bitdefender.com phone: +(4021) 233 18 52; 233 07 80 fax: (+4021) 233.07.63 Bucharest, ROMANIA http://www.bitdefender.com http://www.softwin.ro ------------------------------------- secure your every bit ------------------------------------- -------------- 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: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: BitDefender.txt URL: From bobk at ocf.berkeley.edu Wed Jan 5 20:07:06 2005 From: bobk at ocf.berkeley.edu (Bob Kashani) Date: Wed, 05 Jan 2005 12:07:06 -0800 Subject: SELinux error with yum --installroot In-Reply-To: <41DBE73F.6040902@redhat.com> References: <1104380829.3448.15.camel@chaucer> <20050103164131.GA9027@minimumble.lab.boston.redhat.com> <1104820688.4044.19.camel@chaucer> <1104822351.4044.32.camel@chaucer> <1104822899.4044.39.camel@chaucer> <1104851922.20724.8.camel@moss-spartans.epoch.ncsc.mil> <1104909684.3391.39.camel@chaucer> <41DBE73F.6040902@redhat.com> Message-ID: <1104955626.4174.10.camel@chaucer> On Wed, 2005-01-05 at 08:10 -0500, Daniel J Walsh wrote: > >I read the thread and I seem to understand the technical reason behind > >why ldconfig is restricted in the way that it is (the security side of > >the issue). But is seems a little harsh from a usability point of view > >since for example, you can no longer run ldconfig in a chroot in your > >home dir. I like fine grained security but isn't the whole idea behind > >policy-targeted to enable security without restricting usability too > >much? I would understand not allowing ldconfig to execute in /home with > >policy-strict but shouldn't policy-targeted allow you to do this > >regardless of the potential security issues? Do the security concerns in > >this case outweigh the usability issues? > > > >Bob > > > > > > > What AVC messages are you seeing. We can and probably should loosen up > ldconfig policy for targeted. > > Dan Here is the AVC message I'm getting: Jan 5 11:56:39 chaucer kernel: audit(1104954999.233:0): avc: denied { search } for pid=4605 exe=/sbin/ldconfig name=g-chroot dev=hdb1 ino=855792 scontext=root:system_r:ldconfig_t tcontext=system_u:object_r:user_home_t tclass=dir Bob -- Bob Kashani http://www.ocf.berkeley.edu/~bobk/garnome From jordan.morgan at usg.edu Wed Jan 5 23:48:16 2005 From: jordan.morgan at usg.edu (Jordan Morgan) Date: Wed, 05 Jan 2005 18:48:16 -0500 Subject: newbie question Message-ID: <41DC7CBF.3000705@usg.edu> Hi, I'm currently running FC2 instead of FC3. Tried to enable SELinux by running in /root yum install policy policycoreutils as instructed by the Fedora 2 SELinux FAQ page. However it failed. I got error message of Package not found and all. Checked out another FAQ page and they said something about modifying the yum.conf file to include the ftp site managed by Dan Walsh, and then running the command of yum install checkpolicy policy policycoreutils pam passwd vixie-cron this time, pam, passwd, and vixie-cron were installed (even though I don't know what they are and what they do), but got more error messages saying the policy headers need some file(not included). I tried to go through your archive and look for answers but got no luck so far. I thought I might give this a try first while reading more of the threads. I apologize in advance if this is a repeated question. On the redhat site, they said SELinux is not functional in FC2 and suggested user to install FC3. So I guess my another question is: Should I seek help in installing SELinux in the current FC2 or should I simply install FC3 instead? Your help on this is highly appreciated. Thanks! Jordan From russell at coker.com.au Thu Jan 6 10:31:54 2005 From: russell at coker.com.au (Russell Coker) Date: Thu, 6 Jan 2005 21:31:54 +1100 Subject: /etc/init.d/ script In-Reply-To: <1104937424.10567.87.camel@bagica.dsd.ro> References: <1104937424.10567.87.camel@bagica.dsd.ro> Message-ID: <200501062131.57515.russell@coker.com.au> On Thursday 06 January 2005 02:03, Bogdan Agica wrote: > 1. Relabel the script from initrd_exec_t to something else, > in which case I'll run into problems starting / stopping the programs. You could have the init.d script call something else to do the work. So you split the script into a worker script in /usr/sbin and a start script in the init.d directory that just calls the worker. > 2. Give read access to initrd_t in bitdefender_etc_t and _lib_t, > which I think is a stupid workaround, providing read access to all > scripts in /etc/init.d to this dir. That's the usual approach. Not ideal but not too bad either. What is the bitdefender data? initrc_t is a very powerful domain that can break your system in many ways. Protecting files from it provides little benefit with the way things work now. > I know, the best idea would to leave the /etc/init.d/ script for > starting and stopping the program, and to provide all the other > functionality via other means, but that is not feasible in the short > term. It's not difficult to split a shell script into two shell scripts. > Is there any way to "inherit" a type (C++like inheritance), e.g. to > create a type (say bitdefender_initrc_exec_t), which inherits all the > attributes of it's successor, but adds new functionality? (Would be a > nice idea if there isn't yet) No. -- 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 Jan 6 12:50:52 2005 From: russell at coker.com.au (Russell Coker) Date: Thu, 6 Jan 2005 23:50:52 +1100 Subject: crontab In-Reply-To: <1104861535.4244.10.camel@gonzo.agamura.com> References: <1104861535.4244.10.camel@gonzo.agamura.com> Message-ID: <200501062350.56085.russell@coker.com.au> On Wednesday 05 January 2005 04:58, Giuseppe Greco wrote: > I've the following script under /root/cron: > > -rwxr-xr-x root root root:object_r:user_home_t checkconn If you have /root labeled as user_home_dir_t (as I guess from the above) then you have just lost most of the benefits of strict policy. If you label /root as sysadm_home_dir_t and /root/.* as sysadm_home_t then it should work. -- 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 epoch.ncsc.mil Thu Jan 6 13:13:20 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 06 Jan 2005 08:13:20 -0500 Subject: SELinux error with yum --installroot In-Reply-To: <1104909684.3391.39.camel@chaucer> References: <1104380829.3448.15.camel@chaucer> <20050103164131.GA9027@minimumble.lab.boston.redhat.com> <1104820688.4044.19.camel@chaucer> <1104822351.4044.32.camel@chaucer> <1104822899.4044.39.camel@chaucer> <1104851922.20724.8.camel@moss-spartans.epoch.ncsc.mil> <1104909684.3391.39.camel@chaucer> Message-ID: <1105017200.24438.1.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-01-05 at 02:21, Bob Kashani wrote: > I read the thread and I seem to understand the technical reason behind > why ldconfig is restricted in the way that it is (the security side of > the issue). But is seems a little harsh from a usability point of view > since for example, you can no longer run ldconfig in a chroot in your > home dir. I like fine grained security but isn't the whole idea behind > policy-targeted to enable security without restricting usability too > much? I would understand not allowing ldconfig to execute in /home with > policy-strict but shouldn't policy-targeted allow you to do this > regardless of the potential security issues? Do the security concerns in > this case outweigh the usability issues? I'm not clear on why ldconfig runs in its own domain at all under targeted policy (vs. unconfined_t). It used to just run unconfined_t in older versions of the targeted policy. Is it an attempt to preserve the type on /etc/ld.so.cache via the file type transition rules? -- Stephen Smalley National Security Agency From russell at coker.com.au Thu Jan 6 13:36:17 2005 From: russell at coker.com.au (Russell Coker) Date: Fri, 7 Jan 2005 00:36:17 +1100 Subject: newbie question In-Reply-To: <41DC7CBF.3000705@usg.edu> References: <41DC7CBF.3000705@usg.edu> Message-ID: <200501070036.21467.russell@coker.com.au> On Thursday 06 January 2005 10:48, Jordan Morgan wrote: > On the redhat site, they said SELinux is not functional in FC2 and > suggested user to install FC3. So I guess my another question is: Should > I seek help in installing SELinux in the current FC2 or should I simply > install FC3 instead? Just install FC3. Getting FC2 in a usable state with the updates will come close to making it FC3 anyway. Might as well just install FC3, it's easier and gives a better result. -- 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 jordan.morgan at usg.edu Thu Jan 6 14:27:35 2005 From: jordan.morgan at usg.edu (Jordan Morgan) Date: Thu, 06 Jan 2005 09:27:35 -0500 Subject: newbie question In-Reply-To: <200501070036.21467.russell@coker.com.au> References: <41DC7CBF.3000705@usg.edu> <200501070036.21467.russell@coker.com.au> Message-ID: <41DD4AD7.5020306@usg.edu> Thanks Russell! Then that's what I'll do! Russell Coker wrote: >On Thursday 06 January 2005 10:48, Jordan Morgan >wrote: > > >>On the redhat site, they said SELinux is not functional in FC2 and >>suggested user to install FC3. So I guess my another question is: Should >>I seek help in installing SELinux in the current FC2 or should I simply >>install FC3 instead? >> >> > >Just install FC3. Getting FC2 in a usable state with the updates will come >close to making it FC3 anyway. Might as well just install FC3, it's easier >and gives a better result. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From russell at coker.com.au Thu Jan 6 15:09:46 2005 From: russell at coker.com.au (Russell Coker) Date: Fri, 7 Jan 2005 02:09:46 +1100 Subject: Problems with sudo In-Reply-To: <1103302082.10336.132.camel@bagica.dsd.ro> References: <1103282264.10336.85.camel@bagica.dsd.ro> <41C2D28C.7040208@mindspring.com> <1103302082.10336.132.camel@bagica.dsd.ro> Message-ID: <200501070209.49906.russell@coker.com.au> On Saturday 18 December 2004 03:48, Bogdan Agica wrote: > When do you think runuser goes mainstream? Because, as far as I have > checked, it's only in FC3 with selinux (not in Debian, and not in > Gentoo). Debian has a program called start-stop-daemon which is similar to runuser but has some extra features. Gentoo will get something equivalent too (they have to). -- 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 Thu Jan 6 15:16:01 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 06 Jan 2005 10:16:01 -0500 Subject: SELinux error with yum --installroot In-Reply-To: <1105017200.24438.1.camel@moss-spartans.epoch.ncsc.mil> References: <1104380829.3448.15.camel@chaucer> <20050103164131.GA9027@minimumble.lab.boston.redhat.com> <1104820688.4044.19.camel@chaucer> <1104822351.4044.32.camel@chaucer> <1104822899.4044.39.camel@chaucer> <1104851922.20724.8.camel@moss-spartans.epoch.ncsc.mil> <1104909684.3391.39.camel@chaucer> <1105017200.24438.1.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <41DD5631.5060308@redhat.com> Stephen Smalley wrote: >On Wed, 2005-01-05 at 02:21, Bob Kashani wrote: > > >>I read the thread and I seem to understand the technical reason behind >>why ldconfig is restricted in the way that it is (the security side of >>the issue). But is seems a little harsh from a usability point of view >>since for example, you can no longer run ldconfig in a chroot in your >>home dir. I like fine grained security but isn't the whole idea behind >>policy-targeted to enable security without restricting usability too >>much? I would understand not allowing ldconfig to execute in /home with >>policy-strict but shouldn't policy-targeted allow you to do this >>regardless of the potential security issues? Do the security concerns in >>this case outweigh the usability issues? >> >> > >I'm not clear on why ldconfig runs in its own domain at all under >targeted policy (vs. unconfined_t). It used to just run unconfined_t in >older versions of the targeted policy. Is it an attempt to preserve the >type on /etc/ld.so.cache via the file type transition rules? > > > Yes. From sds at epoch.ncsc.mil Thu Jan 6 15:14:44 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 06 Jan 2005 10:14:44 -0500 Subject: SELinux error with yum --installroot In-Reply-To: <41DD5631.5060308@redhat.com> References: <1104380829.3448.15.camel@chaucer> <20050103164131.GA9027@minimumble.lab.boston.redhat.com> <1104820688.4044.19.camel@chaucer> <1104822351.4044.32.camel@chaucer> <1104822899.4044.39.camel@chaucer> <1104851922.20724.8.camel@moss-spartans.epoch.ncsc.mil> <1104909684.3391.39.camel@chaucer> <1105017200.24438.1.camel@moss-spartans.epoch.ncsc.mil> <41DD5631.5060308@redhat.com> Message-ID: <1105024484.24438.83.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-01-06 at 10:16, Daniel J Walsh wrote: > Stephen Smalley wrote: > >I'm not clear on why ldconfig runs in its own domain at all under > >targeted policy (vs. unconfined_t). It used to just run unconfined_t in > >older versions of the targeted policy. Is it an attempt to preserve the > >type on /etc/ld.so.cache via the file type transition rules? > > > > > > > Yes. Ok, so why not just add an unconfined_domain(ldconfig_t) to unconfined.te in the targeted policy, so that ldconfig will still have the file type transition rule but will be unrestricted there. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Thu Jan 6 20:31:28 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 06 Jan 2005 15:31:28 -0500 Subject: SELinux error with yum --installroot In-Reply-To: <1105024484.24438.83.camel@moss-spartans.epoch.ncsc.mil> References: <1104380829.3448.15.camel@chaucer> <20050103164131.GA9027@minimumble.lab.boston.redhat.com> <1104820688.4044.19.camel@chaucer> <1104822351.4044.32.camel@chaucer> <1104822899.4044.39.camel@chaucer> <1104851922.20724.8.camel@moss-spartans.epoch.ncsc.mil> <1104909684.3391.39.camel@chaucer> <1105017200.24438.1.camel@moss-spartans.epoch.ncsc.mil> <41DD5631.5060308@redhat.com> <1105024484.24438.83.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <41DDA020.9000504@redhat.com> Stephen Smalley wrote: >On Thu, 2005-01-06 at 10:16, Daniel J Walsh wrote: > > >>Stephen Smalley wrote: >> >> >>>I'm not clear on why ldconfig runs in its own domain at all under >>>targeted policy (vs. unconfined_t). It used to just run unconfined_t in >>>older versions of the targeted policy. Is it an attempt to preserve the >>>type on /etc/ld.so.cache via the file type transition rules? >>> >>> >>> >>> >>> >>Yes. >> >> > >Ok, so why not just add an unconfined_domain(ldconfig_t) to >unconfined.te in the targeted policy, so that ldconfig will still have >the file type transition rule but will be unrestricted there. > > > I have done that. From bagica at bitdefender.com Fri Jan 7 09:30:12 2005 From: bagica at bitdefender.com (Bogdan Agica) Date: Fri, 07 Jan 2005 11:30:12 +0200 Subject: /etc/init.d/ script In-Reply-To: <200501062131.57515.russell@coker.com.au> References: <1104937424.10567.87.camel@bagica.dsd.ro> <200501062131.57515.russell@coker.com.au> Message-ID: <1105090213.10566.106.camel@bagica.dsd.ro> On Thu, 2005-01-06 at 21:31 +1100, Russell Coker wrote: > On Thursday 06 January 2005 02:03, Bogdan Agica > wrote: > > 1. Relabel the script from initrd_exec_t to something else, > > in which case I'll run into problems starting / stopping the programs. > > You could have the init.d script call something else to do the work. So you > split the script into a worker script in /usr/sbin and a start script in the > init.d directory that just calls the worker. That's probably how we're gonna do it. Thanx for the tips. > > 2. Give read access to initrd_t in bitdefender_etc_t and _lib_t, > > which I think is a stupid workaround, providing read access to all > > scripts in /etc/init.d to this dir. > > That's the usual approach. Not ideal but not too bad either. What is the > bitdefender data? initrc_t is a very powerful domain that can break your > system in many ways. Protecting files from it provides little benefit with > the way things work now. The data accessed is not very sensitive (only statistics and settings, not anybody's email messages). However it would be only an workaround, not a fix. > > Is there any way to "inherit" a type (C++like inheritance), e.g. to > > create a type (say bitdefender_initrc_exec_t), which inherits all the > > attributes of it's successor, but adds new functionality? (Would be a > > nice idea if there isn't yet) > > No. Are there any plans for this? I guess it would make things easier for a lot of people. Thanx again for the reply, Bogdan -- Bogdan Agica BitDefender Internal Testing Engineer ------------------------------------- SOFTWIN Data Security Division ------------------------------------- email: bagica at bitdefender.com phone: +(4021) 233 18 52; 233 07 80 fax: (+4021) 233.07.63 Bucharest, ROMANIA http://www.bitdefender.com http://www.softwin.ro ------------------------------------- secure your every bit ------------------------------------- -------------- 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: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: BitDefender.txt URL: From ivg2 at cornell.edu Fri Jan 7 15:09:26 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 07 Jan 2005 08:09:26 -0700 Subject: Samba file server Message-ID: <1105110566.32405.12.camel@cobra.ivg2.net> Hi, I have a fairly trivial setup ( I think ) that I'd like to get working under SElinux. I have a bunch of data on /data, which is its own LVM logical volume. I have symlinks to the parts of the data in /data/smb that I'd like to export via smb. My server also exports user home directories and all printers. The problem is: Stuff on /data is labeled: system_u:object_r:default_t Stuff on /home is labeled: system_u:object_r:user_home_dir_t under system_u:object_r:home_root_t I get: audit(1105106751.784:0): avc: denied { search } for pid=32352 exe=/usr/sbin/smbd name=/ dev=dm-1 ino=2 scontext=user_u:system_r:smbd_t tcontext=system_u:object_r:default_t tclass=dir audit(1105107520.694:0): avc: denied { search } for pid=32629 exe=/usr/sbin/smbd name=/ dev=dm-2 ino=2 scontext=user_u:system_r:smbd_t tcontext=system_u:object_r:home_root_t tclass=dir - How can I address this situation? - What if I wanted to share /data over httpd as well? Thanks for any help, -- Ivan Gyurdiev Cornell University From russell at coker.com.au Fri Jan 7 15:53:29 2005 From: russell at coker.com.au (Russell Coker) Date: Sat, 8 Jan 2005 02:53:29 +1100 Subject: /etc/init.d/ script In-Reply-To: <1105090213.10566.106.camel@bagica.dsd.ro> References: <1104937424.10567.87.camel@bagica.dsd.ro> <200501062131.57515.russell@coker.com.au> <1105090213.10566.106.camel@bagica.dsd.ro> Message-ID: <200501080253.32451.russell@coker.com.au> On Friday 07 January 2005 20:30, Bogdan Agica wrote: > > > Is there any way to "inherit" a type (C++like inheritance), e.g. to > > > create a type (say bitdefender_initrc_exec_t), which inherits all the > > > attributes of it's successor, but adds new functionality? (Would be a > > > nice idea if there isn't yet) > > > > No. > > Are there any plans for this? I guess it would make things easier for a > lot of people. This has been requested and rejected in the past, but there have been some design changes in the mean time, so it might be better accepted if requested again now. This is not a good list for such a discussion, the main SE Linux list is the correct list. This list is about getting the current SE Linux implementation working in Fedora, if you post here about SE Linux feature requests (as opposed to requests for Fedora to better use existing SE Linux features) then most of the people who need to see such messages probably won't. I suggest that you subscribe to the NSA list (if you haven't already) and post a new message there with your feature request. -- 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 kwade at redhat.com Fri Jan 7 19:31:10 2005 From: kwade at redhat.com (Karsten Wade) Date: Fri, 07 Jan 2005 11:31:10 -0800 Subject: Samba file server In-Reply-To: <1105110566.32405.12.camel@cobra.ivg2.net> References: <1105110566.32405.12.camel@cobra.ivg2.net> Message-ID: <1105126271.9831.93.camel@erato.phig.org> On Fri, 2005-01-07 at 08:09 -0700, Ivan Gyurdiev wrote: > Hi, > > I have a fairly trivial setup ( I think ) that I'd like to get working > under SElinux. > > I have a bunch of data on /data, which is its own LVM logical volume. > I have symlinks to the parts of the data in /data/smb that I'd like to > export via smb. > > My server also exports user home directories and all printers. > > The problem is: > Stuff on /data is labeled: system_u:object_r:default_t > Stuff on /home is labeled: system_u:object_r:user_home_dir_t > under system_u:object_r:home_root_t > > I get: > > audit(1105106751.784:0): avc: denied { search } for pid=32352 > exe=/usr/sbin/smbd name=/ dev=dm-1 ino=2 scontext=user_u:system_r:smbd_t > tcontext=system_u:object_r:default_t tclass=dir > > audit(1105107520.694:0): avc: denied { search } for pid=32629 > exe=/usr/sbin/smbd name=/ dev=dm-2 ino=2 scontext=user_u:system_r:smbd_t > tcontext=system_u:object_r:home_root_t tclass=dir You have /root on this share? Interesting. I'm not sure you can do what I describe below in /root. > - How can I address this situation? Try relabeling the portions of /data that you want to have user_home_dir_t and user_home_t: chcon -t user_home_dir_t /data/smb cd /data/smb chcon -R -r user_home_t ./* > - What if I wanted to share /data over httpd as well? Off the top of my head, I don't think you can both share /data over httpd and have it be normal user home directory data. The types are distinctly separate. The normal procedure is to have an e.g. public_html/ folder, which would have a different type. There is a Boolean value for httpd that will allow httpd to access user directories, for the purpose of serving content that is labeled appropriately. You can set this using system-config-securitylevel, SELinux tab > Modify SELinux Policy > Allow HTTPD to read home directories. You then need to relabel the content you want served: chcon -t httpd_sys_content_t /path/to/public_html/ The folder gains the new type, and all children created inside of that gain the type. This guide has more information on customizing Apache and SELinux: http://fedora.redhat.com/docs/selinux-apache-fc3/sn-user-homedir.html -- Karsten Wade, RHCE, Sr. Tech Writer a lemon is just a melon in disguise http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 From ivg2 at cornell.edu Fri Jan 7 20:29:30 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 07 Jan 2005 13:29:30 -0700 Subject: Samba file server In-Reply-To: <1105126271.9831.93.camel@erato.phig.org> References: <1105110566.32405.12.camel@cobra.ivg2.net> <1105126271.9831.93.camel@erato.phig.org> Message-ID: <1105129770.17145.22.camel@cobra.ivg2.net> > You have /root on this share? Interesting. I'm not sure you can do > what I describe below in /root. No I don't. That's what the avc output says. I have no idea why it says that - I guess it prints the path relative to the volume mount point, not to the global /. > > Try relabeling the portions of /data that you want to have > user_home_dir_t and user_home_t: > > chcon -t user_home_dir_t /data/smb > cd /data/smb > chcon -R -r user_home_t ./* That sounds like a hack. This isn't a home directory so why should I label it as such. It's a bunch of common files. In addition to that I want home directories under /home. Since smbd currently fails to read even those, how would labeling /data user_home_t help? ============= Part of the problem in my mind is that I do not know what the SElinux types are, which ones I need to do what I want, and how to add new ones to perform this simple task. Consider traditional UNIX permissions. There's a straightforward procedure for doing what I want. I create a group called data. I put whoever I want in it (user1, user2, user3, httpd..). Then I chgrp /data with that. Nice and simple. I forget what smbd does - I think it checks to see if the UNIX user that you're logged in with has access to that folder. What's the SElinux equivalent? -- Ivan Gyurdiev Cornell University From bobk at ocf.berkeley.edu Fri Jan 7 20:33:53 2005 From: bobk at ocf.berkeley.edu (Bob Kashani) Date: Fri, 07 Jan 2005 12:33:53 -0800 Subject: SELinux error with yum --installroot In-Reply-To: <41DDA020.9000504@redhat.com> References: <1104380829.3448.15.camel@chaucer> <20050103164131.GA9027@minimumble.lab.boston.redhat.com> <1104820688.4044.19.camel@chaucer> <1104822351.4044.32.camel@chaucer> <1104822899.4044.39.camel@chaucer> <1104851922.20724.8.camel@moss-spartans.epoch.ncsc.mil> <1104909684.3391.39.camel@chaucer> <1105017200.24438.1.camel@moss-spartans.epoch.ncsc.mil> <41DD5631.5060308@redhat.com> <1105024484.24438.83.camel@moss-spartans.epoch.ncsc.mil> <41DDA020.9000504@redhat.com> Message-ID: <1105130033.3965.2.camel@chaucer> On Thu, 2005-01-06 at 15:31 -0500, Daniel J Walsh wrote: > > > >Ok, so why not just add an unconfined_domain(ldconfig_t) to > >unconfined.te in the targeted policy, so that ldconfig will still have > >the file type transition rule but will be unrestricted there. > > > > > > > I have done that. Thanks guys for fixing this. Any chance this will get backported to FC3? Bob -- Bob Kashani http://www.ocf.berkeley.edu/~bobk/garnome From dwalsh at redhat.com Fri Jan 7 20:48:10 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 07 Jan 2005 15:48:10 -0500 Subject: Samba file server In-Reply-To: <1105129770.17145.22.camel@cobra.ivg2.net> References: <1105110566.32405.12.camel@cobra.ivg2.net> <1105126271.9831.93.camel@erato.phig.org> <1105129770.17145.22.camel@cobra.ivg2.net> Message-ID: <41DEF58A.8050909@redhat.com> Ivan Gyurdiev wrote: >>You have /root on this share? Interesting. I'm not sure you can do >>what I describe below in /root. >> >> > >No I don't. That's what the avc output says. I have no idea why it says >that - I guess it prints the path relative to the volume mount point, >not to the global /. > > >>Try relabeling the portions of /data that you want to have >>user_home_dir_t and user_home_t: >> >>chcon -t user_home_dir_t /data/smb >>cd /data/smb >>chcon -R -r user_home_t ./* >> >> > >That sounds like a hack. This isn't a home directory so why >should I label it as such. It's a bunch of common files. >In addition to that I want home directories under /home. >Since smbd currently fails to read even those, how would labeling >/data user_home_t help? > >============= > >Part of the problem in my mind is that I do not know what >the SElinux types are, which ones I need to do what I want, >and how to add new ones to perform this simple task. > >Consider traditional UNIX permissions. There's a straightforward >procedure for doing what I want. I create a group called data. >I put whoever I want in it (user1, user2, user3, httpd..). Then >I chgrp /data with that. Nice and simple. I forget what smbd does - I >think it checks to see if the UNIX user that you're logged in with >has access to that folder. > >What's the SElinux equivalent? > > > I think you want to label them samba_share_t. chcon -R -t samba_share_t /data From dwalsh at redhat.com Fri Jan 7 20:53:19 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 07 Jan 2005 15:53:19 -0500 Subject: SELinux error with yum --installroot In-Reply-To: <1105130033.3965.2.camel@chaucer> References: <1104380829.3448.15.camel@chaucer> <20050103164131.GA9027@minimumble.lab.boston.redhat.com> <1104820688.4044.19.camel@chaucer> <1104822351.4044.32.camel@chaucer> <1104822899.4044.39.camel@chaucer> <1104851922.20724.8.camel@moss-spartans.epoch.ncsc.mil> <1104909684.3391.39.camel@chaucer> <1105017200.24438.1.camel@moss-spartans.epoch.ncsc.mil> <41DD5631.5060308@redhat.com> <1105024484.24438.83.camel@moss-spartans.epoch.ncsc.mil> <41DDA020.9000504@redhat.com> <1105130033.3965.2.camel@chaucer> Message-ID: <41DEF6BF.3050205@redhat.com> Bob Kashani wrote: >On Thu, 2005-01-06 at 15:31 -0500, Daniel J Walsh wrote: > > >>>Ok, so why not just add an unconfined_domain(ldconfig_t) to >>>unconfined.te in the targeted policy, so that ldconfig will still have >>>the file type transition rule but will be unrestricted there. >>> >>> >>> >>> >>> >>I have done that. >> >> > >Thanks guys for fixing this. Any chance this will get backported to FC3? > >Bob > > > Yes selinux-policy-targeted-1.17.30-2.68 should be out shortly From walters at redhat.com Fri Jan 7 20:52:27 2005 From: walters at redhat.com (Colin Walters) Date: Fri, 07 Jan 2005 15:52:27 -0500 Subject: Samba file server In-Reply-To: <1105129770.17145.22.camel@cobra.ivg2.net> References: <1105110566.32405.12.camel@cobra.ivg2.net> <1105126271.9831.93.camel@erato.phig.org> <1105129770.17145.22.camel@cobra.ivg2.net> Message-ID: <1105131147.27205.48.camel@nexus.verbum.private> On Fri, 2005-01-07 at 13:29 -0700, Ivan Gyurdiev wrote: > That sounds like a hack. This isn't a home directory so why > should I label it as such. It's a bunch of common files. Well, that's currently the type we use for data that users can modify. It may be a bit weird given the name, but if from a security perspective the files elsewhere are equivalent to the user's $HOME, then giving them the same label makes sense. > Part of the problem in my mind is that I do not know what > the SElinux types are, which ones I need to do what I want, > and how to add new ones to perform this simple task. Right; this is something that should definitely be documented somewhere. Both the purpose of existing types, as well as how to add new ones for specific purposes. > Consider traditional UNIX permissions. There's a straightforward > procedure for doing what I want. I create a group called data. > I put whoever I want in it (user1, user2, user3, httpd..). Then > I chgrp /data with that. Nice and simple. Offtopic, but: you really want to use ACLs instead of groups; much simpler then mucking about with groups. > I forget what smbd does - I > think it checks to see if the UNIX user that you're logged in with > has access to that folder. It uses setfsuid, IIRC. > What's the SElinux equivalent? You create a new type: type foodata_t, file_type, sysadmfile; Then grant permissions from other domains to it: r_dir_file(user1_t, foodata_t) create_dir_file(user2_t, foodata_t) create_dir_file(samba_t, foodata_t) From ivg2 at cornell.edu Fri Jan 7 20:57:48 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 07 Jan 2005 13:57:48 -0700 Subject: Samba file server In-Reply-To: <41DEF58A.8050909@redhat.com> References: <1105110566.32405.12.camel@cobra.ivg2.net> <1105126271.9831.93.camel@erato.phig.org> <1105129770.17145.22.camel@cobra.ivg2.net> <41DEF58A.8050909@redhat.com> Message-ID: <1105131468.17263.6.camel@cobra.ivg2.net> > I think you want to label them samba_share_t. > > chcon -R -t samba_share_t /data Excellent. Where can I find such information in the future? There must be a better way of communicating to the user what the needed contexts are instead of looking at the policy (which is in binary form on my machine). How about integrating some sort of check in system-config-samba that asks if it should relabel those shares for you when you add them? Or some sort of document (for Samba) like the one for HTTP that kwade at redhat.com mentioned. Also, what about home directories? -- Ivan Gyurdiev Cornell University From dwalsh at redhat.com Fri Jan 7 20:59:58 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 07 Jan 2005 15:59:58 -0500 Subject: Samba file server In-Reply-To: <1105131468.17263.6.camel@cobra.ivg2.net> References: <1105110566.32405.12.camel@cobra.ivg2.net> <1105126271.9831.93.camel@erato.phig.org> <1105129770.17145.22.camel@cobra.ivg2.net> <41DEF58A.8050909@redhat.com> <1105131468.17263.6.camel@cobra.ivg2.net> Message-ID: <41DEF84E.1090507@redhat.com> Ivan Gyurdiev wrote: >>I think you want to label them samba_share_t. >> >>chcon -R -t samba_share_t /data >> >> > >Excellent. Where can I find such information in the future? >There must be a better way of communicating to the user what >the needed contexts are instead of looking at the policy >(which is in binary form on my machine). >How about integrating some sort of check in >system-config-samba that asks if it should >relabel those shares for you when you add them? > >Or some sort of document (for Samba) like the one for HTTP that >kwade at redhat.com mentioned. > >Also, what about home directories? > > > Sounds like a good idea. Could you submit a bugzilla. Thanks. From kwade at redhat.com Fri Jan 7 21:27:57 2005 From: kwade at redhat.com (Karsten Wade) Date: Fri, 07 Jan 2005 13:27:57 -0800 Subject: Samba file server In-Reply-To: <1105129770.17145.22.camel@cobra.ivg2.net> References: <1105110566.32405.12.camel@cobra.ivg2.net> <1105126271.9831.93.camel@erato.phig.org> <1105129770.17145.22.camel@cobra.ivg2.net> Message-ID: <1105133277.9831.110.camel@erato.phig.org> On Fri, 2005-01-07 at 13:29 -0700, Ivan Gyurdiev wrote: > > You have /root on this share? Interesting. I'm not sure you can do > > what I describe below in /root. > > No I don't. That's what the avc output says. I have no idea why it says > that - I guess it prints the path relative to the volume mount point, > not to the global /. Right, it does. I was blurry eyed this morning. :) I thought I understood what was happening to you. Are you running the strict or rawhide policy? Samba wasn't covered in the targeted policy for FC3, so /usr/sbin/smbd wouldn't have the type smb_t under that policy > > Try relabeling the portions of /data that you want to have > > user_home_dir_t and user_home_t: > > > > chcon -t user_home_dir_t /data/smb > > cd /data/smb > > chcon -R -r user_home_t ./* > > That sounds like a hack. This isn't a home directory so why > should I label it as such. It's a bunch of common files. > In addition to that I want home directories under /home. > Since smbd currently fails to read even those, how would labeling > /data user_home_t help? Sorry, I misread your intent, I thought your task was mounting home directories. I don't have a modern strict or rawhide targeted policy installed anywhere right now and I would need that to analyze what the policy is regulating against what you are trying to do. > Part of the problem in my mind is that I do not know what > the SElinux types are, which ones I need to do what I want, > and how to add new ones to perform this simple task. In the targeted policy, you won't have to worry about that. Choosing to run the strict or rawhide policy puts you in an area that is more complex. If you accept that complexity, you accept that you are going to need to customize policy or file bugs/feature requests (as Dan Walsh requested.) The documentation is catching up with the code. Slowly. :/ - Karsten -- Karsten Wade, RHCE, Sr. Tech Writer a lemon is just a melon in disguise http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 From kwade at redhat.com Fri Jan 7 21:29:16 2005 From: kwade at redhat.com (Karsten Wade) Date: Fri, 07 Jan 2005 13:29:16 -0800 Subject: Samba file server In-Reply-To: <1105131468.17263.6.camel@cobra.ivg2.net> References: <1105110566.32405.12.camel@cobra.ivg2.net> <1105126271.9831.93.camel@erato.phig.org> <1105129770.17145.22.camel@cobra.ivg2.net> <41DEF58A.8050909@redhat.com> <1105131468.17263.6.camel@cobra.ivg2.net> Message-ID: <1105133356.9831.113.camel@erato.phig.org> On Fri, 2005-01-07 at 13:57 -0700, Ivan Gyurdiev wrote: > Or some sort of document (for Samba) like the one for HTTP that > kwade at redhat.com mentioned. The Fedora docs project needs writers to tackle tutorials like what you describe. If you or anyone you know is interested, send them over to http://fedora.redhat.com/projects/docs/. - Karsten -- Karsten Wade, RHCE, Sr. Tech Writer a lemon is just a melon in disguise http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 From kwade at redhat.com Fri Jan 7 22:31:50 2005 From: kwade at redhat.com (Karsten Wade) Date: Fri, 07 Jan 2005 14:31:50 -0800 Subject: Samba file server In-Reply-To: <1105131147.27205.48.camel@nexus.verbum.private> References: <1105110566.32405.12.camel@cobra.ivg2.net> <1105126271.9831.93.camel@erato.phig.org> <1105129770.17145.22.camel@cobra.ivg2.net> <1105131147.27205.48.camel@nexus.verbum.private> Message-ID: <1105137110.9831.129.camel@erato.phig.org> On Fri, 2005-01-07 at 15:52 -0500, Colin Walters wrote: > On Fri, 2005-01-07 at 13:29 -0700, Ivan Gyurdiev wrote: > > > That sounds like a hack. This isn't a home directory so why > > should I label it as such. It's a bunch of common files. > > Well, that's currently the type we use for data that users can modify. > It may be a bit weird given the name, but if from a security perspective > the files elsewhere are equivalent to the user's $HOME, then giving them > the same label makes sense. Heh, I knew I had the right answer but I wasn't sure why it was the only right answer. :) (me refers to grogginess mentioned earlier) > > Part of the problem in my mind is that I do not know what > > the SElinux types are, which ones I need to do what I want, > > and how to add new ones to perform this simple task. > > Right; this is something that should definitely be documented somewhere. > Both the purpose of existing types, as well as how to add new ones for > specific purposes. Documenting all the types sounds like a monumental task. It is also pretty dry reading (and writing). I could go on and on here, but IMHO this is not a manual documentation task. Similar is the idea of having a tutorial for every domain. Already that is an unwieldy idea for the targeted policy, and I *shudder* just thinking about it for the strict policy. Which brings us to a procedural and programmatic solution, the kind I much prefer. I'd like to hear developer ideas on this. Also, it would be nice to integrate this with the online documentation, meaning manual and info pages. Perhaps the pages could have an include that pulls a list of appropriate types from the policy. For example, the man page for sshd(8) would pull a formatted list of types (and tips) from /etc/selinux/policyname/docs/sshd.doc. The file sshd.doc is generated in the policy build (and supplied in binary policy and can be build from policy source), combining sshd.tips with an extraction of the types from the current policy. Similarly, sys.doc could be generated to give a view into all _sys_ types, sysadmr.doc could list all the things the sysadm_r role can do, and so forth. Essentially, all this stuff is there to find in the policy and using analysis tools such as apol. Be nice to make it easier for our friends the sysadmins than to make them into policy analysts. :) - Karsten -- Karsten Wade, RHCE, Sr. Tech Writer a lemon is just a melon in disguise http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 From selinux at gmail.com Sat Jan 8 18:41:44 2005 From: selinux at gmail.com (Tom London) Date: Sat, 8 Jan 2005 10:41:44 -0800 Subject: kernel-2.6.10-1.1074_FC4 breaks firefox? Message-ID: <4c4ba153050108104177ffe4c7@mail.gmail.com> Running strict/enforcing, latest Rawhide. After downloading today's updates, including kernel-2.6.10-1.1074_FC4, and rebooting, (and before the kernel oops with a kernel page fault): firefox refuses to start in enforcing mode. Here are the AVCs: Jan 8 10:28:01 fedora kernel: audit(1105208881.086:0): avc: denied { execmod } for pid=4242 comm=java path=/lib/ld-2.3.4.so dev=hda2 ino=3178514 scontext=user_u:user_r:user_t tcontext=system_u:object_r:ld_so_t tclass=file Jan 8 10:28:01 fedora kernel: audit(1105208881.831:0): avc: denied { execmem } for pid=4266 comm=firefox-bin scontext=user_u:user_r:user_mozilla_t tcontext=user_u:user_r:user_mozilla_t tclass=process Jan 8 10:28:01 fedora kernel: audit(1105208881.928:0): avc: denied { execmem } for pid=4266 comm=firefox-bin scontext=user_u:user_r:user_mozilla_t tcontext=user_u:user_r:user_mozilla_t tclass=process Policy needs fixing for new kernel mods? tom -- Tom London From selinux at gmail.com Sat Jan 8 19:34:05 2005 From: selinux at gmail.com (Tom London) Date: Sat, 8 Jan 2005 11:34:05 -0800 Subject: pam & /etc/selinux/strict/contexts/files/media Message-ID: <4c4ba153050108113451e04543@mail.gmail.com> Running strict/enforcing, latest Rawhide, but reverted to kernel-2.6.10-1.1063_FC4. Noticed the following AVCs from pam early in boot: Jan 8 10:33:17 fedora kernel: audit(1105180348.115:0): avc: denied { read } for pid=1562 exe=/sbin/pam_console_apply path=/etc/selinux/strict/contexts/files/media dev=hda2 ino=4506184 scontext=system_u:system_r:pam_console_t tcontext=system_u:object_r:file_context_t tclass=file Jan 8 10:33:17 fedora kernel: audit(1105180348.145:0): avc: denied { read } for pid=1566 exe=/sbin/pam_console_apply path=/etc/selinux/strict/contexts/files/media dev=hda2 ino=4506184 scontext=system_u:system_r:pam_console_t tcontext=system_u:object_r:file_context_t tclass=file allow pam_console_t file_context_t:file read; dontallow? tom -- Tom London From bobk at ocf.berkeley.edu Sun Jan 9 05:55:07 2005 From: bobk at ocf.berkeley.edu (Bob Kashani) Date: Sat, 08 Jan 2005 21:55:07 -0800 Subject: load_policy in chroot question Message-ID: <1105250107.4246.14.camel@chaucer> When I install the selinux-policy-targeted rpm in a chroot it seems that load_policy is executed and loads the policy that's installed in the chroot into the running kernel (I'm assuming via %post). Should installing the selinux-policy-targeted rpm in a chroot allow this to happen? What if you're installing a policy into the chroot that's different than the one you have installed on your system? Is there a way to not allow load_policy to execute in a chroot? Here is the AVC messages I'm getting: Jan 8 21:38:23 chaucer kernel: audit(1105249103.605:0): avc: granted { load_policy } for pid=4233 exe=/usr/sbin/load_policy scontext=root:system_r:unconfined_t tcontext=system_u:object_r:security_t tclass=security Jan 8 21:38:23 chaucer kernel: security: 3 users, 4 roles, 316 types, 20 bools Jan 8 21:38:23 chaucer kernel: security: 53 classes, 7962 rules Bob -- Bob Kashani http://www.ocf.berkeley.edu/~bobk/garnome From Valdis.Kletnieks at vt.edu Sun Jan 9 06:20:22 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 09 Jan 2005 01:20:22 -0500 Subject: load_policy in chroot question In-Reply-To: Your message of "Sat, 08 Jan 2005 21:55:07 PST." <1105250107.4246.14.camel@chaucer> References: <1105250107.4246.14.camel@chaucer> Message-ID: <200501090620.j096KNpF021408@turing-police.cc.vt.edu> On Sat, 08 Jan 2005 21:55:07 PST, Bob Kashani said: > When I install the selinux-policy-targeted rpm in a chroot it seems that > load_policy is executed and loads the policy that's installed in the > chroot into the running kernel (I'm assuming via %post). Should > installing the selinux-policy-targeted rpm in a chroot allow this to > happen? What if you're installing a policy into the chroot that's > different than the one you have installed on your system? Is there a way > to not allow load_policy to execute in a chroot? In general, there's not much way to distinguish "in a chroot". The "SELinux Way" to address this is to make sure that all files on the system that can legitimately be loaded as policy are flagged with a context that allows loading them. If there's nothing in the chroot with the appropriate context, it can't load it. I notice yours is flagged as 'unconfined_t', which smells a lot like running the targeted policy. The design point for that policy is "constrain certain daemons, but assume that users are in general trusted and know what they're doing". As such, it's assuming that if you're loading the policy from a chroot that you know what you're doing and should be allowed to do so. If that doesn't describe how you want things to work, maybe you should be running 'strict' instead of 'targeted'? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From selinux at gmail.com Sun Jan 9 17:29:47 2005 From: selinux at gmail.com (Tom London) Date: Sun, 9 Jan 2005 09:29:47 -0800 Subject: kernel-2.6.10-1.1074_FC4 breaks firefox? In-Reply-To: <4c4ba153050108104177ffe4c7@mail.gmail.com> References: <4c4ba153050108104177ffe4c7@mail.gmail.com> Message-ID: <4c4ba15305010909294acf7e0f@mail.gmail.com> Same problem in 1075_FC4. Works (with similar AVCs) in permissive mode. tom From walters at redhat.com Sun Jan 9 17:48:05 2005 From: walters at redhat.com (Colin Walters) Date: Sun, 09 Jan 2005 12:48:05 -0500 Subject: load_policy in chroot question In-Reply-To: <1105250107.4246.14.camel@chaucer> References: <1105250107.4246.14.camel@chaucer> Message-ID: <1105292885.4605.21.camel@nexus.verbum.private> On Sat, 2005-01-08 at 21:55 -0800, Bob Kashani wrote: > When I install the selinux-policy-targeted rpm in a chroot it seems that > load_policy is executed and loads the policy that's installed in the > chroot into the running kernel (I'm assuming via %post). Should > installing the selinux-policy-targeted rpm in a chroot allow this to > happen? What if you're installing a policy into the chroot that's > different than the one you have installed on your system? Is there a way > to not allow load_policy to execute in a chroot? I don't think we're going to be able to support generically using SELinux in chroots?. Fundamentally chroot is a very weak virtualization mechanism; much of the core system leaks to the chroot (and vice versa), and that's the problem you're running into here. I think moving forward most of what people are doing with chroots (e.g. package building and especially testing) should be done with "real" virtualization like UML or Xen. But one workaround for your problem may be to make SELinux appear to be disabled inside the chroot. I've attached two (completely untested) patches; the first attempts to make SELinux appear to be disabled if you don't mount /selinux inside the chroot, and the second makes load_policy exit immediately with 0 status if SELinux isn't enabled. ? By "generically" I mean e.g. a stock FC3 installation. Certainly it's possible to add policy for a specific chrooted application. -------------- next part -------------- A non-text attachment was scrubbed... Name: libselinux-enabled-checking.patch Type: text/x-patch Size: 360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: policycoreutils-load-policy-chroot.patch Type: text/x-patch Size: 532 bytes Desc: not available URL: From Jochen at herr-schmitt.de Sun Jan 9 20:24:16 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Sun, 09 Jan 2005 21:24:16 +0100 Subject: Adding net .fc file for Fedora Extra package Message-ID: Hello, I have create the suck package, which was available from the fedora extra repository. Becouse on FC3 SELinux is enable as default, I think, that I have to write a own suck.fc file to put suck in the same domain as inn. Now I will aks, how ist the best practice to distribute a *.fc file in a Fedora Extra package. Best Regards: Jochen Schmitt From bobk at ocf.berkeley.edu Mon Jan 10 03:33:57 2005 From: bobk at ocf.berkeley.edu (Bob Kashani) Date: Sun, 09 Jan 2005 19:33:57 -0800 Subject: load_policy in chroot question In-Reply-To: <200501090620.j096KNpF021408@turing-police.cc.vt.edu> References: <1105250107.4246.14.camel@chaucer> <200501090620.j096KNpF021408@turing-police.cc.vt.edu> Message-ID: <1105328037.3254.3.camel@chaucer> On Sun, 2005-01-09 at 01:20 -0500, Valdis.Kletnieks at vt.edu wrote: > I notice yours is flagged as 'unconfined_t', which smells a lot like running > the targeted policy. The design point for that policy is "constrain certain > daemons, but assume that users are in general trusted and know what they're doing". > As such, it's assuming that if you're loading the policy from a chroot that > you know what you're doing and should be allowed to do so. If that doesn't > describe how you want things to work, maybe you should be running 'strict' > instead of 'targeted'? I actually like the flexibility of targeted and I tried strict yesterday and it causes my system to hang. When I do get the chance I will play around with strict though. Bob -- Bob Kashani http://www.ocf.berkeley.edu/~bobk/garnome From bobk at ocf.berkeley.edu Mon Jan 10 03:51:14 2005 From: bobk at ocf.berkeley.edu (Bob Kashani) Date: Sun, 09 Jan 2005 19:51:14 -0800 Subject: load_policy in chroot question In-Reply-To: <1105292885.4605.21.camel@nexus.verbum.private> References: <1105250107.4246.14.camel@chaucer> <1105292885.4605.21.camel@nexus.verbum.private> Message-ID: <1105329074.3254.20.camel@chaucer> On Sun, 2005-01-09 at 12:48 -0500, Colin Walters wrote: > On Sat, 2005-01-08 at 21:55 -0800, Bob Kashani wrote: > > When I install the selinux-policy-targeted rpm in a chroot it seems that > > load_policy is executed and loads the policy that's installed in the > > chroot into the running kernel (I'm assuming via %post). Should > > installing the selinux-policy-targeted rpm in a chroot allow this to > > happen? What if you're installing a policy into the chroot that's > > different than the one you have installed on your system? Is there a way > > to not allow load_policy to execute in a chroot? > > I don't think we're going to be able to support generically using > SELinux in chroots?. Fundamentally chroot is a very weak virtualization > mechanism; much of the core system leaks to the chroot (and vice versa), > and that's the problem you're running into here. I think moving forward > most of what people are doing with chroots (e.g. package building and > especially testing) should be done with "real" virtualization like UML > or Xen. I'm actually playing around with UML as well. :) The only issue with virtualization is that you end up taking a performance hit but on the other hand it does make life easier. > But one workaround for your problem may be to make SELinux appear to be > disabled inside the chroot. I've attached two (completely untested) > patches; the first attempts to make SELinux appear to be disabled if you > don't mount /selinux inside the chroot, and the second makes load_policy > exit immediately with 0 status if SELinux isn't enabled. I'll try your patches. But I did figure out a simple workaround. (not mounting /selinux in the chroot). It seems that if you don't mount /selinux in the chroot then load_policy doesn't try to install the policy in the chroot into the running kernel. I have no idea why that is the case. But everything seems to work without mounting /selinux so...in fact it seems that I don't even need /sys either. I just tried mounting only /proc (which is what I was doing in the first place) with selinux- policy-targeted-1.17.30-2.68 and everything works!!! :) I did do a 'touch /.autorelabel' as specified in the FAQ which seems to have helped with a few other things as well. I'll let you know how it goes with your patches. Thanks, Bob -- Bob Kashani http://www.ocf.berkeley.edu/~bobk/garnome From walters at redhat.com Mon Jan 10 04:20:04 2005 From: walters at redhat.com (Colin Walters) Date: Sun, 09 Jan 2005 23:20:04 -0500 Subject: load_policy in chroot question In-Reply-To: <1105329074.3254.20.camel@chaucer> References: <1105250107.4246.14.camel@chaucer> <1105292885.4605.21.camel@nexus.verbum.private> <1105329074.3254.20.camel@chaucer> Message-ID: <1105330805.4605.41.camel@nexus.verbum.private> On Sun, 2005-01-09 at 19:51 -0800, Bob Kashani wrote: > I'm actually playing around with UML as well. :) The only issue with > virtualization is that you end up taking a performance hit but on the > other hand it does make life easier. Right. By the way, I think Xen is in rawhide now, so that could be worth checking out. > I'll try your patches. But I did figure out a simple workaround. (not > mounting /selinux in the chroot). It seems that if you don't > mount /selinux in the chroot then load_policy doesn't try to install the > policy in the chroot into the running kernel. I have no idea why that is > the case. Well, loading the policy will fail since load_policy just writes data to /selinux/load. I'm surprised that doesn't turn into a postinst error. Anyways, I suspect that you don't want other tools inside the chroot to think SELinux is enabled, so the patches should help there. But I haven't tested this, so there may be something I'm missing. > But everything seems to work without mounting /selinux so...in > fact it seems that I don't even need /sys either. Lacking /sys will almost certainly cause problems. > I just tried mounting > only /proc (which is what I was doing in the first place) with selinux- > policy-targeted-1.17.30-2.68 and everything works!!! :) I did do a > 'touch /.autorelabel' as specified in the FAQ which seems to have helped > with a few other things as well. What is it specifically that you are doing with the chroot? Building RPMs? From walters at redhat.com Mon Jan 10 04:21:54 2005 From: walters at redhat.com (Colin Walters) Date: Sun, 09 Jan 2005 23:21:54 -0500 Subject: Adding net .fc file for Fedora Extra package In-Reply-To: References: Message-ID: <1105330914.4605.43.camel@nexus.verbum.private> On Sun, 2005-01-09 at 21:24 +0100, Jochen Schmitt wrote: > Hello, > > I have create the suck package, which was available from the > fedora extra repository. > > Becouse on FC3 SELinux is enable as default, I think, that I have > to write a own suck.fc file to put suck in the same domain as > inn. > > Now I will aks, how ist the best practice to distribute a *.fc > file in a Fedora Extra package. The best practice at the moment is to submit it as a patch in Bugzilla against the selinux-policy-strict package. Or submit it upstream at selinux at tycho.nsa.gov. From bobk at ocf.berkeley.edu Mon Jan 10 05:01:11 2005 From: bobk at ocf.berkeley.edu (Bob Kashani) Date: Sun, 09 Jan 2005 21:01:11 -0800 Subject: load_policy in chroot question In-Reply-To: <1105330805.4605.41.camel@nexus.verbum.private> References: <1105250107.4246.14.camel@chaucer> <1105292885.4605.21.camel@nexus.verbum.private> <1105329074.3254.20.camel@chaucer> <1105330805.4605.41.camel@nexus.verbum.private> Message-ID: <1105333271.3254.39.camel@chaucer> On Sun, 2005-01-09 at 23:20 -0500, Colin Walters wrote: > On Sun, 2005-01-09 at 19:51 -0800, Bob Kashani wrote: > > > I'm actually playing around with UML as well. :) The only issue with > > virtualization is that you end up taking a performance hit but on the > > other hand it does make life easier. > > Right. By the way, I think Xen is in rawhide now, so that could be > worth checking out. Cool, I'll check it out. Thanks!!! :) > > I'll try your patches. But I did figure out a simple workaround. (not > > mounting /selinux in the chroot). It seems that if you don't > > mount /selinux in the chroot then load_policy doesn't try to install the > > policy in the chroot into the running kernel. I have no idea why that is > > the case. > > Well, loading the policy will fail since load_policy just writes data > to /selinux/load. I'm surprised that doesn't turn into a postinst > error. I just checked the selinux-policy-targeted.spec and in the %post section at the very end there is an 'exit 0'. > Anyways, I suspect that you don't want other tools inside the chroot to > think SELinux is enabled, so the patches should help there. But I > haven't tested this, so there may be something I'm missing. > > > But everything seems to work without mounting /selinux so...in > > fact it seems that I don't even need /sys either. > > Lacking /sys will almost certainly cause problems. Really? Nothing fails to install because of it. I tried with and without it and there is no difference. But I'm only installing RPMS in the chroot at the moment so that might be the reason. I'll keep this in mind when I get around to building my RPMS later though...thanks. :) > > I just tried mounting > > only /proc (which is what I was doing in the first place) with selinux- > > policy-targeted-1.17.30-2.68 and everything works!!! :) I did do a > > 'touch /.autorelabel' as specified in the FAQ which seems to have helped > > with a few other things as well. > > What is it specifically that you are doing with the chroot? Building > RPMs? Yup. Bob -- Bob Kashani http://www.ocf.berkeley.edu/~bobk/garnome From bobk at ocf.berkeley.edu Mon Jan 10 06:01:05 2005 From: bobk at ocf.berkeley.edu (Bob Kashani) Date: Sun, 09 Jan 2005 22:01:05 -0800 Subject: load_policy in chroot question In-Reply-To: <1105333271.3254.39.camel@chaucer> References: <1105250107.4246.14.camel@chaucer> <1105292885.4605.21.camel@nexus.verbum.private> <1105329074.3254.20.camel@chaucer> <1105330805.4605.41.camel@nexus.verbum.private> <1105333271.3254.39.camel@chaucer> Message-ID: <1105336865.4209.7.camel@chaucer> On Sun, 2005-01-09 at 21:01 -0800, Bob Kashani wrote: > On Sun, 2005-01-09 at 23:20 -0500, Colin Walters wrote: > > On Sun, 2005-01-09 at 19:51 -0800, Bob Kashani wrote: > > > > > I'm actually playing around with UML as well. :) The only issue with > > > virtualization is that you end up taking a performance hit but on the > > > other hand it does make life easier. > > > > Right. By the way, I think Xen is in rawhide now, so that could be > > worth checking out. > > Cool, I'll check it out. Thanks!!! :) > > > > I'll try your patches. But I did figure out a simple workaround. (not > > > mounting /selinux in the chroot). It seems that if you don't > > > mount /selinux in the chroot then load_policy doesn't try to install the > > > policy in the chroot into the running kernel. I have no idea why that is > > > the case. > > > > Well, loading the policy will fail since load_policy just writes data > > to /selinux/load. I'm surprised that doesn't turn into a postinst > > error. > > I just checked the selinux-policy-targeted.spec and in the %post section > at the very end there is an 'exit 0'. Just to clarify: I meant that as an observation and not as something that would cause it to fail. BTW: I have a selinux dir in my chroot but there is nothing in it. Where do the files in /selinux come from? Bob -- Bob Kashani http://www.ocf.berkeley.edu/~bobk/garnome From walters at redhat.com Mon Jan 10 06:14:50 2005 From: walters at redhat.com (Colin Walters) Date: Mon, 10 Jan 2005 01:14:50 -0500 Subject: load_policy in chroot question In-Reply-To: <1105336865.4209.7.camel@chaucer> References: <1105250107.4246.14.camel@chaucer> <1105292885.4605.21.camel@nexus.verbum.private> <1105329074.3254.20.camel@chaucer> <1105330805.4605.41.camel@nexus.verbum.private> <1105333271.3254.39.camel@chaucer> <1105336865.4209.7.camel@chaucer> Message-ID: <1105337690.4605.45.camel@nexus.verbum.private> On Sun, 2005-01-09 at 22:01 -0800, Bob Kashani wrote: > BTW: I have a selinux dir in my chroot but there is nothing in it. Where > do the files in /selinux come from? /selinux is a kernel filesystem (selinuxfs), normally mounted by init, IIRC. From selinux at gmail.com Mon Jan 10 14:31:52 2005 From: selinux at gmail.com (Tom London) Date: Mon, 10 Jan 2005 06:31:52 -0800 Subject: kernel-2.6.10-1.1074_FC4 breaks firefox? In-Reply-To: <4c4ba15305010909294acf7e0f@mail.gmail.com> References: <4c4ba153050108104177ffe4c7@mail.gmail.com> <4c4ba15305010909294acf7e0f@mail.gmail.com> Message-ID: <4c4ba153050110063123e42a7@mail.gmail.com> Uhhh....This went away on this mornings boot..... I don't remember changing anything to fix it..... Could a cron triggered job have fixed this...? tom From justin.conover at gmail.com Mon Jan 10 15:21:24 2005 From: justin.conover at gmail.com (Justin Conover) Date: Mon, 10 Jan 2005 09:21:24 -0600 Subject: Head-banging targets, please In-Reply-To: <1104467140.8264.9.camel@turtle.localdomain> References: <1104445584.3312.100.camel@Eng-Lab-002> <1104467140.8264.9.camel@turtle.localdomain> Message-ID: I did buy this book and was wondering what the Fedora Developers thought abou it compared to how Fedora is currently using/intergrated SELinux? Is this book fairly accurate to the same methods used? On Thu, 30 Dec 2004 20:25:40 -0800, Vincent wrote: > On Thu, 2004-12-30 at 16:26 -0600, David Hart wrote: > > I need help understanding SELinux! > > > > I've read just about every on-line SELinux article I can find, and I am > > getting progressively more confused as I read more. Following along in > > these articles on a Fedora Core 3 system, reading documents written for > > Fedora Core 2 Test 3 and before, is confusing. The older the document, > > the more my installation fails to match the documentation. > > > > I need a starting place, some things to look at once I have my Fedora > > Core 3 installation running. Some simple things, some that work > > correctly, some that fail and I can learn how to track down and fix. > > Have you read "NSA's Open Source Security Enhanced Linux" By O'reilly? > http://www.oreilly.com/catalog/selinux/ > > I have the E-book and you can find it on google with little trouble. > Someone was suppose to get it for me for Christmas, but low and behold.. > socks! > > -- > 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 Mon Jan 10 15:24:29 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 10 Jan 2005 10:24:29 -0500 Subject: load_policy in chroot question In-Reply-To: <1105250107.4246.14.camel@chaucer> References: <1105250107.4246.14.camel@chaucer> Message-ID: <41E29E2D.4080801@redhat.com> Bob Kashani wrote: >When I install the selinux-policy-targeted rpm in a chroot it seems that >load_policy is executed and loads the policy that's installed in the >chroot into the running kernel (I'm assuming via %post). Should >installing the selinux-policy-targeted rpm in a chroot allow this to >happen? What if you're installing a policy into the chroot that's >different than the one you have installed on your system? Is there a way >to not allow load_policy to execute in a chroot? > >Here is the AVC messages I'm getting: > >Jan 8 21:38:23 chaucer kernel: audit(1105249103.605:0): avc: granted >{ load_policy } for pid=4233 exe=/usr/sbin/load_policy >scontext=root:system_r:unconfined_t >tcontext=system_u:object_r:security_t tclass=security >Jan 8 21:38:23 chaucer kernel: security: 3 users, 4 roles, 316 types, >20 bools >Jan 8 21:38:23 chaucer kernel: security: 53 classes, 7962 rules > >Bob > > > rpm --noscripts From dwalsh at redhat.com Mon Jan 10 15:30:49 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 10 Jan 2005 10:30:49 -0500 Subject: Adding net .fc file for Fedora Extra package In-Reply-To: References: Message-ID: <41E29FA9.9020600@redhat.com> Jochen Schmitt wrote: >Hello, > >I have create the suck package, which was available from the >fedora extra repository. > >Becouse on FC3 SELinux is enable as default, I think, that I have >to write a own suck.fc file to put suck in the same domain as >inn. > > > If suck is just going to run with the inn policy you should just add the appropriate lines of suck to innd.fc fc files are only used if there is a matching te file. >Now I will aks, how ist the best practice to distribute a *.fc >file in a Fedora Extra package. > >Best Regards: > >Jochen Schmitt > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From selinux at gmail.com Mon Jan 10 15:37:12 2005 From: selinux at gmail.com (Tom London) Date: Mon, 10 Jan 2005 07:37:12 -0800 Subject: kernel-2.6.10-1.1074_FC4 breaks firefox? In-Reply-To: <4c4ba153050110063123e42a7@mail.gmail.com> References: <4c4ba153050108104177ffe4c7@mail.gmail.com> <4c4ba15305010909294acf7e0f@mail.gmail.com> <4c4ba153050110063123e42a7@mail.gmail.com> Message-ID: <4c4ba15305011007373ab16694@mail.gmail.com> Sorry, accidently booted 1063_FC4 by accident. Still happens in 1075_FC4. tom -- Tom London From mike at math.umn.edu Tue Jan 11 01:00:18 2005 From: mike at math.umn.edu (Mike Ulrich) Date: Mon, 10 Jan 2005 19:00:18 -0600 Subject: nscd, ldap, ssl, and selinux Message-ID: <41E32522.3080703@math.umn.edu> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144731 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144208 nscd has issues reading the cert.pem file with targeted selinux enabled. The cert.pem stores our certificate authority public key, rendering peer checking impossible. The bug reports listed above have more detail. -------------- next part -------------- A non-text attachment was scrubbed... Name: mike.vcf Type: text/x-vcard Size: 318 bytes Desc: not available URL: From selinux at gmail.com Tue Jan 11 05:42:23 2005 From: selinux at gmail.com (Tom London) Date: Mon, 10 Jan 2005 21:42:23 -0800 Subject: kernel-2.6.10-1.1074_FC4 breaks firefox? In-Reply-To: <4c4ba15305011007373ab16694@mail.gmail.com> References: <4c4ba153050108104177ffe4c7@mail.gmail.com> <4c4ba15305010909294acf7e0f@mail.gmail.com> <4c4ba153050110063123e42a7@mail.gmail.com> <4c4ba15305011007373ab16694@mail.gmail.com> Message-ID: <4c4ba153050110214223d62d02@mail.gmail.com> OK. My fault.... This is caused by the Sun java plugin and by the Adobe pdf plugin. Removing them allows firefox to startup and work. Still get these AVCs: Jan 10 21:39:31 fedora kernel: audit(1105421971.189:0): avc: denied { execmem } for pid=6696 comm=firefox-bin scontext=user_u:user_r:user_mozilla_t tcontext=user_u:user_r:user_mozilla_t tclass=process Jan 10 21:39:33 fedora kernel: audit(1105421973.479:0): avc: denied { execmem } for pid=6696 comm=firefox-bin scontext=user_u:user_r:user_mozilla_t tcontext=user_u:user_r:user_mozilla_t tclass=process Jan 10 21:39:33 fedora kernel: audit(1105421973.487:0): avc: denied { execmem } for pid=6696 comm=firefox-bin scontext=user_u:user_r:user_mozilla_t tcontext=user_u:user_r:user_mozilla_t tclass=process tom -- Tom London From sds at epoch.ncsc.mil Tue Jan 11 15:06:51 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Tue, 11 Jan 2005 10:06:51 -0500 Subject: kernel-2.6.10-1.1074_FC4 breaks firefox? In-Reply-To: <4c4ba153050108104177ffe4c7@mail.gmail.com> References: <4c4ba153050108104177ffe4c7@mail.gmail.com> Message-ID: <1105456010.20566.34.camel@moss-spartans.epoch.ncsc.mil> On Sat, 2005-01-08 at 13:41, Tom London wrote: > Running strict/enforcing, latest Rawhide. > > After downloading today's updates, including > kernel-2.6.10-1.1074_FC4, and rebooting, > (and before the kernel oops with a kernel > page fault): > > firefox refuses to start in enforcing mode. Here > are the AVCs: > > Jan 8 10:28:01 fedora kernel: audit(1105208881.086:0): avc: denied > { execmod } for pid=4242 comm=java path=/lib/ld-2.3.4.so dev=hda2 > ino=3178514 scontext=user_u:user_r:user_t > tcontext=system_u:object_r:ld_so_t tclass=file > Jan 8 10:28:01 fedora kernel: audit(1105208881.831:0): avc: denied > { execmem } for pid=4266 comm=firefox-bin > scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_mozilla_t tclass=process > Jan 8 10:28:01 fedora kernel: audit(1105208881.928:0): avc: denied > { execmem } for pid=4266 comm=firefox-bin > scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:user_r:user_mozilla_t tclass=process > > Policy needs fixing for new kernel mods? New controls for executable mappings in SELinux, see http://marc.theaimsgroup.com/?l=linux-kernel&m=110200324503263&w=2. The upstream strict policy includes allow rules for user domains, but not for mozilla, although I suppose this will have to change for compatibility. -- Stephen Smalley National Security Agency From jorton at redhat.com Wed Jan 12 09:44:40 2005 From: jorton at redhat.com (Joe Orton) Date: Wed, 12 Jan 2005 09:44:40 +0000 Subject: labelling issues In-Reply-To: <1102964929.27895.32.camel@moss-spartans.epoch.ncsc.mil> References: <20041203080343.GA28886@redhat.com> <1102081001.29971.33.camel@moss-spartans.epoch.ncsc.mil> <1102081338.29971.37.camel@moss-spartans.epoch.ncsc.mil> <20041208232715.GA8302@redhat.com> <1102598376.32175.22.camel@moss-spartans.epoch.ncsc.mil> <1102598794.32175.24.camel@moss-spartans.epoch.ncsc.mil> <20041209161433.GA11218@redhat.com> <1102964929.27895.32.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20050112094440.GA7899@redhat.com> I notice there are two different types of errors being reported here, is that significant? The first is an open() failure: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140706 Starting httpd: /usr/sbin/httpd: error while loading shared libraries: libpcre.so.0: cannot open shared object file: Permission denied the second is, I presume, an mmap() failure, which means the open() must have succeeded: http://bugs.php.net/bug.php?id=30952 Cannot load /usr/lib/httpd/modules/libphp5.so into server: libpng.so.3: failed to map segment from shared object: Permission denied [FAILED] I've just got the second type of error happening on one of my FC3 test boxes: [root at pepsi ~]# service httpd start Starting httpd: /usr/sbin/httpd: error while loading shared libraries: librt.so.1: failed to map segment from shared object: Permission denied [FAILED] [root at pepsi ~]# dmesg | tail -1 audit(1105522884.846:0): avc: denied { execute } for pid=10455 path=/lib/tls/librt-2.3.4.so dev=hda2 ino=3480245 scontext=root:system_r:httpd_t tcontext=system_u:object_r:lib_t tclass=file [root at pepsi ~]# ls -lZ /lib/tls/librt-2.3.4.so -rwxr-xr-x root root system_u:object_r:lib_t /lib/tls/librt-2.3.4.so which appears to be the correct labelling, no? The box has the current updates installed, there are no SELinux-related errors in prelink.log. joe From parklee_sel at yahoo.com Wed Jan 12 10:32:24 2005 From: parklee_sel at yahoo.com (Park Lee) Date: Wed, 12 Jan 2005 02:32:24 -0800 (PST) Subject: Is there any IPsec-Tools policy available in FC2? Message-ID: <20050112103224.92448.qmail@web51504.mail.yahoo.com> Hi, Is there a IPsec-Tools [1] (i.e. racoon, setkey) policy made for SELinux in Fedora Core 2 ? Thank you. [1] http://ipsec-tools.sourceforge.net/ ===== Best Regards, Park Lee __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com From sds at epoch.ncsc.mil Wed Jan 12 13:55:12 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 12 Jan 2005 08:55:12 -0500 Subject: Is there any IPsec-Tools policy available in FC2? In-Reply-To: <20050112103224.92448.qmail@web51504.mail.yahoo.com> References: <20050112103224.92448.qmail@web51504.mail.yahoo.com> Message-ID: <1105538112.22495.2.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-01-12 at 05:32, Park Lee wrote: > Hi, > Is there a IPsec-Tools [1] (i.e. racoon, setkey) > policy made for SELinux in Fedora Core 2 ? > > Thank you. > > [1] http://ipsec-tools.sourceforge.net/ Petre posted a racoon policy to the selinux list on Oct 25th, see the mailing list archives. There is also an older ipsec policy already in the policy tree. Note btw that you should be running FC3 rather than FC2 if using SELinux; FC2 is deprecated for SELinux users. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Wed Jan 12 14:03:14 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 12 Jan 2005 09:03:14 -0500 Subject: labelling issues In-Reply-To: <20050112094440.GA7899@redhat.com> References: <20041203080343.GA28886@redhat.com> <1102081001.29971.33.camel@moss-spartans.epoch.ncsc.mil> <1102081338.29971.37.camel@moss-spartans.epoch.ncsc.mil> <20041208232715.GA8302@redhat.com> <1102598376.32175.22.camel@moss-spartans.epoch.ncsc.mil> <1102598794.32175.24.camel@moss-spartans.epoch.ncsc.mil> <20041209161433.GA11218@redhat.com> <1102964929.27895.32.camel@moss-spartans.epoch.ncsc.mil> <20050112094440.GA7899@redhat.com> Message-ID: <41E52E22.6040207@redhat.com> Joe Orton wrote: >I notice there are two different types of errors being reported here, is >that significant? The first is an open() failure: > >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140706 >Starting httpd: /usr/sbin/httpd: error while loading shared libraries: >libpcre.so.0: cannot open shared object file: Permission denied > >the second is, I presume, an mmap() failure, which means the open() must >have succeeded: > >http://bugs.php.net/bug.php?id=30952 >Cannot load /usr/lib/httpd/modules/libphp5.so into server: libpng.so.3: >failed to map segment from shared object: Permission denied >[FAILED] > >I've just got the second type of error happening on one of my FC3 test >boxes: > >[root at pepsi ~]# service httpd start >Starting httpd: /usr/sbin/httpd: error while loading shared libraries: >librt.so.1: failed to map segment from shared object: Permission denied > [FAILED] >[root at pepsi ~]# dmesg | tail -1 >audit(1105522884.846:0): avc: denied { execute } for pid=10455 >path=/lib/tls/librt-2.3.4.so dev=hda2 ino=3480245 >scontext=root:system_r:httpd_t tcontext=system_u:object_r:lib_t >tclass=file >[root at pepsi ~]# ls -lZ /lib/tls/librt-2.3.4.so >-rwxr-xr-x root root system_u:object_r:lib_t >/lib/tls/librt-2.3.4.so > >which appears to be the correct labelling, no? The box has the current >updates installed, there are no SELinux-related errors in prelink.log. > > > No they should be shlib_t. You need to restorecon. >joe > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From sds at epoch.ncsc.mil Wed Jan 12 14:37:27 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 12 Jan 2005 09:37:27 -0500 Subject: labelling issues In-Reply-To: <20050112094440.GA7899@redhat.com> References: <20041203080343.GA28886@redhat.com> <1102081001.29971.33.camel@moss-spartans.epoch.ncsc.mil> <1102081338.29971.37.camel@moss-spartans.epoch.ncsc.mil> <20041208232715.GA8302@redhat.com> <1102598376.32175.22.camel@moss-spartans.epoch.ncsc.mil> <1102598794.32175.24.camel@moss-spartans.epoch.ncsc.mil> <20041209161433.GA11218@redhat.com> <1102964929.27895.32.camel@moss-spartans.epoch.ncsc.mil> <20050112094440.GA7899@redhat.com> Message-ID: <1105540647.22495.46.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-01-12 at 04:44, Joe Orton wrote: > I notice there are two different types of errors being reported here, is > that significant? The first is an open() failure: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140706 > Starting httpd: /usr/sbin/httpd: error while loading shared libraries: > libpcre.so.0: cannot open shared object file: Permission denied > > the second is, I presume, an mmap() failure, which means the open() must > have succeeded: > > http://bugs.php.net/bug.php?id=30952 > Cannot load /usr/lib/httpd/modules/libphp5.so into server: libpng.so.3: > failed to map segment from shared object: Permission denied > [FAILED] > > I've just got the second type of error happening on one of my FC3 test > boxes: > > [root at pepsi ~]# service httpd start > Starting httpd: /usr/sbin/httpd: error while loading shared libraries: > librt.so.1: failed to map segment from shared object: Permission denied > [FAILED] > [root at pepsi ~]# dmesg | tail -1 > audit(1105522884.846:0): avc: denied { execute } for pid=10455 > path=/lib/tls/librt-2.3.4.so dev=hda2 ino=3480245 > scontext=root:system_r:httpd_t tcontext=system_u:object_r:lib_t > tclass=file > [root at pepsi ~]# ls -lZ /lib/tls/librt-2.3.4.so > -rwxr-xr-x root root system_u:object_r:lib_t > /lib/tls/librt-2.3.4.so > > which appears to be the correct labelling, no? The box has the current > updates installed, there are no SELinux-related errors in prelink.log. Shared objects are supposed to have shlib_t, not lib_t. The open(2) denial is likely due to a lack of file read permission to lib_t, whereas the mmap(2) denial is likely due to a lack of file execute permission to lib_t. Suggestion for Russell/Dan/Colin/Jim to consider: What if we coalesced lib_t and shlib_t, e.g. made shlib_t a typealias for lib_t rather than a separate type? Then, the default inherit-from-parent-directory labeling would be adequate for preserving the type on shared objects. The downside is that this makes everything under lib directories executable, unless prohibited by DAC, and is a move away from what we ultimately want in a very strict policy (i.e. finer-grained shared object types so that we can bind specific trusted programs to only execute specific shared objects). Possibly only a change for targeted policy. Thoughts? -- Stephen Smalley National Security Agency From parklee_sel at yahoo.com Wed Jan 12 20:18:15 2005 From: parklee_sel at yahoo.com (Park Lee) Date: Wed, 12 Jan 2005 12:18:15 -0800 (PST) Subject: Is there any IPsec-Tools policy available in FC2? In-Reply-To: <41E575A9.7060303@gentoo.org> Message-ID: <20050112201815.33562.qmail@web51503.mail.yahoo.com> On Wed, 12 Jan 2005 at 21:08, petre rodan wrote: > Park Lee wrote: > > Hi, > > Is there a IPsec-Tools [1] (i.e. racoon, setkey) > > policy made for SELinux in Fedora Core 2 ? > > latest Gentoo policies can be found here: >http://dev.gentoo.org/~kaiowas/policy/gentoo/domains/ >program/ipsec.te >http://dev.gentoo.org/~kaiowas/policy/gentoo/file_con >texts/program/ipsec.fc > > net_contexts should also contain: > ifdef(`ipsec.te', `portcon udp 500 > system_u:object_r:isakmp_port_t') > > if you tweak the file contexts for Fedora, please > also send us the changes. I'll try to transform these policies into Fedora Core. But, I'm not familiar with Gentoo. Would you please tell me what the main difference between the two is? and Is there anything else we should take care of in order to do the job? Thanks. ===== Best Regards, Park Lee __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail From sds at epoch.ncsc.mil Wed Jan 12 22:20:44 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 12 Jan 2005 17:20:44 -0500 Subject: kernel-2.6.10-1.1074_FC4 breaks firefox? In-Reply-To: <4c4ba153050108104177ffe4c7@mail.gmail.com> References: <4c4ba153050108104177ffe4c7@mail.gmail.com> Message-ID: <1105568444.23136.67.camel@moss-spartans.epoch.ncsc.mil> On Sat, 2005-01-08 at 13:41, Tom London wrote: > Running strict/enforcing, latest Rawhide. > > After downloading today's updates, including > kernel-2.6.10-1.1074_FC4, and rebooting, > (and before the kernel oops with a kernel > page fault): > > firefox refuses to start in enforcing mode. Here > are the AVCs: > > Jan 8 10:28:01 fedora kernel: audit(1105208881.086:0): avc: denied > { execmod } for pid=4242 comm=java path=/lib/ld-2.3.4.so dev=hda2 > ino=3178514 scontext=user_u:user_r:user_t > tcontext=system_u:object_r:ld_so_t tclass=file This one is suspect. Can you reproduce with a kernel booted with audit=1 enabled so that we can also get the syscall auditing information for this denial? Also, possibly run it under strace and collect the output? -- Stephen Smalley National Security Agency From w5set at alltel.net Wed Jan 12 23:58:44 2005 From: w5set at alltel.net (Steve Thacker) Date: Wed, 12 Jan 2005 17:58:44 -0600 Subject: kernel-2.6.10-1.1074_FC4 breaks firefox? In-Reply-To: <1105568444.23136.67.camel@moss-spartans.epoch.ncsc.mil> References: <4c4ba153050108104177ffe4c7@mail.gmail.com> <1105568444.23136.67.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <41E5B9B4.8060809@alltel.net> Immediately after the Kernel-2.6.10-737_FC3 update here, I couldn't get the Firefox panel button (KDE)to startup Firefox, either (Firefox not something error, didn't read or save this notice, but just fixed the problem). After a little right click on the button and then properties, then application tab, then browsing to /usr/bin/firefox (the command box browse area button) it has worked just fine. New policy in this kernel that did away with the default panel button settings or what? Works just fine now tho. Thanks to all the developers for Fedora Core, I have tried several Linux distro's and have settled on Fedora as it meets and exceeds all my needs from servers to browsers and Desktops. Looks real good too!! thanks ya'll..............steve w5set at alltel.net Stephen Smalley wrote: > On Sat, 2005-01-08 at 13:41, Tom London wrote: > >>Running strict/enforcing, latest Rawhide. >> >>After downloading today's updates, including >>kernel-2.6.10-1.1074_FC4, and rebooting, >> >>firefox refuses to start in enforcing mode. Here >>are the AVCs: >> > > This one is suspect. Can you reproduce with a kernel booted with > audit=1 enabled so that we can also get the syscall auditing information > for this denial? Also, possibly run it under strace and collect the > output? > From selinux at gmail.com Thu Jan 13 06:24:49 2005 From: selinux at gmail.com (Tom London) Date: Wed, 12 Jan 2005 22:24:49 -0800 Subject: kernel-2.6.10-1.1074_FC4 breaks firefox? In-Reply-To: <41E5B9B4.8060809@alltel.net> References: <4c4ba153050108104177ffe4c7@mail.gmail.com> <1105568444.23136.67.camel@moss-spartans.epoch.ncsc.mil> <41E5B9B4.8060809@alltel.net> Message-ID: <4c4ba153050112222453c0e820@mail.gmail.com> > > This one is suspect. Can you reproduce with a kernel booted with > > audit=1 enabled so that we can also get the syscall auditing information > > for this denial? Also, possibly run it under strace and collect the > > output? > > > Uhhh..I came home, put libjavaplugin_oji.so back into /usr/mozilla/plugins (I had moved it into /usr/mozilla), and rebooted with audit=1 as your suggested. I know this is going to sound crazy, but it no longer fails as before. I'm running selinux-policy-strict-1.20.1-3 now (was running earlier policy when I filed the report). I see that mozilla_macros.te has allow $1_mozilla_t self:process { execmem setrlimit setsched }; Could this have 'fixed' this? tom -- Tom London From selinux at gmail.com Thu Jan 13 06:27:00 2005 From: selinux at gmail.com (Tom London) Date: Wed, 12 Jan 2005 22:27:00 -0800 Subject: kernel-2.6.10-1.1074_FC4 breaks firefox? In-Reply-To: <4c4ba153050112222453c0e820@mail.gmail.com> References: <4c4ba153050108104177ffe4c7@mail.gmail.com> <1105568444.23136.67.camel@moss-spartans.epoch.ncsc.mil> <41E5B9B4.8060809@alltel.net> <4c4ba153050112222453c0e820@mail.gmail.com> Message-ID: <4c4ba153050112222752f55a84@mail.gmail.com> Sorry.... I'm also now running kernel 1076_FC4. -- Tom London From parklee_sel at yahoo.com Thu Jan 13 11:12:13 2005 From: parklee_sel at yahoo.com (Park Lee) Date: Thu, 13 Jan 2005 03:12:13 -0800 (PST) Subject: Is there any IPsec-Tools policy available in FC2? In-Reply-To: <41E626E0.7070209@gentoo.org> Message-ID: <20050113111213.73850.qmail@web51507.mail.yahoo.com> On Wed, 12 Jan 2005 at 21:08, Petre Rodan wrote: > latest Gentoo policies can be found here: > > http://dev.gentoo.org/~kaiowas/policy/gentoo/domains/program/ipsec.te > http://dev.gentoo.org/~kaiowas/policy/gentoo/file_contexts/program/ipsec.fc > > net_contexts should also contain: > ifdef(`ipsec.te', `portcon udp 500 system_u:object_r:isakmp_port_t') I've made some modifications in the ipsec.te and ipsec.fc you mentioned above.and put them into the proper location in Fedora Core 2. When I ran 'make load' in src/policy directory. There came a WARNING as following: ... ... /usr/bin/checkpolicy: loading policy configuration from policy.conf domains/program/ipsec.te:63:WARNING 'conflicting rule for (sysadm_locate_t, setkey_exec_t:process): default was setkey_t, is now sysadm_setkey_t' at token ';' on line 120846: #line 63 type_transition sysadm_t setkey_exec_t:process sysadm_setkey_t; ... ... Why did it bring out such a WARNING? Is there a method to solve it? Thank you. ===== Best Regards, Park Lee __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com From sds at epoch.ncsc.mil Thu Jan 13 15:45:56 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 13 Jan 2005 10:45:56 -0500 Subject: kernel-2.6.10-1.1074_FC4 breaks firefox? In-Reply-To: <4c4ba153050112222453c0e820@mail.gmail.com> References: <4c4ba153050108104177ffe4c7@mail.gmail.com> <1105568444.23136.67.camel@moss-spartans.epoch.ncsc.mil> <41E5B9B4.8060809@alltel.net> <4c4ba153050112222453c0e820@mail.gmail.com> Message-ID: <1105631156.24406.4.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-01-13 at 01:24, Tom London wrote: > Uhhh..I came home, put libjavaplugin_oji.so back into /usr/mozilla/plugins > (I had moved it into /usr/mozilla), and rebooted with audit=1 as your > suggested. > > I know this is going to sound crazy, but it no longer fails as before. > I'm running selinux-policy-strict-1.20.1-3 now (was running earlier > policy when I filed the report). > > I see that mozilla_macros.te has > allow $1_mozilla_t self:process { execmem setrlimit setsched }; > > Could this have 'fixed' this? I'm concerned about the execmod denial on ld.so, not the execmem denials. I think Dan added both to the policy, but we need to remove the execmod rule and debug this further, because it seems wrong. -- Stephen Smalley National Security Agency From selinux at gmail.com Thu Jan 13 16:23:10 2005 From: selinux at gmail.com (Tom London) Date: Thu, 13 Jan 2005 08:23:10 -0800 Subject: kernel-2.6.10-1.1074_FC4 breaks firefox? In-Reply-To: <1105631156.24406.4.camel@moss-spartans.epoch.ncsc.mil> References: <4c4ba153050108104177ffe4c7@mail.gmail.com> <1105568444.23136.67.camel@moss-spartans.epoch.ncsc.mil> <41E5B9B4.8060809@alltel.net> <4c4ba153050112222453c0e820@mail.gmail.com> <1105631156.24406.4.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4c4ba15305011308236295ece0@mail.gmail.com> On Thu, 13 Jan 2005 10:45:56 -0500, Stephen Smalley wrote: > I'm concerned about the execmod denial on ld.so, not the execmem > denials. I think Dan added both to the policy, but we need to remove > the execmod rule and debug this further, because it seems wrong. > Understand. I see the execmod rule in base_user_macros.te. How can I help? Would it be useful for me to remove the execmod rule for ld_so_t from there and rerun with audit=1? Something else? tom -- Tom London From sds at epoch.ncsc.mil Thu Jan 13 16:34:46 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 13 Jan 2005 11:34:46 -0500 Subject: kernel-2.6.10-1.1074_FC4 breaks firefox? In-Reply-To: <4c4ba15305011308236295ece0@mail.gmail.com> References: <4c4ba153050108104177ffe4c7@mail.gmail.com> <1105568444.23136.67.camel@moss-spartans.epoch.ncsc.mil> <41E5B9B4.8060809@alltel.net> <4c4ba153050112222453c0e820@mail.gmail.com> <1105631156.24406.4.camel@moss-spartans.epoch.ncsc.mil> <4c4ba15305011308236295ece0@mail.gmail.com> Message-ID: <1105634086.24406.52.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-01-13 at 11:23, Tom London wrote: > Understand. I see the execmod rule in base_user_macros.te. > > How can I help? > > Would it be useful for me to remove the execmod rule for > ld_so_t from there and rerun with audit=1? Something else? Yes. And also to run it under strace (in permissive mode) and collect the output to send to me. However, this looks similar to me to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133505, except that was caused by faulty logic in the mmap/mprotect hooks. But reading the comments in that bug report suggests that ld.so is being mapped writable (in a private mapping) and modified, which would run into this execmod check. -- Stephen Smalley National Security Agency From rj at baucells.org Thu Jan 13 18:54:13 2005 From: rj at baucells.org (Rogelio J. Baucells) Date: Thu, 13 Jan 2005 13:54:13 -0500 Subject: dhcpd targeted policy Message-ID: <41E6C3D5.1010304@baucells.org> Hi, I am running a FC3 computer with the latest targeted policy (selinux-policy-targeted-1.17.30-2.68) and I am getting the following messages at the time dhcpd starts: ----------------------------------------------------------------- audit(1105547723.050:0): avc: denied { net_admin } for pid=6247 exe=/usr/sbin/dhcpd capability=12 scontext=root:system_r:dhcpd_t tcontext=root:system_r:dhcpd_t tclass=capability audit(1105547723.244:0): avc: denied { read } for pid=6247 exe=/usr/sbin/dhcpd name=cacert.org.pem dev=hdc2 ino=230129 scontext=root:system_r:dhcpd_t tcontext=system_u:object_r:usr_t tclass=file ----------------------------------------------------------------- I looked at the configuration file (dhcpd.conf) and I do not see any place where I am referencing the cacert.org cert file. I use that file for other services and it is located at (/usr/share/ssl/certs). Is there any information on how to resolve this errors? Thanks RJB From steve at atc-nycorp.com Thu Jan 13 21:47:11 2005 From: steve at atc-nycorp.com (Steve Brueckner) Date: Thu, 13 Jan 2005 16:47:11 -0500 Subject: Creating new roles Message-ID: <60D45469A1AAD311A04C009027B6BF6804FCEFF7@server20.inside.oracorp.com> I'm just getting started with SELinux. I've read a bunch and just installed FC3. I'm trying to add a new role, but can't figure out where roles are defined. The O'Reilly book says they're "scattered around the policy tree" and Debian references say they're in users.te, which doesn't appear to exist in FC3. If I can find where the few extant roles are defined, I can probably figure out how to define my own. Or should I be trying to do it from scratch by making a new file? In which case I could use some hints on how to do it. - Steve From sds at epoch.ncsc.mil Thu Jan 13 21:51:04 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 13 Jan 2005 16:51:04 -0500 Subject: Creating new roles In-Reply-To: <60D45469A1AAD311A04C009027B6BF6804FCEFF7@server20.inside.oracorp.com> References: <60D45469A1AAD311A04C009027B6BF6804FCEFF7@server20.inside.oracorp.com> Message-ID: <1105653064.24406.190.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-01-13 at 16:47, Steve Brueckner wrote: > I'm just getting started with SELinux. I've read a bunch and just installed > FC3. > > I'm trying to add a new role, but can't figure out where roles are defined. > The O'Reilly book says they're "scattered around the policy tree" and Debian > references say they're in users.te, which doesn't appear to exist in FC3. > > If I can find where the few extant roles are defined, I can probably figure > out how to define my own. Or should I be trying to do it from scratch by > making a new file? In which case I could use some hints on how to do it. By default, FC3 uses the "targeted" policy, which only confines specific network services and does not have any real notion of user roles and domains. You can switch to the "strict" policy by installing it (e.g. yum install selinux-policy-strict*) and then using system-config-securitylevel GUI to set the active policy to it and rebooting, at which point it should automatically relabel. Or manually, you can just edit /etc/selinux/config to set the SELINUXTYPE to strict, reboot single user, and run fixfiles relabel by hand, then bring the system up the rest of the way. Have you read the Fedora SELinux FAQ? http://fedora.redhat.com/docs/selinux-faq-fc3/ -- Stephen Smalley National Security Agency From steve at atc-nycorp.com Thu Jan 13 22:47:57 2005 From: steve at atc-nycorp.com (Steve Brueckner) Date: Thu, 13 Jan 2005 17:47:57 -0500 Subject: Creating new roles Message-ID: <60D45469A1AAD311A04C009027B6BF6804FCEFF8@server20.inside.oracorp.com> I spent my first couple of days in SELinux tinkering with FC2, and only installed FC3 today. It's possible I may not yet fully appreciate the differences in working with the targeted policy. I see now that even though multiple roles are defined, they're all assigned to the unconfined_t domain. The targeted policy appeals to me for the obvious reasons: I'd like most of the system to run without the complications introduced by SELinux. I'd rather not go back to the strict policy unless I have to. My goal, however, is to do some fairly serious policy writing to lock down a few applications, but leave most of the system alone. I think I'll need to make new domains, new roles, and new transitions to do this. >From my limited understanding, it looks like even though the default targeted policy is role-blind, I should be able to modify it to add my own custom roles that aren't of type unconfined_t. After all, it's still SELinux under the hood, isn't it? Or am I missing something fundamental? Will I have no choice but to use the strict policy as my starting point? - Steve -----Original Message----- From: Stephen Smalley [mailto:sds at epoch.ncsc.mil] Sent: Thursday, January 13, 2005 4:51 PM To: Fedora SELinux support list for users & developers. Subject: Re: Creating new roles On Thu, 2005-01-13 at 16:47, Steve Brueckner wrote: > I'm just getting started with SELinux. I've read a bunch and just installed > FC3. > > I'm trying to add a new role, but can't figure out where roles are defined. > The O'Reilly book says they're "scattered around the policy tree" and Debian > references say they're in users.te, which doesn't appear to exist in FC3. > > If I can find where the few extant roles are defined, I can probably figure > out how to define my own. Or should I be trying to do it from scratch by > making a new file? In which case I could use some hints on how to do it. By default, FC3 uses the "targeted" policy, which only confines specific network services and does not have any real notion of user roles and domains. You can switch to the "strict" policy by installing it (e.g. yum install selinux-policy-strict*) and then using system-config-securitylevel GUI to set the active policy to it and rebooting, at which point it should automatically relabel. Or manually, you can just edit /etc/selinux/config to set the SELINUXTYPE to strict, reboot single user, and run fixfiles relabel by hand, then bring the system up the rest of the way. Have you read the Fedora SELinux FAQ? http://fedora.redhat.com/docs/selinux-faq-fc3/ -- 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 From sds at epoch.ncsc.mil Fri Jan 14 12:36:47 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 14 Jan 2005 07:36:47 -0500 Subject: Creating new roles In-Reply-To: <60D45469A1AAD311A04C009027B6BF6804FCEFF8@server20.inside.oracorp.com> References: <60D45469A1AAD311A04C009027B6BF6804FCEFF8@server20.inside.oracorp.com> Message-ID: <1105706207.26366.3.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-01-13 at 17:47, Steve Brueckner wrote: > I spent my first couple of days in SELinux tinkering with FC2, and only > installed FC3 today. It's possible I may not yet fully appreciate the > differences in working with the targeted policy. I see now that even though > multiple roles are defined, they're all assigned to the unconfined_t domain. > > The targeted policy appeals to me for the obvious reasons: I'd like most of > the system to run without the complications introduced by SELinux. I'd > rather not go back to the strict policy unless I have to. > > My goal, however, is to do some fairly serious policy writing to lock down a > few applications, but leave most of the system alone. I think I'll need to > make new domains, new roles, and new transitions to do this. > > >From my limited understanding, it looks like even though the default > targeted policy is role-blind, I should be able to modify it to add my own > custom roles that aren't of type unconfined_t. After all, it's still > SELinux under the hood, isn't it? Or am I missing something fundamental? > Will I have no choice but to use the strict policy as my starting point? The mechanism is the same, only the policy configuration differs. But the differences in the policy configurations are substantial and structural, and it should be easier to take the strict policy as your starting point and move certain programs into its unconfined_t domain if you truly want user roles and domains. But if you merely want to lock down additional applications, you can do that with the targeted policy, and you do not need new roles at all, just domains for those programs. The process transition permission controls the ability to transition among domains on a pairwise basis, so the fact that domains foo, bar, and baz are all associated with role R does not mean that they can jump among each other. -- Stephen Smalley National Security Agency From walters at redhat.com Fri Jan 14 16:47:33 2005 From: walters at redhat.com (Colin Walters) Date: Fri, 14 Jan 2005 11:47:33 -0500 Subject: /selinux/null being labeled as root_t? Message-ID: <1105721253.24456.12.camel@nexus.verbum.private> Hi, I'm seeing an odd denial on my FC2 server after the latest kernel updates. Jan 14 11:38:15 monk kernel: audit(1105720695.913:0): avc: denied { getattr } for pid=6661 exe=/usr/sbin/sendmail.postfix path=/null dev=selinuxfs ino=189 scontext=zosima:staff_r:staff_mail_t tcontext=system_u:object_r:root_t tclass=chr_file So this is the /selinux/null file, which should be labeled with security_t, correct? My genfscon file just has: # selinuxfs genfscon selinuxfs / system_u:object_r:security_t I'm pretty sure this is a kernel problem since I haven't changed my policy in some time. (Yes, I plan to upgrade to FC3 soon :)) From sds at epoch.ncsc.mil Fri Jan 14 16:50:42 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 14 Jan 2005 11:50:42 -0500 Subject: /selinux/null being labeled as root_t? In-Reply-To: <1105721253.24456.12.camel@nexus.verbum.private> References: <1105721253.24456.12.camel@nexus.verbum.private> Message-ID: <1105721442.26366.128.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-01-14 at 11:47, Colin Walters wrote: > Hi, > > I'm seeing an odd denial on my FC2 server after the latest kernel > updates. > > Jan 14 11:38:15 monk kernel: audit(1105720695.913:0): avc: denied { getattr } for pid=6661 exe=/usr/sbin/sendmail.postfix path=/null dev=selinuxfs ino=189 scontext=zosima:staff_r:staff_mail_t tcontext=system_u:object_r:root_t tclass=chr_file > > So this is the /selinux/null file, which should be labeled with > security_t, correct? My genfscon file just has: > > # selinuxfs > genfscon selinuxfs / system_u:object_r:security_t > > I'm pretty sure this is a kernel problem since I haven't changed my > policy in some time. > > (Yes, I plan to upgrade to FC3 soon :)) This is one of the problems that surfaced a long time ago in FC2 because of a lack of any coordinated policy update for the kernel updates. When we introduced the code to re-open descriptors to the null device when SELinux closes them upon a context-changing execve, we defined and used an initial SID to label the null device node, as it is setup before initial policy load and is assigned directly by the kernel. That required a coordinated policy change to define the initial SID and assign it a security context. In the absence of such a policy definition, the initial SID value being used by the kernel is just getting re-used for some dynamically allocated SID, in this case, the SID of the first inode brought incore. So you need to update your policy to include the definition in initial_sids and initial_sid_contexts, and reboot (as initial SID changes can only take affect during initialization, not upon a policy reload). -- Stephen Smalley National Security Agency From aoliva at redhat.com Fri Jan 14 22:13:43 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 14 Jan 2005 20:13:43 -0200 Subject: load_policy in chroot question In-Reply-To: <1105330805.4605.41.camel@nexus.verbum.private> References: <1105250107.4246.14.camel@chaucer> <1105292885.4605.21.camel@nexus.verbum.private> <1105329074.3254.20.camel@chaucer> <1105330805.4605.41.camel@nexus.verbum.private> Message-ID: On Jan 10, 2005, Colin Walters wrote: > What is it specifically that you are doing with the chroot? Building > RPMs? In my case, what I used to do was to maintain two or more installs on each box, each of them up-to-date, such that, in case I messed up with the daily-use install (say rawhide), I could go back to a known-good install (say FC3 or even FC2). Ever since SELinux came into the picture, it became impossible to do this properly. What would be really nice would be if loading a policy into selinux affected the behavior within that chroot (or rather within the directory tree accessible from the root at the time of policy load), while leaving the policy for the original root alone. I suppose this would be tricky to implement, but I don't see that it would be impossible nor insecure. You might of course need some policy tweaks to enable a chroot dir to have a policy loaded inside it, that might override the part of the original-root policy that applied to the chroot, but nothing outside the chroot. Or something along these lines. Personally, I'd find this useful, although now I see that, in order to keep a known-good alternate distro available, I'd better not be installing updates on it, since the updates might sometimes make it, erhm, ungood :-) -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From walters at redhat.com Sat Jan 15 00:32:49 2005 From: walters at redhat.com (Colin Walters) Date: Fri, 14 Jan 2005 19:32:49 -0500 Subject: load_policy in chroot question In-Reply-To: References: <1105250107.4246.14.camel@chaucer> <1105292885.4605.21.camel@nexus.verbum.private> <1105329074.3254.20.camel@chaucer> <1105330805.4605.41.camel@nexus.verbum.private> Message-ID: <1105749169.4413.22.camel@nexus.verbum.private> On Fri, 2005-01-14 at 20:13 -0200, Alexandre Oliva wrote: > On Jan 10, 2005, Colin Walters wrote: > > > What is it specifically that you are doing with the chroot? Building > > RPMs? > > In my case, what I used to do was to maintain two or more installs on > each box, each of them up-to-date, such that, in case I messed up with > the daily-use install (say rawhide), I could go back to a known-good > install (say FC3 or even FC2). Xen. From selinux at gmail.com Sat Jan 15 19:55:33 2005 From: selinux at gmail.com (Tom London) Date: Sat, 15 Jan 2005 11:55:33 -0800 Subject: hald, udev ... Message-ID: <4c4ba15305011511556d34303@mail.gmail.com> Running strict/enforcing off of Rawhide, kernel-2.6.10-1.1087_FC4. After applying today's updates, but booting above kernel (1089 has problems....) I get the following AVCs: Jan 15 11:38:33 fedora kernel: audit(1105789089.441:0): avc: denied { search } for pid=1501 exe=/bin/bash name=modules dev=hda2 ino=3178500 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:modules_object_t tclass=dir Jan 15 11:38:33 fedora kernel: audit(1105789091.037:0): avc: denied { search } for pid=1659 exe=/bin/bash name=usb dev=hda2 ino=4456490 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:hotplug_var_run_t tclass=dir Jan 15 11:38:33 fedora kernel: audit(1105789091.040:0): avc: denied { search } for pid=1659 exe=/bin/bash name=modules dev=hda2 ino=3178500 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:modules_object_t tclass=dir Jan 15 11:38:33 fedora kernel: audit(1105789091.055:0): avc: denied { search } for pid=1691 exe=/bin/bash name=usb dev=hda2 ino=4456490 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:hotplug_var_run_t tclass=dir Jan 15 11:38:33 fedora kernel: audit(1105789091.057:0): avc: denied { search } for pid=1691 exe=/bin/bash name=modules dev=hda2 ino=3178500 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:modules_object_t tclass=dir Jan 15 11:38:33 fedora kernel: audit(1105789091.869:0): avc: denied { search } for pid=1688 exe=/bin/bash name=usb dev=hda2 ino=4456490 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:hotplug_var_run_t tclass=dir Jan 15 11:38:33 fedora kernel: audit(1105789091.872:0): avc: denied { search } for pid=1688 exe=/bin/bash name=modules dev=hda2 ino=3178500 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:modules_object_t tclass=dir Jan 15 11:38:33 fedora kernel: audit(1105789092.598:0): avc: denied { search } for pid=1724 exe=/bin/bash name=usb dev=hda2 ino=4456490 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:hotplug_var_run_t tclass=dir Jan 15 11:38:33 fedora kernel: audit(1105789092.601:0): avc: denied { search } for pid=1724 exe=/bin/bash name=modules dev=hda2 ino=3178500 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:modules_object_t tclass=dir Jan 15 11:38:33 fedora kernel: audit(1105789093.046:0): avc: denied { search } for pid=1735 exe=/bin/bash name=modules dev=hda2 ino=3178500 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:modules_object_t tclass=dir Jan 15 11:38:33 fedora kernel: audit(1105789093.091:0): avc: denied { search } for pid=1772 exe=/bin/bash name=modules dev=hda2 ino=3178500 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:modules_object_t tclass=dir Jan 15 11:38:33 fedora kernel: audit(1105789093.120:0): avc: denied { search } for pid=1779 exe=/bin/bash name=modules dev=hda2 ino=3178500 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:modules_object_t tclass=dir Jan 15 11:39:02 fedora kernel: audit(1105817942.699:0): avc: denied { search } for pid=2766 exe=/usr/sbin/hald name=net dev=proc ino=-268435434 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:proc_net_t tclass=dir Jan 15 11:39:02 fedora kernel: audit(1105817942.924:0): avc: denied { search } for pid=2766 exe=/usr/sbin/hald name=net dev=proc ino=-268435434 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:proc_net_t tclass=dir suggesting: r_dir_file(hald_t, proc_net_t) r_dir_file(udev_t, {hotplug_var_t modules_object_t}) tom -- Tom London From selinux at gmail.com Sat Jan 15 20:25:57 2005 From: selinux at gmail.com (Tom London) Date: Sat, 15 Jan 2005 12:25:57 -0800 Subject: kgpg, execmod... Message-ID: <4c4ba1530501151225258e2a47@mail.gmail.com> running strict/enforcing, latest rawhide. Trying to start kgpg rusults in: [tbl at fedora mozExtensions]$ kgpg gpg: error while loading shared libraries: cannot restore segment prot after reloc: Permission denied gpg: error while loading shared libraries: cannot restore segment prot after reloc: Permission denied [tbl at fedora mozExtensions]$ Here are the AVCs. Notice the execmod denial: Jan 15 12:15:02 fedora crond(pam_unix)[3567]: session closed for user root Jan 15 12:19:06 fedora kernel: audit(1105820346.545:0): avc: denied { read } for pid=3583 exe=/usr/bin/kgpg name=gpg.conf dev=hda2 ino=3802156 scontext=user_u:user_r:user_t tcontext=system_u:object_r:user_gpg_secret_t tclass=file Jan 15 12:19:07 fedora kernel: audit(1105820347.033:0): avc: denied { execmod } for pid=3597 comm=gpg path=/usr/bin/gpg dev=hda2 ino=4127070 scontext=user_u:user_r:user_gpg_t tcontext=system_u:object_r:gpg_exec_t tclass=file Jan 15 12:19:07 fedora kernel: audit(1105820347.035:0): avc: denied { read } for pid=3583 exe=/usr/bin/kgpg name=gpg.conf dev=hda2 ino=3802156 scontext=user_u:user_r:user_t tcontext=system_u:object_r:user_gpg_secret_t tclass=file Jan 15 12:19:07 fedora kernel: audit(1105820347.043:0): avc: denied { execmod } for pid=3598 comm=gpg path=/usr/bin/gpg dev=hda2 ino=4127070 scontext=user_u:user_r:user_gpg_t tcontext=system_u:object_r:gpg_exec_t tclass=file Jan 15 12:19:07 fedora kernel: audit(1105820347.074:0): avc: denied { read } for pid=3583 exe=/usr/bin/kgpg name=gpg.conf dev=hda2 ino=3802156 scontext=user_u:user_r:user_t tcontext=system_u:object_r:user_gpg_secret_t tclass=file Jan 15 12:19:07 fedora kernel: audit(1105820347.143:0): avc: denied { read } for pid=3583 exe=/usr/bin/kgpg name=gpg.conf dev=hda2 ino=3802156 scontext=user_u:user_r:user_t tcontext=system_u:object_r:user_gpg_secret_t tclass=file allow user_gpg_t gpg_exec_t:file execmod; I'm gun shy to be sprinkling these around. Any thoughts/help? tom -- Tom London From rirving at antient.org Sun Jan 16 01:32:08 2005 From: rirving at antient.org (Richard Irving) Date: Sat, 15 Jan 2005 20:32:08 -0500 Subject: hald, udev ... In-Reply-To: <4c4ba15305011511556d34303@mail.gmail.com> References: <4c4ba15305011511556d34303@mail.gmail.com> Message-ID: <41E9C418.4060506@antient.org> Any chance you had selinux deactivated when you applied the updates ? You may want to re-enable it, and run relabel. I had a similar problem after updating when I had enforcing turned off. Just a thought. Tom London wrote: > Running strict/enforcing off of Rawhide, > kernel-2.6.10-1.1087_FC4. > > After applying today's updates, but booting > above kernel (1089 has problems....) > I get the following AVCs: > > Jan 15 11:38:33 fedora kernel: audit(1105789089.441:0): avc: denied > { search } for pid=1501 exe=/bin/bash name=modules dev=hda2 > ino=3178500 scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:modules_object_t tclass=dir > Jan 15 11:38:33 fedora kernel: audit(1105789091.037:0): avc: denied > { search } for pid=1659 exe=/bin/bash name=usb dev=hda2 ino=4456490 > scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:hotplug_var_run_t tclass=dir > Jan 15 11:38:33 fedora kernel: audit(1105789091.040:0): avc: denied > { search } for pid=1659 exe=/bin/bash name=modules dev=hda2 > ino=3178500 scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:modules_object_t tclass=dir > Jan 15 11:38:33 fedora kernel: audit(1105789091.055:0): avc: denied > { search } for pid=1691 exe=/bin/bash name=usb dev=hda2 ino=4456490 > scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:hotplug_var_run_t tclass=dir > Jan 15 11:38:33 fedora kernel: audit(1105789091.057:0): avc: denied > { search } for pid=1691 exe=/bin/bash name=modules dev=hda2 > ino=3178500 scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:modules_object_t tclass=dir > Jan 15 11:38:33 fedora kernel: audit(1105789091.869:0): avc: denied > { search } for pid=1688 exe=/bin/bash name=usb dev=hda2 ino=4456490 > scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:hotplug_var_run_t tclass=dir > Jan 15 11:38:33 fedora kernel: audit(1105789091.872:0): avc: denied > { search } for pid=1688 exe=/bin/bash name=modules dev=hda2 > ino=3178500 scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:modules_object_t tclass=dir > Jan 15 11:38:33 fedora kernel: audit(1105789092.598:0): avc: denied > { search } for pid=1724 exe=/bin/bash name=usb dev=hda2 ino=4456490 > scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:hotplug_var_run_t tclass=dir > Jan 15 11:38:33 fedora kernel: audit(1105789092.601:0): avc: denied > { search } for pid=1724 exe=/bin/bash name=modules dev=hda2 > ino=3178500 scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:modules_object_t tclass=dir > Jan 15 11:38:33 fedora kernel: audit(1105789093.046:0): avc: denied > { search } for pid=1735 exe=/bin/bash name=modules dev=hda2 > ino=3178500 scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:modules_object_t tclass=dir > Jan 15 11:38:33 fedora kernel: audit(1105789093.091:0): avc: denied > { search } for pid=1772 exe=/bin/bash name=modules dev=hda2 > ino=3178500 scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:modules_object_t tclass=dir > Jan 15 11:38:33 fedora kernel: audit(1105789093.120:0): avc: denied > { search } for pid=1779 exe=/bin/bash name=modules dev=hda2 > ino=3178500 scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:modules_object_t tclass=dir > Jan 15 11:39:02 fedora kernel: audit(1105817942.699:0): avc: denied > { search } for pid=2766 exe=/usr/sbin/hald name=net dev=proc > ino=-268435434 scontext=system_u:system_r:hald_t > tcontext=system_u:object_r:proc_net_t tclass=dir > Jan 15 11:39:02 fedora kernel: audit(1105817942.924:0): avc: denied > { search } for pid=2766 exe=/usr/sbin/hald name=net dev=proc > ino=-268435434 scontext=system_u:system_r:hald_t > tcontext=system_u:object_r:proc_net_t tclass=dir > > suggesting: > r_dir_file(hald_t, proc_net_t) > r_dir_file(udev_t, {hotplug_var_t modules_object_t}) > > tom > > From selinux at gmail.com Sun Jan 16 02:03:38 2005 From: selinux at gmail.com (Tom London) Date: Sat, 15 Jan 2005 18:03:38 -0800 Subject: hald, udev ... In-Reply-To: <41E9C418.4060506@antient.org> References: <4c4ba15305011511556d34303@mail.gmail.com> <41E9C418.4060506@antient.org> Message-ID: <4c4ba15305011518031d5e16c@mail.gmail.com> On Sat, 15 Jan 2005 20:32:08 -0500, Richard Irving wrote: > Any chance you had selinux deactivated when > you applied the updates ? > > You may want to re-enable it, and run > relabel. > > I had a similar problem after updating > when I had enforcing turned off. > > Just a thought. > > Nah. Always on 'strict/enforcing'. This may have something to do with the new cpio being broken and messing up the initrd..... tom -- Tom London From aoliva at redhat.com Sun Jan 16 18:20:32 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 16 Jan 2005 16:20:32 -0200 Subject: load_policy in chroot question In-Reply-To: <1105749169.4413.22.camel@nexus.verbum.private> References: <1105250107.4246.14.camel@chaucer> <1105292885.4605.21.camel@nexus.verbum.private> <1105329074.3254.20.camel@chaucer> <1105330805.4605.41.camel@nexus.verbum.private> <1105749169.4413.22.camel@nexus.verbum.private> Message-ID: On Jan 14, 2005, Colin Walters wrote: > On Fri, 2005-01-14 at 20:13 -0200, Alexandre Oliva wrote: >> On Jan 10, 2005, Colin Walters wrote: >> >> > What is it specifically that you are doing with the chroot? Building >> > RPMs? >> >> In my case, what I used to do was to maintain two or more installs on >> each box, each of them up-to-date, such that, in case I messed up with >> the daily-use install (say rawhide), I could go back to a known-good >> install (say FC3 or even FC2). > Xen. Not available in neither FC3 nor FC2 kernels. Nor earlier releases of FC, for that matter, where the significant kernel differences would make it even trickier. Xen is the way forward. Keeping earlier installs is a way to go back. So Xen is not an option, as appealing as it might seem. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From i.pilcher at comcast.net Sun Jan 16 23:02:27 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Sun, 16 Jan 2005 17:02:27 -0600 Subject: Getting PostgreSQL working again Message-ID: I just returned from 5 weeks out of the country, and one of the updates that rolled out in that time is preventing PostgreSQL from starting. The exact error message is: Jan 16 16:57:53 home kernel: audit(1105916273.121:0): avc: denied { read } for pid=7164 exe=/usr/bin/postgres name=PG_VERSION dev=md1 ino=296800 scontext=root:system_r:postgresql_t tcontext=user_u:object_r:var_lib_t tclass=file I found one thread about this problem, but it did not seem to contain a solution. (Unlike that poster, my database is in my root filesystem.) I'm all for a theoretical discussion about why this happened, but I would also really appreciate anyone who can tell me how to get things working again. Thanks! -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From Valdis.Kletnieks at vt.edu Mon Jan 17 00:09:13 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 16 Jan 2005 19:09:13 -0500 Subject: load_policy in chroot question In-Reply-To: Your message of "Sun, 16 Jan 2005 16:20:32 -0200." References: <1105250107.4246.14.camel@chaucer> <1105292885.4605.21.camel@nexus.verbum.private> <1105329074.3254.20.camel@chaucer> <1105330805.4605.41.camel@nexus.verbum.private> <1105749169.4413.22.camel@nexus.verbum.private> Message-ID: <200501170009.j0H09DrH011253@turing-police.cc.vt.edu> On Sun, 16 Jan 2005 16:20:32 -0200, Alexandre Oliva said: > On Jan 14, 2005, Colin Walters wrote: > > Xen. > > Not available in neither FC3 nor FC2 kernels. It *is* however in the current FC-devel tree. (I haven't actually tried it myself, as I'm usually running a custom kernel that resembles a -mm kernel with -execshield and Ingo's -RT patches on top...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From justin.conover at gmail.com Mon Jan 17 16:10:54 2005 From: justin.conover at gmail.com (Justin Conover) Date: Mon, 17 Jan 2005 10:10:54 -0600 Subject: SELinux on CentOS 3.4? Message-ID: Does anyone know if it is possible to install SELinux on CentOS? I thought Dan Walsh used to have a rhel 3.0 script that would add a yum.repo and install the packages, but I don't see it. ftp://people.redhat.com/dwalsh/SELinux/ Could I simply grab/rebuild the srpms and install those on to it or would that be a dep nightmare. ftp://people.redhat.com/dwalsh/SELinux/srpms/ thx, From aoliva at redhat.com Mon Jan 17 16:17:00 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 17 Jan 2005 14:17:00 -0200 Subject: load_policy in chroot question In-Reply-To: <200501170009.j0H09DrH011253@turing-police.cc.vt.edu> References: <1105250107.4246.14.camel@chaucer> <1105292885.4605.21.camel@nexus.verbum.private> <1105329074.3254.20.camel@chaucer> <1105330805.4605.41.camel@nexus.verbum.private> <1105749169.4413.22.camel@nexus.verbum.private> <200501170009.j0H09DrH011253@turing-police.cc.vt.edu> Message-ID: On Jan 16, 2005, Valdis.Kletnieks at vt.edu wrote: > On Sun, 16 Jan 2005 16:20:32 -0200, Alexandre Oliva said: >> On Jan 14, 2005, Colin Walters wrote: >> > Xen. >> >> Not available in neither FC3 nor FC2 kernels. > It *is* however in the current FC-devel tree. Yeah, sure, but how does this help installing updates on my existing alternate FC1 or FC2 installs, without having to reboot FC3 or rawhide into them? Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From steve at atc-nycorp.com Mon Jan 17 16:27:32 2005 From: steve at atc-nycorp.com (Steve Brueckner) Date: Mon, 17 Jan 2005 11:27:32 -0500 Subject: New user/role transition error Message-ID: <60D45469A1AAD311A04C009027B6BF6804FCF002@server20.inside.oracorp.com> I'm trying to add a new role and test it by adding a user with access to that role. I can su to the new user, but then when I try to newrole I get "... is not a valid context". Here are my steps so far; I'm starting from the default strict policy: #useradd engineer Added the following to .../strict/src/policy/users user engineer roles { user_r developer_r }; Added the following to .../strict/src/policy/domains/user.te full_user_role(developer) allow system_r developer_r allow sysadm_r developer_r allow user_r developer_r allow staff_r developer_r Added the following into in_user_role macro in .../strict/src/policy/macros/user_macros.te role developer_r types $1; Added the following to .../strict/src/policy/appconfig/default_type developer_r:user_t #make load steve$ id -Z user_u:user_r:user_t steve$ su engineer engineer$ id -Z engineer:user_r:user_t engineer$ newrole -r developer_r engineer:developer_r:user_t is not a valid context Any ideas what I've neglected in setting this up? Thanks! From selinux at gmail.com Mon Jan 17 18:01:02 2005 From: selinux at gmail.com (Tom London) Date: Mon, 17 Jan 2005 10:01:02 -0800 Subject: more 'modules_object_t' stuff... udev_t? Message-ID: <4c4ba1530501171001215a0155@mail.gmail.com> Running strict/enforcing, latest rawhide. I happened to boot with the KVM set to another computer. When I set the KVM to point to 'this' machine, I 'reset' the mouse by unplugging/plugging it back into the KVM'. (Yeah, I know, but it seems to be the only thing that makes the wheel work on this computer. Works fine on other systems....) Anyway, doing this produced the following: Jan 17 09:32:16 fedora hal.hotplug[3737]: DEVPATH is not set Jan 17 09:32:16 fedora hal.hotplug[3746]: DEVPATH is not set Jan 17 09:32:16 fedora kernel: audit(1105983136.436:0): avc: denied { search } for pid=3747 exe=/bin/bash name=modules dev=hda2 ino=3178500 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:modules_object_t tclass=dir Jan 17 09:32:16 fedora kernel: input: PS2++ Logitech Wheel Mouse on isa0060/serio1 Jan 17 09:32:16 fedora kernel: audit(1105983136.756:0): avc: denied { search } for pid=3755 exe=/bin/bash name=modules dev=hda2 ino=3178500 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:modules_object_t tclass=dir Jan 17 09:32:16 fedora kernel: audit(1105983136.861:0): avc: denied { search } for pid=3763 exe=/bin/bash name=modules dev=hda2 ino=3178500 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:modules_object_t tclass=dir Jan 17 09:32:19 fedora kernel: psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost synchronization, throwing 2 bytes away. Does udev_t need r_dir_file(udev_t, module_object_t) or allow udev_t module_object_t:dir r_dir_perms; ? tom -- Tom London From tolan at bgz-consultants.com Fri Jan 7 20:47:52 2005 From: tolan at bgz-consultants.com (Tolan Blundell) Date: Fri, 07 Jan 2005 20:47:52 +0000 Subject: mysql-server-3.23.58-14 on FC3 x86 Message-ID: <41DEF578.7050108@bgz-consultants.com> Hi, I just did a yum upgrade and it's killed MySQL, the problem seems to be with selinux.. When I try to start mysqld it fails, and I get the following in /var/log/messages: [...] Jan 7 20:33:17 thome kernel: audit(1105129997.241:0): avc: denied { associate } for pid=6221 exe=/usr/libexec/mysqld name=mysql.sock scontext=root:object_r:unlabeled_t tcontext=system_u:object_r:fs_t tclass=filesystem Jan 7 20:33:27 thome mysqld: Starting MySQL: failed [...] I see from the changelog that there have been some changes to the selinux config in this package [...] * Wed Jan 05 2005 Tom Lane 3.23.58-14 - work around SELinux restriction that breaks mysql_install_db (bug #141062) - Add a restorecon to keep the mysql.log file in the right context (bz#143887) - Fix init script to not need a valid username for startup check (bz#142328) - Don't assume /etc/my.cnf will specify pid-file (bz#143724) [...] Any suggestions gratefully received :) Tolan. From kaiowas at gentoo.org Wed Jan 12 19:08:25 2005 From: kaiowas at gentoo.org (petre rodan) Date: Wed, 12 Jan 2005 21:08:25 +0200 Subject: Is there any IPsec-Tools policy available in FC2? In-Reply-To: <20050112103224.92448.qmail@web51504.mail.yahoo.com> References: <20050112103224.92448.qmail@web51504.mail.yahoo.com> Message-ID: <41E575A9.7060303@gentoo.org> Hi, Park Lee wrote: > Hi, > Is there a IPsec-Tools [1] (i.e. racoon, setkey) > policy made for SELinux in Fedora Core 2 ? latest Gentoo policies can be found here: http://dev.gentoo.org/~kaiowas/policy/gentoo/domains/program/ipsec.te http://dev.gentoo.org/~kaiowas/policy/gentoo/file_contexts/program/ipsec.fc net_contexts should also contain: ifdef(`ipsec.te', `portcon udp 500 system_u:object_r:isakmp_port_t') if you tweak the file contexts for Fedora, please also send us the changes. bye, peter > > Thank you. > > [1] http://ipsec-tools.sourceforge.net/ > > ===== > Best Regards, > Park Lee -- petre rodan Developer, Hardened Gentoo Linux -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From rj at baucells.net Wed Jan 12 19:20:07 2005 From: rj at baucells.net (Rogelio J. Baucells) Date: Wed, 12 Jan 2005 14:20:07 -0500 Subject: dhcpd targeted policy Message-ID: <41E57867.6060300@baucells.net> Hi, I am running a FC3 computer with the latest targeted policy (selinux-policy-targeted-1.17.30-2.68) and I am getting the following messages at the time dhcpd starts: ----------------------------------------------------------------- audit(1105547723.050:0): avc: denied { net_admin } for pid=6247 exe=/usr/sbin/dhcpd capability=12 scontext=root:system_r:dhcpd_t tcontext=root:system_r:dhcpd_t tclass=capability audit(1105547723.244:0): avc: denied { read } for pid=6247 exe=/usr/sbin/dhcpd name=cacert.org.pem dev=hdc2 ino=230129 scontext=root:system_r:dhcpd_t tcontext=system_u:object_r:usr_t tclass=file ----------------------------------------------------------------- I looked at the configuration file (dhcpd.conf) and I do not see any place where I am referencing the cacert.org cert file. I use that file for other services and it is located at (/usr/share/ssl/certs). Is there any information on how to resolve this errors? Thanks RJB From justin.conover at gmail.com Tue Jan 18 03:03:56 2005 From: justin.conover at gmail.com (Justin Conover) Date: Mon, 17 Jan 2005 21:03:56 -0600 Subject: systrace + selinux + fedora core 4ish? Message-ID: http://www.systrace.org/ http://www.citi.umich.edu/u/provos/systrace/linux.html Anybody, seen/use systrace on FC? What are your thoughts about using/adding it to FC? >From reading a bit about it, looks to be a very good/useful tool and was wondering what others thought about it? From walters at redhat.com Tue Jan 18 03:36:51 2005 From: walters at redhat.com (Colin Walters) Date: Mon, 17 Jan 2005 22:36:51 -0500 Subject: systrace + selinux + fedora core 4ish? In-Reply-To: References: Message-ID: <1106019411.24492.33.camel@nexus.verbum.private> On Mon, 2005-01-17 at 21:03 -0600, Justin Conover wrote: > http://www.systrace.org/ > > http://www.citi.umich.edu/u/provos/systrace/linux.html > > Anybody, seen/use systrace on FC? What are your thoughts about > using/adding it to FC? > > >From reading a bit about it, looks to be a very good/useful tool and > was wondering what others thought about it? My opinion is that it is essentially an inferior implementation of much of the functionality SELinux provides. It does have some additional features like the dynamic privilege elevation that seem possibly useful, but I don't think it makes sense to use systrace just for that. For example, from the "usr_sbin_httpd" policy: (http://www.citi.umich.edu/u/provos/systrace/usr_sbin_httpd): native-kill: permit As far as I can tell, this rule permits the "unprivileged" httpd to kill any other process it wants with the same uid, and should the root portion be compromised, any process can be killed. The language just doesn't allow you to express anything more fine-grained like the SELinux TE language does. From Valdis.Kletnieks at vt.edu Tue Jan 18 07:43:04 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 18 Jan 2005 02:43:04 -0500 Subject: systrace + selinux + fedora core 4ish? In-Reply-To: Your message of "Mon, 17 Jan 2005 22:36:51 EST." <1106019411.24492.33.camel@nexus.verbum.private> References: <1106019411.24492.33.camel@nexus.verbum.private> Message-ID: <200501180743.j0I7h416005053@turing-police.cc.vt.edu> On Mon, 17 Jan 2005 22:36:51 EST, Colin Walters said: > My opinion is that it is essentially an inferior implementation of much > of the functionality SELinux provides. It does have some additional > features like the dynamic privilege elevation that seem possibly useful, > but I don't think it makes sense to use systrace just for that. I admit not having read the Systrace stuff yet. Are there any features that SELinux would benefit from implementing similar functionality? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From sds at epoch.ncsc.mil Tue Jan 18 13:51:29 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Tue, 18 Jan 2005 08:51:29 -0500 Subject: SELinux on CentOS 3.4? In-Reply-To: References: Message-ID: <1106056289.18274.78.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-01-17 at 11:10, Justin Conover wrote: > Does anyone know if it is possible to install SELinux on CentOS? > > I thought Dan Walsh used to have a rhel 3.0 script that would add a > yum.repo and install the packages, but I don't see it. > > ftp://people.redhat.com/dwalsh/SELinux/ > > Could I simply grab/rebuild the srpms and install those on to it or > would that be a dep nightmare. > > ftp://people.redhat.com/dwalsh/SELinux/srpms/ IIRC, Dan stopped maintaining the RHEL3 packages a while back, during FC2 development. Likely a dependency nightmare at this point. You would also need to migrate to a 2.6 kernel or alternatively try the 2.4 back port of SELinux (no longer maintained by us, but some people on the outside are trying to update it and maintain it). Easier to just move to FC3 or RHEL4 beta at this point... -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Tue Jan 18 14:08:12 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Tue, 18 Jan 2005 09:08:12 -0500 Subject: systrace + selinux + fedora core 4ish? In-Reply-To: References: Message-ID: <1106057292.18274.91.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-01-17 at 22:03, Justin Conover wrote: > http://www.systrace.org/ > > http://www.citi.umich.edu/u/provos/systrace/linux.html > > Anybody, seen/use systrace on FC? What are your thoughts about > using/adding it to FC? > > >From reading a bit about it, looks to be a very good/useful tool and > was wondering what others thought about it? Providing security via system call interception and making security decisions based on pathnames considered harmful to security; see the Flask paper available from http://www.nsa.gov/selinux/papers/flask-abs.cfm. Sadly, the systrace site acknowledges the Flask paper, but misses the point entirely... -- Stephen Smalley National Security Agency From justin.conover at gmail.com Tue Jan 18 17:56:12 2005 From: justin.conover at gmail.com (Justin Conover) Date: Tue, 18 Jan 2005 11:56:12 -0600 Subject: honeypot risks? Message-ID: What are the risk of opening a box on then net to use as a honeypot for testing/learning? As in, would it be easy for a "hacker/script kiddie" to take the box and use it to hack the NSA and blame me ;-) I was thinking of using honeyd: http://dag.wieers.com/packages/honeyd/ http://www.citi.umich.edu/u/provos/honeyd/ Anyone recommend any good books for honeypots, I have found the following on amazon.com Honeypots: Tracking Hackers Know Your Enemy : Learning about Security Threats (2nd Edition) Network Intrusion Detection (3rd Edition) I'm pretty sure I have that ladder sitting on my bookshelf at home and will look when I get home tonight. From Debasis_Ghosh_-_Indal_Kolkata_Library at adityabirla.com Wed Jan 19 13:14:43 2005 From: Debasis_Ghosh_-_Indal_Kolkata_Library at adityabirla.com (Debasis_Ghosh_-_Indal_Kolkata_Library at adityabirla.com) Date: Wed, 19 Jan 2005 18:44:43 +0530 Subject: FEDORA CORE 3.0 MANUAL Message-ID: I would like to know whether any online reference manual or a list of useful commands and interpretations for Fedora Core is available. I would be grateful for any good help. Regards Debasis Ghosh ghoshd at adityabirla.com Disclaimer: The information contained in this communication is intended solely for the individual or entity to which it is addressed. It may contain confidential and/or legally privileged information. Any review, retransmission, dissemination or other use of, or taking any action in reliance on the contents of this information by persons or entities other than the intended recipient is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Aditya Birla Group Companies attempts to sweep e-mails and attachments for viruses, it does not guarantee that either are virus free and that we accept no liability for any damage sustained as a result of viruses. From dwalsh at redhat.com Wed Jan 19 15:17:59 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 19 Jan 2005 10:17:59 -0500 Subject: dhcpd targeted policy In-Reply-To: <41E6C3D5.1010304@baucells.org> References: <41E6C3D5.1010304@baucells.org> Message-ID: <41EE7A27.6080007@redhat.com> Rogelio J. Baucells wrote: > Hi, > > I am running a FC3 computer with the latest targeted policy > (selinux-policy-targeted-1.17.30-2.68) and I am getting the following > messages at the time dhcpd starts: > > ----------------------------------------------------------------- > audit(1105547723.050:0): avc: denied { net_admin } for pid=6247 > exe=/usr/sbin/dhcpd capability=12 scontext=root:system_r:dhcpd_t > tcontext=root:system_r:dhcpd_t tclass=capability > > audit(1105547723.244:0): avc: denied { read } for pid=6247 > exe=/usr/sbin/dhcpd name=cacert.org.pem dev=hdc2 ino=230129 > scontext=root:system_r:dhcpd_t tcontext=system_u:object_r:usr_t > tclass=file > ----------------------------------------------------------------- > > I looked at the configuration file (dhcpd.conf) and I do not see any > place where I am referencing the cacert.org cert file. I use that file > for other services and it is located at (/usr/share/ssl/certs). > > Is there any information on how to resolve this errors? > > Thanks > > RJB > selinux-policy-targeted-1.17.30-2.72 should have a fix for this > -- > 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 Wed Jan 19 15:19:16 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 19 Jan 2005 10:19:16 -0500 Subject: Getting PostgreSQL working again In-Reply-To: References: Message-ID: <41EE7A74.50805@redhat.com> Ian Pilcher wrote: > I just returned from 5 weeks out of the country, and one of the updates > that rolled out in that time is preventing PostgreSQL from starting. > The exact error message is: > > Jan 16 16:57:53 home kernel: audit(1105916273.121:0): avc: denied { > read } for pid=7164 exe=/usr/bin/postgres name=PG_VERSION dev=md1 > ino=296800 scontext=root:system_r:postgresql_t > tcontext=user_u:object_r:var_lib_t tclass=file > > I found one thread about this problem, but it did not seem to contain a > solution. (Unlike that poster, my database is in my root filesystem.) > > I'm all for a theoretical discussion about why this happened, but I > would also really appreciate anyone who can tell me how to get things > working again. > > Thanks! > Have you tried restorecon -R -v /var/lib From mayerf at tresys.com Wed Jan 19 16:05:58 2005 From: mayerf at tresys.com (Frank Mayer) Date: Wed, 19 Jan 2005 11:05:58 -0500 Subject: Keynote speaker announced for SELinux symposium Message-ID: <20050119160559.GFVV2104.mm-ismta3.bizmailsrvcs.net@FLM800> For those of you planning to attend the SELinux symposium in March, we just announced the keynote speaker: Dan Wolf, Director of the Information Assurance Directorate at NSA. You can see the full announcement at www.selinux-symposium.org. Just a friendly reminder, if you are planning to attend, early discounted registration end Feb 5. Regards, Frank From i.pilcher at comcast.net Wed Jan 19 16:35:16 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Wed, 19 Jan 2005 10:35:16 -0600 Subject: Getting PostgreSQL working again In-Reply-To: <41EE7A74.50805@redhat.com> References: <41EE7A74.50805@redhat.com> Message-ID: Daniel J Walsh wrote: >> Jan 16 16:57:53 home kernel: audit(1105916273.121:0): avc: denied { >> read } for pid=7164 exe=/usr/bin/postgres name=PG_VERSION dev=md1 >> ino=296800 scontext=root:system_r:postgresql_t >> tcontext=user_u:object_r:var_lib_t tclass=file >> > Have you tried > > restorecon -R -v /var/lib > Actually, I ended up using restorecon -R /var/lib/pgsql (after using -n -v). Things appear to be working again. Thanks for the response! -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From dwalsh at redhat.com Wed Jan 19 16:49:39 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 19 Jan 2005 11:49:39 -0500 Subject: mysql-server-3.23.58-14 on FC3 x86 In-Reply-To: <41DEF578.7050108@bgz-consultants.com> References: <41DEF578.7050108@bgz-consultants.com> Message-ID: <41EE8FA3.3000905@redhat.com> Tolan Blundell wrote: > Hi, > > I just did a yum upgrade and it's killed MySQL, the problem seems to > be with selinux.. > > When I try to start mysqld it fails, and I get the following in > /var/log/messages: > > [...] > Jan 7 20:33:17 thome kernel: audit(1105129997.241:0): avc: denied { > associate } for pid=6221 exe=/usr/libexec/mysqld name=mysql.sock > scontext=root:object_r:unlabeled_t tcontext=system_u:object_r:fs_t > tclass=filesystem > Jan 7 20:33:27 thome mysqld: Starting MySQL: failed > [...] > > I see from the changelog that there have been some changes to the > selinux config in this package > > [...] > * Wed Jan 05 2005 Tom Lane 3.23.58-14 > > - work around SELinux restriction that breaks mysql_install_db (bug > #141062) > - Add a restorecon to keep the mysql.log file in the right context > (bz#143887) > - Fix init script to not need a valid username for startup check > (bz#142328) > - Don't assume /etc/my.cnf will specify pid-file (bz#143724) > [...] > > Any suggestions gratefully received :) > > Tolan. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list Looks like you have a labeling problem. Easiest way to fix is touch /.autorelabel reboot From justin.conover at gmail.com Wed Jan 19 17:02:40 2005 From: justin.conover at gmail.com (Justin Conover) Date: Wed, 19 Jan 2005 11:02:40 -0600 Subject: Keynote speaker announced for SELinux symposium In-Reply-To: <20050119160559.GFVV2104.mm-ismta3.bizmailsrvcs.net@FLM800> References: <20050119160559.GFVV2104.mm-ismta3.bizmailsrvcs.net@FLM800> Message-ID: I've sent my boss some info about this, I hope they will pay my way ;-) Looks like $1950 for everything if your early right? On Wed, 19 Jan 2005 11:05:58 -0500, Frank Mayer wrote: > For those of you planning to attend the SELinux symposium in March, we just > announced the keynote speaker: Dan Wolf, Director of the Information > Assurance Directorate at NSA. You can see the full announcement at > www.selinux-symposium.org. Just a friendly reminder, if you are planning to > attend, early discounted registration end Feb 5. > > Regards, Frank > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > From rj at baucells.org Wed Jan 19 17:26:16 2005 From: rj at baucells.org (Rogelio J. Baucells) Date: Wed, 19 Jan 2005 12:26:16 -0500 Subject: dhcpd targeted policy In-Reply-To: <41EE7A27.6080007@redhat.com> References: <41E6C3D5.1010304@baucells.org> <41EE7A27.6080007@redhat.com> Message-ID: <41EE9838.9020705@baucells.org> Daniel J Walsh wrote: > Rogelio J. Baucells wrote: > >> Hi, >> >> I am running a FC3 computer with the latest targeted policy >> (selinux-policy-targeted-1.17.30-2.68) and I am getting the following >> messages at the time dhcpd starts: >> >> ----------------------------------------------------------------- >> audit(1105547723.050:0): avc: denied { net_admin } for pid=6247 >> exe=/usr/sbin/dhcpd capability=12 scontext=root:system_r:dhcpd_t >> tcontext=root:system_r:dhcpd_t tclass=capability >> >> audit(1105547723.244:0): avc: denied { read } for pid=6247 >> exe=/usr/sbin/dhcpd name=cacert.org.pem dev=hdc2 ino=230129 >> scontext=root:system_r:dhcpd_t tcontext=system_u:object_r:usr_t >> tclass=file >> ----------------------------------------------------------------- >> >> I looked at the configuration file (dhcpd.conf) and I do not see any >> place where I am referencing the cacert.org cert file. I use that file >> for other services and it is located at (/usr/share/ssl/certs). >> >> Is there any information on how to resolve this errors? >> >> Thanks >> >> RJB >> > selinux-policy-targeted-1.17.30-2.72 should have a fix for this > >> -- >> 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 Hi, I just checked again using the selinux-policy-targeted-1.17.30-2.72 and now I am getting two new errors in the log file at the time of starting dhcpd (I did a "restorecon -R /var/named" before starting the service). ------------------------------------------------------------------- audit(1106155180.751:0): avc: denied { read } for pid=21770 exe=/usr/sbin/dhcpd name=urandom dev=tmpfs ino=503 scontext=root:system_r:dhcpd_t tcontext=system_u:object_r:urandom_device_t tclass=chr_file audit(1106155180.752:0): avc: denied { read } for pid=21770 exe=/usr/sbin/dhcpd name=random dev=tmpfs ino=501 scontext=root:system_r:dhcpd_t tcontext=system_u:object_r:random_device_t tclass=chr_file ------------------------------------------------------------------- I do not longer have the old errors... I think the problem is accessing the /var/named/chroot/dev/random file. This is my selinux related settings for the files in that directory: crw-r--r-- root root system_u:object_r:null_device_t null crw-r--r-- root root system_u:object_r:random_device_t random crw-r--r-- root root system_u:object_r:zero_device_t zero Is there anything else I can do? Thanks for your help RJB From dac at tresys.com Wed Jan 19 22:41:28 2005 From: dac at tresys.com (David Caplan) Date: Wed, 19 Jan 2005 17:41:28 -0500 Subject: Keynote speaker announced for SELinux symposium In-Reply-To: References: <20050119160559.GFVV2104.mm-ismta3.bizmailsrvcs.net@FLM800> Message-ID: <41EEE218.6040103@tresys.com> That figure is not correct. Registration is $450 (until Feb 5. as Frank noted), and that covers the presentations on March 3 and 4. There are _optional_ tutorial tracks on the first day (March 2) which are priced separately. You may pick tutorial track one or two (or none). Both tracks run simultaneously on March 2. David Justin Conover wrote: > I've sent my boss some info about this, I hope they will pay my way ;-) > > Looks like $1950 for everything if your early right? > > > On Wed, 19 Jan 2005 11:05:58 -0500, Frank Mayer wrote: > >>For those of you planning to attend the SELinux symposium in March, we just >>announced the keynote speaker: Dan Wolf, Director of the Information >>Assurance Directorate at NSA. You can see the full announcement at >>www.selinux-symposium.org. Just a friendly reminder, if you are planning to >>attend, early discounted registration end Feb 5. >> >>Regards, Frank >> >>-- >>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 -- __________________________________ David Caplan 410 290 1411 x105 dac at tresys.com Tresys Technology, LLC 8840 Stanford Blvd., Suite 2100 Columbia, MD 21045 From nicku at nicku.org Thu Jan 20 00:23:21 2005 From: nicku at nicku.org (Nick Urbanik) Date: Thu, 20 Jan 2005 11:23:21 +1100 Subject: SELinux: home dir is symlink, httpd from files in home dir Message-ID: <20050120002321.GA21634@nicku.org> Dear Folks, I'm totally new to SELinux, and am quite confused on a number of points. I took the plunge and enabled SELinux on this FC3 box. Problem is with Apache. I have symlinks pointing to my home directory, and to the pub directory, publicly served by Apache. $ ls -l /home/nicku /var/ftp/pub lrwxrwxrwx 1 root root 12 Oct 26 14:36 /home/nicku -> ../opt/nicku lrwxrwxrwx 1 root root 13 Oct 26 14:48 /var/ftp/pub -> ../../opt/pub ls -Zd /opt/nicku /home/nicku lrwxrwxrwx root root system_u:object_r:default_t /home/nicku -> ../opt/nicku drwx-----x nicku nicku system_u:object_r:user_home_dir_t /opt/nicku I have three main questions: 1. How do I solve my problem about httpd access to /opt/nicku/work/teaching/ict/ossi securely? 2. Where should I put my modifications to the policy? 3. What attribute should I give to the symlink /home/nicku? Here is what I did: After enabling SELinux, access to http://localhost/ossi was forbidden. I then proceeded to try to make this work. However, my fairly random messing about is certainly not right. I don't know where I should put my modifications. I would prefer not to change the original policy files, but would prefer to make new ones. Contents of /etc/selinux/targeted/src/policy/file_contexts/misc/nicks-opt.fc: /opt/lost\+found(/.*)? system_u:object_r:lost_found_t /opt/nicku -d system_u:object_r:user_home_dir_t /opt/nicku/.+ system_u:object_r:user_home_t /opt/ogg(/.*)? system_u:object_r:default_t /opt/pub(/.*)? system_u:object_r:default_t /opt/nicku/public_htm(/.*)? system_u:object_r:httpd_user_content_t /opt/backup(/.*)? system_u:object_r:default_t /opt/cdimage(/.*)? system_u:object_r:default_t /opt/nicku/photos(/.*)? system_u:object_r:httpd_user_content_t /opt/nicku/work/teaching/ict/snm(/.*)? system_u:object_r:httpd_user_content_t /opt/nicku/work/teaching/ict/ossi(/.*)? system_u:object_r:httpd_user_content_t THIS IS CERTAINLY IN THE WRONG PLACE? WHERE SHOULD IT GO? cat /etc/selinux/targeted/src/policy/domains/program/apache-nicks-opt-extra.te # Extra stuff for apache to cope with the symbolic links to # /opt/nicku and /opt/pub These came from audit2allow. The first one is certainly wrong. I should change the attribute on the symlink /home/nicku. What should I change it to? # to give access to /home/nicku: # This looks BAD by removing SELinux protection of all symlinks: allow httpd_t default_t:lnk_file { getattr read }; # to give access to /opt/pub: allow httpd_t var_t:lnk_file { getattr read }; # to give access to /opt/nicku/{photos,work/{ossi,snm}} allow httpd_t user_home_t:lnk_file { getattr read }; make reload complained till I touched this file: ls -l /etc/selinux/targeted/src/policy/file_contexts/program/apache-nicks-opt-extra.fc -rw-r--r-- 1 root root 0 Jan 20 07:51 /etc/selinux/targeted/src/policy/file_contexts/program/apache-nicks-opt-extra.fc From httpd configuration: Alias /ossi /home/nicku/work/teaching/ict/ossi Options Indexes MultiViews FollowSymLinks AllowOverride None Order allow,deny Allow from all What should I do to enable httpd access to /ossi? Here's what SELinux says: Jan 20 10:53:20 nicku kernel: audit(1106178800.510:0): avc: denied { search } for pid=6133 exe=/usr/sbin/httpd name=work dev=sda1 ino=5620038 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:user_home_t tclass=dir Jan 20 10:53:20 nicku kernel: audit(1106178800.510:0): avc: denied { getattr } for pid=6133 exe=/usr/sbin/httpd path=/opt/nicku/work dev=sda1 ino=5620038 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:user_home_t tclass=dir When I do: tail -20 /var/log/messages | audit2allow -v -i - allow httpd_t user_home_t:dir { getattr search }; #EXE=/usr/sbin/httpd NAME=work : search #EXE=/usr/sbin/httpd PATH=/opt/nicku/work : getattr Where should this rule go? I would prefer not to modify the installed /etc/selinux/targeted/src/policy/domains/program/apache.te and /etc/selinux/targeted/src/policy/file_contexts/program/apache.fc; I would rather put my own customised changes in their own files so updates to the policies can be easily installed. -- Nick Urbanik RHCE http://nicku.org nicku(at)nicku.org Proud ex-member of Dept. of Information & Communications Technology in Hong Kong IVE (Tsing Yi), Home of Visual Paradigm: Jolt Productivity Award winner, programmed by ICT's own graduates! GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From walters at redhat.com Thu Jan 20 02:48:30 2005 From: walters at redhat.com (Colin Walters) Date: Wed, 19 Jan 2005 21:48:30 -0500 Subject: SELinux: home dir is symlink, httpd from files in home dir In-Reply-To: <20050120002321.GA21634@nicku.org> References: <20050120002321.GA21634@nicku.org> Message-ID: <1106189311.3753.26.camel@nexus.verbum.private> On Thu, 2005-01-20 at 11:23 +1100, Nick Urbanik wrote: > Dear Folks, > > I'm totally new to SELinux, and am quite confused on a number of > points. > > I took the plunge and enabled SELinux on this FC3 box. > Problem is with Apache. Have you read the Fedora Apache guide? http://fedora.redhat.com/docs/selinux-apache-fc3/ It's slightly out of date but still informative, I think. > I have symlinks pointing to my home > directory, This will cause a number of problems. Many programs are given the permissions 'getattr' and 'search' on user_home_dir_t:dir, so they can access the toplevel home directory but not necessarily anything contained in it. The ":dir" part here is important, as it means the permissions are restricted to directories with that type; symlinks are not allowed. I wonder why you're symlinking into /opt, but assuming for now that's what you have to do, one solution might be to use bind mounts instead of symlinks: rm /home/nicku mkdir /home/nicku mount -obind /opt/nicku /home/nicku You can add the bind mount to /etc/fstab so it's done automatically. Another (very hackish) approach might be to label the /home/nicku symlink with a type such as usr_t; most domains have permission to read usr_t:lnk_file (i.e. symlink). That's about all I can think of, short of modifying the policy sources. > 1. How do I solve my problem about httpd access to > /opt/nicku/work/teaching/ict/ossi securely? I hope the above helps. > 2. Where should I put my modifications to the policy? If you choose to modify policy, the right solution I think is to label the /home/nicku symlink with the type user_home_dir_t, and add the permissions like: allow user_home_dir_type:lnk_file { getattr read }; Substitute particular domains such as httpd_t for . When I modify policy, I tend to put my modifications in a local.te file. > 3. What attribute should I give to the symlink /home/nicku? user_home_dir_t. > /etc/selinux/targeted/src/policy/file_contexts/misc/nicks-opt.fc: > > /opt/lost\+found(/.*)? system_u:object_r:lost_found_t > /opt/nicku -d system_u:object_r:user_home_dir_t > /opt/nicku/.+ system_u:object_r:user_home_t > /opt/ogg(/.*)? system_u:object_r:default_t > /opt/pub(/.*)? system_u:object_r:default_t Hmm; using the default_t type seems a bit wrong, but I can't think offhand of something better. > /opt/nicku/public_htm(/.*)? system_u:object_r:httpd_user_content_t Right. > THIS IS CERTAINLY IN THE WRONG PLACE? WHERE SHOULD IT GO? No, that's fine. > cat /etc/selinux/targeted/src/policy/domains/program/apache-nicks-opt-extra.te Reasonable, although I like using a well-commented local.te personally. > # to give access to /home/nicku: > # This looks BAD by removing SELinux protection of all symlinks: > allow httpd_t default_t:lnk_file { getattr read }; It doesn't remove protection of all symlinks, but it does mean that Apache can read symlinks that aren't assigned a label by the file_contexts regexps (i.e. are given the default_t type). Given that you're using default_t for a lot of data, I wouldn't recommend this permission. > # to give access to /opt/pub: > allow httpd_t var_t:lnk_file { getattr read }; I'd use bind mounts instead of permissions like this, personally. But this one probably isn't too harmful. > # to give access to /opt/nicku/{photos,work/{ossi,snm}} > allow httpd_t user_home_t:lnk_file { getattr read }; This is bad; the data should be labeled as httpd_user_content_t. > make reload complained till I touched this file: > > ls -l /etc/selinux/targeted/src/policy/file_contexts/program/apache-nicks-opt-extra.fc > -rw-r--r-- 1 root root 0 Jan 20 07:51 > /etc/selinux/targeted/src/policy/file_contexts/program/apache-nicks-opt-extra.fc Yeah; use misc/local.te instead, or the like. te files in program require a corresponding .fc file to be enabled. > What should I do to enable httpd access to /ossi? > > Here's what SELinux says: > > Jan 20 10:53:20 nicku kernel: audit(1106178800.510:0): avc: denied { search } for pid=6133 exe=/usr/sbin/httpd name=work dev=sda1 ino=5620038 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:user_home_t tclass=dir > Jan 20 10:53:20 nicku kernel: audit(1106178800.510:0): avc: denied { getattr } for pid=6133 exe=/usr/sbin/httpd path=/opt/nicku/work dev=sda1 ino=5620038 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:user_home_t tclass=dir Any data you want httpd to access needs to be one of the types outlined in the Fedora Apache/SELinux guide, such as httpd_user_content_t. From cochranb at speakeasy.net Thu Jan 20 03:25:12 2005 From: cochranb at speakeasy.net (Robert L Cochran) Date: Wed, 19 Jan 2005 22:25:12 -0500 Subject: PHP 5.0.3 ldap.so extension denied Message-ID: <41EF2498.8090807@speakeasy.net> I compiled PHP version 5.0.3 from source obtained from php.net on a Pentium 4 system running Fedora Core 3 and this message appears in /var/log/messages after httpd starts: audit(1106189173.206:0): avc: denied { execute } for pid=3999 path=/usr/lib/20041030/ldap.so dev=dm-0 ino=3129353 scontext=user_u:system_r:httpd_t tcontext=root:object_r:lib_t tclass=file /usr/lib/20041030/ldap.so is a PHP "extension". How can I fix this problem and allow the extension execute permission? Any help gratefully accepted! Thanks a lot, Bob Cochran Greenbelt, Maryland From cochranb at speakeasy.net Thu Jan 20 03:35:16 2005 From: cochranb at speakeasy.net (Robert L Cochran) Date: Wed, 19 Jan 2005 22:35:16 -0500 Subject: MySQL 4.1.9 avc denied messages Message-ID: <41EF26F4.1090104@speakeasy.net> The following "avc denied" messages were recorded after upgrading MySQL-client-4.1.8 and MySQL-devel-4.1.8 to the corresponding 4.1.9 versions. After upgrading these, I additionally installed (for the first time) MySQL-server-4.1.9 and MySQL-shared-4.1.9. These are all binary x86 RPM packages downloaded from MySQL.com. They are running on a Fedora Core 3 system fully updated including the 741 kernel. My question is: can I fix the problems brought up by these avc denied messages by following the same advice given earlier to the poster named "dragoran" from 11/10/2004 through 11/16/2004, in several messages with the subject line "PHP cannot connect to mysql server?" I wish to allow MySQL execute permission. Any help gratefully accepted. Thanks! Bob Cochran Greenbelt, Maryland And here are the avc messages: audit(1106189173.580:0): avc: denied { append } for pid=4051 exe=/usr/sbin/mysqld path=/var/lib/mysql/rachelsp4.lingpgmr.com.err dev=dm-0 ino=3260518 scontext=user_u:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=file audit(1106189174.329:0): avc: denied { write } for pid=4051 exe=/usr/sbin/mysqld name=mysql dev=dm-0 ino=3260470 scontext=user_u:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=dir audit(1106189174.329:0): avc: denied { add_name } for pid=4051 exe=/usr/sbin/mysqld name=rachelsp4.lower-test scontext=user_u:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=dir audit(1106189174.329:0): avc: denied { create } for pid=4051 exe=/usr/sbin/mysqld name=rachelsp4.lower-test scontext=user_u:system_r:mysqld_t tcontext=user_u:object_r:var_lib_t tclass=file audit(1106189174.408:0): avc: denied { remove_name } for pid=4051 exe=/usr/sbin/mysqld name=rachelsp4.lower-test dev=dm-0 ino=3260519 scontext=user_u:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=dir audit(1106189174.408:0): avc: denied { unlink } for pid=4051 exe=/usr/sbin/mysqld name=rachelsp4.lower-test dev=dm-0 ino=3260519 scontext=user_u:system_r:mysqld_t tcontext=user_u:object_r:var_lib_t tclass=file audit(1106189174.449:0): avc: denied { create } for pid=4051 exe=/usr/sbin/mysqld name=mysql.sock scontext=user_u:system_r:mysqld_t tcontext=user_u:object_r:var_lib_t tclass=sock_file audit(1106189174.711:0): avc: denied { read write } for pid=4051 exe=/usr/sbin/mysqld name=ibdata1 dev=dm-0 ino=3260520 scontext=user_u:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=file audit(1106189174.711:0): avc: denied { lock } for pid=4051 exe=/usr/sbin/mysqld path=/var/lib/mysql/ibdata1 dev=dm-0 ino=3260520 scontext=user_u:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=file audit(1106189175.480:0): avc: denied { write } for pid=4109 exe=/usr/sbin/mysqld path=/var/lib/mysql/rachelsp4.lingpgmr.com.pid dev=dm-0 ino=3260523 scontext=user_u:system_r:mysqld_t tcontext=user_u:object_r:var_lib_t tclass=file audit(1106189175.845:0): avc: denied { getattr } for pid=4051 exe=/usr/sbin/mysqld path=/var/lib/mysql/mysql/host.MYI dev=dm-0 ino=3260477 scontext=user_u:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=file From nicku at nicku.org Thu Jan 20 03:44:05 2005 From: nicku at nicku.org (Nick Urbanik) Date: Thu, 20 Jan 2005 14:44:05 +1100 Subject: SELinux: home dir is symlink, httpd from files in home dir In-Reply-To: <1106189311.3753.26.camel@nexus.verbum.private> References: <20050120002321.GA21634@nicku.org> <1106189311.3753.26.camel@nexus.verbum.private> Message-ID: <20050120034405.GA25846@nicku.org> Thank you very much for your very helpful reply, Colin. On Wed, Jan 19, 2005 at 09:48:30PM -0500, Colin Walters wrote: > On Thu, 2005-01-20 at 11:23 +1100, Nick Urbanik wrote: > > Dear Folks, > > > > I'm totally new to SELinux, and am quite confused on a number of > > points. > > > > I took the plunge and enabled SELinux on this FC3 box. > > Problem is with Apache. > > Have you read the Fedora Apache guide? Thank you, yes, it is very helpful. > http://fedora.redhat.com/docs/selinux-apache-fc3/ > > It's slightly out of date but still informative, I think. Thanks. I have finally got everything to work, and now will make it work more securely. > > I have symlinks pointing to my home > > directory, > > This will cause a number of problems. Many programs are given the > permissions 'getattr' and 'search' on user_home_dir_t:dir, so they can > access the toplevel home directory but not necessarily anything > contained in it. The ":dir" part here is important, as it means the > permissions are restricted to directories with that type; symlinks are > not allowed. > > I wonder why you're symlinking into /opt, I have a 512 gigabyte 3ware raid partition, and am using it for many different purposes, and had used symlinks to access it. I'm changing it to mount as you sensibly suggest. > but assuming for now that's what you have to do, one solution might > be to use bind mounts instead of symlinks: > > rm /home/nicku > mkdir /home/nicku > mount -obind /opt/nicku /home/nicku > > You can add the bind mount to /etc/fstab so it's done automatically. That's a wonderful idea! The mount man page indicates that I can use mount --move /opt/nicku /home/nicku to achieve exactly what I wanted originally. Does that work well? > Yeah; use misc/local.te instead, or the like. te files in program > require a corresponding .fc file to be enabled. Yes, I finally realised that's where it should go. -- Nick Urbanik RHCE http://nicku.org nicku(at)nicku.org Proud ex-member of Dept. of Information & Communications Technology in Hong Kong IVE (Tsing Yi), Home of Visual Paradigm: Jolt Productivity Award winner, programmed by ICT's own graduates! GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicku at nicku.org Thu Jan 20 03:47:47 2005 From: nicku at nicku.org (Nick Urbanik) Date: Thu, 20 Jan 2005 14:47:47 +1100 Subject: SELinux settings for a program run either by apache or user? Message-ID: <20050120034747.GB25846@nicku.org> Dear Folks, I have written a program that I use both run by Apache and by normal users as a command line application. When I changed the attribute of the program file to httpd_sys_script_exec_t, It no longer had permission to write to the console. What is the simplest way to handle this properly in SELinux? -- Nick Urbanik RHCE http://nicku.org nicku(at)nicku.org Proud ex-member of Dept. of Information & Communications Technology in Hong Kong IVE (Tsing Yi), Home of Visual Paradigm: Jolt Productivity Award winner, programmed by ICT's own graduates! GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From walters at redhat.com Thu Jan 20 03:56:16 2005 From: walters at redhat.com (Colin Walters) Date: Wed, 19 Jan 2005 22:56:16 -0500 Subject: SELinux: home dir is symlink, httpd from files in home dir In-Reply-To: <20050120034405.GA25846@nicku.org> References: <20050120002321.GA21634@nicku.org> <1106189311.3753.26.camel@nexus.verbum.private> <20050120034405.GA25846@nicku.org> Message-ID: <1106193376.3753.32.camel@nexus.verbum.private> On Thu, 2005-01-20 at 14:44 +1100, Nick Urbanik wrote: > I have a 512 gigabyte 3ware raid partition, and am using it for many > different purposes, and had used symlinks to access it. I'm changing > it to mount as you sensibly suggest. You could use LVM to pool your local disk containing / and the raid partition containing /opt; this makes the fact that the files are on different stores transparent to applications and removes the need for symlinks or bind mounts, and in general is a lot nicer to manage. > That's a wonderful idea! The mount man page indicates that I can use > > mount --move /opt/nicku /home/nicku Ah, it's unclear to me exactly what --move is supposed to do; the example doesn't work for me. From walters at redhat.com Thu Jan 20 04:07:59 2005 From: walters at redhat.com (Colin Walters) Date: Wed, 19 Jan 2005 23:07:59 -0500 Subject: SELinux settings for a program run either by apache or user? In-Reply-To: <20050120034747.GB25846@nicku.org> References: <20050120034747.GB25846@nicku.org> Message-ID: <1106194079.3753.38.camel@nexus.verbum.private> On Thu, 2005-01-20 at 14:47 +1100, Nick Urbanik wrote: > Dear Folks, > > I have written a program that I use both run by Apache and by normal > users as a command line application. > > When I changed the attribute of the program file to > httpd_sys_script_exec_t, It no longer had permission to write to the > console. What is the simplest way to handle this properly in SELinux? The simplest solution is to simply make two copies of the program file (by using e.g. cp), accessible by different names, with different labels. So you'd have e.g. "/usr/bin/program.cgi" labeled as httpd_sys_script_exec_t, and just "/usr/bin/program" labeled as bin_t. The other solution is to define a new type, and grant both domains in question access to it. This is a lot more complex; now you have to consider potential information flow between the two domains which were (presumably) separate before. From walters at redhat.com Thu Jan 20 04:12:16 2005 From: walters at redhat.com (Colin Walters) Date: Wed, 19 Jan 2005 23:12:16 -0500 Subject: PHP 5.0.3 ldap.so extension denied In-Reply-To: <41EF2498.8090807@speakeasy.net> References: <41EF2498.8090807@speakeasy.net> Message-ID: <1106194336.3753.43.camel@nexus.verbum.private> On Wed, 2005-01-19 at 22:25 -0500, Robert L Cochran wrote: > I compiled PHP version 5.0.3 from source obtained from php.net on a > Pentium 4 system running Fedora Core 3 and this message appears in > /var/log/messages after httpd starts: > > audit(1106189173.206:0): avc: denied { execute } for pid=3999 > path=/usr/lib/20041030/ldap.so dev=dm-0 ino=3129353 > scontext=user_u:system_r:httpd_t tcontext=root:object_r:lib_t tclass=file Try running "restorecon /usr/lib/20041030/ldap.so". That should reset the type of the file to shlib_t. You'll notice that shared libraries directly in /usr/lib/ have this type; this ensures that protected daemons are not able to map other random files that may be in lib into executable memory. (If that doesn't work, try "chcon -t shlib_t /usr/lib/20041030/ldap.so") From cochranb at speakeasy.net Thu Jan 20 04:36:37 2005 From: cochranb at speakeasy.net (Robert L Cochran) Date: Wed, 19 Jan 2005 23:36:37 -0500 Subject: PHP 5.0.3 ldap.so extension denied In-Reply-To: <1106194336.3753.43.camel@nexus.verbum.private> References: <41EF2498.8090807@speakeasy.net> <1106194336.3753.43.camel@nexus.verbum.private> Message-ID: <41EF3555.9030300@speakeasy.net> Colin Walters wrote: >On Wed, 2005-01-19 at 22:25 -0500, Robert L Cochran wrote: > > >>I compiled PHP version 5.0.3 from source obtained from php.net on a >>Pentium 4 system running Fedora Core 3 and this message appears in >>/var/log/messages after httpd starts: >> >>audit(1106189173.206:0): avc: denied { execute } for pid=3999 >>path=/usr/lib/20041030/ldap.so dev=dm-0 ino=3129353 >>scontext=user_u:system_r:httpd_t tcontext=root:object_r:lib_t tclass=file >> >> > >Try running "restorecon /usr/lib/20041030/ldap.so". That should reset >the type of the file to shlib_t. You'll notice that shared libraries >directly in /usr/lib/ have this type; this ensures that protected >daemons are not able to map other random files that may be in lib into >executable memory. > >(If that doesn't work, try "chcon -t shlib_t /usr/lib/20041030/ldap.so") > > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > Colin, Thanks for your help! It worked for that specific file. Now I'm getting the same message for file "mysql.so" in the same directory, so I assume that I need to run 'restorecon' for every *.so file in that directory. (PHP created the directory and installed the modules to it.) Thanks again! Bob From walters at redhat.com Thu Jan 20 04:47:00 2005 From: walters at redhat.com (Colin Walters) Date: Wed, 19 Jan 2005 23:47:00 -0500 Subject: PHP 5.0.3 ldap.so extension denied In-Reply-To: <41EF3555.9030300@speakeasy.net> References: <41EF2498.8090807@speakeasy.net> <1106194336.3753.43.camel@nexus.verbum.private> <41EF3555.9030300@speakeasy.net> Message-ID: <1106196420.3753.50.camel@nexus.verbum.private> On Wed, 2005-01-19 at 23:36 -0500, Robert L Cochran wrote: > Thanks for your help! It worked for that specific file. Now I'm getting > the same message for file "mysql.so" in the same directory, so I assume > that I need to run 'restorecon' for every *.so file in that directory. > (PHP created the directory and installed the modules to it.) Yeah; in general, software installation by third party installers is not a solved problem yet. "restorecon" can fix it for typical things such as shared libraries installed in /usr/lib or binaries in /usr/bin, but not for arbitrary paths such as an executable called /opt/mypackage/binaries/foo. From nicku at nicku.org Thu Jan 20 08:04:19 2005 From: nicku at nicku.org (Nick Urbanik) Date: Thu, 20 Jan 2005 19:04:19 +1100 Subject: (OT) LVM and mount (was SELinux: home dir is symlink, httpd from files in home dir) In-Reply-To: <1106193376.3753.32.camel@nexus.verbum.private> References: <20050120002321.GA21634@nicku.org> <1106189311.3753.26.camel@nexus.verbum.private> <20050120034405.GA25846@nicku.org> <1106193376.3753.32.camel@nexus.verbum.private> Message-ID: <20050120080419.GA11272@nicku.org> G'day, On Wed, Jan 19, 2005 at 10:56:16PM -0500, Colin Walters wrote: > On Thu, 2005-01-20 at 14:44 +1100, Nick Urbanik wrote: > > > I have a 512 gigabyte 3ware raid partition, and am using it for many > > different purposes, and had used symlinks to access it. I'm changing > > it to mount as you sensibly suggest. > > You could use LVM to pool your local disk containing / and the raid > partition containing /opt; this makes the fact that the files are on > different stores transparent to applications and removes the need for > symlinks or bind mounts, and in general is a lot nicer to manage. Yes, I used LVM for many years, but found that the performance of the virtual disks was quite a lot lower than the physical ones (using hdparm -t and other measures). That has probably changed by now; I was using LVM 1. > > That's a wonderful idea! The mount man page indicates that I can use > > > > mount --move /opt/nicku /home/nicku > > Ah, it's unclear to me exactly what --move is supposed to do; the > example doesn't work for me. No, it didn't work for me either. I used bind mounts, which do the job just nicely. -- Nick Urbanik RHCE http://nicku.org nicku(at)nicku.org Proud ex-member of Dept. of Information & Communications Technology in Hong Kong IVE (Tsing Yi), Home of Visual Paradigm: Jolt Productivity Award winner, programmed by ICT's own graduates! GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicku at nicku.org Thu Jan 20 08:56:11 2005 From: nicku at nicku.org (Nick Urbanik) Date: Thu, 20 Jan 2005 19:56:11 +1100 Subject: SELinux settings for a program run either by apache or user? In-Reply-To: <1106194079.3753.38.camel@nexus.verbum.private> References: <20050120034747.GB25846@nicku.org> <1106194079.3753.38.camel@nexus.verbum.private> Message-ID: <20050120085611.GA12028@nicku.org> Dear Folks, On Wed, Jan 19, 2005 at 11:07:59PM -0500, Colin Walters wrote: > On Thu, 2005-01-20 at 14:47 +1100, Nick Urbanik wrote: > > Dear Folks, > > > > I have written a program that I use both run by Apache and by normal > > users as a command line application. > > > > When I changed the attribute of the program file to > > httpd_sys_script_exec_t, It no longer had permission to write to the > > console. What is the simplest way to handle this properly in SELinux? > > The simplest solution is to simply make two copies of the program file > (by using e.g. cp), accessible by different names, with different > labels. So you'd have e.g. "/usr/bin/program.cgi" labeled as > httpd_sys_script_exec_t, and just "/usr/bin/program" labeled as > bin_t. This raises a can of worms when maintaining the program, and the question arises as to which is the "real one". I'm likely to forget to update one or the other. "Which one do I enter into version control?" is a question I would ask myself often. Where are SELinux attributes stored? In the inode? If not, can hard links be given different attributes? > The other solution is to define a new type, and grant both domains in > question access to it. This is a lot more complex; now you have to > consider potential information flow between the two domains which were > (presumably) separate before. Well, that may be more managable in the long term. Can you suggest a (relatively) simple way of doing that? -- Nick Urbanik RHCE http://nicku.org nicku(at)nicku.org Proud ex-member of Dept. of Information & Communications Technology in Hong Kong IVE (Tsing Yi), Home of Visual Paradigm: Jolt Productivity Award winner, programmed by ICT's own graduates! GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Debasis_Ghosh_-_Indal_Kolkata_Library at adityabirla.com Thu Jan 20 10:21:34 2005 From: Debasis_Ghosh_-_Indal_Kolkata_Library at adityabirla.com (Debasis_Ghosh_-_Indal_Kolkata_Library at adityabirla.com) Date: Thu, 20 Jan 2005 15:51:34 +0530 Subject: FEDORA CORE 3.0 : MANUAL Message-ID: Dear Friends, I am a non-techie beginner to Fedora Core 3.0. Could you please guide me whether there is any online reference manual or command summary (and interpretations) on Fedora Core 3.0 is available. Look forward to your kind help. Regards Debasis Ghosh ghoshd at adityabirla.com Disclaimer: The information contained in this communication is intended solely for the individual or entity to which it is addressed. It may contain confidential and/or legally privileged information. Any review, retransmission, dissemination or other use of, or taking any action in reliance on the contents of this information by persons or entities other than the intended recipient is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Aditya Birla Group Companies attempts to sweep e-mails and attachments for viruses, it does not guarantee that either are virus free and that we accept no liability for any damage sustained as a result of viruses. From dwalsh at redhat.com Thu Jan 20 15:44:39 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 20 Jan 2005 10:44:39 -0500 Subject: MySQL 4.1.9 avc denied messages In-Reply-To: <41EF26F4.1090104@speakeasy.net> References: <41EF26F4.1090104@speakeasy.net> Message-ID: <41EFD1E7.5000601@redhat.com> Robert L Cochran wrote: > The following "avc denied" messages were recorded after upgrading > MySQL-client-4.1.8 and MySQL-devel-4.1.8 to the corresponding 4.1.9 > versions. After upgrading these, I additionally installed (for the > first time) MySQL-server-4.1.9 and MySQL-shared-4.1.9. These are all > binary x86 RPM packages downloaded from MySQL.com. They are running on > a Fedora Core 3 system fully updated including the 741 kernel. > > My question is: can I fix the problems brought up by these avc denied > messages by following the same advice given earlier to the poster > named "dragoran" from 11/10/2004 through 11/16/2004, in several > messages with the subject line "PHP cannot connect to mysql server?" I > wish to allow MySQL execute permission. > > Any help gratefully accepted. > > Thanks! > > Bob Cochran > Greenbelt, Maryland > > And here are the avc messages: > > audit(1106189173.580:0): avc: denied { append } for pid=4051 > exe=/usr/sbin/mysqld path=/var/lib/mysql/rachelsp4.lingpgmr.com.err > dev=dm-0 ino=3260518 scontext=user_u:system_r:mysqld_t > tcontext=root:object_r:var_lib_t tclass=file > audit(1106189174.329:0): avc: denied { write } for pid=4051 > exe=/usr/sbin/mysqld name=mysql dev=dm-0 ino=3260470 > scontext=user_u:system_r:mysqld_t tcontext=root:object_r:var_lib_t > tclass=dir > audit(1106189174.329:0): avc: denied { add_name } for pid=4051 > exe=/usr/sbin/mysqld name=rachelsp4.lower-test > scontext=user_u:system_r:mysqld_t tcontext=root:object_r:var_lib_t > tclass=dir > audit(1106189174.329:0): avc: denied { create } for pid=4051 > exe=/usr/sbin/mysqld name=rachelsp4.lower-test > scontext=user_u:system_r:mysqld_t tcontext=user_u:object_r:var_lib_t > tclass=file > audit(1106189174.408:0): avc: denied { remove_name } for pid=4051 > exe=/usr/sbin/mysqld name=rachelsp4.lower-test dev=dm-0 ino=3260519 > scontext=user_u:system_r:mysqld_t tcontext=root:object_r:var_lib_t > tclass=dir > audit(1106189174.408:0): avc: denied { unlink } for pid=4051 > exe=/usr/sbin/mysqld name=rachelsp4.lower-test dev=dm-0 ino=3260519 > scontext=user_u:system_r:mysqld_t tcontext=user_u:object_r:var_lib_t > tclass=file > audit(1106189174.449:0): avc: denied { create } for pid=4051 > exe=/usr/sbin/mysqld name=mysql.sock scontext=user_u:system_r:mysqld_t > tcontext=user_u:object_r:var_lib_t tclass=sock_file > audit(1106189174.711:0): avc: denied { read write } for pid=4051 > exe=/usr/sbin/mysqld name=ibdata1 dev=dm-0 ino=3260520 > scontext=user_u:system_r:mysqld_t tcontext=root:object_r:var_lib_t > tclass=file > audit(1106189174.711:0): avc: denied { lock } for pid=4051 > exe=/usr/sbin/mysqld path=/var/lib/mysql/ibdata1 dev=dm-0 ino=3260520 > scontext=user_u:system_r:mysqld_t tcontext=root:object_r:var_lib_t > tclass=file > audit(1106189175.480:0): avc: denied { write } for pid=4109 > exe=/usr/sbin/mysqld path=/var/lib/mysql/rachelsp4.lingpgmr.com.pid > dev=dm-0 ino=3260523 scontext=user_u:system_r:mysqld_t > tcontext=user_u:object_r:var_lib_t tclass=file > audit(1106189175.845:0): avc: denied { getattr } for pid=4051 > exe=/usr/sbin/mysqld path=/var/lib/mysql/mysql/host.MYI dev=dm-0 > ino=3260477 scontext=user_u:system_r:mysqld_t > tcontext=root:object_r:var_lib_t tclass=file > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list restorecon -R -v /usr/lib/mysql should fix the problem. Dan From dwalsh at redhat.com Thu Jan 20 15:47:21 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 20 Jan 2005 10:47:21 -0500 Subject: SELinux settings for a program run either by apache or user? In-Reply-To: <20050120085611.GA12028@nicku.org> References: <20050120034747.GB25846@nicku.org> <1106194079.3753.38.camel@nexus.verbum.private> <20050120085611.GA12028@nicku.org> Message-ID: <41EFD289.4070804@redhat.com> Nick Urbanik wrote: >Dear Folks, > >On Wed, Jan 19, 2005 at 11:07:59PM -0500, Colin Walters wrote: > > >>On Thu, 2005-01-20 at 14:47 +1100, Nick Urbanik wrote: >> >> >>>Dear Folks, >>> >>>I have written a program that I use both run by Apache and by normal >>>users as a command line application. >>> >>>When I changed the attribute of the program file to >>>httpd_sys_script_exec_t, It no longer had permission to write to the >>>console. What is the simplest way to handle this properly in SELinux? >>> >>> >>The simplest solution is to simply make two copies of the program file >>(by using e.g. cp), accessible by different names, with different >>labels. So you'd have e.g. "/usr/bin/program.cgi" labeled as >>httpd_sys_script_exec_t, and just "/usr/bin/program" labeled as >>bin_t. >> >> > >This raises a can of worms when maintaining the program, and the >question arises as to which is the "real one". I'm likely to forget >to update one or the other. "Which one do I enter into version >control?" is a question I would ask myself often. > >Where are SELinux attributes stored? In the inode? If not, can hard >links be given different attributes? > > > >>The other solution is to define a new type, and grant both domains in >>question access to it. This is a lot more complex; now you have to >>consider potential information flow between the two domains which were >>(presumably) separate before. >> >> > >Well, that may be more managable in the long term. Can you suggest a >(relatively) simple way of doing that? > > >------------------------------------------------------------------------ > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > This sounds like a bug. A user executing a httpd script should not be changing context to httpd_sys_script_t, correct? From walters at redhat.com Thu Jan 20 15:52:17 2005 From: walters at redhat.com (Colin Walters) Date: Thu, 20 Jan 2005 10:52:17 -0500 Subject: SELinux settings for a program run either by apache or user? In-Reply-To: <20050120085611.GA12028@nicku.org> References: <20050120034747.GB25846@nicku.org> <1106194079.3753.38.camel@nexus.verbum.private> <20050120085611.GA12028@nicku.org> Message-ID: <1106236337.3753.75.camel@nexus.verbum.private> On Thu, 2005-01-20 at 19:56 +1100, Nick Urbanik wrote: > This raises a can of worms when maintaining the program, and the > question arises as to which is the "real one". Well...no, since you still have the same source code and build process, etc. This solution is a lot like what pre-SELinux chroot scripts did for bind, etc. > I'm likely to forget > to update one or the other. I'd imagine that your Makefile or whatever would install the two copies explicitly. Or you could do it in the RPM build process. > "Which one do I enter into version > control?" is a question I would ask myself often. You enter binaries into version control? > Where are SELinux attributes stored? In the inode? They are tightly coupled to the inode, yes. Just like Unix permissions are. > If not, can hard > links be given different attributes? No; hard links are just additional names for the same object. SELinux protects the actual object, not names or references to objects. > > The other solution is to define a new type, and grant both domains in > > question access to it. This is a lot more complex; now you have to > > consider potential information flow between the two domains which were > > (presumably) separate before. > > Well, that may be more managable in the long term. Can you suggest a > (relatively) simple way of doing that? You'd have to explain more about your setup. Are you just trying to run the CGI script as an ordinary user from unconfined_t? From walters at redhat.com Thu Jan 20 16:05:07 2005 From: walters at redhat.com (Colin Walters) Date: Thu, 20 Jan 2005 11:05:07 -0500 Subject: SELinux settings for a program run either by apache or user? In-Reply-To: <41EFD289.4070804@redhat.com> References: <20050120034747.GB25846@nicku.org> <1106194079.3753.38.camel@nexus.verbum.private> <20050120085611.GA12028@nicku.org> <41EFD289.4070804@redhat.com> Message-ID: <1106237108.3753.88.camel@nexus.verbum.private> On Thu, 2005-01-20 at 10:47 -0500, Daniel J Walsh wrote: > This sounds like a bug. A user executing a httpd script should not be > changing context to httpd_sys_script_t, correct? There's an explicit rule for this now, in macros/program/apache_macros.te: ifelse($1, sys, ` # # If a user starts a script by hand it gets the proper context # domain_auto_trans(sysadm_t, httpd_$1_script_exec_t, httpd_$1_script_t) role sysadm_r types httpd_$1_script_t; ', ` # If a user starts a script by hand it gets the proper context domain_auto_trans($1_t, httpd_$1_script_exec_t, httpd_$1_script_t) role $1_r types httpd_$1_script_t; We probably want to just drop this in targeted policy. In strict, we grant userdomains access to all the derived types such as httpd_sys_content_t, so not doing the transition (i.e. just changing it to can_exec, or maybe domain_trans) should allow the CGI script to continue to work, at first glance. But I have a feeling there was a particular reason policy has this rule; clearly it was intentional. I'll think about this for a bit. From Valdis.Kletnieks at vt.edu Thu Jan 20 16:55:23 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 20 Jan 2005 11:55:23 -0500 Subject: quota files oddity... Message-ID: <200501201655.j0KGtNan001364@turing-police.cc.vt.edu> Running FC from the devel tree as of last night, and a 2.6.10-mm1-RT kernel. OK.. So I go and put user and group quotas on all the R/W file systems (it's a lot quicker to run 'repquota /full.fs' than to run 'du' and similar when you're sitting at 99%.. ;) Then quite some time later I run setfiles because I was pretty sure that I had a lot of files that hadn't been installed by rpm and thus didn't have the right contexts on them, and I get: /usr/sbin/setfiles: relabeling /aquota.user from system_u:object_r:quota_db_t to system_u:object_r:default_t /aquota.user: Operation not permitted /usr/sbin/setfiles: unable to relabel /aquota.user to system_u:object_r:default_t /usr/sbin/setfiles: relabeling /aquota.group from system_u:object_r:quota_db_t to system_u:object_r:default_t /aquota.group: Operation not permitted /usr/sbin/setfiles: unable to relabel /aquota.group to system_u:object_r:default_t /usr/sbin/setfiles: relabeling /boot/aquota.user from system_u:object_r:quota_db_t to system_u:object_r:boot_t /boot/aquota.user: Operation not permitted /usr/sbin/setfiles: unable to relabel /boot/aquota.user to system_u:object_r:boot_t /usr/sbin/setfiles: relabeling /boot/aquota.group from system_u:object_r:quota_db_t to system_u:object_r:boot_t /boot/aquota.group: Operation not permitted /usr/sbin/setfiles: unable to relabel /boot/aquota.group to system_u:object_r:boot_t /usr/sbin/setfiles: relabeling /usr/aquota.user from root:object_r:quota_db_t to system_u:object_r:usr_t /usr/aquota.user: Operation not permitted /usr/sbin/setfiles: unable to relabel /usr/aquota.user to system_u:object_r:usr_t /usr/sbin/setfiles: relabeling /usr/aquota.group from system_u:object_r:quota_db_t to system_u:object_r:usr_t /usr/aquota.group: Operation not permitted /usr/sbin/setfiles: unable to relabel /usr/aquota.group to system_u:object_r:usr_t Is there any way to express: $MOUNTPOINT/aquota\.(user|group)$ -- system_u:object_r:quota_db_t in the .fc files, or do we need to settle for '/.*/aquota\.(user|group)' as the regexp? (And no, I have no idea how I ended up with 'root:object_r:quota_db_t' on /usr/aquota.user, but the other ones were system_u....) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Thu Jan 20 17:01:07 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 20 Jan 2005 12:01:07 -0500 Subject: honeypot risks? In-Reply-To: Your message of "Tue, 18 Jan 2005 11:56:12 CST." References: Message-ID: <200501201701.j0KH17ek021014@turing-police.cc.vt.edu> On Tue, 18 Jan 2005 11:56:12 CST, Justin Conover said: > What are the risk of opening a box on then net to use as a honeypot > for testing/learning? As in, would it be easy for a "hacker/script > kiddie" to take the box and use it to hack the NSA and blame me ;-) > > I was thinking of using honeyd: You really want to be asking that over on honeypots at securityfocus.com, as that's where *everybody* is to be found. Feel free to come back once you get to asking "How do I use selinux to secure a honeypot?" (answer - somebody needs to write .te and .fc files for honeyd). Hmm.. actually, that *is* a very sensible thing to do. Any takers? ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From selinux at gmail.com Thu Jan 20 17:57:11 2005 From: selinux at gmail.com (Tom London) Date: Thu, 20 Jan 2005 09:57:11 -0800 Subject: latest targeted policy: missing types....? Message-ID: <4c4ba15305012009574f566738@mail.gmail.com> Running targeted/enforcing, latest rawhide: The latest policy: selinux-policy-targeted-1.21.2-4 seems to be missing some types. Get this on 'restorecon .....'. Did I mess up the update? tom /etc/selinux/targeted/contexts/files/file_contexts: line 874 has invalid context system_u:object_r:login_exec_t /etc/selinux/targeted/contexts/files/file_contexts: line 875 has invalid context system_u:object_r:login_exec_t /etc/selinux/targeted/contexts/files/file_contexts: line 1035 has invalid context system_u:object_r:rlogind_exec_t /etc/selinux/targeted/contexts/files/file_contexts: line 1036 has invalid context system_u:object_r:rlogind_exec_t /etc/selinux/targeted/contexts/files/file_contexts: line 1037 has invalid context system_u:object_r:rlogind_exec_t /etc/selinux/targeted/contexts/files/file_contexts: line 1158 has invalid context system_u:object_r:telnetd_exec_t /etc/selinux/targeted/contexts/files/file_contexts: line 1159 has invalid context system_u:object_r:telnetd_exec_t -- Tom London From Valdis.Kletnieks at vt.edu Thu Jan 20 18:14:00 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 20 Jan 2005 13:14:00 -0500 Subject: latest targeted policy: missing types....? In-Reply-To: Your message of "Thu, 20 Jan 2005 09:57:11 PST." <4c4ba15305012009574f566738@mail.gmail.com> References: <4c4ba15305012009574f566738@mail.gmail.com> Message-ID: <200501201814.j0KIE05H015461@turing-police.cc.vt.edu> On Thu, 20 Jan 2005 09:57:11 PST, Tom London said: > Running targeted/enforcing, latest rawhide: > > The latest policy: selinux-policy-targeted-1.21.2-4 > seems to be missing some types. Get this on > 'restorecon .....'. > > Did I mess up the update? selinux-policy-strict-1.21.2-2 complained about telnetd_exec_t as well.. Oddly enough, 'make reload' cleared it up - was this a new type that wasn't known till after the reload took effect? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From kwade at redhat.com Thu Jan 20 18:46:27 2005 From: kwade at redhat.com (Karsten Wade) Date: Thu, 20 Jan 2005 10:46:27 -0800 Subject: FEDORA CORE 3.0 : MANUAL In-Reply-To: References: Message-ID: <1106246787.31480.422.camel@erato.phig.org> Note: this is off-topic, this list is for discussing Fedora Core and SELinux. Fedora-list would be the appropriate forum for this question. To help steer you further, I gave some answers below. On Thu, 2005-01-20 at 15:51 +0530, Debasis_Ghosh_- _Indal_Kolkata_Library at adityabirla.com wrote: > I am a non-techie beginner to Fedora Core 3.0. Could you please guide me > whether there is any online reference manual or command summary (and > interpretations) on Fedora Core 3.0 is available. Look forward to your kind > help. There are not. The Fedora Docs Project needs writers to help create some of these HOWTOs and tutorials. These might help: * http://www.fedoranews.org -- many tips, tricks, and useful articles. * http://www.fedorafaq.org/ -- many frequently asked questions are answered here. * http://www.redhat.com/docs/manuals/linux -- related to RHL 9 which is the version before Fedora Core 1, most of the commands are still and references are still useful. Good luck! -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 IT executives rate Red Hat #1 for value http://www.redhat.com/promo/vendor/ From walters at redhat.com Thu Jan 20 20:30:00 2005 From: walters at redhat.com (Colin Walters) Date: Thu, 20 Jan 2005 15:30:00 -0500 Subject: SELinux settings for a program run either by apache or user? In-Reply-To: <1106238103.26753.121.camel@moss-spartans.epoch.ncsc.mil> References: <20050120034747.GB25846@nicku.org> <1106194079.3753.38.camel@nexus.verbum.private> <20050120085611.GA12028@nicku.org> <41EFD289.4070804@redhat.com> <1106237108.3753.88.camel@nexus.verbum.private> <1106237039.26753.107.camel@moss-spartans.epoch.ncsc.mil> <1106237996.3753.95.camel@nexus.verbum.private> <1106238103.26753.121.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1106253000.5060.16.camel@nexus.verbum.private> On Thu, 2005-01-20 at 11:21 -0500, Stephen Smalley wrote: > On Thu, 2005-01-20 at 11:19, Colin Walters wrote: > > Right; but studying the policy a bit more, there are definitely > > permissions given to CGI scripts not given to ordinary userdomains, > > e.g.: > > > > ############################################ > > # Allow scripts to append to http logs > > ######################################### > > allow httpd_$1_script_t httpd_log_t:file { getattr append }; > > Append-only access should be relatively benign, although I'm not sure > whether it is justified here. But if it allowed to httpd_user_script_t, > then user_t effectively has those permissions anyway, as he can always > create a CGI script with arbitrary code and then access the URL to > invoke it from httpd, whether or not he can directly transition to the > domain or not. Agreed; I was bringing this up primarily to point out that simply removing the automatic transition would introduce other issues. I have a feeling that there's another issue having to do with preserving file contexts, but I can't put my finger on it. > > So that's something to consider. Perhaps what we really want is a > > domain derived from httpd_$1_script_t, e.g. httpd_$1_test_script_t, > > which is allowed to write to the terminal as well. That would be fairly > > complex though... > > Could certainly be done via shared macros for these testing domains and > the normal script domain. But not clear it is worth it... Yeah. It might be nice if the policy language had an easy "subclass" mechanism. That's a whole other topic though... For now anyways, we could probably just change it to a domain_trans; a quick look at the policy seems to show the httpd_log_t access being the only obvious additional permission granted. Presumably a majority of setups with CGI scripts and users are using suEXEC and do not allow ordinary uids any kind of write access to the main httpd logs. From dwalsh at redhat.com Thu Jan 20 20:50:20 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 20 Jan 2005 15:50:20 -0500 Subject: SELinux settings for a program run either by apache or user? In-Reply-To: <1106236337.3753.75.camel@nexus.verbum.private> References: <20050120034747.GB25846@nicku.org> <1106194079.3753.38.camel@nexus.verbum.private> <20050120085611.GA12028@nicku.org> <1106236337.3753.75.camel@nexus.verbum.private> Message-ID: <41F0198C.5030804@redhat.com> Colin Walters wrote: >On Thu, 2005-01-20 at 19:56 +1100, Nick Urbanik wrote: > > > >>This raises a can of worms when maintaining the program, and the >>question arises as to which is the "real one". >> >> > >Well...no, since you still have the same source code and build process, >etc. This solution is a lot like what pre-SELinux chroot scripts did >for bind, etc. > > > >> I'm likely to forget >>to update one or the other. >> >> > >I'd imagine that your Makefile or whatever would install the two copies >explicitly. Or you could do it in the RPM build process. > > > >>"Which one do I enter into version >>control?" is a question I would ask myself often. >> >> > >You enter binaries into version control? > > > >>Where are SELinux attributes stored? In the inode? >> >> > >They are tightly coupled to the inode, yes. Just like Unix permissions >are. > > > >>If not, can hard >>links be given different attributes? >> >> > >No; hard links are just additional names for the same object. SELinux >protects the actual object, not names or references to objects. > > > >>>The other solution is to define a new type, and grant both domains in >>>question access to it. This is a lot more complex; now you have to >>>consider potential information flow between the two domains which were >>>(presumably) separate before. >>> >>> >>Well, that may be more managable in the long term. Can you suggest a >>(relatively) simple way of doing that? >> >> > >You'd have to explain more about your setup. Are you just trying to run >the CGI script as an ordinary user from unconfined_t? > > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > After thinking about it, I think preserving file context would be the problem. So a different solution, might be to take advantage of the http_tty_comm boolean and turn on access to it from httpd_$$$_script_t so if an admin or an unconfined_t process ran the script it would be able to output to the terminal. Dan From selinux at gmail.com Thu Jan 20 20:51:31 2005 From: selinux at gmail.com (Tom London) Date: Thu, 20 Jan 2005 12:51:31 -0800 Subject: latest targeted policy: missing types....? In-Reply-To: <200501201814.j0KIE05H015461@turing-police.cc.vt.edu> References: <4c4ba15305012009574f566738@mail.gmail.com> <200501201814.j0KIE05H015461@turing-police.cc.vt.edu> Message-ID: <4c4ba15305012012513c88f4a0@mail.gmail.com> On Thu, 20 Jan 2005 13:14:00 -0500, Valdis.Kletnieks at vt.edu wrote: > selinux-policy-strict-1.21.2-2 complained about telnetd_exec_t as well.. > > Oddly enough, 'make reload' cleared it up - was this a new type that wasn't > known till after the reload took effect? > Thanks for the hint. 'make reload' fixes it for targeted too. I tried just 'make', but that didn't work. tom -- Tom London From russell at coker.com.au Fri Jan 21 00:28:49 2005 From: russell at coker.com.au (Russell Coker) Date: Fri, 21 Jan 2005 11:28:49 +1100 Subject: (OT) LVM and mount (was SELinux: home dir is symlink, httpd from files in home dir) In-Reply-To: <20050120080419.GA11272@nicku.org> References: <20050120002321.GA21634@nicku.org> <1106193376.3753.32.camel@nexus.verbum.private> <20050120080419.GA11272@nicku.org> Message-ID: <200501211128.52062.russell@coker.com.au> On Thursday 20 January 2005 19:04, Nick Urbanik wrote: > Yes, I used LVM for many years, but found that the performance of the > virtual disks was quite a lot lower than the physical ones (using > hdparm -t and other measures). That has probably changed by now; I > was using LVM 1. Everything has changed since LVM1. Please run the benchmarks that matter to you using LVM2 with a recent Fedora or RHEL kernel. If you find any significant performance loss then please raise it for discussion on fedora-devel-list or an LVM list. LVM should be giving you good performance. -- 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 Fri Jan 21 15:38:15 2005 From: selinux at gmail.com (Tom London) Date: Fri, 21 Jan 2005 07:38:15 -0800 Subject: 1105 fails to boot.... Message-ID: <4c4ba15305012107382086bc90@mail.gmail.com> Running strict/enforcing, latest rawhide: After installing latest packages, relabeling /etc, /bin, /lib, .... and rebooting, the system produces lots of udev type errors (cannot remove /dev/.udev_tdb/classSTUFF) and hangs on 'adding hardware' Boots (with messages) in permissive mode. Here are the 'early' AVCs: Jan 21 07:24:30 fedora kernel: SELinux: initialized (dev bdev, type bdev), uses genfs_contexts Jan 21 07:24:30 fedora kernel: SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts Jan 21 07:24:30 fedora kernel: SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts Jan 21 07:24:30 fedora kernel: audit(1106292231.919:0): avc: denied { read } for pid=478 exe=/bin/hostname path=/init dev=rootfs ino=17 scontext=system_u:system_r:hostname_t tcontext=system_u:object_r:root_t tclass=file Jan 21 07:24:30 fedora kernel: SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts Jan 21 07:24:30 fedora kernel: audit(1106292233.809:0): avc: denied { read } for pid=576 exe=/sbin/restorecon path=/init dev=rootfs ino=17 scontext=system_u:system_r:restorecon_t tcontext=system_u:object_r:root_t tclass=file Jan 21 07:24:30 fedora kernel: audit(1106292234.081:0): avc: denied { read } for pid=576 exe=/sbin/restorecon name=customizable_types dev=hda2 ino=4506184 scontext=system_u:system_r:restorecon_t tcontext=system_u:object_r:default_context_t tclass=file Jan 21 07:24:30 fedora kernel: audit(1106292235.062:0): avc: denied { use } for pid=702 exe=/bin/dmesg path=/init dev=rootfs ino=17 scontext=system_u:system_r:dmesg_t tcontext=system_u:system_r:kernel_t tclass=fd Jan 21 07:24:30 fedora kernel: audit(1106292235.062:0): avc: denied { read } for pid=702 exe=/bin/dmesg path=/init dev=rootfs ino=17 scontext=system_u:system_r:dmesg_t tcontext=system_u:object_r:root_t tclass=file Jan 21 07:24:30 fedora kernel: audit(1106292235.086:0): avc: denied { read } for pid=703 exe=/bin/bash path=/init dev=rootfs ino=17 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:root_t tclass=file Jan 21 07:24:30 fedora kernel: audit(1106292239.427:0): avc: denied { use } for pid=1233 exe=/sbin/kmodule path=/init dev=rootfs ino=17 scontext=system_u:system_r:kudzu_t tcontext=system_u:system_r:kernel_t tclass=fd Jan 21 07:24:30 fedora kernel: audit(1106292239.428:0): avc: denied { read } for pid=1233 exe=/sbin/kmodule path=/init dev=rootfs ino=17 scontext=system_u:system_r:kudzu_t tcontext=system_u:object_r:root_t tclass=file Jan 21 07:24:30 fedora ptal-mlcd: SYSLOG at ExMgr.cpp:652, dev=, pid=2629, e=2, t=1106321070 ptal-mlcd successfully initialized. Jan 21 07:24:30 fedora ptal-printd: ptal-printd(mlc:usb:PSC_900_Series) successfully initialized using /var/run/ptal-printd/mlc_usb_PSC_900_Series*. Jan 21 07:24:30 fedora kernel: Floppy drive(s): fd0 is 1.44M I'll probe a bit, but any help is welcome! tom -- Tom London From selinux at gmail.com Fri Jan 21 16:36:51 2005 From: selinux at gmail.com (Tom London) Date: Fri, 21 Jan 2005 08:36:51 -0800 Subject: 1105 fails to boot.... In-Reply-To: <4c4ba15305012107382086bc90@mail.gmail.com> References: <4c4ba15305012107382086bc90@mail.gmail.com> Message-ID: <4c4ba15305012108361413084e@mail.gmail.com> On Fri, 21 Jan 2005 07:38:15 -0800, Tom London wrote: > Running strict/enforcing, latest rawhide: > > After installing latest packages, relabeling /etc, /bin, /lib, .... > and rebooting, the system produces lots of udev type errors > (cannot remove /dev/.udev_tdb/classSTUFF) and hangs > on 'adding hardware' > > Boots (with messages) in permissive mode. > > > I'll probe a bit, but any help is welcome! > OK. Doing the obvious (i.e. adding all of the following) fixes the problem: allow dmesg_t kernel_t:fd use; allow dmesg_t root_t:file read; allow hostname_t root_t:file read; allow kudzu_t kernel_t:fd use; allow kudzu_t root_t:file read; allow restorecon_t default_context_t:file read; allow restorecon_t root_t:file read; allow udev_t root_t:file read; Adding 'root_t' to { kudzu_t restorecon_t udev_t } a problem? tom -- Tom London From sds at tycho.nsa.gov Fri Jan 21 16:48:37 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 21 Jan 2005 11:48:37 -0500 Subject: 1105 fails to boot.... In-Reply-To: <4c4ba15305012107382086bc90@mail.gmail.com> References: <4c4ba15305012107382086bc90@mail.gmail.com> Message-ID: <1106326117.28551.86.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-01-21 at 10:38, Tom London wrote: > Jan 21 07:24:30 fedora kernel: audit(1106292231.919:0): avc: denied > { read } for pid=478 exe=/bin/hostname path=/init dev=rootfs ino=17 > scontext=system_u:system_r:hostname_t > tcontext=system_u:object_r:root_t tclass=file I think that this denial reflects a kernel bug - leaking a descriptor to the rootfs to userspace. Shouldn't interfere with booting. > Jan 21 07:24:30 fedora kernel: audit(1106292234.081:0): avc: denied > { read } for pid=576 exe=/sbin/restorecon name=customizable_types > dev=hda2 ino=4506184 scontext=system_u:system_r:restorecon_t > tcontext=system_u:object_r:default_context_t tclass=file This is more likely the culprit. restorecon is now trying to read the customizable_types file to identify contexts that it shouldn't try to relabel, but if it lacks permission to do so, then the current code is going to prevent relabeling anything, as it is merely checking for a non-zero return from is_context_customizable(), which could be an error. Fix is to allow access by restorecon_t and setfiles_t, but also likely change the calling code to distinguish the error case from > 0 case. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Fri Jan 21 17:32:50 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 21 Jan 2005 12:32:50 -0500 Subject: 1105 fails to boot.... In-Reply-To: <1106326117.28551.86.camel@moss-spartans.epoch.ncsc.mil> References: <4c4ba15305012107382086bc90@mail.gmail.com> <1106326117.28551.86.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <41F13CC2.9020308@redhat.com> Stephen Smalley wrote: >On Fri, 2005-01-21 at 10:38, Tom London wrote: > > >>Jan 21 07:24:30 fedora kernel: audit(1106292231.919:0): avc: denied >>{ read } for pid=478 exe=/bin/hostname path=/init dev=rootfs ino=17 >>scontext=system_u:system_r:hostname_t >>tcontext=system_u:object_r:root_t tclass=file >> >> > >I think that this denial reflects a kernel bug - leaking a descriptor to >the rootfs to userspace. Shouldn't interfere with booting. > > > >>Jan 21 07:24:30 fedora kernel: audit(1106292234.081:0): avc: denied >>{ read } for pid=576 exe=/sbin/restorecon name=customizable_types >>dev=hda2 ino=4506184 scontext=system_u:system_r:restorecon_t >>tcontext=system_u:object_r:default_context_t tclass=file >> >> > >This is more likely the culprit. restorecon is now trying to read the >customizable_types file to identify contexts that it shouldn't try to >relabel, but if it lacks permission to do so, then the current code is >going to prevent relabeling anything, as it is merely checking for a >non-zero return from is_context_customizable(), which could be an >error. Fix is to allow access by restorecon_t and setfiles_t, but also >likely change the calling code to distinguish the error case from > 0 >case. > > > Fix in selinux-policy-*-1.21.2-7 From eric at openthought.net Fri Jan 21 20:11:29 2005 From: eric at openthought.net (Eric Andreychek) Date: Fri, 21 Jan 2005 20:11:29 +0000 Subject: PA Security Conference Message-ID: <20050121201129.GA32597@openthought.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, (if you are on the SELinux mailing list, this is the same message that was sent there -- but you did sign up, right? :-) On Saturday March 5, 2005, the Central PA Linux Users Group will be hosting a Security Conference near Harrisburg Pennsylvania. The conference will be geared toward individuals, organizations, and businesses with a technical interest in Linux related networking and security. You may recognize the date -- this conference is the day after the SELinux Symposium. So, if you can't get off work for three days, or find the SELinux Symposium difficult to afford, this conference might be right up your alley. And, if you are going to the SELinux Symposium, what a better way to end the week than by going to this one as well? :-) We booked a room at a local college, and will be able to accomodate up to 200 people. We have a number of really neat folks coming to speak. The speaker lineup is as follows: * Ed Reed, Novell's "Security Tzar", will be delivering the keynote titled "2005: The Platform Hardening Revival". * Russell Coker (RedHat), you know him, you love him, he will be giving an SELinux presentation. * Marcus Ranum (Tenable), known as the inventor of the proxy firewall and implementor of the first commercial firewall product, will be speaking on "System Logging Tools and Tricks for Geeks". * Jon Nelson, of the PA State Police Computer Crimes Unit and a member of the Philly LUG, will be speaking on "Computer Crime Law, Trends, and Security Basics". * Brandon Hale, a Hardened Gentoo developer, will be discussing "Advanced Memory Protections with Linux". * Eric Andreychek (CPLUG), will be speaking on "Getting Started with SELinux". We'll have 5-6 hours worth of presentations, as well as informal discussions before, after, and throughout the conference. At the end of the day, we also are planning a number of Lightning Talks, 5 minute talks from various conference attendees regarding a number of Linux and security related topics. If you or anyone you know are interested, you can get more information as well as register at the conference website: http://cplug.net/conference/ Seating is limited, so if you are interested, be sure to register soon. If you have any questions, please feel free to let us know. We look forward to seeing you there! -Eric -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFB8WHxR5UKaDAjAG4RAvm9AKDRfpW/MlUxv3keOtzsbHlwpVMM9wCgnKiZ Wou3dXLXb/TX0+L4HgGNSGY= =Xdzh -----END PGP SIGNATURE----- From cochranb at speakeasy.net Fri Jan 21 20:20:25 2005 From: cochranb at speakeasy.net (Robert L Cochran) Date: Fri, 21 Jan 2005 15:20:25 -0500 Subject: MySQL 4.1.9 avc denied messages In-Reply-To: <41EFD1E7.5000601@redhat.com> References: <41EF26F4.1090104@speakeasy.net> <41EFD1E7.5000601@redhat.com> Message-ID: <41F16409.40704@speakeasy.net> Daniel J Walsh wrote: > > restorecon -R -v /usr/lib/mysql > should fix the problem. > > Dan I'm sorry to have taken so long to respond to this. I ran 'restorecon' as suggested. Unfortunately, I'm still getting 'avc denied' messages when I restart the computer (e.g. when it shuts down and again when it starts up). Any suggestions? Here are the messages: Jan 21 14:32:58 rachelsp4 kernel: audit(1106335978.786:0): avc: denied { append } for pid=4049 exe=/usr/sbin/mysqld path=/var/lib/mysql/rachelsp4.lingpgmr.com.err dev=dm-0 ino=3260518 scontext=user_u:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=file Jan 21 14:32:59 rachelsp4 kernel: audit(1106335979.125:0): avc: denied { write } for pid=4049 exe=/usr/sbin/mysqld name=mysql dev=dm-0 ino=3260470 scontext=user_u:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=dir Jan 21 14:32:59 rachelsp4 kernel: audit(1106335979.125:0): avc: denied { add_name } for pid=4049 exe=/usr/sbin/mysqld name=rachelsp4.lower-test scontext=user_u:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=dir Jan 21 14:32:59 rachelsp4 kernel: audit(1106335979.125:0): avc: denied { create } for pid=4049 exe=/usr/sbin/mysqld name=rachelsp4.lower-test scontext=user_u:system_r:mysqld_t tcontext=user_u:object_r:var_lib_t tclass=file Jan 21 14:32:59 rachelsp4 kernel: audit(1106335979.139:0): avc: denied { remove_name } for pid=4049 exe=/usr/sbin/mysqld name=rachelsp4.lower-test dev=dm-0 ino=3260519 scontext=user_u:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=dir Jan 21 14:32:59 rachelsp4 kernel: audit(1106335979.139:0): avc: denied { unlink } for pid=4049 exe=/usr/sbin/mysqld name=rachelsp4.lower-test dev=dm-0 ino=3260519 scontext=user_u:system_r:mysqld_t tcontext=user_u:object_r:var_lib_t tclass=file Jan 21 14:32:59 rachelsp4 kernel: audit(1106335979.159:0): avc: denied { create } for pid=4049 exe=/usr/sbin/mysqld name=mysql.sock scontext=user_u:system_r:mysqld_t tcontext=user_u:object_r:var_lib_t tclass=sock_file Jan 21 14:32:59 rachelsp4 kernel: audit(1106335979.581:0): avc: denied { read write } for pid=4049 exe=/usr/sbin/mysqld name=ibdata1 dev=dm-0 ino=3260520 scontext=user_u:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=file Jan 21 14:32:59 rachelsp4 kernel: audit(1106335979.581:0): avc: denied { lock } for pid=4049 exe=/usr/sbin/mysqld path=/var/lib/mysql/ibdata1 dev=dm-0 ino=3260520 scontext=user_u:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=file Jan 21 14:33:00 rachelsp4 kernel: audit(1106335980.183:0): avc: denied { write } for pid=4079 exe=/usr/sbin/mysqld path=/var/lib/mysql/rachelsp4.lingpgmr.com.pid dev=dm-0 ino=3260523 scontext=user_u:system_r:mysqld_t tcontext=user_u:object_r:var_lib_t tclass=file Jan 21 14:33:00 rachelsp4 xfs: xfs startup succeeded Jan 21 14:33:00 rachelsp4 kernel: audit(1106335980.237:0): avc: denied { getattr } for pid=4049 exe=/usr/sbin/mysqld path=/var/lib/mysql/mysql/host.MYI dev=dm-0 ino=3260477 scontext=user_u:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=file Bob From dwalsh at redhat.com Fri Jan 21 20:26:23 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 21 Jan 2005 15:26:23 -0500 Subject: MySQL 4.1.9 avc denied messages In-Reply-To: <41F16409.40704@speakeasy.net> References: <41EF26F4.1090104@speakeasy.net> <41EFD1E7.5000601@redhat.com> <41F16409.40704@speakeasy.net> Message-ID: <41F1656F.8040108@redhat.com> Robert L Cochran wrote: > Daniel J Walsh wrote: > >> >> restorecon -R -v /usr/lib/mysql >> should fix the problem. >> >> Dan > > > I'm sorry to have taken so long to respond to this. I ran 'restorecon' > as suggested. Unfortunately, I'm still getting 'avc denied' messages > when I restart the computer (e.g. when it shuts down and again when it > starts up). Any suggestions? Here are the messages: > > Jan 21 14:32:58 rachelsp4 kernel: audit(1106335978.786:0): avc: > denied { append } for pid=4049 exe=/usr/sbin/mysqld > path=/var/lib/mysql/rachelsp4.lingpgmr.com.err dev=dm-0 ino=3260518 > scontext=user_u:system_r:mysqld_t tcontext=root:object_r:var_lib_t > tclass=file > Jan 21 14:32:59 rachelsp4 kernel: audit(1106335979.125:0): avc: > denied { write } for pid=4049 exe=/usr/sbin/mysqld name=mysql > dev=dm-0 ino=3260470 scontext=user_u:system_r:mysqld_t > tcontext=root:object_r:var_lib_t tclass=dir > Jan 21 14:32:59 rachelsp4 kernel: audit(1106335979.125:0): avc: > denied { add_name } for pid=4049 exe=/usr/sbin/mysqld > name=rachelsp4.lower-test scontext=user_u:system_r:mysqld_t > tcontext=root:object_r:var_lib_t tclass=dir > Jan 21 14:32:59 rachelsp4 kernel: audit(1106335979.125:0): avc: > denied { create } for pid=4049 exe=/usr/sbin/mysqld > name=rachelsp4.lower-test scontext=user_u:system_r:mysqld_t > tcontext=user_u:object_r:var_lib_t tclass=file > Jan 21 14:32:59 rachelsp4 kernel: audit(1106335979.139:0): avc: > denied { remove_name } for pid=4049 exe=/usr/sbin/mysqld > name=rachelsp4.lower-test dev=dm-0 ino=3260519 > scontext=user_u:system_r:mysqld_t tcontext=root:object_r:var_lib_t > tclass=dir > Jan 21 14:32:59 rachelsp4 kernel: audit(1106335979.139:0): avc: > denied { unlink } for pid=4049 exe=/usr/sbin/mysqld > name=rachelsp4.lower-test dev=dm-0 ino=3260519 > scontext=user_u:system_r:mysqld_t tcontext=user_u:object_r:var_lib_t > tclass=file > Jan 21 14:32:59 rachelsp4 kernel: audit(1106335979.159:0): avc: > denied { create } for pid=4049 exe=/usr/sbin/mysqld name=mysql.sock > scontext=user_u:system_r:mysqld_t tcontext=user_u:object_r:var_lib_t > tclass=sock_file > Jan 21 14:32:59 rachelsp4 kernel: audit(1106335979.581:0): avc: > denied { read write } for pid=4049 exe=/usr/sbin/mysqld name=ibdata1 > dev=dm-0 ino=3260520 scontext=user_u:system_r:mysqld_t > tcontext=root:object_r:var_lib_t tclass=file > Jan 21 14:32:59 rachelsp4 kernel: audit(1106335979.581:0): avc: > denied { lock } for pid=4049 exe=/usr/sbin/mysqld > path=/var/lib/mysql/ibdata1 dev=dm-0 ino=3260520 > scontext=user_u:system_r:mysqld_t tcontext=root:object_r:var_lib_t > tclass=file > Jan 21 14:33:00 rachelsp4 kernel: audit(1106335980.183:0): avc: > denied { write } for pid=4079 exe=/usr/sbin/mysqld > path=/var/lib/mysql/rachelsp4.lingpgmr.com.pid dev=dm-0 ino=3260523 > scontext=user_u:system_r:mysqld_t tcontext=user_u:object_r:var_lib_t > tclass=file > Jan 21 14:33:00 rachelsp4 xfs: xfs startup succeeded > Jan 21 14:33:00 rachelsp4 kernel: audit(1106335980.237:0): avc: > denied { getattr } for pid=4049 exe=/usr/sbin/mysqld > path=/var/lib/mysql/mysql/host.MYI dev=dm-0 ino=3260477 > scontext=user_u:system_r:mysqld_t tcontext=root:object_r:var_lib_t > tclass=file > > > Bob > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list Are you up 2 date on policy. The latest version is selinux-policy-targeted-1.17.30-2. /var/lib/mysql should be labeled mysql_db_t Dan From cochranb at speakeasy.net Fri Jan 21 20:48:01 2005 From: cochranb at speakeasy.net (Robert L Cochran) Date: Fri, 21 Jan 2005 15:48:01 -0500 Subject: MySQL 4.1.9 avc denied messages In-Reply-To: <41F1656F.8040108@redhat.com> References: <41EF26F4.1090104@speakeasy.net> <41EFD1E7.5000601@redhat.com> <41F16409.40704@speakeasy.net> <41F1656F.8040108@redhat.com> Message-ID: <41F16A81.8070005@speakeasy.net> Daniel J Walsh wrote: > Robert L Cochran wrote: > >> Daniel J Walsh wrote: >> >>> >>> restorecon -R -v /usr/lib/mysql >>> should fix the problem. >>> >>> Dan >> >> >> > > Are you up 2 date on policy. > > The latest version is selinux-policy-targeted-1.17.30-2. > > /var/lib/mysql should be labeled mysql_db_t > > Dan > I'll check if I'm up to date on policy, I should be. Meanwhile I wonder if you earlier meant I should run restorecon -R -v /var/lib/mysql instead of restorecon -R -v /usr/lib/mysql? Thanks Bob From cochranb at speakeasy.net Fri Jan 21 21:10:18 2005 From: cochranb at speakeasy.net (Robert L Cochran) Date: Fri, 21 Jan 2005 16:10:18 -0500 Subject: MySQL 4.1.9 avc denied messages In-Reply-To: <41F16A81.8070005@speakeasy.net> References: <41EF26F4.1090104@speakeasy.net> <41EFD1E7.5000601@redhat.com> <41F16409.40704@speakeasy.net> <41F1656F.8040108@redhat.com> <41F16A81.8070005@speakeasy.net> Message-ID: <41F16FBA.7020306@speakeasy.net> Robert L Cochran wrote: > Daniel J Walsh wrote: > >> Robert L Cochran wrote: >> >>> Daniel J Walsh wrote: >>> >>>> >>>> restorecon -R -v /usr/lib/mysql >>>> should fix the problem. >>>> >>>> Dan >>> >>> >>> >>> >> >> Are you up 2 date on policy. >> >> The latest version is selinux-policy-targeted-1.17.30-2. >> >> /var/lib/mysql should be labeled mysql_db_t >> >> Dan >> > I'll check if I'm up to date on policy, I should be. Meanwhile I > wonder if you earlier meant I should run > > restorecon -R -v /var/lib/mysql > > instead of > > restorecon -R -v /usr/lib/mysql? > > Thanks > > Bob Yep -- an update to 1.17.30-2.73 plus running 'restorecon -R -v /var/lib/mysql' fixed it. Thanks a lot for your help, much appreciated! Bob From hampton at employees.org Fri Jan 21 23:06:17 2005 From: hampton at employees.org (David Hampton) Date: Fri, 21 Jan 2005 18:06:17 -0500 Subject: Exim Message-ID: <1106348777.28341.11.camel@hampton-pc.rainbolthampton.net> Does anyone have file context and type enforcement files for exim? I'd like to lock exim down, but I'd rather not have to start from scratch if I can help it. Google did produce a reference to an exim.te file on NSA's SELinux mailing list archive, but it seems that the file attachment has already been deleted. Thanks. David -------------- 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 rwelty at averillpark.net Sat Jan 22 00:12:58 2005 From: rwelty at averillpark.net (Richard Welty) Date: Fri, 21 Jan 2005 19:12:58 -0500 (EST) Subject: Exim In-Reply-To: <1106348777.28341.11.camel@hampton-pc.rainbolthampton.net> References: <1106348777.28341.11.camel@hampton-pc.rainbolthampton.net> Message-ID: On Fri, 21 Jan 2005 18:06:17 -0500 David Hampton wrote: > Does anyone have file context and type enforcement files for exim? I'd > like to lock exim down, but I'd rather not have to start from scratch if > I can help it. Google did produce a reference to an exim.te file on > NSA's SELinux mailing list archive, but it seems that the file > attachment has already been deleted. Thanks. i'd been experimenting in FC2, but the system i was using as a play pen had to go into production in colo after a hardware failure in another box, so i'm temporarily without a place to work. additionally, since it was FC2, i was pretty much expecting to start over from scratch in FC3. when the new playpen gets here in about a week, i'll install FC3 on it and start over. richard -- Richard Welty rwelty at averillpark.net Averill Park Networking 518-573-7592 Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security From selinux at gmail.com Sat Jan 22 21:06:00 2005 From: selinux at gmail.com (Tom London) Date: Sat, 22 Jan 2005 13:06:00 -0800 Subject: targeted policy: crond_t now invalid for initrc_t ? Message-ID: <4c4ba153050122130677eb79a5@mail.gmail.com> Running targeted/enforcing, latest Rawhide: Get the following on boot with latest policy (selinux-policy-targeted-1.21.2-6): Jan 22 12:57:54 localhost kernel: audit(1106427474.075:0): security_compute_sid: invalid context user_u:system_r:crond_t for scontext=user_u:system_r:initrc_t tcontext=system_u:object_r:crond_exec_t tclass=process Jan 22 12:57:54 localhost gpm[2789]: *** info [mice.c(1766)]: Jan 22 12:57:54 localhost gpm[2789]: imps2: Auto-detected intellimouse PS/2 Jan 22 12:57:55 localhost kernel: audit(1106427475.435:0): security_compute_sid: invalid context user_u:system_r:crond_t for scontext=user_u:system_r:initrc_t tcontext=system_u:object_r:anacron_exec_t tclass=process Jan 22 12:57:55 localhost xfs[2826]: ignoring font path element /usr/X11R6/lib/X11/fonts/Speedo (unreadable) Jan 22 12:57:55 localhost kernel: audit(1106427475.634:0): security_compute_sid: invalid context user_u:system_r:crond_t for scontext=user_u:system_r:initrc_t tcontext=system_u:object_r:crond_exec_t tclass=process From russell at coker.com.au Sun Jan 23 02:47:20 2005 From: russell at coker.com.au (Russell Coker) Date: Sun, 23 Jan 2005 13:47:20 +1100 Subject: Exim In-Reply-To: <1106348777.28341.11.camel@hampton-pc.rainbolthampton.net> References: <1106348777.28341.11.camel@hampton-pc.rainbolthampton.net> Message-ID: <200501231347.23750.russell@coker.com.au> On Saturday 22 January 2005 10:06, David Hampton wrote: > Does anyone have file context and type enforcement files for exim? I'd > like to lock exim down, but I'd rather not have to start from scratch if > I can help it. Google did produce a reference to an exim.te file on > NSA's SELinux mailing list archive, but it seems that the file > attachment has already been deleted. Thanks. To do this properly some patches to the Exim source are required along with some minor changes to the packaging. Some experiments have been made on this but no-one has finished the job. -- 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 Sun Jan 23 19:30:30 2005 From: mroselinux at eastgranby.k12.ct.us (mroselinux at eastgranby.k12.ct.us) Date: Sun, 23 Jan 2005 14:30:30 -0500 (EST) Subject: ntpd drift.TEMP file Message-ID: <1373.24.2.210.202.1106508630.squirrel@mail.eastgranby.k12.ct.us> I have just built an FC3 samba server using the K12LTSP iso's and am getting the following messages on the log. Jan 21 01:55:14 admin ntpd[9988]: can't open /etc/ntp/drift.TEMP: Permission denied Jan 21 01:55:14 admin kernel: audit(1106290514.375:0): avc: denied { write } for pid=9988 exe=/usr/sbin/ntpd name=ntp dev=hda3 ino=3392705 scontext=root:system_r:ntpd_t tcontext=system_u:object_r:etc_t tclass=dir With SELinux enabled, the drift file could not be created. In permissive mode, the drift file is properly created and updated. What have I done wrong? [root at admin ntp]# ls -dZ . drwxr-xr-x ntp ntp system_u:object_r:etc_t [root at admin ntp]# ls -lZ drift -rw-r--r-- ntp ntp root:object_r:etc_t drift Mark Orenstein East Granby, CT School System From selinux at gmail.com Sun Jan 23 19:39:29 2005 From: selinux at gmail.com (Tom London) Date: Sun, 23 Jan 2005 11:39:29 -0800 Subject: ntpd drift.TEMP file In-Reply-To: <1373.24.2.210.202.1106508630.squirrel@mail.eastgranby.k12.ct.us> References: <1373.24.2.210.202.1106508630.squirrel@mail.eastgranby.k12.ct.us> Message-ID: <4c4ba153050123113914160be4@mail.gmail.com> On Sun, 23 Jan 2005 14:30:30 -0500 (EST), mroselinux at eastgranby.k12.ct.us wrote: > I have just built an FC3 samba server using the K12LTSP iso's and am > getting the following messages on the log. > > Jan 21 01:55:14 admin ntpd[9988]: can't open /etc/ntp/drift.TEMP: > Permission denied > Jan 21 01:55:14 admin kernel: audit(1106290514.375:0): avc: denied { > write } for pid=9988 exe=/usr/sbin/ntpd name=ntp dev=hda3 ino=3392705 > scontext=root:system_r:ntpd_t tcontext=system_u:object_r:etc_t tclass=dir > > With SELinux enabled, the drift file could not be created. In permissive > mode, the drift file is properly created and updated. What have I done > wrong? > > [root at admin ntp]# ls -dZ . > drwxr-xr-x ntp ntp system_u:object_r:etc_t > [root at admin ntp]# ls -lZ drift > -rw-r--r-- ntp ntp root:object_r:etc_t drift > version of ntp? Mine (ntp-4.2.0.a.20040617-6) places the drift file in /var/lib/ntp. /var/lib/ntp seems appropriately labeled ntp_drift_t. tom -- Tom London From mroselinux at eastgranby.k12.ct.us Mon Jan 24 03:01:45 2005 From: mroselinux at eastgranby.k12.ct.us (mroselinux at eastgranby.k12.ct.us) Date: Sun, 23 Jan 2005 22:01:45 -0500 (EST) Subject: ntpd drift.TEMP file In-Reply-To: <4c4ba153050123113914160be4@mail.gmail.com> References: <1373.24.2.210.202.1106508630.squirrel@mail.eastgranby.k12.ct.us> <4c4ba153050123113914160be4@mail.gmail.com> Message-ID: <1767.24.2.210.202.1106535705.squirrel@mail.eastgranby.k12.ct.us> Thanks, I had driftfile pointing to /etc/ntp and changing it to /var/lib/ntp fixed it. It's a file I've carried forward for at least four years. Mark > On Sun, 23 Jan 2005 14:30:30 -0500 (EST), > mroselinux at eastgranby.k12.ct.us > wrote: >> I have just built an FC3 samba server using the K12LTSP iso's and am >> getting the following messages on the log. >> >> Jan 21 01:55:14 admin ntpd[9988]: can't open /etc/ntp/drift.TEMP: >> Permission denied >> Jan 21 01:55:14 admin kernel: audit(1106290514.375:0): avc: denied { >> write } for pid=9988 exe=/usr/sbin/ntpd name=ntp dev=hda3 ino=3392705 >> scontext=root:system_r:ntpd_t tcontext=system_u:object_r:etc_t >> tclass=dir >> >> With SELinux enabled, the drift file could not be created. In >> permissive >> mode, the drift file is properly created and updated. What have I done >> wrong? >> >> [root at admin ntp]# ls -dZ . >> drwxr-xr-x ntp ntp system_u:object_r:etc_t >> [root at admin ntp]# ls -lZ drift >> -rw-r--r-- ntp ntp root:object_r:etc_t drift >> > version of ntp? > > Mine (ntp-4.2.0.a.20040617-6) places the drift file in /var/lib/ntp. > /var/lib/ntp seems appropriately labeled ntp_drift_t. > > tom > > -- > Tom London > > -- > 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 Mon Jan 24 19:36:38 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 24 Jan 2005 14:36:38 -0500 Subject: Exim In-Reply-To: <1106348777.28341.11.camel@hampton-pc.rainbolthampton.net> References: <1106348777.28341.11.camel@hampton-pc.rainbolthampton.net> Message-ID: <1106595398.19246.190.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-01-21 at 18:06, David Hampton wrote: > Does anyone have file context and type enforcement files for exim? I'd > like to lock exim down, but I'd rather not have to start from scratch if > I can help it. Google did produce a reference to an exim.te file on > NSA's SELinux mailing list archive, but it seems that the file > attachment has already been deleted. Thanks. The file attachment should be accessible again - permissions problem on the server. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Mon Jan 24 20:02:22 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 24 Jan 2005 15:02:22 -0500 Subject: targeted policy: crond_t now invalid for initrc_t ? In-Reply-To: <4c4ba153050122130677eb79a5@mail.gmail.com> References: <4c4ba153050122130677eb79a5@mail.gmail.com> Message-ID: <41F5544E.5070701@redhat.com> Tom London wrote: >Running targeted/enforcing, latest Rawhide: > >Get the following on boot with latest policy (selinux-policy-targeted-1.21.2-6): > >Jan 22 12:57:54 localhost kernel: audit(1106427474.075:0): >security_compute_sid: invalid context user_u:system_r:crond_t for >scontext=user_u:system_r:initrc_t >tcontext=system_u:object_r:crond_exec_t tclass=process >Jan 22 12:57:54 localhost gpm[2789]: *** info [mice.c(1766)]: >Jan 22 12:57:54 localhost gpm[2789]: imps2: Auto-detected intellimouse PS/2 >Jan 22 12:57:55 localhost kernel: audit(1106427475.435:0): >security_compute_sid: invalid context user_u:system_r:crond_t for >scontext=user_u:system_r:initrc_t >tcontext=system_u:object_r:anacron_exec_t tclass=process >Jan 22 12:57:55 localhost xfs[2826]: ignoring font path element >/usr/X11R6/lib/X11/fonts/Speedo (unreadable) >Jan 22 12:57:55 localhost kernel: audit(1106427475.634:0): >security_compute_sid: invalid context user_u:system_r:crond_t for >scontext=user_u:system_r:initrc_t >tcontext=system_u:object_r:crond_exec_t tclass=process > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Can you try a make -C /etc/selinux/targeted/src/policy load From abdul3003 at yahoo.com Tue Jan 25 03:24:54 2005 From: abdul3003 at yahoo.com (abdul ayub) Date: Mon, 24 Jan 2005 19:24:54 -0800 (PST) Subject: Hi,my e- mail for the list Message-ID: <20050125032454.51458.qmail@web13808.mail.yahoo.com> Hi, This is abdul ayub.i am sending you the e-mail for adding and the e-mail is abdul3003 at yahoo.com thanks abdul ayub. --------------------------------- Do you Yahoo!? Yahoo! Search presents - Jib Jab's 'Second Term' -------------- next part -------------- An HTML attachment was scrubbed... URL: From selinux at gmail.com Tue Jan 25 15:40:43 2005 From: selinux at gmail.com (Tom London) Date: Tue, 25 Jan 2005 07:40:43 -0800 Subject: targeted policy: crond_t now invalid for initrc_t ? In-Reply-To: <41F5544E.5070701@redhat.com> References: <4c4ba153050122130677eb79a5@mail.gmail.com> <41F5544E.5070701@redhat.com> Message-ID: <4c4ba1530501250740404323ac@mail.gmail.com> On Mon, 24 Jan 2005 15:02:22 -0500, Daniel J Walsh wrote: > Can you try a > make -C /etc/selinux/targeted/src/policy load > Sorry, no soap. :-( Here's a log: [root at tlondon ~]# cd /etc/selinux/targeted [root at tlondon targeted]# cd src/policy [root at tlondon policy]# make -C /etc/selinux/targeted/src/policy load make: Entering directory `/etc/selinux/targeted/src/policy' /usr/sbin/load_policy /etc/selinux/targeted/policy/policy.18 touch tmp/load make: Leaving directory `/etc/selinux/targeted/src/policy' [root at tlondon ~]# cd /etc/init.d [root at tlondon init.d]# ./crond status crond is stopped [root at tlondon init.d]# ./crond start Starting crond: /etc/init.d/functions: line 148: /usr/sbin/crond: Permission denied [FAILED] [root at tlondon init.d]# Here's the AVC: Jan 25 07:38:17 localhost kernel: audit(1106667497.815:0): security_compute_sid: invalid context root:system_r:crond_t for scontext=root:system_r:initrc_t tcontext=system_u:object_r:crond_exec_t tclass=process tom -- Tom London From dwalsh at redhat.com Tue Jan 25 17:10:52 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 25 Jan 2005 12:10:52 -0500 Subject: targeted policy: crond_t now invalid for initrc_t ? In-Reply-To: <4c4ba1530501250740404323ac@mail.gmail.com> References: <4c4ba153050122130677eb79a5@mail.gmail.com> <41F5544E.5070701@redhat.com> <4c4ba1530501250740404323ac@mail.gmail.com> Message-ID: <41F67D9C.8000408@redhat.com> Tom London wrote: >On Mon, 24 Jan 2005 15:02:22 -0500, Daniel J Walsh wrote: > > >>Can you try a >>make -C /etc/selinux/targeted/src/policy load >> >> >> >Sorry, no soap. :-( > >Here's a log: >[root at tlondon ~]# cd /etc/selinux/targeted >[root at tlondon targeted]# cd src/policy >[root at tlondon policy]# make -C /etc/selinux/targeted/src/policy load >make: Entering directory `/etc/selinux/targeted/src/policy' >/usr/sbin/load_policy /etc/selinux/targeted/policy/policy.18 >touch tmp/load >make: Leaving directory `/etc/selinux/targeted/src/policy' >[root at tlondon ~]# cd /etc/init.d >[root at tlondon init.d]# ./crond status >crond is stopped >[root at tlondon init.d]# ./crond start >Starting crond: /etc/init.d/functions: line 148: /usr/sbin/crond: >Permission denied > [FAILED] >[root at tlondon init.d]# > >Here's the AVC: >Jan 25 07:38:17 localhost kernel: audit(1106667497.815:0): >security_compute_sid: invalid context root:system_r:crond_t for >scontext=root:system_r:initrc_t >tcontext=system_u:object_r:crond_exec_t tclass=process > >tom > > > > Ok, you need to change the policy for crond.te --- crond.te~ 2005-01-21 16:16:11.000000000 -0500 +++ crond.te 2005-01-25 12:04:52.000000000 -0500 @@ -19,5 +19,5 @@ type sysadm_cron_spool_t, file_type, sysadmfile; type crond_log_t, file_type, sysadmfile; type crond_var_run_t, file_type, sysadmfile; -domain_auto_trans(initrc_t, crond_exec_t, crond_t) -domain_auto_trans(initrc_t, anacron_exec_t, crond_t) +domain_auto_trans(initrc_t, crond_exec_t, unconfined_t) +domain_auto_trans(initrc_t, anacron_exec_t, unconfined_t) I will update policy and throw it out on people. selinux-policy-targeted-1.21.3-2 From lockhart at redhat.com Wed Jan 26 02:34:37 2005 From: lockhart at redhat.com (John W. Lockhart) Date: Tue, 25 Jan 2005 21:34:37 -0500 Subject: Running httpd scripts from nfs mounts? Message-ID: <41F701BD.2040302@redhat.com> I'm trying to run scripts via httpd from a trusted nfs server, but selinux is preventing me: kernel: audit(1106703013.728:0): avc: denied { execute } for pid=28425 exe=/usr/sbin/httpd name=sanity_server.pl dev=0:12 ino=32407792 scontext=root:system_r:httpd_t tcontext=system_u:object_r:nfs_t tclass=file So I umounted the nfs volume, and added the following to the mount options in /etc/fstab: context=system_u:object_r:httpd_sys_content_t I mounted the volume again, and re-tried. That failed with: kernel: audit(1106705663.904:0): avc: denied { execute_no_trans } for pid=28573 exe=/usr/sbin/httpd path=/mnt/myserver/testing-scripts/sanity_server.pl dev=0:12 ino=3 2407792 scontext=root:system_r:httpd_t tcontext=system_u:object_r:httpd_sys_content_t tclass=file Now, there's a lot of miscellaneous stuff on /mnt/myserver, not just the web scripts. I need to figure out how to get the scripts working again (preferably without breaking anything else)... they worked fine under RHEL3, but are failing as above under the current RHEL4 candidate. kernel is: 2.6.9-5.EL #1 SMP Wed Jan 5 19:23:24 EST 2005 ia64 ia64 ia64 GNU/Linux (The script fails on other architectures, as well; I just happened to be using the ia64 box tonight.) Any/all words of wisdom appreciated, -- John From walters at redhat.com Wed Jan 26 05:09:03 2005 From: walters at redhat.com (Colin Walters) Date: Wed, 26 Jan 2005 00:09:03 -0500 Subject: Running httpd scripts from nfs mounts? In-Reply-To: <41F701BD.2040302@redhat.com> References: <41F701BD.2040302@redhat.com> Message-ID: <1106716143.4353.14.camel@nexus.verbum.private> On Tue, 2005-01-25 at 21:34 -0500, John W. Lockhart wrote: > I'm trying to run scripts via httpd from a trusted nfs server, > but selinux is preventing me: > > kernel: audit(1106703013.728:0): avc: denied { execute } for pid=28425 > exe=/usr/sbin/httpd name=sanity_server.pl dev=0:12 ino=32407792 > scontext=root:system_r:httpd_t tcontext=system_u:object_r:nfs_t > tclass=file Yeah; we have a few booleans for NFS home dirs and the like, but it's difficult to support arbitrarily placement of nfs_t in policy. > So I umounted the nfs volume, and added the following to the > mount options in /etc/fstab: > context=system_u:object_r:httpd_sys_content_t This is the best approach, IMO. > I mounted the volume again, and re-tried. That failed with: > > kernel: audit(1106705663.904:0): avc: denied { execute_no_trans } for > pid=28573 exe=/usr/sbin/httpd > path=/mnt/myserver/testing-scripts/sanity_server.pl dev=0:12 ino=3 > 2407792 scontext=root:system_r:httpd_t > tcontext=system_u:object_r:httpd_sys_content_t tclass=file Weird. What's the output of "getsebool httpd_unified"? From lockhart at redhat.com Wed Jan 26 15:22:29 2005 From: lockhart at redhat.com (John W. Lockhart) Date: Wed, 26 Jan 2005 10:22:29 -0500 Subject: Running httpd scripts from nfs mounts? In-Reply-To: <1106716143.4353.14.camel@nexus.verbum.private> References: <41F701BD.2040302@redhat.com> <1106716143.4353.14.camel@nexus.verbum.private> Message-ID: <41F7B5B5.3010201@redhat.com> Colin Walters wrote: > > Weird. What's the output of "getsebool httpd_unified"? > # getsebool httpd_unified httpd_unified --> active -- John From selinux at gmail.com Wed Jan 26 16:42:54 2005 From: selinux at gmail.com (Tom London) Date: Wed, 26 Jan 2005 08:42:54 -0800 Subject: targeted policy: crond_t now invalid for initrc_t ? In-Reply-To: <41F67D9C.8000408@redhat.com> References: <4c4ba153050122130677eb79a5@mail.gmail.com> <41F5544E.5070701@redhat.com> <4c4ba1530501250740404323ac@mail.gmail.com> <41F67D9C.8000408@redhat.com> Message-ID: <4c4ba15305012608424a230772@mail.gmail.com> On Tue, 25 Jan 2005 12:10:52 -0500, Daniel J Walsh wrote: >> Ok, you need to change the policy for crond.te > > --- crond.te~ 2005-01-21 16:16:11.000000000 -0500 > +++ crond.te 2005-01-25 12:04:52.000000000 -0500 > @@ -19,5 +19,5 @@ > type sysadm_cron_spool_t, file_type, sysadmfile; > type crond_log_t, file_type, sysadmfile; > type crond_var_run_t, file_type, sysadmfile; > -domain_auto_trans(initrc_t, crond_exec_t, crond_t) > -domain_auto_trans(initrc_t, anacron_exec_t, crond_t) > +domain_auto_trans(initrc_t, crond_exec_t, unconfined_t) > +domain_auto_trans(initrc_t, anacron_exec_t, unconfined_t) > > I will update policy and throw it out on people. > > selinux-policy-targeted-1.21.3-2 > I updated to selinux-policy-targeted-1.21.3-3 and I think I'm still seeing this problem: Jan 26 08:33:18 localhost kernel: audit(1106757198.533:0): security_compute_sid: invalid context user_u:system_r:system_crond_t for scontext=user_u:system_r:initrc_t tcontext=system_u:object_r:crond_exec_t tclass=process Jan 26 08:33:20 localhost kernel: audit(1106757200.158:0): security_compute_sid: invalid context user_u:system_r:system_crond_t for scontext=user_u:system_r:initrc_t tcontext=system_u:object_r:anacron_exec_t tclass=process Jan 26 08:33:20 localhost kernel: audit(1106757200.370:0): security_compute_sid: invalid context user_u:system_r:system_crond_t for scontext=user_u:system_r:initrc_t tcontext=system_u:object_r:crond_exec_t tclass=process Jan 26 08:33:29 localhost fstab-sync[3279]: removed all generated mount points crond.te says: type crond_var_run_t, file_type, sysadmfile; domain_auto_trans(initrc_t, crond_exec_t, system_crond_t) domain_auto_trans(initrc_t, anacron_exec_t, system_crond_t) unconfined_domain(system_crond_t) tom tom -- Tom London From selinux at gmail.com Wed Jan 26 17:20:29 2005 From: selinux at gmail.com (Tom London) Date: Wed, 26 Jan 2005 09:20:29 -0800 Subject: targeted policy: crond_t now invalid for initrc_t ? In-Reply-To: <1106759331.23386.274.camel@moss-spartans.epoch.ncsc.mil> References: <4c4ba153050122130677eb79a5@mail.gmail.com> <41F5544E.5070701@redhat.com> <4c4ba1530501250740404323ac@mail.gmail.com> <41F67D9C.8000408@redhat.com> <4c4ba15305012608424a230772@mail.gmail.com> <1106759331.23386.274.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4c4ba1530501260920c470b72@mail.gmail.com> On Wed, 26 Jan 2005 12:08:51 -0500, Stephen Smalley wrote: > The error message isn't a permission denial; it is an invalid context, > e.g. the role isn't authorized for the type in the targeted policy. Got > a 'role system_r types system_crond_t;' anywhere? Likely just a failure > to transfer over all of the necessary bits from the strict policy. > > Got it. The strict policy has this line, targeted does not. tom -- Tom London From hongwei at wustl.edu Wed Jan 26 18:28:51 2005 From: hongwei at wustl.edu (Hongwei Li) Date: Wed, 26 Jan 2005 12:28:51 -0600 (CST) Subject: selinux in fc3 and squirrelmail Message-ID: <4983.128.252.85.103.1106764131.squirrel@morpheus.wustl.edu> Hi, I have some problems with squirrelmail 1.4.3a in a redhat fc3 linux system where selinux is enforced. My system: os: RedHat FC3 linux, kernel 2.6.9, selinux enforced, iptables enabled web: httpd-2.0.52-3.1 (apache) sendmail: 8.13.1-2 squirrelmail: 1.4.3a-6.FC3 configured with smtp, not sendmail php: 4.3.10-3.2 mysql: 3.23.58-13 I have found 2 major problems of squirrelmail so far when selinux is enforced: 1. cannot connect mysql database for any purpose (addressbook, pref, etc.) -- always "Error initializing addressbook database" etc.; The system log shows: Jan 23 10:21:18 pippo kernel: audit(1105978878.395:0): avc: denied { write } for pid=21651 exe=/usr/sbin/httpd name=mysql.sock dev=hda3 ino=455088 scontext=root:system_r:httpd_t tcontext=user_u:object_r:var_lib_t tclass=sock_file 2. cannot attach any file to send -- always denied. The system log shows: ... Jan 25 15:09:25 pippo kernel: audit(1106687365.076:0): avc: denied { write } for pid=23123 exe=/usr/sbin/httpd name=attach dev=hda3 ino=470516 scontext=root:system_r:httpd_t tcontext=system_u:object_r:var_spool_t tclass=dir ... The sm attachment dir is set by default as in config.php: $attachment_dir = '/var/spool/squirrelmail/attach/'; and it's mode is: # ls -lZ /var/spool/squirrelmail/ drwx------ apache apache system_u:object_r:var_spool_t attach There might be more problems in sm when selinux is enforced, but I just haven't found. If I disable selinux while iptables is still enabled and the required ports are opened, everything in squirrelmail works well, no problem at all. Is there anybody using sm 1.4.3a in fc3 with selinux enforced? Do you have any problem with mysql database initialization and attach files to send? If you find a way to solve the problem, please share it with me. I'd greatly appreciate all help! Thanks! Hongwei Li From dwalsh at redhat.com Wed Jan 26 18:37:31 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 26 Jan 2005 13:37:31 -0500 Subject: targeted policy: crond_t now invalid for initrc_t ? In-Reply-To: <4c4ba1530501260920c470b72@mail.gmail.com> References: <4c4ba153050122130677eb79a5@mail.gmail.com> <41F5544E.5070701@redhat.com> <4c4ba1530501250740404323ac@mail.gmail.com> <41F67D9C.8000408@redhat.com> <4c4ba15305012608424a230772@mail.gmail.com> <1106759331.23386.274.camel@moss-spartans.epoch.ncsc.mil> <4c4ba1530501260920c470b72@mail.gmail.com> Message-ID: <41F7E36B.2030009@redhat.com> Tom London wrote: >On Wed, 26 Jan 2005 12:08:51 -0500, Stephen Smalley wrote: > > >>The error message isn't a permission denial; it is an invalid context, >>e.g. the role isn't authorized for the type in the targeted policy. Got >>a 'role system_r types system_crond_t;' anywhere? Likely just a failure >>to transfer over all of the necessary bits from the strict policy. >> >> >> >> > >Got it. The strict policy has this line, targeted does not. > >tom > > Added in selinux-policy-targeted-1.21.3-5 From dwalsh at redhat.com Wed Jan 26 18:46:03 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 26 Jan 2005 13:46:03 -0500 Subject: Running httpd scripts from nfs mounts? In-Reply-To: <41F7B5B5.3010201@redhat.com> References: <41F701BD.2040302@redhat.com> <1106716143.4353.14.camel@nexus.verbum.private> <41F7B5B5.3010201@redhat.com> Message-ID: <41F7E56B.6010708@redhat.com> John W. Lockhart wrote: > Colin Walters wrote: > >> >> Weird. What's the output of "getsebool httpd_unified"? >> > > # getsebool httpd_unified > httpd_unified --> active > Policy does not have a can_exec(httpd_t, httpdcontent) Only can_exec(httpd_$1_script_t, httpdcontent) > -- John > > -- > 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 Wed Jan 26 18:59:29 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 26 Jan 2005 13:59:29 -0500 Subject: selinux in fc3 and squirrelmail In-Reply-To: <4983.128.252.85.103.1106764131.squirrel@morpheus.wustl.edu> References: <4983.128.252.85.103.1106764131.squirrel@morpheus.wustl.edu> Message-ID: <41F7E891.50304@redhat.com> Hongwei Li wrote: >Hi, > >I have some problems with squirrelmail 1.4.3a in a redhat fc3 linux system >where selinux is enforced. My system: > >os: RedHat FC3 linux, kernel 2.6.9, selinux enforced, iptables enabled >web: httpd-2.0.52-3.1 (apache) >sendmail: 8.13.1-2 >squirrelmail: 1.4.3a-6.FC3 configured with smtp, not sendmail >php: 4.3.10-3.2 >mysql: 3.23.58-13 > >I have found 2 major problems of squirrelmail so far when selinux is >enforced: > >1. cannot connect mysql database for any purpose (addressbook, pref, etc.) >-- always "Error initializing addressbook database" etc.; > >The system log shows: > >Jan 23 10:21:18 pippo kernel: audit(1105978878.395:0): avc: denied { >write } for pid=21651 exe=/usr/sbin/httpd name=mysql.sock dev=hda3 >ino=455088 scontext=root:system_r:httpd_t >tcontext=user_u:object_r:var_lib_t tclass=sock_file > >2. cannot attach any file to send -- always denied. > >The system log shows: >... >Jan 25 15:09:25 pippo kernel: audit(1106687365.076:0): avc: denied { >write } for pid=23123 exe=/usr/sbin/httpd name=attach dev=hda3 ino=470516 >scontext=root:system_r:httpd_t tcontext=system_u:object_r:var_spool_t >tclass=dir >... > >The sm attachment dir is set by default as in config.php: > >$attachment_dir = '/var/spool/squirrelmail/attach/'; > >and it's mode is: > ># ls -lZ /var/spool/squirrelmail/ >drwx------ apache apache system_u:object_r:var_spool_t attach > > >There might be more problems in sm when selinux is enforced, but I just >haven't found. > >If I disable selinux while iptables is still enabled and the required >ports are opened, everything in squirrelmail works well, no problem at >all. > >Is there anybody using sm 1.4.3a in fc3 with selinux enforced? Do you >have any problem with mysql database initialization and attach files to >send? If you find a way to solve the problem, please share it with me. >I'd greatly appreciate all help! > >Thanks! > >Hongwei Li > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Have you updated to the latest policy? If not please do. With the latest policy installed run restorecon -R -v /var/lib /var/spool rpm -q -l mysql-server | restorecon -R -v -f - service mysql restart service apache restart From hongwei at wustl.edu Wed Jan 26 19:41:24 2005 From: hongwei at wustl.edu (Hongwei Li) Date: Wed, 26 Jan 2005 13:41:24 -0600 (CST) Subject: targeted policy: crond_t now invalid for initrc_t ? In-Reply-To: <41F7E36B.2030009@redhat.com> References: <4c4ba153050122130677eb79a5@mail.gmail.com> <41F5544E.5070701@redhat.c om> <4c4ba1530501250740404323ac@mail.gmail.com> <41F67D9C.8000408@redh at.com> <4c4ba15305012608424a230772@mail.gmail.com> <1106759331.23386. 274.camel@moss-spartans.epoch.ncsc.mil><4c4ba1530501260920c470b72@mail .gmail.com> <41F7E36B.2030009@redhat.com> Message-ID: <1251.128.252.85.103.1106768484.squirrel@morpheus.wustl.edu> > Tom London wrote: > >>On Wed, 26 Jan 2005 12:08:51 -0500, Stephen Smalley >> wrote: >> >> >>>The error message isn't a permission denial; it is an invalid context, >>>e.g. the role isn't authorized for the type in the targeted policy. Got >>>a 'role system_r types system_crond_t;' anywhere? Likely just a failure >>>to transfer over all of the necessary bits from the strict policy. >>> >>> >>> >>> >> >>Got it. The strict policy has this line, targeted does not. >> >>tom >> >> > Added in selinux-policy-targeted-1.21.3-5 > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > Where to get selinux-policy-targeted-1.21.3-5? When I run yum in my fc3 system, it lists only: Available Packages selinux-doc.noarch 1.14.1-1 base selinux-policy-strict.noarch 1.19.10-2 updates-released selinux-policy-strict-sources.noarch 1.19.10-2 updates-released selinux-policy-targeted.noarch 1.17.30-2.73 updates-released selinux-policy-targeted-sources.noarch 1.17.30-2.73 updates-released Thanks! Hongwei Li From dwalsh at redhat.com Wed Jan 26 20:03:53 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 26 Jan 2005 15:03:53 -0500 Subject: targeted policy: crond_t now invalid for initrc_t ? In-Reply-To: <1251.128.252.85.103.1106768484.squirrel@morpheus.wustl.edu> References: <4c4ba153050122130677eb79a5@mail.gmail.com> <41F5544E.5070701@redhat.c om> <4c4ba1530501250740404323ac@mail.gmail.com> <41F67D9C.8000408@redh at.com> <4c4ba15305012608424a230772@mail.gmail.com> <1106759331.23386. 274.camel@moss-spartans.epoch.ncsc.mil><4c4ba1530501260920c470b72@mail .gmail.com> <41F7E36B.2030009@redhat.com> <1251.128.252.85.103.1106768484.squirrel@morpheus.wustl.edu> Message-ID: <41F7F7A9.2050409@redhat.com> Hongwei Li wrote: >>Tom London wrote: >> >> >> >>>On Wed, 26 Jan 2005 12:08:51 -0500, Stephen Smalley >>>wrote: >>> >>> >>> >>> >>>>The error message isn't a permission denial; it is an invalid context, >>>>e.g. the role isn't authorized for the type in the targeted policy. Got >>>>a 'role system_r types system_crond_t;' anywhere? Likely just a failure >>>>to transfer over all of the necessary bits from the strict policy. >>>> >>>> >>>> >>>> >>>> >>>> >>>Got it. The strict policy has this line, targeted does not. >>> >>>tom >>> >>> >>> >>> >>Added in selinux-policy-targeted-1.21.3-5 >> >>-- >>fedora-selinux-list mailing list >>fedora-selinux-list at redhat.com >>http://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >> >> > >Where to get selinux-policy-targeted-1.21.3-5? When I run yum in my fc3 >system, it lists only: > >Available Packages >selinux-doc.noarch 1.14.1-1 base >selinux-policy-strict.noarch 1.19.10-2 >updates-released >selinux-policy-strict-sources.noarch 1.19.10-2 >updates-released >selinux-policy-targeted.noarch 1.17.30-2.73 >updates-released >selinux-policy-targeted-sources.noarch 1.17.30-2.73 >updates-released > >Thanks! > >Hongwei Li > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > No you have the correct policy. 1.21 and later are for rawhide, which will be FC4. You are up to date on policy so now you need to do the restorecon stuff. Dan From sds at epoch.ncsc.mil Wed Jan 26 17:08:51 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 26 Jan 2005 12:08:51 -0500 Subject: targeted policy: crond_t now invalid for initrc_t ? In-Reply-To: <4c4ba15305012608424a230772@mail.gmail.com> References: <4c4ba153050122130677eb79a5@mail.gmail.com> <41F5544E.5070701@redhat.com> <4c4ba1530501250740404323ac@mail.gmail.com> <41F67D9C.8000408@redhat.com> <4c4ba15305012608424a230772@mail.gmail.com> Message-ID: <1106759331.23386.274.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-01-26 at 11:42, Tom London wrote: > Jan 26 08:33:18 localhost kernel: audit(1106757198.533:0): > security_compute_sid: invalid context user_u:system_r:system_crond_t > for scontext=user_u:system_r:initrc_t > tcontext=system_u:object_r:crond_exec_t tclass=process The error message isn't a permission denial; it is an invalid context, e.g. the role isn't authorized for the type in the targeted policy. Got a 'role system_r types system_crond_t;' anywhere? Likely just a failure to transfer over all of the necessary bits from the strict policy. -- Stephen Smalley National Security Agency From hampton at employees.org Thu Jan 27 02:25:50 2005 From: hampton at employees.org (David Hampton) Date: Wed, 26 Jan 2005 21:25:50 -0500 Subject: Help with domain transitions Message-ID: <1106792750.12204.21.camel@hampton-pc.rainbolthampton.net> I'm having trouble getting exim to consistently transition domains so I can work on a new policy. I'm probably overlooking something simple here, but I can't figure out what. I started with the targeted policy on an up to date FC3 system. In my new exim.te file, I have a daemon_domain(exim, ...) declaration, which yields (among other things) the following in the policy.conf file when I run make: type exim_exec_t, file_type, sysadmfile, exec_type; allow initrc_t exim_exec_t:file { { read getattr lock execute ioctl } execute_no_trans }; allow sysadm_t exim_exec_t:file { { read getattr lock execute ioctl } execute_no_trans }; allow initrc_t exim_exec_t:file { read { getattr execute } }; allow exim_t exim_exec_t:file { read getattr lock execute ioctl }; allow exim_t exim_exec_t:file entrypoint; type_transition initrc_t exim_exec_t:process exim_t; The executable is correctly labeled: -rwsr-xr-x root root system_u:object_r:exim_exec_t /usr/sbin/exim I have run 'make reload', and /var/log/messages shows that the new policy file was loaded. However, when I run exim it still always ends up in the unconfined_t domain. It doesn't matter if I use 'service exim restart', 'run_init service exim restart', or start exim by hand. If I do a 'make fixfiles' then everything starts working as expected, and all three ways of starting exim cause the transition to occur into the exim_t domain. Perhaps this is because I forcefully (rpm -U --force) reinstalled the selinux-policy-targeted RPM the other night after I finished testing things? Something's definitely fubar on my system. David -------------- 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 walters at redhat.com Thu Jan 27 03:14:55 2005 From: walters at redhat.com (Colin Walters) Date: Wed, 26 Jan 2005 22:14:55 -0500 Subject: Running httpd scripts from nfs mounts? In-Reply-To: <41F7E56B.6010708@redhat.com> References: <41F701BD.2040302@redhat.com> <1106716143.4353.14.camel@nexus.verbum.private> <41F7B5B5.3010201@redhat.com> <41F7E56B.6010708@redhat.com> Message-ID: <1106795695.4353.35.camel@nexus.verbum.private> On Wed, 2005-01-26 at 13:46 -0500, Daniel J Walsh wrote: > John W. Lockhart wrote: > > > Colin Walters wrote: > > > >> > >> Weird. What's the output of "getsebool httpd_unified"? > >> > > > > # getsebool httpd_unified > > httpd_unified --> active > > > Policy does not have a can_exec(httpd_t, httpdcontent) > Only can_exec(httpd_$1_script_t, httpdcontent) Right; but why isn't it trying to transition, via the domain_auto_trans(httpd_t, httpdcontent, httpd_sys_script_t)? From Valdis.Kletnieks at vt.edu Thu Jan 27 07:38:48 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 27 Jan 2005 02:38:48 -0500 Subject: Help with domain transitions In-Reply-To: Your message of "Wed, 26 Jan 2005 21:25:50 EST." <1106792750.12204.21.camel@hampton-pc.rainbolthampton.net> References: <1106792750.12204.21.camel@hampton-pc.rainbolthampton.net> Message-ID: <200501270738.j0R7cmNY025020@turing-police.cc.vt.edu> On Wed, 26 Jan 2005 21:25:50 EST, David Hampton said: > type_transition initrc_t exim_exec_t:process exim_t; > policy file was loaded. However, when I run exim it still always ends > up in the unconfined_t domain. It doesn't matter if I use 'service exim > restart', 'run_init service exim restart', or start exim by hand. That type_transition is only going to do anything interesting if you're already in initrc_t - if you're starting off in unconfined_t, it won't do much. Most likely, the 'make fixfiles' relabelled something so that your next attempt at starting exim happened in some domain that could actually reach exim_t. But it's 2:30AM, and I have no idea what specifically got relabelled to explain it.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From sds at epoch.ncsc.mil Thu Jan 27 12:27:49 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 27 Jan 2005 07:27:49 -0500 Subject: Help with domain transitions In-Reply-To: <1106792750.12204.21.camel@hampton-pc.rainbolthampton.net> References: <1106792750.12204.21.camel@hampton-pc.rainbolthampton.net> Message-ID: <1106828868.28623.17.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-01-26 at 21:25, David Hampton wrote: > I'm having trouble getting exim to consistently transition domains so I > can work on a new policy. I'm probably overlooking something simple > here, but I can't figure out what. > > I started with the targeted policy on an up to date FC3 system. In my > new exim.te file, I have a daemon_domain(exim, ...) declaration, which > yields (among other things) the following in the policy.conf file when I > run make: > > type exim_exec_t, file_type, sysadmfile, exec_type; > allow initrc_t exim_exec_t:file { { read getattr lock execute ioctl } > execute_no_trans }; > allow sysadm_t exim_exec_t:file { { read getattr lock execute ioctl } > execute_no_trans }; > allow initrc_t exim_exec_t:file { read { getattr execute } }; > allow exim_t exim_exec_t:file { read getattr lock execute ioctl }; > allow exim_t exim_exec_t:file entrypoint; > type_transition initrc_t exim_exec_t:process exim_t; > > The executable is correctly labeled: > > -rwsr-xr-x root root system_u:object_r:exim_exec_t /usr/sbin/exim > > I have run 'make reload', and /var/log/messages shows that the new > policy file was loaded. However, when I run exim it still always ends > up in the unconfined_t domain. It doesn't matter if I use 'service exim > restart', 'run_init service exim restart', or start exim by hand. > > If I do a 'make fixfiles' then everything starts working as expected, > and all three ways of starting exim cause the transition to occur into > the exim_t domain. > > Perhaps this is because I forcefully (rpm -U --force) reinstalled the > selinux-policy-targeted RPM the other night after I finished testing > things? Something's definitely fubar on my system. If there isn't a type_transition from unconfined_t (or one of its aliases, like sysadm_t), then a direct execution of exim won't cause a transition - you would have to use the init scripts (whether directly or via /sbin/service or via run_init). Note that is a deviation from the default in strict policy, where direct_sysadm_daemon is enabled by default and direct transitions from sysadm_t are defined. IIUC, Gentoo has modified their policy to force people to only run daemons via the init scripts to ensure that they don't accidentally run them in the wrong domain. But the behavior you describe is very odd and might indicate a different problem that we have seen at times, where the kernel's incore notion of the inode's security label diverges from the on-disk extended attribute and doesn't get back into sync unless you manually relabel it. This happens when the type on the inode isn't defined in the policy when it is first brought incore, causing the kernel to label the incore inode with the unlabeled SID, but ls -Z will show you the on-disk extended attribute. Policy reload doesn't automatically walk the list of all inodes to recheck them, so this won't be correct until you either manually relabel the file or the incore inode is flushed and subsequently re-acquired after the type has been defined. fixfiles relabel might have yielded the latter result; it wouldn't have actually relabeled the inode if the on-disk extended attribute was already set correctly. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Thu Jan 27 15:36:35 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 27 Jan 2005 10:36:35 -0500 Subject: Running httpd scripts from nfs mounts? In-Reply-To: <1106795695.4353.35.camel@nexus.verbum.private> References: <41F701BD.2040302@redhat.com> <1106716143.4353.14.camel@nexus.verbum.private> <41F7B5B5.3010201@redhat.com> <41F7E56B.6010708@redhat.com> <1106795695.4353.35.camel@nexus.verbum.private> Message-ID: <41F90A83.5040907@redhat.com> Colin Walters wrote: >On Wed, 2005-01-26 at 13:46 -0500, Daniel J Walsh wrote: > > >>John W. Lockhart wrote: >> >> >> >>>Colin Walters wrote: >>> >>> >>> >>>>Weird. What's the output of "getsebool httpd_unified"? >>>> >>>> >>>> >>># getsebool httpd_unified >>>httpd_unified --> active >>> >>> >>> >>Policy does not have a can_exec(httpd_t, httpdcontent) >>Only can_exec(httpd_$1_script_t, httpdcontent) >> >> > >Right; but why isn't it trying to transition, via the >domain_auto_trans(httpd_t, httpdcontent, httpd_sys_script_t)? > > > > Ah, good point, I wonder if this might be a bug? Is the kernel not seeing the file as httpdcontent but as nfs_t even though the mount option was specified. >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From sds at epoch.ncsc.mil Thu Jan 27 15:33:41 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 27 Jan 2005 10:33:41 -0500 Subject: Running httpd scripts from nfs mounts? In-Reply-To: <41F90A83.5040907@redhat.com> References: <41F701BD.2040302@redhat.com> <1106716143.4353.14.camel@nexus.verbum.private> <41F7B5B5.3010201@redhat.com> <41F7E56B.6010708@redhat.com> <1106795695.4353.35.camel@nexus.verbum.private> <41F90A83.5040907@redhat.com> Message-ID: <1106840021.28623.119.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-01-27 at 10:36, Daniel J Walsh wrote: > Ah, good point, I wonder if this might be a bug? Is the kernel not > seeing the file as httpdcontent but as nfs_t > even though the mount option was specified. Is the filesystem mounted nosuid? If so, the kernel will ignore domain transitions on it for the same reason as it ignores setuid programs. -- Stephen Smalley National Security Agency From lockhart at redhat.com Thu Jan 27 16:25:40 2005 From: lockhart at redhat.com (John W. Lockhart) Date: Thu, 27 Jan 2005 11:25:40 -0500 Subject: Running httpd scripts from nfs mounts? In-Reply-To: <1106840021.28623.119.camel@moss-spartans.epoch.ncsc.mil> References: <41F701BD.2040302@redhat.com> <1106716143.4353.14.camel@nexus.verbum.private> <41F7B5B5.3010201@redhat.com> <41F7E56B.6010708@redhat.com> <1106795695.4353.35.camel@nexus.verbum.private> <41F90A83.5040907@redhat.com> <1106840021.28623.119.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <41F91604.6090902@redhat.com> Stephen Smalley wrote: > On Thu, 2005-01-27 at 10:36, Daniel J Walsh wrote: > >>Ah, good point, I wonder if this might be a bug? Is the kernel not >>seeing the file as httpdcontent but as nfs_t >>even though the mount option was specified. > > > Is the filesystem mounted nosuid? If so, the kernel will ignore domain > transitions on it for the same reason as it ignores setuid programs. > Aha! It is indeed mounted nosuid: rw,nosuid,nodev,noatime,rsize=8192,wsize=8192,bg,intr,soft,context=system_u:object_r:httpd_sys_content_t Any other options I should or shouldn't have in there? -- John From sds at epoch.ncsc.mil Thu Jan 27 16:52:13 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 27 Jan 2005 11:52:13 -0500 Subject: Running httpd scripts from nfs mounts? In-Reply-To: <41F91604.6090902@redhat.com> References: <41F701BD.2040302@redhat.com> <1106716143.4353.14.camel@nexus.verbum.private> <41F7B5B5.3010201@redhat.com> <41F7E56B.6010708@redhat.com> <1106795695.4353.35.camel@nexus.verbum.private> <41F90A83.5040907@redhat.com> <1106840021.28623.119.camel@moss-spartans.epoch.ncsc.mil> <41F91604.6090902@redhat.com> Message-ID: <1106844733.28623.159.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-01-27 at 11:25, John W. Lockhart wrote: > Aha! It is indeed mounted nosuid: > rw,nosuid,nodev,noatime,rsize=8192,wsize=8192,bg,intr,soft,context=system_u:object_r:httpd_sys_content_t > > Any other options I should or shouldn't have in there? Not clear you want to just remove nosuid, as that obviously has other security implications. If policy allowed httpd_t to set its exec context, then you could use a wrapper script that just does a runcon -t httpd_sys_script_t to manually transition to the new domain. -- Stephen Smalley National Security Agency From abdul3003 at yahoo.com Thu Jan 27 16:04:48 2005 From: abdul3003 at yahoo.com (abdul ayub) Date: Thu, 27 Jan 2005 08:04:48 -0800 (PST) Subject: Hi,I forget my username,and also it does not allow me to login. Message-ID: <20050127160448.81940.qmail@web13823.mail.yahoo.com> Hi, My name is abdul ayub.I forget my username but i know my password,but when i went there to login.I could not be able to login because i forget my username.Can you plz tell me my username so that i will be able to login and participate in the Forum. Thanks abdul ayub. --------------------------------- Do you Yahoo!? Yahoo! Search presents - Jib Jab's 'Second Term' -------------- next part -------------- An HTML attachment was scrubbed... URL: From aoliva at redhat.com Thu Jan 27 18:41:53 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 27 Jan 2005 16:41:53 -0200 Subject: getting nfsd to export /mnt/whatever and /l/x Message-ID: So I have some filesystems in /mnt/whatever, /l/x, /l/y/z that are exported over nfs. FC3 used to be able to export them fine, but in yesterday's rawhide tree, mountd fails to stat the exported mount points, so everything falls apart. bug 118946 seems to imply this should be fixed, but it doesn't work for me. Should I reopen that bug, or create a new one? -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From dwalsh at redhat.com Thu Jan 27 18:47:32 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 27 Jan 2005 13:47:32 -0500 Subject: getting nfsd to export /mnt/whatever and /l/x In-Reply-To: References: Message-ID: <41F93744.7080304@redhat.com> Alexandre Oliva wrote: >So I have some filesystems in /mnt/whatever, /l/x, /l/y/z that are >exported over nfs. FC3 used to be able to export them fine, but in >yesterday's rawhide tree, mountd fails to stat the exported mount >points, so everything falls apart. bug 118946 seems to imply this >should be fixed, but it doesn't work for me. Should I reopen that >bug, or create a new one? > > > Do you have the nfs booleans turned on? nfs_export_all_ro --> inactive nfs_export_all_rw --> inactive From selinux at gmail.com Thu Jan 27 18:59:43 2005 From: selinux at gmail.com (Tom London) Date: Thu, 27 Jan 2005 10:59:43 -0800 Subject: Enormous local.users (849MB!!!) Message-ID: <4c4ba15305012710592e7360d7@mail.gmail.com> Running strict/enforcing, latest rawhide. After installing today's updates, here is 'ls -l /etc/selinux/strict/users': [root at fedora users]# ls -l total 830620 -rw-r--r-- 1 root root 849689211 Jan 27 07:18 local.users -rw-r--r-- 1 root root 1062 Jan 26 15:17 local.users.rpmnew -rw-r--r-- 1 root root 511 Jan 27 07:12 system.users -rw-r--r-- 1 root root 509 Jan 26 07:08 system.users.rpmsave I did 'mv local.users foobar', and did a 'make reload': [root at fedora policy]# make reload m4 tunables/distro.tun tunables/tunable.tun tmp/program_used_flags.te /etc/selinux/strict/users/local.users | sed 's/^user/#user/g' >> tmp/local.users m4: /etc/selinux/strict/users/local.users: No such file or directory install -m 644 tmp/local.users /etc/selinux/strict/users/local.users Validating file_contexts ... /usr/sbin/setfiles -q -c /etc/selinux/strict/policy/policy.18 /etc/selinux/strict/contexts/files/file_contexts /usr/sbin/load_policy /etc/selinux/strict/policy/policy.18 touch tmp/load [root at fedora policy]# Here's the results: [root at fedora users]# ls -l total 1661216 -rw-r--r-- 1 root root 849689211 Jan 27 07:18 foobar -rw-r--r-- 1 root root 849690274 Jan 27 10:53 local.users -rw-r--r-- 1 root root 1062 Jan 26 15:17 local.users.rpmnew -rw-r--r-- 1 root root 511 Jan 27 07:12 system.users -rw-r--r-- 1 root root 509 Jan 26 07:08 system.users.rpmsave [root at fedora users]# [root at fedora policy]# ls -l tmp total 830636 -rw-r--r-- 1 root root 371 Jan 12 08:23 configurable_types -rw-r--r-- 1 root root 371 Jan 27 07:12 customizable_types -rw-r--r-- 1 root root 0 Jan 27 10:53 load -rw-r--r-- 1 root root 849690274 Jan 27 10:52 local.users -rw-r--r-- 1 root root 3354 Jan 27 07:12 program_used_flags.te -rw-r--r-- 1 root root 511 Jan 27 07:12 system.users -rw-r--r-- 1 root root 0 Jan 27 10:53 valid_fc [root at fedora policy]# What did I do wrong? 849MB tmp/local.users?????? Should the command be '>/tmp/local.users' instead of '>>/tmp/local.users'???? Can I clear this out? tom -- Tom London From dwalsh at redhat.com Thu Jan 27 19:06:16 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 27 Jan 2005 14:06:16 -0500 Subject: Enormous local.users (849MB!!!) In-Reply-To: <4c4ba15305012710592e7360d7@mail.gmail.com> References: <4c4ba15305012710592e7360d7@mail.gmail.com> Message-ID: <41F93BA8.2020109@redhat.com> Tom London wrote: >Running strict/enforcing, latest rawhide. > >After installing today's updates, here is 'ls -l /etc/selinux/strict/users': >[root at fedora users]# ls -l >total 830620 >-rw-r--r-- 1 root root 849689211 Jan 27 07:18 local.users >-rw-r--r-- 1 root root 1062 Jan 26 15:17 local.users.rpmnew >-rw-r--r-- 1 root root 511 Jan 27 07:12 system.users >-rw-r--r-- 1 root root 509 Jan 26 07:08 system.users.rpmsave > >I did 'mv local.users foobar', and did a 'make reload': >[root at fedora policy]# make reload >m4 tunables/distro.tun tunables/tunable.tun tmp/program_used_flags.te >/etc/selinux/strict/users/local.users | sed 's/^user/#user/g' >> >tmp/local.users >m4: /etc/selinux/strict/users/local.users: No such file or directory >install -m 644 tmp/local.users /etc/selinux/strict/users/local.users >Validating file_contexts ... >/usr/sbin/setfiles -q -c /etc/selinux/strict/policy/policy.18 >/etc/selinux/strict/contexts/files/file_contexts >/usr/sbin/load_policy /etc/selinux/strict/policy/policy.18 >touch tmp/load >[root at fedora policy]# > >Here's the results: >[root at fedora users]# ls -l >total 1661216 >-rw-r--r-- 1 root root 849689211 Jan 27 07:18 foobar >-rw-r--r-- 1 root root 849690274 Jan 27 10:53 local.users >-rw-r--r-- 1 root root 1062 Jan 26 15:17 local.users.rpmnew >-rw-r--r-- 1 root root 511 Jan 27 07:12 system.users >-rw-r--r-- 1 root root 509 Jan 26 07:08 system.users.rpmsave >[root at fedora users]# > >[root at fedora policy]# ls -l tmp >total 830636 >-rw-r--r-- 1 root root 371 Jan 12 08:23 configurable_types >-rw-r--r-- 1 root root 371 Jan 27 07:12 customizable_types >-rw-r--r-- 1 root root 0 Jan 27 10:53 load >-rw-r--r-- 1 root root 849690274 Jan 27 10:52 local.users >-rw-r--r-- 1 root root 3354 Jan 27 07:12 program_used_flags.te >-rw-r--r-- 1 root root 511 Jan 27 07:12 system.users >-rw-r--r-- 1 root root 0 Jan 27 10:53 valid_fc >[root at fedora policy]# > >What did I do wrong? 849MB tmp/local.users?????? >Should the command be '>/tmp/local.users' instead of >'>>/tmp/local.users'???? > >Can I clear this out? > tom > > > Yes From aoliva at redhat.com Thu Jan 27 19:40:48 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 27 Jan 2005 17:40:48 -0200 Subject: getting nfsd to export /mnt/whatever and /l/x In-Reply-To: References: Message-ID: On Jan 27, 2005, Alexandre Oliva wrote: > So I have some filesystems in /mnt/whatever, /l/x, /l/y/z that are > exported over nfs. FC3 used to be able to export them fine, but in > yesterday's rawhide tree, mountd fails to stat the exported mount > points, so everything falls apart. bug 118946 seems to imply this > should be fixed, but it doesn't work for me. Nevermind, I was missing nfs_export_all_r[ow]. Should these perhaps be enabled by default, for backward compatibility? -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From dwalsh at redhat.com Thu Jan 27 19:48:59 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 27 Jan 2005 14:48:59 -0500 Subject: getting nfsd to export /mnt/whatever and /l/x In-Reply-To: References: Message-ID: <41F945AB.1010506@redhat.com> Alexandre Oliva wrote: >On Jan 27, 2005, Alexandre Oliva wrote: > > > >>So I have some filesystems in /mnt/whatever, /l/x, /l/y/z that are >>exported over nfs. FC3 used to be able to export them fine, but in >>yesterday's rawhide tree, mountd fails to stat the exported mount >>points, so everything falls apart. bug 118946 seems to imply this >>should be fixed, but it doesn't work for me. >> >> > >Nevermind, I was missing nfs_export_all_r[ow]. Should these perhaps >be enabled by default, for backward compatibility? > > They should be turned on in a fresh install this is the booleans file currently in targeted File Edit Options Buffers Tools Help allow_kerberos=1 allow_ypbind=1 ftpd_is_daemon=1 ftp_home_dir=1 httpd_enable_cgi=1 httpd_enable_homedirs=1 httpd_ssi_exec=1 httpd_tty_comm=0 httpd_unified=1 named_write_master_zones=0 read_default_t=1 nfs_export_all_ro=1 nfs_export_all_rw=1 stunnel_is_daemon=0 use_nfs_home_dirs=0 They are turned off by default on strict. From lockhart at redhat.com Thu Jan 27 20:49:04 2005 From: lockhart at redhat.com (John W. Lockhart) Date: Thu, 27 Jan 2005 15:49:04 -0500 Subject: Running httpd scripts from nfs mounts? In-Reply-To: <1106844733.28623.159.camel@moss-spartans.epoch.ncsc.mil> References: <41F701BD.2040302@redhat.com> <1106716143.4353.14.camel@nexus.verbum.private> <41F7B5B5.3010201@redhat.com> <41F7E56B.6010708@redhat.com> <1106795695.4353.35.camel@nexus.verbum.private> <41F90A83.5040907@redhat.com> <1106840021.28623.119.camel@moss-spartans.epoch.ncsc.mil> <41F91604.6090902@redhat.com> <1106844733.28623.159.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <41F953C0.5030801@redhat.com> Stephen Smalley wrote: > On Thu, 2005-01-27 at 11:25, John W. Lockhart wrote: > >>Aha! It is indeed mounted nosuid: >>rw,nosuid,nodev,noatime,rsize=8192,wsize=8192,bg,intr,soft,context=system_u:object_r:httpd_sys_content_t > Not clear you want to just remove nosuid, as that obviously has other > security implications. If policy allowed httpd_t to set its exec > context, then you could use a wrapper script that just does a runcon -t > httpd_sys_script_t to manually transition to the new > domain. For now, since the nfs server contains trusted materials, I got rid of the nosuid. Got a little farther, but hit: kernel: audit(1106858631.779:0): avc: denied { search } for pid=22886 exe=/usr/bin/perl name=mnt dev=dm-0 ino=3932161 scontext=root:system_r:httpd_sys_script_t tcontext=system_u:object_r:mnt_t tclass=dir -- John From walters at redhat.com Thu Jan 27 21:07:37 2005 From: walters at redhat.com (Colin Walters) Date: Thu, 27 Jan 2005 16:07:37 -0500 Subject: Running httpd scripts from nfs mounts? In-Reply-To: <41F953C0.5030801@redhat.com> References: <41F701BD.2040302@redhat.com> <1106716143.4353.14.camel@nexus.verbum.private> <41F7B5B5.3010201@redhat.com> <41F7E56B.6010708@redhat.com> <1106795695.4353.35.camel@nexus.verbum.private> <41F90A83.5040907@redhat.com> <1106840021.28623.119.camel@moss-spartans.epoch.ncsc.mil> <41F91604.6090902@redhat.com> <1106844733.28623.159.camel@moss-spartans.epoch.ncsc.mil> <41F953C0.5030801@redhat.com> Message-ID: <1106860058.4677.18.camel@nexus.verbum.private> On Thu, 2005-01-27 at 15:49 -0500, John W. Lockhart wrote: > Stephen Smalley wrote: > > On Thu, 2005-01-27 at 11:25, John W. Lockhart wrote: > > > >>Aha! It is indeed mounted nosuid: > >>rw,nosuid,nodev,noatime,rsize=8192,wsize=8192,bg,intr,soft,context=system_u:object_r:httpd_sys_content_t > > > Not clear you want to just remove nosuid, as that obviously has other > > security implications. If policy allowed httpd_t to set its exec > > context, then you could use a wrapper script that just does a runcon -t > > httpd_sys_script_t to manually transition to the new > > domain. > > For now, since the nfs server contains trusted materials, I got rid of the > nosuid. Got a little farther, but hit: > > kernel: audit(1106858631.779:0): avc: denied { search } for pid=22886 > exe=/usr/bin/perl name=mnt dev=dm-0 ino=3932161 > scontext=root:system_r:httpd_sys_script_t tcontext=system_u:object_r:mnt_t > tclass=dir Wouldn't be harmful to allow by default, I think. From kmacmillan at tresys.com Thu Jan 27 21:18:57 2005 From: kmacmillan at tresys.com (Karl MacMillan) Date: Thu, 27 Jan 2005 16:18:57 -0500 Subject: [OT] SELinux symposium BoFs and WiPs Message-ID: <200501272118.j0RLIv8R015811@gotham.columbia.tresys.com> This message is for those attending or considering attending the SELinux Symposium. I have been asked to organize Birds-of-a-Feature sessions (BoFs) and Work-in-progress Reports (WiPs) for the upcoming SELinux symposium (http://www.selinux-symposium.net/). These sessions will be a less formal time to present new work or discuss topics of mutual interest. Hopefully this will provide an opportunity for community building and collaboration. The conference organizers are currently planning to have a reception with food and drinks on the evening of the first day of the conference. At the beginning of the reception there will be 30 - 45 minutes of WiPs. During the rest of the reception there will be small breakout groups for BoFs. If you are attending the symposium and interested in organizing a BoF or presenting a WiP please submit a proposal. The number of slots for each will be limited, so the sooner you submit your proposal the more likely it will be included. Details on the submission process are included below. Thanks, Karl Work-in-Progress Reports (WiPs) WiPs are an opportunity to present emerging projects and technologies to the community in short presentations. The presentations usually cover works-in-progress, new results, or timely topics. Speakers should submit the title of the presentation, a few sentences describing the topic, and a brief bio by Feb 14 to chair at selinux-symposium.org. Accepted presenters will be notified by email and the final schedule will be placed on the website and posted at the conference. Birds-of-a-Feature Sessions (BoFs) BoFs are an opportunity to have an informal gathering of community members interested in a particular topic. BoFs often include brief introductory remarks or a demonstration followed by discussion. Interested parties can submit suggestions for BoFs by Feb 14 to chair at selinux-symposium.org. Please include a title, brief description of the topic, and contact information for the organizer. Organizers will be notified of the acceptance of their BoF by email and the final schedule will be placed on the website and posted at the conference. --- Karl MacMillan Tresys Technology http://www.tresys.com (410) 290-1411 ext 134 From selinux at gmail.com Fri Jan 28 16:38:29 2005 From: selinux at gmail.com (Tom London) Date: Fri, 28 Jan 2005 08:38:29 -0800 Subject: execmod avcs from today's policy Message-ID: <4c4ba153050128083863c42324@mail.gmail.com> Running strict/enforcing, today's Rawhide. Noticed the avcs below in the log. I believe the java one may be from the sun JVM I have installed.... xscreensaver and helixplayer ones are new. My understanding is that I need to set the boolean 'allow_execmod' to allow this kind of thing (although nothing appears broken....) Do I have that correct? tom Jan 28 07:54:36 fedora gdm(pam_unix)[3218]: session opened for user tbl by (uid=0) Jan 28 07:54:48 fedora kernel: audit(1106927688.744:0): avc: denied { execmod } for pid=3491 comm=xscreensaver-gl path=/usr/X11R6/lib/libGL.so.1.2 dev=hda2 ino=4127021 scontext=user_u:user_r:user_t tcontext=system_u:object_r:shlib_t tclass=file Jan 28 07:54:57 fedora kernel: audit(1106927697.979:0): avc: denied { execmod } for pid=3549 comm=java path=/lib/libc-2.3.4.so dev=hda2 ino=3178539 scontext=user_u:user_r:user_t tcontext=system_u:object_r:shlib_t tclass=file Jan 28 07:55:19 fedora kernel: audit(1106927719.841:0): avc: denied { execmod } for pid=3650 comm=hxplay.bin path=/usr/lib/helix/plugins/swfrender.so dev=hda2 ino=4375247 scontext=user_u:user_r:user_t tcontext=system_u:object_r:shlib_t tclass=file Jan 28 07:55:21 fedora kernel: audit(1106927721.289:0): avc: denied { execmod } for pid=3650 comm=hxplay.bin path=/usr/lib/helix/plugins/oggfformat.so dev=hda2 ino=4376641 scontext=user_u:user_r:user_t tcontext=system_u:object_r:shlib_t tclass=file Jan 28 07:55:21 fedora kernel: audit(1106927721.316:0): avc: denied { execmod } for pid=3650 comm=hxplay.bin path=/usr/lib/helix/plugins/theorarend.so dev=hda2 ino=4376654 scontext=user_u:user_r:user_t tcontext=system_u:object_r:shlib_t tclass=file Jan 28 07:55:22 fedora kernel: audit(1106927722.757:0): avc: denied { execmod } for pid=3650 comm=hxplay.bin path=/usr/lib/helix/plugins/vorbisrend.so dev=hda2 ino=4376655 scontext=user_u:user_r:user_t tcontext=system_u:object_r:shlib_t tclass=file From sds at epoch.ncsc.mil Fri Jan 28 18:12:02 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 28 Jan 2005 13:12:02 -0500 Subject: execmod avcs from today's policy In-Reply-To: <4c4ba153050128083863c42324@mail.gmail.com> References: <4c4ba153050128083863c42324@mail.gmail.com> Message-ID: <1106935922.32737.83.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-01-28 at 11:38, Tom London wrote: > Running strict/enforcing, today's Rawhide. > > Noticed the avcs below in the log. > > I believe the java one may be from the sun JVM I have installed.... > xscreensaver and helixplayer ones are new. > > My understanding is that I need to set the boolean 'allow_execmod' to > allow this kind of thing (although nothing appears broken....) > > Do I have that correct? I think that the allow_execmod boolean only allows execmod permission to files labeled with the new texrel_shlib_t type. Or at least that is what it should do. Any existing occurrences of execmod permission in the policy should be changed to use texrel_shlib_t now that it is defined, and then any DSOs that require it should be relabeled to that type. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Fri Jan 28 18:35:25 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 28 Jan 2005 13:35:25 -0500 Subject: execmod avcs from today's policy In-Reply-To: <1106935922.32737.83.camel@moss-spartans.epoch.ncsc.mil> References: <4c4ba153050128083863c42324@mail.gmail.com> <1106935922.32737.83.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1106937325.32737.99.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-01-28 at 13:12, Stephen Smalley wrote: > I think that the allow_execmod boolean only allows execmod permission to > files labeled with the new texrel_shlib_t type. Or at least that is > what it should do. Any existing occurrences of execmod permission in > the policy should be changed to use texrel_shlib_t now that it is > defined, and then any DSOs that require it should be relabeled to that > type. We should also wrap occurrences of execmem with a boolean, but a separate one than the execmod rules. Might also want multiple booleans, e.g. to allow certain programs without allowing all others. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Fri Jan 28 18:55:51 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 28 Jan 2005 13:55:51 -0500 Subject: execmod avcs from today's policy In-Reply-To: <4c4ba153050128083863c42324@mail.gmail.com> References: <4c4ba153050128083863c42324@mail.gmail.com> Message-ID: <1106938550.32737.108.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-01-28 at 11:38, Tom London wrote: > Jan 28 07:54:57 fedora kernel: audit(1106927697.979:0): avc: denied > { execmod } for pid=3549 comm=java path=/lib/libc-2.3.4.so dev=hda2 > ino=3178539 scontext=user_u:user_r:user_t > tcontext=system_u:object_r:shlib_t tclass=file Naturally, relabeling libc to texrel_shlib_t isn't an option. Likewise for ld.so. java needs to run in its own domain so that we only have to give execmod to shlib_t to specific domains, not the base user domain. Care to make one? -- Stephen Smalley National Security Agency From hongwei at wustl.edu Fri Jan 28 20:38:04 2005 From: hongwei at wustl.edu (Hongwei Li) Date: Fri, 28 Jan 2005 14:38:04 -0600 (CST) Subject: selinux and feedback from web Message-ID: <1676.128.252.85.103.1106944684.squirrel@morpheus.wustl.edu> Hi, My system information -- os: RedHat FC3 linux, kernel-2.6.10-1.741_FC3, selinux enforced, iptables enabled selinux: selinux-policy-targeted-1.17.30-2.73 (the most update one) iptables: iptables-1.2.11-3.1.FC3 web: httpd-2.0.52-3.1 sendmail: sendmail-8.13.1-2 php: php-4.3.10-3.2 SELINUXTYPE targeted I have a testing feedback php code for my web site using mail($toaddress, $subject, $mailcontent, $fromaddress); If selinux is disabled, the code works well. The user ($toaddress) receives the content ($mailcontent), etc. However, if selinux is enforced, the user does not receive it and the system log shows: Jan 28 14:19:46 pippo kernel: audit(1106943586.048:0): avc: denied { read } for pid=6801 exe=/usr/sbin/sendmail.sendmail name=clientmqueue dev=hda3 ino=470506 scontext=user_u:system_r:httpd_sys_script_t tcontext=system_u:object_r:mqueue_spool_t tclass=dir Should I do something to make it working with selinux enforced? Thanks! Hongwei From ivg2 at cornell.edu Sat Jan 29 03:06:21 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 28 Jan 2005 20:06:21 -0700 Subject: execmod avcs from today's policy In-Reply-To: <1106938550.32737.108.camel@moss-spartans.epoch.ncsc.mil> References: <4c4ba153050128083863c42324@mail.gmail.com> <1106938550.32737.108.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1106967981.18431.0.camel@cobra.ivg2.net> On Fri, 2005-01-28 at 13:55 -0500, Stephen Smalley wrote: > On Fri, 2005-01-28 at 11:38, Tom London wrote: > > Jan 28 07:54:57 fedora kernel: audit(1106927697.979:0): avc: denied > > { execmod } for pid=3549 comm=java path=/lib/libc-2.3.4.so dev=hda2 > > ino=3178539 scontext=user_u:user_r:user_t > > tcontext=system_u:object_r:shlib_t tclass=file > > Naturally, relabeling libc to texrel_shlib_t isn't an option. > Likewise for ld.so. java needs to run in its own domain so that we only > have to give execmod to shlib_t to specific domains, not the base user > domain. Care to make one? What exactly is causing this denial... I see two more like it: audit(1106919680.669:0): avc: denied { execmod } for pid=26098 comm=setiathome path=/lib/tls/libc-2.3.4.so dev=dm-0 ino=115333 scontext=user_u:user_r:user_t tcontext=system_u:object_r:shlib_t tclass=file audit(1106919680.669:0): avc: denied { execmod } for pid=26098 comm=setiathome path=/lib/ld-2.3.4.so dev=dm-0 ino=113630 scontext=user_u:user_r:user_t tcontext=system_u:object_r:ld_so_t tclass=file and audit(1106936406.702:0): avc: denied { execmod } for pid=669 comm=ut2004-bin path=/lib/tls/libc-2.3.4.so dev=dm-0 ino=115333 scontext=user_u:user_r:user_t tcontext=system_u:object_r:shlib_t tclass=file audit(1106936406.798:0): avc: denied { execmod } for pid=669 comm=ut2004-bin path=/lib/ld-2.3.4.so dev=dm-0 ino=113630 scontext=user_u:user_r:user_t tcontext=system_u:object_r:ld_so_t tclass=file -- Ivan Gyurdiev Cornell University From aoliva at redhat.com Sat Jan 29 07:02:15 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 29 Jan 2005 05:02:15 -0200 Subject: getting nfsd to export /mnt/whatever and /l/x In-Reply-To: <41F945AB.1010506@redhat.com> References: <41F945AB.1010506@redhat.com> Message-ID: On Jan 27, 2005, Daniel J Walsh wrote: > Alexandre Oliva wrote: >> Nevermind, I was missing nfs_export_all_r[ow]. Should these perhaps >> be enabled by default, for backward compatibility? >> > They should be turned on in a fresh install I had an all-new rawhide install on Wednesday or so (not sure whether I did the install on Wednesday with the previous day's rawhide, or used Wednesday's rawhide for an install on Thursday), and they certainly were not active. Maybe the bug was fixed since then? -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From selinux at gmail.com Sat Jan 29 16:56:00 2005 From: selinux at gmail.com (Tom London) Date: Sat, 29 Jan 2005 08:56:00 -0800 Subject: execmod avcs from today's policy In-Reply-To: <1106967981.18431.0.camel@cobra.ivg2.net> References: <4c4ba153050128083863c42324@mail.gmail.com> <1106938550.32737.108.camel@moss-spartans.epoch.ncsc.mil> <1106967981.18431.0.camel@cobra.ivg2.net> Message-ID: <4c4ba15305012908565556b0c4@mail.gmail.com> On Fri, 28 Jan 2005 20:06:21 -0700, Ivan Gyurdiev wrote: > What exactly is causing this denial... I see two more like it: > > audit(1106919680.669:0): avc: denied { execmod } for pid=26098 > comm=setiathome path=/lib/tls/libc-2.3.4.so dev=dm-0 ino=115333 > scontext=user_u:user_r:user_t tcontext=system_u:object_r:shlib_t > tclass=file > > audit(1106919680.669:0): avc: denied { execmod } for pid=26098 > comm=setiathome path=/lib/ld-2.3.4.so dev=dm-0 ino=113630 > scontext=user_u:user_r:user_t tcontext=system_u:object_r:ld_so_t > tclass=file > > and > > audit(1106936406.702:0): avc: denied { execmod } for pid=669 > comm=ut2004-bin path=/lib/tls/libc-2.3.4.so dev=dm-0 ino=115333 > scontext=user_u:user_r:user_t tcontext=system_u:object_r:shlib_t > tclass=file > audit(1106936406.798:0): avc: denied { execmod } for pid=669 > comm=ut2004-bin path=/lib/ld-2.3.4.so dev=dm-0 ino=113630 > scontext=user_u:user_r:user_t tcontext=system_u:object_r:ld_so_t > tclass=file > Here's my understanding: The new kernel/policy can now enforce controls on the modification to memory mapped regions that can be executed. I think this is a very good thing..... However, existing code/applications do funny things with such memory mapped regions (like writing one word, like relocating, like ....), so we get these AVCs for them. There seem to be two approaches to fix: first, fix the apps (I believe you need new tool chain at least, or am I getting confused....), and now that there policy support, create policy specs for the apps that need it. In my case, I see these for the Sun Jave JVM I have installed. In your case, looks like 'setiathome' and 'ut2004' are the culprits. Do I have this correct? tom -- Tom London From ivg2 at cornell.edu Sat Jan 29 17:42:20 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Sat, 29 Jan 2005 10:42:20 -0700 Subject: execmod avcs from today's policy In-Reply-To: <4c4ba15305012908565556b0c4@mail.gmail.com> References: <4c4ba153050128083863c42324@mail.gmail.com> <1106938550.32737.108.camel@moss-spartans.epoch.ncsc.mil> <1106967981.18431.0.camel@cobra.ivg2.net> <4c4ba15305012908565556b0c4@mail.gmail.com> Message-ID: <1107020540.26622.2.camel@cobra.ivg2.net> > However, existing code/applications do funny things with such memory > mapped regions (like writing one word, like relocating, like ....), so > we get these AVCs for them. But that's a different kind of execmod denial than others I've seen - I thought libs with text relocations all had this TEXTREL tag... [phantom at cobra ~]$ readelf -d /usr/lib/libSDL-1.2.so.0.7.0|grep TEXTREL 0x00000016 (TEXTREL) 0x0 -- Ivan Gyurdiev Cornell University From aoliva at redhat.com Sat Jan 29 19:19:04 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 29 Jan 2005 17:19:04 -0200 Subject: getting nfsd to export /mnt/whatever and /l/x In-Reply-To: References: <41F945AB.1010506@redhat.com> Message-ID: On Jan 29, 2005, Alexandre Oliva wrote: > I had an all-new rawhide install on Wednesday or so (not sure whether > I did the install on Wednesday with the previous day's rawhide, or > used Wednesday's rawhide for an install on Thursday), and they > certainly were not active. Maybe the bug was fixed since then? And to make matters worse, after up2dating the box to yesterday's rawhide, the nfs_* setting was back to inactive (and 0 in the booleans config file), although I had enabled it with setsebool -P before. What gives? -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From sitsofe at yahoo.com Sun Jan 30 17:14:30 2005 From: sitsofe at yahoo.com (Sitsofe Wheeler) Date: Sun, 30 Jan 2005 17:14:30 +0000 Subject: Permissive mode on individual services Message-ID: <1107105270.4328.22.camel@galvatron.localdomain> Hello, In a similar way to the way that selinux can be turned on or off for a single service like apache, is there anyway to selectively have permissive mode on just one service and enforcing on all the rest? -- Sitsofe | http://sucs.org/~sits/ From m3freak at rogers.com Mon Jan 31 01:06:37 2005 From: m3freak at rogers.com (Kanwar Ranbir Sandhu) Date: Sun, 30 Jan 2005 20:06:37 -0500 Subject: Request Tracker 3 Message-ID: <1107133597.4988.34.camel@localhost.localdomain> Hello Everyone, Has anyone attempted to run RT3 (3.2.2) on a FC3 system? I'm running into a bunch of selinux errors, and I'm having problems resolving the issue: I'm just not very familiar with selinux. Here's the error in /var/log/httpd/error_log: ---start--- [Sun Jan 30 19:42:14 2005] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Sun Jan 30 19:42:17 2005] [notice] Digest: generating secret for digest authentication ... [Sun Jan 30 19:42:17 2005] [notice] Digest: done [Sun Jan 30 19:42:17 2005] [notice] LDAP: Built with OpenLDAP LDAP SDK [Sun Jan 30 19:42:17 2005] [notice] LDAP: SSL support unavailable [Sun Jan 30 19:42:17 2005] [notice] FastCGI: process manager initialized (pid 669) [Sun Jan 30 19:42:17 2005] [warn] FastCGI: server "/var/www/rt/bin/mason_handler.fcgi" started (pid 670) [Sun Jan 30 19:42:17 2005] [notice] mod_python: Creating 4 session mutexes based on 256 max processes and 0 max threads. [Sun Jan 30 19:42:19 2005] [notice] Apache/2.0.52 (Fedora) configured -- resuming normal operations [Sun Jan 30 19:42:22 2005] [warn] FastCGI: server "/var/www/rt/bin/mason_handler.fcgi" started (pid 679) [Sun Jan 30 19:42:27 2005] [warn] FastCGI: server "/var/www/rt/bin/mason_handler.fcgi" started (pid 681) [Sun Jan 30 19:42:32 2005] [warn] FastCGI: server "/var/www/rt/bin/mason_handler.fcgi" started (pid 682) Log file /var/log/rt.log couldn't be written or created. RT can't run. at /var/www/rt/lib/RT.pm line 204. ---end--- And here's what's output to /var/log/messages while that's going on: ---start-- avc: denied { getattr } for pid=681 exe=/usr/bin/perl path=/var/log dev=dm-5 ino=129025 scontext=root:system_r:httpd_sys_script_t tcontext=system_u:object_r:var_log_t tclass=dir avc: denied { ioctl } for pid=693 exe=/usr/bin/perl path=/var/log/httpd/error_log dev=dm-5 ino=129070 scontext=root:system_r:httpd_sys_script_t tcontext=system_u:object_r:httpd_log_t tclass=file avc: denied { read } for pid=693 exe=/usr/bin/perl name=tmp dev=dm-3 ino=12 scontext=root:system_r:httpd_sys_script_t tcontext=system_u:object_r:tmp_t tclass=lnk_file ---end--- Ummm..not quite sure how to interpret that. But, it looks like selinux doesn't like the context of /var/log/rt.log, which currently is: -rw-r--r-- root rt system_u:object_r:httpd_log_t /var/log/rt.log And for /var/log/http (as well as for all files within): drwx------ root root system_u:object_r:httpd_log_t I could just turn off selinux, but seeing as how I've managed to run SugarCRM and Mambo on the same box, RT3 should work as well. Thanks in advance. Regards, Ranbir -- Kanwar Ranbir Sandhu Linux Consultant Systems Aligned Inc. www.systemsaligned.com From sds at epoch.ncsc.mil Mon Jan 31 12:36:14 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 31 Jan 2005 07:36:14 -0500 Subject: Permissive mode on individual services In-Reply-To: <1107105270.4328.22.camel@galvatron.localdomain> References: <1107105270.4328.22.camel@galvatron.localdomain> Message-ID: <1107174974.24654.4.camel@moss-spartans.epoch.ncsc.mil> On Sun, 2005-01-30 at 12:14, Sitsofe Wheeler wrote: > Hello, > > In a similar way to the way that selinux can be turned on or off for a > single service like apache, is there anyway to selectively have > permissive mode on just one service and enforcing on all the rest? Not presently. It would however be straightforward to add a macro the policy that includes both the allow rules from unconfined_domain and a corresponding auditallow rule for each such allow rule, so that when you apply that macro to a domain, it will be allowed to do everything but all of its accesses will be audited. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Mon Jan 31 13:00:36 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 31 Jan 2005 08:00:36 -0500 Subject: execmod avcs from today's policy In-Reply-To: <1106967981.18431.0.camel@cobra.ivg2.net> References: <4c4ba153050128083863c42324@mail.gmail.com> <1106938550.32737.108.camel@moss-spartans.epoch.ncsc.mil> <1106967981.18431.0.camel@cobra.ivg2.net> Message-ID: <1107176436.24654.23.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-01-28 at 22:06, Ivan Gyurdiev wrote: > What exactly is causing this denial... I see two more like it: > > audit(1106919680.669:0): avc: denied { execmod } for pid=26098 > comm=setiathome path=/lib/tls/libc-2.3.4.so dev=dm-0 ino=115333 > scontext=user_u:user_r:user_t tcontext=system_u:object_r:shlib_t > tclass=file > > audit(1106919680.669:0): avc: denied { execmod } for pid=26098 > comm=setiathome path=/lib/ld-2.3.4.so dev=dm-0 ino=113630 > scontext=user_u:user_r:user_t tcontext=system_u:object_r:ld_so_t > tclass=file > > and > > audit(1106936406.702:0): avc: denied { execmod } for pid=669 > comm=ut2004-bin path=/lib/tls/libc-2.3.4.so dev=dm-0 ino=115333 > scontext=user_u:user_r:user_t tcontext=system_u:object_r:shlib_t > tclass=file > audit(1106936406.798:0): avc: denied { execmod } for pid=669 > comm=ut2004-bin path=/lib/ld-2.3.4.so dev=dm-0 ino=113630 > scontext=user_u:user_r:user_t tcontext=system_u:object_r:ld_so_t > tclass=file Legacy binaries (those that lack PT_GNU_STACK on x86) have PROT_READ mmap/mprotect requests automatically translated to PROT_READ|PROT_EXEC for backward compatibility. The dynamic linker needs to modify one word in the mapping, so the linker makes it writable, modifies the word, and changes it back to read-only. But since it is a legacy binary, the kernel views the latter as an attempt to make executable a mapping that was previously modified, and triggers the execmod permission check on it. Such legacy binaries should be placed into a separate domain so that they can be separately confined. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Mon Jan 31 13:10:33 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 31 Jan 2005 08:10:33 -0500 Subject: execmod avcs from today's policy In-Reply-To: <4c4ba15305012908565556b0c4@mail.gmail.com> References: <4c4ba153050128083863c42324@mail.gmail.com> <1106938550.32737.108.camel@moss-spartans.epoch.ncsc.mil> <1106967981.18431.0.camel@cobra.ivg2.net> <4c4ba15305012908565556b0c4@mail.gmail.com> Message-ID: <1107177033.24654.33.camel@moss-spartans.epoch.ncsc.mil> On Sat, 2005-01-29 at 11:56, Tom London wrote: > The new kernel/policy can now enforce controls on the modification to > memory mapped regions that can be executed. I think this is a very > good thing..... execmem permission controls the ability to make executable an anonymous mapping or a writable private file mapping. execmod permission controls the ability to make executable a previously modified private file mapping. The controls were introduced in http://marc.theaimsgroup.com/?l=bk-commits-head&m=110491550432114&w=2. > However, existing code/applications do funny things with such memory > mapped regions (like writing one word, like relocating, like ....), so > we get these AVCs for them. The dynamic linker needs to write one word; normally, this isn't a problem as the mapping in question is not executable. However, for legacy binaries, the read protection is translated to read|execute, which then triggers the checks. > There seem to be two approaches to fix: first, fix the apps (I believe > you need new tool chain at least, or am I getting confused....), and > now that there policy support, create policy specs for the apps that > need it. Newer tool chain will at least try to classify the application and mark it accordingly. Modifications to the application or its build may be necessary to avoid unnecessarily lax marking. > In my case, I see these for the Sun Jave JVM I have installed. In your > case, looks like 'setiathome' and 'ut2004' are the culprits. > > Do I have this correct? Yes. -- Stephen Smalley National Security Agency From twaugh at redhat.com Mon Jan 31 14:48:04 2005 From: twaugh at redhat.com (Tim Waugh) Date: Mon, 31 Jan 2005 14:48:04 +0000 Subject: findutils-4.2.15 Message-ID: <20050131144804.GN5322@redhat.com> Hi, I just updated findutils to 4.2.15 in devel. Please check that I didn't make any mistakes porting the findutils-selinux.patch. Thanks, Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jorton at redhat.com Mon Jan 31 16:48:29 2005 From: jorton at redhat.com (Joe Orton) Date: Mon, 31 Jan 2005 16:48:29 +0000 Subject: other Raw Hide avc messages Message-ID: <20050131164829.GA14626@redhat.com> selinux-policy-targeted-1.21.5-1 kernel-2.6.10-1.1115_FC4 one lot of: type=KERNEL msg=audit(1107189317.896:165031): avc: denied { create } for pid= 3061 exe=/usr/sbin/htt_server name=.iiimp-unix scontext=user_u:system_r:i18n_inp ut_t tcontext=user_u:object_r:i18n_input_var_run_t tclass=dir and many times: type=KERNEL msg=audit(1107189602.159:494563): avc: denied { transition } for pid=3596 exe=/usr/sbin/crond path=/bin/bash dev=hda3 ino=1933320 scontext=user_u :system_r:crond_t tcontext=system_u:system_r:unconfined_t tclass=process which seems to mean that all cron scripts are failing and I am getting a execl: couldn't exec `/bin/sh' execl: Permission denied message from crond every couple of minutes. joe From walters at redhat.com Mon Jan 31 16:58:06 2005 From: walters at redhat.com (Colin Walters) Date: Mon, 31 Jan 2005 11:58:06 -0500 Subject: Permissive mode on individual services In-Reply-To: <1107105270.4328.22.camel@galvatron.localdomain> References: <1107105270.4328.22.camel@galvatron.localdomain> Message-ID: <1107190686.3777.8.camel@nexus.verbum.private> On Sun, 2005-01-30 at 17:14 +0000, Sitsofe Wheeler wrote: > Hello, > > In a similar way to the way that selinux can be turned on or off for a > single service like apache, Yes; see: http://fedora.redhat.com/docs/selinux-faq-fc3/index.html#using-s-c-securitylevel The FAQ should probably also say that you can use e.g. "setsebool -P httpd_disable_trans=1" from the command line. Also note that you need to restart the service, e.g. "service httpd restart". From walters at redhat.com Mon Jan 31 17:05:26 2005 From: walters at redhat.com (Colin Walters) Date: Mon, 31 Jan 2005 12:05:26 -0500 Subject: Permissive mode on individual services In-Reply-To: <1107190686.3777.8.camel@nexus.verbum.private> References: <1107105270.4328.22.camel@galvatron.localdomain> <1107190686.3777.8.camel@nexus.verbum.private> Message-ID: <1107191126.3777.17.camel@nexus.verbum.private> On Mon, 2005-01-31 at 11:58 -0500, Colin Walters wrote: > On Sun, 2005-01-30 at 17:14 +0000, Sitsofe Wheeler wrote: > > Hello, > > > > In a similar way to the way that selinux can be turned on or off for a > > single service like apache, Sorry, I read your question too quickly, Stephen's response is right of course. From walters at redhat.com Mon Jan 31 17:12:48 2005 From: walters at redhat.com (Colin Walters) Date: Mon, 31 Jan 2005 12:12:48 -0500 Subject: Request Tracker 3 In-Reply-To: <1107133597.4988.34.camel@localhost.localdomain> References: <1107133597.4988.34.camel@localhost.localdomain> Message-ID: <1107191568.3777.25.camel@nexus.verbum.private> On Sun, 2005-01-30 at 20:06 -0500, Kanwar Ranbir Sandhu wrote: > Hello Everyone, > > Has anyone attempted to run RT3 (3.2.2) on a FC3 system? I'm running > into a bunch of selinux errors, and I'm having problems resolving the > issue: I'm just not very familiar with selinux. Have you seen the Fedora Apache/SELinux guide? http://fedora.redhat.com/docs/selinux-apache-fc3/ > avc: denied { getattr } for pid=681 exe=/usr/bin/perl path=/var/log > dev=dm-5 ino=129025 scontext=root:system_r:httpd_sys_script_t > tcontext=system_u:object_r:var_log_t tclass=dir Hmm. Given that we allow access to httpd_log_t which is in the default configuration a subdirectory of var_log_t, I'm surprised that this access is not allowed. Ideally though the app should not need this. > avc: denied { ioctl } for pid=693 exe=/usr/bin/perl > path=/var/log/httpd/error_log dev=dm-5 ino=129070 > scontext=root:system_r:httpd_sys_script_t > tcontext=system_u:object_r:httpd_log_t tclass=file This one is probably harmless; I think perl does an ioctl even on regular files in many situations (to find out whether it's a tty?). > avc: denied { read } for pid=693 exe=/usr/bin/perl name=tmp dev=dm-3 > ino=12 scontext=root:system_r:httpd_sys_script_t > tcontext=system_u:object_r:tmp_t tclass=lnk_file Is this /usr/tmp? Try running "chcon -h -t usr_t /usr/tmp". This is a bug in our policy package because it doesn't presently ensure that it's relabeled on upgrades. From m3freak at rogers.com Mon Jan 31 18:16:41 2005 From: m3freak at rogers.com (Kanwar Ranbir Sandhu) Date: Mon, 31 Jan 2005 13:16:41 -0500 Subject: Request Tracker 3 In-Reply-To: <1107191568.3777.25.camel@nexus.verbum.private> References: <1107133597.4988.34.camel@localhost.localdomain> <1107191568.3777.25.camel@nexus.verbum.private> Message-ID: <1107195401.4739.18.camel@localhost.localdomain> On Mon, 2005-31-01 at 12:12 -0500, Colin Walters wrote: > Have you seen the Fedora Apache/SELinux guide? > http://fedora.redhat.com/docs/selinux-apache-fc3/ Yes, I read that when I started to migrate SugarCRM from a FC1 box to a FC3 server, so I'm familiar with selinux. But, probably not enough to figure out what's wrong right now. > > avc: denied { getattr } for pid=681 exe=/usr/bin/perl path=/var/log > > dev=dm-5 ino=129025 scontext=root:system_r:httpd_sys_script_t > > tcontext=system_u:object_r:var_log_t tclass=dir > > Hmm. Given that we allow access to httpd_log_t which is in the default > configuration a subdirectory of var_log_t, I'm surprised that this > access is not allowed. Ideally though the app should not need this. In RT, you can define a separate log file instead of having everything dumped to /var/log/messages. I haven't tried yet, but I'm assuming if I disabled the separate log file, this error would disappear. I would rather keep /var/log/rt.log. It makes reading the log a lot easier since it will only contain messages pertaining to RT. > > avc: denied { ioctl } for pid=693 exe=/usr/bin/perl > > path=/var/log/httpd/error_log dev=dm-5 ino=129070 > > scontext=root:system_r:httpd_sys_script_t > > tcontext=system_u:object_r:httpd_log_t tclass=file > > This one is probably harmless; I think perl does an ioctl even on > regular files in many situations (to find out whether it's a tty?). I'll have to look into it. > > avc: denied { read } for pid=693 exe=/usr/bin/perl name=tmp dev=dm-3 > > ino=12 scontext=root:system_r:httpd_sys_script_t > > tcontext=system_u:object_r:tmp_t tclass=lnk_file > > Is this /usr/tmp? Try running "chcon -h -t usr_t /usr/tmp". This is a > bug in our policy package because it doesn't presently ensure that it's > relabeled on upgrades. Actually, it's just /tmp. FastCGI dumps its temporary files there while it's running. The location can be changed, but in the past (on FC1) when I've tried using /var/log/httpd/fastcgi, I just get a bunch of errors about FastCGI not having permission to write to that directory (I believe the only way I managed to fix that was by changing permissions on /var/log/httpd to 777). The command you mentioned above won't work in this case, will it? I'm assuming that context is meant only for directories under /usr. Thanks, Ranbir -- Kanwar Ranbir Sandhu Linux Consultant Systems Aligned Inc. www.systemsaligned.com From walters at redhat.com Mon Jan 31 18:43:35 2005 From: walters at redhat.com (Colin Walters) Date: Mon, 31 Jan 2005 13:43:35 -0500 Subject: Request Tracker 3 In-Reply-To: <1107195401.4739.18.camel@localhost.localdomain> References: <1107133597.4988.34.camel@localhost.localdomain> <1107191568.3777.25.camel@nexus.verbum.private> <1107195401.4739.18.camel@localhost.localdomain> Message-ID: <1107197015.3777.34.camel@nexus.verbum.private> On Mon, 2005-01-31 at 13:16 -0500, Kanwar Ranbir Sandhu wrote: > In RT, you can define a separate log file instead of having everything > dumped to /var/log/messages. I haven't tried yet, but I'm assuming if I > disabled the separate log file, this error would disappear. > > I would rather keep /var/log/rt.log. It makes reading the log a lot > easier since it will only contain messages pertaining to RT. Right. Can you try moving the log into /var/log/httpd? I can't think of another solution short of installing the policy sources and adding the permissions. My guess is that it is actually this permission that is stopping the program; the others are likely harmless. > Actually, it's just /tmp. Is your /tmp a symlink elsewhere? Or do you actually have a symlink in /tmp named "tmp"? Are you *sure* it's really /tmp? Do an "ls -di /tmp" to see if its inode number is 12. Then do "ls -di /usr/tmp". > FastCGI dumps its temporary files there while > it's running. The location can be changed, but in the past (on FC1) > when I've tried using /var/log/httpd/fastcgi, I just get a bunch of > errors about FastCGI not having permission to write to that directory (I > believe the only way I managed to fix that was by changing permissions > on /var/log/httpd to 777). Better to use an ACL than mode 777; e.g. "setfacl -m 'apache:rwx' /var/log/httpd". > The command you mentioned above won't work in this case, will it? I'm > assuming that context is meant only for directories under /usr. It only changes the type of the /usr/tmp symlink. My guess is still that your program has some code (or a library it uses does) that tries /usr/tmp first, and is getting permission denial on that symlink because it should be usr_t, not tmp_t. From dwalsh at redhat.com Mon Jan 31 19:13:23 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 31 Jan 2005 14:13:23 -0500 Subject: getting nfsd to export /mnt/whatever and /l/x In-Reply-To: References: <41F945AB.1010506@redhat.com> Message-ID: <41FE8353.6050608@redhat.com> Alexandre Oliva wrote: >On Jan 29, 2005, Alexandre Oliva wrote: > > > >>I had an all-new rawhide install on Wednesday or so (not sure whether >>I did the install on Wednesday with the previous day's rawhide, or >>used Wednesday's rawhide for an install on Thursday), and they >>certainly were not active. Maybe the bug was fixed since then? >> >> > >And to make matters worse, after up2dating the box to yesterday's >rawhide, the nfs_* setting was back to inactive (and 0 in the booleans >config file), although I had enabled it with setsebool -P before. >What gives? > > > That is strange since booleans is a %config(noreplace) From dwalsh at redhat.com Mon Jan 31 19:49:14 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 31 Jan 2005 14:49:14 -0500 Subject: other Raw Hide avc messages In-Reply-To: <20050131164829.GA14626@redhat.com> References: <20050131164829.GA14626@redhat.com> Message-ID: <41FE8BBA.5040501@redhat.com> Joe Orton wrote: >selinux-policy-targeted-1.21.5-1 >kernel-2.6.10-1.1115_FC4 > >one lot of: > >type=KERNEL msg=audit(1107189317.896:165031): avc: denied { create } >for pid= 3061 exe=/usr/sbin/htt_server name=.iiimp-unix >scontext=user_u:system_r:i18n_inp ut_t >tcontext=user_u:object_r:i18n_input_var_run_t tclass=dir > >and many times: > >type=KERNEL msg=audit(1107189602.159:494563): avc: denied { transition >} for pid=3596 exe=/usr/sbin/crond path=/bin/bash dev=hda3 ino=1933320 >scontext=user_u :system_r:crond_t >tcontext=system_u:system_r:unconfined_t tclass=process > >which seems to mean that all cron scripts are failing and I am getting a > >execl: couldn't exec `/bin/sh' >execl: Permission denied > >message from crond every couple of minutes. > >joe > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Could you check out the selinux-policy-targeted-1.21.5-1 on ftp://people.redhat.com/dwalsh/selinux/Fedora I think this fixes the crond problem. I will fix the htt_server problem in 1.21.5-2 From roger at gwch.net Mon Jan 31 21:37:19 2005 From: roger at gwch.net (Roger Grosswiler) Date: Mon, 31 Jan 2005 22:37:19 +0100 Subject: Squirrelmail, MySQL-change password and SELinux Message-ID: <41FEA50F.1090707@gwch.net> Hi, tried successfully installing squirrelmail with mysql authentication. After installting the change_mysql-plugin, i got the following message in /var/log/messages: > Jan 31 22:21:53 frodo kernel: audit(1107206513.281:0): avc: denied { write } for pid=12823 exe=/usr/sbin/httpd name=mysql.sock dev=dm-0 ino=360554 scontext=root:system_r:httpd_t tcontext=root:object_r:var_lib_t tclass=sock_file > Jan 31 22:22:07 frodo kernel: audit(1107206527.169:0): avc: denied { write } for pid=12825 exe=/usr/sbin/httpd name=mysql.sock dev=dm-0 ino=360554 scontext=root:system_r:httpd_t tcontext=root:object_r:var_lib_t tclass=sock_file while squirrel's plugin meant, that the database is busy. If i understand the above right, selinux didn't let the plugin write the new password in the mysql-database. What can i do (except disabling selinux)? Thanks, Roger From dwalsh at redhat.com Mon Jan 31 22:19:36 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 31 Jan 2005 17:19:36 -0500 Subject: Squirrelmail, MySQL-change password and SELinux In-Reply-To: <41FEA50F.1090707@gwch.net> References: <41FEA50F.1090707@gwch.net> Message-ID: <41FEAEF8.9090803@redhat.com> Roger Grosswiler wrote: > Hi, > > tried successfully installing squirrelmail with mysql authentication. > After installting the change_mysql-plugin, i got the following message > in /var/log/messages: > >> Jan 31 22:21:53 frodo kernel: audit(1107206513.281:0): avc: denied >> { write } for pid=12823 exe=/usr/sbin/httpd name=mysql.sock dev=dm-0 >> ino=360554 scontext=root:system_r:httpd_t >> tcontext=root:object_r:var_lib_t tclass=sock_file >> Jan 31 22:22:07 frodo kernel: audit(1107206527.169:0): avc: denied >> { write } for pid=12825 exe=/usr/sbin/httpd name=mysql.sock dev=dm-0 >> ino=360554 scontext=root:system_r:httpd_t >> tcontext=root:object_r:var_lib_t tclass=sock_file > > > > while squirrel's plugin meant, that the database is busy. If i > understand the above right, selinux didn't let the plugin write the > new password in the mysql-database. > > What can i do (except disabling selinux)? > The problem is you do not have the latest policy installed on this machine, and you need to relabel mysql. Upgrade to the latest policy via yum rpm -q -l mysql-server | restorecon -R -v -f - service mysql restart Should fix the problem. > Thanks, > Roger > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list