From russell at coker.com.au Sun Aug 1 07:39:30 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 1 Aug 2004 17:39:30 +1000 Subject: Can not access files in own home directory In-Reply-To: <1091215339.11946.13230.camel@erato.phig.org> References: <600B91D5E4B8D211A58C00902724252C01BC06AD@piramida.hermes.si> <40C865AE.7030908@redhat.com> <1091215339.11946.13230.camel@erato.phig.org> Message-ID: <200408011739.30550.russell@coker.com.au> On Sat, 31 Jul 2004 05:22, Karsten Wade wrote: > On Thu, 2004-06-10 at 06:44, Daniel J Walsh wrote: > > After running fixfiles relabel you should always reboot in order to > > start programs under the right context, If you do this in level 5 there > > is a chance the applications will write files out with bad context after > > the relabel, before the reboot. > > Is it sufficient to do this in run level 3? So far it's worked for me, > but is it risky? As has been mentioned 3 is equivalent to 5 for such things. If the machine booted in enforcing mode and was never in permissive mode then the number of programs which could be in the wrong domain and which could create files with the wrong context on shutdown is small. If you are running in permissive mode with bad labelling then it's quite likely that programs are in the wrong domain but the only real problem is /etc/mtab which will have restorecon run on it at boot time. If you change from targetted to strict policy then you can have user processes running in the wrong context. In my lab on writing SE Linux policy at the IBM Technical University the students had a problem because they were using OpenOffice to read the lab notes (didn't have time to get then printed) and when running in unconfined_t OO had created a socket in /tmp which it couldn't access after rebooting in enforcing mode with strict policy. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From russell at coker.com.au Sun Aug 1 10:19:17 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 1 Aug 2004 20:19:17 +1000 Subject: macro ? In-Reply-To: <460CD43658CA76469A49B3EA56279C2908C5CC@cmiex1.cmi.itu.edu.tr> References: <460CD43658CA76469A49B3EA56279C2908C5CC@cmiex1.cmi.itu.edu.tr> Message-ID: <200408012019.17079.russell@coker.com.au> On Sat, 31 Jul 2004 14:20, ?smail ?yig?nler wrote: > what is macro conceptually ? >From The Collaborative International Dictionary of English v.0.48 [gcide]: macro \macro\ n. [shortened form of macroinstruction] 1. a single computer instruction which symbolizes, and is converted at the time of program execution or by a compiler into, a series of instructions in the same computer language. [WordNet 1.5] > i'm just a beginner in SELinux, just read your > documents and testing in my system, and i'm having lots of denied messages > from console usually, is it normal ? and what is the differences between What are the messages? Please post a few of them here. > default user_r and staff_r roles, can i group users by their authority by > user_r and staff_r roles? , and can i assign "group"s to any roles? If not, > how can i do it? Give regular users the role user_r, and only people who are involved in running the machine staff_r. At this time you can't make the Unix GID have any relevance to SE Linux roles. -- 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 comcast.net Sun Aug 1 21:00:46 2004 From: selinux at comcast.net (Tom London) Date: Sun, 01 Aug 2004 14:00:46 -0700 Subject: cups... new avcs? Message-ID: <410D59FE.2050405@comcast.net> I noticed what I think are new avcs coming from starting cups: Aug 1 13:49:59 fedora kernel: audit(1091393399.153:0): avc: denied { write } for pid=2117 exe=/usr/bin/python name=util dev=hda2 ino=4309019 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usr_t tclass=dir Aug 1 13:49:59 fedora kernel: audit(1091393399.432:0): avc: denied { write } for pid=2117 exe=/usr/bin/python name=util dev=hda2 ino=4309019 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usr_t tclass=dir ino#4309019 is /usr/share/printconf/util (not sure why cups wants to write there ....) tom From selinux at comcast.net Sun Aug 1 21:26:17 2004 From: selinux at comcast.net (Tom London) Date: Sun, 01 Aug 2004 14:26:17 -0700 Subject: .ICE-unix, gdm-binary Message-ID: <410D5FF9.9000308@comcast.net> Running strict/enforcing off of Rawhide, every time I boot up graphical login, I got the following avcs: Aug 1 13:50:31 fedora kernel: audit(1091393431.642:0): avc: denied { setattr } for pid=2884 exe=/usr/bin/gdm-binary name=.ICE-unix dev=hda2 ino=4655823 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:xdm_xserver_tmp_t tclass=dir Aug 1 13:50:31 fedora kernel: audit(1091393431.642:0): avc: denied { setattr } for pid=2884 exe=/usr/bin/gdm-binary name=.ICE-unix dev=hda2 ino=4655823 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:xdm_xserver_tmp_t tclass=dir Aug 1 13:50:31 fedora kernel: audit(1091393431.643:0): avc: denied { setattr } for pid=2884 exe=/usr/bin/gdm-binary name=.ICE-unix dev=hda2 ino=4655823 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:xdm_xserver_tmp_t tclass=dir Aug 1 13:50:31 fedora kernel: audit(1091393431.643:0): avc: denied { setattr } for pid=2884 exe=/usr/bin/gdm-binary name=.ICE-unix dev=hda2 ino=4655823 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:xdm_xserver_tmp_t tclass=dir tom [Doesn't seem to hurt anything ....] From selinux at comcast.net Sun Aug 1 21:31:01 2004 From: selinux at comcast.net (Tom London) Date: Sun, 01 Aug 2004 14:31:01 -0700 Subject: gnome settings manager failure.... (X0?) Message-ID: <410D6115.1080404@comcast.net> Running strict/enforcing off of Rawhide, I now get a error window popping up on graphical login saying that the Gnome settings manager can't start. Here is the only avc that looks even close.... Aug 1 13:51:02 fedora kernel: audit(1091393462.647:0): avc: denied { write } for pid=3366 exe=/usr/X11R6/bin/xscreensaver name=X0 dev=hda2 ino=4657817 scontext=user_u:user_r:user_screensaver_t tcontext=system_u:object_r:xdm_tmp_t tclass=sock_file When I try this in permissive mode, I get: Aug 1 14:28:10 fedora kernel: audit(1091395690.098:0): avc: denied { search } for pid=4015 exe=/usr/X11R6/bin/xscreensaver name=run dev=hda2 ino=4456484 scontext=user_u:user_r:user_screensaver_t tcontext=system_u:object_r:var_run_t tclass=dir Aug 1 14:28:10 fedora kernel: audit(1091395690.114:0): avc: denied { write } for pid=4015 exe=/usr/X11R6/bin/xscreensaver name=X0 dev=hda2 ino=4657817 scontext=user_u:user_r:user_screensaver_t tcontext=system_u:object_r:xdm_tmp_t tclass=sock_file Not sure if this is connected. Is there a know problem, or should I do the 'enableaudit' thing? tom From russell at coker.com.au Mon Aug 2 08:06:57 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 2 Aug 2004 18:06:57 +1000 Subject: cups... new avcs? In-Reply-To: <410D59FE.2050405@comcast.net> References: <410D59FE.2050405@comcast.net> Message-ID: <200408021806.57416.russell@coker.com.au> On Mon, 2 Aug 2004 07:00, Tom London wrote: > I noticed what I think are new avcs coming from starting cups: > > Aug 1 13:49:59 fedora kernel: audit(1091393399.153:0): avc: denied { > write } > for pid=2117 exe=/usr/bin/python name=util dev=hda2 ino=4309019 > scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usr_t > tclass=dir > > ino#4309019 is /usr/share/printconf/util > (not sure why cups wants to write there ....) What is under that directory tree? What does cups do in this situation if you put the machine in permissive mode and do the same print operation? Naturally we can't give cups access to usr_t. We could use a different label for the directory in question as an interim measure. But I think that this is really a bug in cups. I don't think that there's any good reason for cups to be writing there. I think that systems with a /usr file system mounted read-only should work fine as print servers! -- 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 Mon Aug 2 14:28:09 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 02 Aug 2004 10:28:09 -0400 Subject: rhgb....still no graphical boot when strict/enforcing In-Reply-To: <410C05AA.9050009@comcast.net> References: <410C05AA.9050009@comcast.net> Message-ID: <1091456889.23449.80.camel@moss-spartans.epoch.ncsc.mil> On Sat, 2004-07-31 at 16:48, Tom London wrote: > I'm still getting only text-based boots when running with strict/enforcing, > but graphical boots if I set 'enforcing=0' That's a feature, not a bug ;) -- Stephen Smalley National Security Agency From selinux at comcast.net Mon Aug 2 14:41:01 2004 From: selinux at comcast.net (Tom London) Date: Mon, 02 Aug 2004 07:41:01 -0700 Subject: cups... new avcs? In-Reply-To: <200408021806.57416.russell@coker.com.au> References: <410D59FE.2050405@comcast.net> <200408021806.57416.russell@coker.com.au> Message-ID: <410E527D.5060908@comcast.net> Agree regarding read-only /usr setups. Looks like cups is writing a python file called /usr/share/printconf/util/backend.pyo. Here are avc's from a permissive boot (sorry I forgot to include in original message): Aug 2 07:33:27 fedora kernel: audit(1091457207.688:0): avc: denied { write } for pid=1997 exe=/usr/bin/python name=util dev=hda2 ino=4309019 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usr_t tclass=dir Aug 2 07:33:27 fedora kernel: audit(1091457207.689:0): avc: denied { remove_name } for pid=1997 exe=/usr/bin/python name=backend.pyo dev=hda2 ino=4309038 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usr_t tclass=dir Aug 2 07:33:27 fedora kernel: audit(1091457207.726:0): avc: denied { add_name } for pid=1997 exe=/usr/bin/python name=backend.pyo scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usr_t tclass=dir Aug 2 07:33:27 fedora kernel: audit(1091457207.726:0): avc: denied { create } for pid=1997 exe=/usr/bin/python name=backend.pyo scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usr_t tclass=file Aug 2 07:33:27 fedora kernel: audit(1091457207.728:0): avc: denied { write } for pid=1997 exe=/usr/bin/python path=/usr/share/printconf/util/backend.pyo dev=hda2 ino=4309038 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usr_t tclass=file Sigh.... [/usr/share/printconf/util/ contains a bunch of python .py and .pyo files, a file named 'smbprint', and a file named 'strip_control_file.sh'. All the files are labeled system_u:object_r:printconf_t, except for one named 'print.py'. It is labeled system_u:object_r:bin_t.] I'll file a bugzilla against cups for this.... tom Russell Coker wrote: >On Mon, 2 Aug 2004 07:00, Tom London wrote: > > >>I noticed what I think are new avcs coming from starting cups: >> >>Aug 1 13:49:59 fedora kernel: audit(1091393399.153:0): avc: denied { >>write } >>for pid=2117 exe=/usr/bin/python name=util dev=hda2 ino=4309019 >>scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usr_t >>tclass=dir >> >>ino#4309019 is /usr/share/printconf/util >>(not sure why cups wants to write there ....) >> >> > >What is under that directory tree? > >What does cups do in this situation if you put the machine in permissive mode >and do the same print operation? > >Naturally we can't give cups access to usr_t. We could use a different label >for the directory in question as an interim measure. But I think that this >is really a bug in cups. I don't think that there's any good reason for cups >to be writing there. I think that systems with a /usr file system mounted >read-only should work fine as print servers! > > > From selinux at comcast.net Mon Aug 2 14:50:19 2004 From: selinux at comcast.net (Tom London) Date: Mon, 02 Aug 2004 07:50:19 -0700 Subject: rhgb....still no graphical boot when strict/enforcing Message-ID: <410E54AB.20209@comcast.net> Hey, now we're talking.... A security related performance speedup! ;) tom > ------------------------------------------------------------------------ > > * /From/: Stephen Smalley > > ------------------------------------------------------------------------ > >On Sat, 2004-07-31 at 16:48, Tom London wrote: >> I'm still getting only text-based boots when running with strict/enforcing, >> but graphical boots if I set 'enforcing=0' > >That's a feature, not a bug ;) > >-- >Stephen Smalley >National Security Agency > > > From dwalsh at redhat.com Mon Aug 2 15:28:21 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 02 Aug 2004 11:28:21 -0400 Subject: install of dev-3.8.3-1.i386 fails w/ strict/enforcing In-Reply-To: <410BE106.408@comcast.net> References: <410BE106.408@comcast.net> Message-ID: <410E5D95.8030005@redhat.com> Tom London wrote: > Attempting to 'yum update' to dev-3.8.3-1.i386 > from dev-3.8.2-1 produces: > > dev 100 % done 50/101 > error: unpacking of archive failed: cpio: lstat > > and the update fails. No avc's in log. > > Rerunning 'yum update dev' in permissive mode > succeeds. > > Avc's from permissive mode run: > > Jul 31 10:56:04 fedora kernel: audit(1091296564.101:0): avc: denied > { getattr } for pid=9419 exe=/usr/bin/python path=/dev/dri dev=hda2 > ino=2689470 scontext=root:sysadm_r:rpm_t > tcontext=system_u:object_r:dri_device_t tclass=dir > Jul 31 10:56:19 fedora kernel: audit(1091296579.901:0): avc: denied > { search } for pid=9421 exe=/usr/sbin/groupadd name=selinux dev=hda2 > ino=4509743 scontext=root:sysadm_r:groupadd_t > tcontext=system_u:object_r:selinux_config_t tclass=dir > Jul 31 10:56:19 fedora kernel: audit(1091296579.901:0): avc: denied > { read } for pid=9421 exe=/usr/sbin/groupadd name=config dev=hda2 > ino=4509759 scontext=root:sysadm_r:groupadd_t > tcontext=system_u:object_r:selinux_config_t tclass=file > Jul 31 10:56:19 fedora kernel: audit(1091296579.902:0): avc: denied > { getattr } for pid=9421 exe=/usr/sbin/groupadd > path=/etc/selinux/config dev=hda2 ino=4509759 > scontext=root:sysadm_r:groupadd_t > tcontext=system_u:object_r:selinux_config_t tclass=file > Jul 31 10:56:20 fedora kernel: audit(1091296580.078:0): avc: denied > { search } for pid=9422 exe=/usr/sbin/useradd name=run dev=hda2 > ino=4456484 scontext=root:sysadm_r:useradd_t > tcontext=system_u:object_r:var_run_t tclass=dir > Jul 31 10:56:29 fedora kernel: audit(1091296589.978:0): avc: denied > { relabelfrom } for pid=9419 exe=/usr/bin/python name=dri dev=hda2 > ino=2689470 scontext=root:sysadm_r:rpm_t > tcontext=system_u:object_r:dri_device_t tclass=dir > Jul 31 10:56:29 fedora kernel: audit(1091296589.979:0): avc: denied > { relabelto } for pid=9419 exe=/usr/bin/python name=dri dev=hda2 > ino=2689470 scontext=root:sysadm_r:rpm_t > tcontext=system_u:object_r:dri_device_t tclass=dir > Jul 31 10:56:30 fedora kernel: audit(1091296590.011:0): avc: denied > { setattr } for pid=9419 exe=/usr/bin/python name=dri dev=hda2 > ino=2689470 scontext=root:sysadm_r:rpm_t > tcontext=system_u:object_r:dri_device_t tclass=dir > Jul 31 10:56:30 fedora kernel: audit(1091296590.017:0): avc: denied > { search } for pid=9419 exe=/usr/bin/python name=dri dev=hda2 > ino=2689470 scontext=root:sysadm_r:rpm_t > tcontext=system_u:object_r:dri_device_t tclass=dir > Jul 31 10:56:30 fedora kernel: audit(1091296590.083:0): avc: denied > { write } for pid=9419 exe=/usr/bin/python name=dri dev=hda2 > ino=2689470 scontext=root:sysadm_r:rpm_t > tcontext=system_u:object_r:dri_device_t tclass=dir > Jul 31 10:56:30 fedora kernel: audit(1091296590.083:0): avc: denied > { add_name } for pid=9419 exe=/usr/bin/python name=card0;410bdd3f > scontext=root:sysadm_r:rpm_t tcontext=system_u:object_r:dri_device_t > tclass=dir > Jul 31 10:56:30 fedora kernel: audit(1091296590.136:0): avc: denied > { remove_name } for pid=9419 exe=/usr/bin/python name=card0;410bdd3f > dev=hda2 ino=2689465 scontext=root:sysadm_r:rpm_t > tcontext=system_u:object_r:dri_device_t tclass=dir > Jul 31 10:57:49 fedora kernel: audit(1091296669.135:0): avc: denied > { search } for pid=9419 exe=/usr/bin/python name=dri dev=hda2 > ino=2689470 scontext=root:sysadm_r:rpm_t > tcontext=system_u:object_r:dri_device_t tclass=dir > Jul 31 10:57:49 fedora kernel: audit(1091296669.136:0): avc: denied > { getattr } for pid=9419 exe=/usr/bin/python path=/dev/dri dev=hda2 > ino=2689470 scontext=root:sysadm_r:rpm_t > tcontext=system_u:object_r:dri_device_t tclass=dir > > Audit2allow on the above produces: > > allow groupadd_t selinux_config_t:dir { search }; > allow groupadd_t selinux_config_t:file { getattr read }; Added rules for groupadd > allow rpm_t dri_device_t:dir { add_name getattr relabelfrom relabelto > remove_name search setattr write }; Modified /dev/dri directory back to device_t > allow useradd_t var_run_t:dir { search } Added dontaudit rule. > ; > > Hope this helps, > tom > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From selinux at comcast.net Tue Aug 3 14:16:16 2004 From: selinux at comcast.net (Tom London) Date: Tue, 03 Aug 2004 07:16:16 -0700 Subject: gnome settings manager failure.... (X0?) In-Reply-To: <410D6115.1080404@comcast.net> References: <410D6115.1080404@comcast.net> Message-ID: <410F9E30.3060503@comcast.net> This appears to be related to the switch from fam -> gamin: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=128890 Sorry for the false alarm, tom Tom London wrote: > Running strict/enforcing off of Rawhide, I now get > a error window popping up on graphical login saying > that the Gnome settings manager can't start. > > Here is the only avc that looks even close.... > > Aug 1 13:51:02 fedora kernel: audit(1091393462.647:0): avc: > denied { write } for pid=3366 > exe=/usr/X11R6/bin/xscreensaver name=X0 dev=hda2 ino=4657817 > scontext=user_u:user_r:user_screensaver_t > tcontext=system_u:object_r:xdm_tmp_t tclass=sock_file > > When I try this in permissive mode, I get: > > Aug 1 14:28:10 fedora kernel: audit(1091395690.098:0): avc: denied { > search } for pid=4015 exe=/usr/X11R6/bin/xscreensaver name=run > dev=hda2 ino=4456484 scontext=user_u:user_r:user_screensaver_t > tcontext=system_u:object_r:var_run_t tclass=dir > Aug 1 14:28:10 fedora kernel: audit(1091395690.114:0): avc: denied { > write } for pid=4015 exe=/usr/X11R6/bin/xscreensaver name=X0 dev=hda2 > ino=4657817 scontext=user_u:user_r:user_screensaver_t > tcontext=system_u:object_r:xdm_tmp_t tclass=sock_file > > Not sure if this is connected. Is there a know problem, > or should I do the 'enableaudit' thing? > > tom > > > > From russell at coker.com.au Wed Aug 4 11:17:59 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 4 Aug 2004 21:17:59 +1000 Subject: cups... new avcs? In-Reply-To: <410E527D.5060908@comcast.net> References: <410D59FE.2050405@comcast.net> <200408021806.57416.russell@coker.com.au> <410E527D.5060908@comcast.net> Message-ID: <200408042117.59734.russell@coker.com.au> On Tue, 3 Aug 2004 00:41, Tom London wrote: > Sigh.... > [/usr/share/printconf/util/ contains a bunch of python .py > and .pyo files, a file named 'smbprint', and a file named > 'strip_control_file.sh'. ?All the files are labeled > system_u:object_r:printconf_t, except for one named > 'print.py'. It is labeled system_u:object_r:bin_t.] > > I'll file a bugzilla against cups for this.... I think that this is the correct thing to do. No matter what the reason for writing the file, /usr/share is not the place for it. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From twaugh at redhat.com Wed Aug 4 11:44:22 2004 From: twaugh at redhat.com (Tim Waugh) Date: Wed, 4 Aug 2004 12:44:22 +0100 Subject: cups... new avcs? In-Reply-To: <200408042117.59734.russell@coker.com.au> References: <410D59FE.2050405@comcast.net> <200408021806.57416.russell@coker.com.au> <410E527D.5060908@comcast.net> <200408042117.59734.russell@coker.com.au> Message-ID: <20040804114422.GY8175@redhat.com> On Wed, Aug 04, 2004 at 09:17:59PM +1000, Russell Coker wrote: > On Tue, 3 Aug 2004 00:41, Tom London wrote: > > Sigh.... > > [/usr/share/printconf/util/ contains a bunch of python .py > > and .pyo files, a file named 'smbprint', and a file named > > 'strip_control_file.sh'. ?All the files are labeled > > system_u:object_r:printconf_t, except for one named > > 'print.py'. It is labeled system_u:object_r:bin_t.] > > > > I'll file a bugzilla against cups for this.... > > I think that this is the correct thing to do. No matter what the reason for > writing the file, /usr/share is not the place for it. CUPS doesn't own any of these files -- system-config-printer does, and some of its components run as cupsd_t. The problem concerning .pyo and .pyc files is a general one -- these should be shipped in the RPM packages, but we need a general method for doing that as it is not trivial. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From davidecolbert at yahoo.com Wed Aug 4 18:48:21 2004 From: davidecolbert at yahoo.com (david colbert) Date: Wed, 4 Aug 2004 11:48:21 -0700 (PDT) Subject: file access audits (NISPOM Chapter 8) Message-ID: <20040804184821.34631.qmail@web60501.mail.yahoo.com> Hello, Does anyone out there have policy config files that bring a Fedora Core 2 system into compliance with Chapter 8 of Defense Security Service's (DSS) National Industrial Security Program Operating Manual (NISPOM)? The gist of my problem is that I need to get more strict access and auditing of any attempted access to system files by non-root users. I am trying to get selinux to log every failed attempt of every non-root user to r/w/x all system files. I can get it working by commenting out the following line in /etc/security/selinux/src/policy/tunable.te: #define(`read_default_t') which gives users acess to all default files The problem is, it disallows access to all users, including root. This means that once I start enforcing, I have to reboot into single user mode to make any system changes as root. I need something which leaves sysadmin alone and only sets restrictions and audits on staff and users (or just users). With the above line still commented out, I tried inserting the following lines in /etc/security/selinux/src/policy/domains/admin.te to open the system files bacck up to root again: general_file_read_access(sysadmin_t) general_file_write_access(sysadmin_t) general_domain_access(sysadmin_t) (Found in the "Configuring the SELinux Policy" doc by Smalley) However, the read and write access lines generated syntax errors when I tried to make the new policy. Anyone know what I am doing wrong? Version mismatch? Mutually exclusive parameters? Anyone actually know how to do what I am trying to do? I am new to selinux, so I am hoping that I am just missing something obvious. Also, is there any other documentation besides the pdf's on the NSA site? Thanks in Advance, David Colbert __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From smoogen at lanl.gov Wed Aug 4 19:18:42 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Wed, 04 Aug 2004 13:18:42 -0600 Subject: file access audits (NISPOM Chapter 8) In-Reply-To: <20040804184821.34631.qmail@web60501.mail.yahoo.com> References: <20040804184821.34631.qmail@web60501.mail.yahoo.com> Message-ID: <41113692.4050900@lanl.gov> david colbert wrote: > Hello, > > Does anyone out there have policy config files that > bring a Fedora Core 2 system into compliance with > Chapter 8 of Defense Security Service's (DSS) National > Industrial Security Program Operating Manual (NISPOM)? > Not sure myself, but I would be interested in pointers on these documents and the eventual answer. I think I will be seeing similar requests. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 From miremadi at ce.sharif.edu Wed Aug 4 20:01:25 2004 From: miremadi at ce.sharif.edu (Sajed Miremadi) Date: Thu, 5 Aug 2004 00:31:25 +0430 (IRDT) Subject: about a new policy file in SELinux! Message-ID: <3532.213.233.160.46.1091649685.squirrel@ce.sharif.edu> Hi, I have asked this question several times before but haven't got the answer I really want. I'll ask it again but more clearly: Does anybody ever write a new policy file except those which is defult in selinux(I mean those in /etc/security/selinux/src/policy/domains/program). When I say a policy file I mean the files with ".te". For example there are some for "ping","innd","tcpdump" and ... . If someone has a .te file with this condition, I would be very glad if he/she could send me that. thanx, Sajed From walters at redhat.com Wed Aug 4 20:12:26 2004 From: walters at redhat.com (Colin Walters) Date: Wed, 04 Aug 2004 16:12:26 -0400 Subject: about a new policy file in SELinux! In-Reply-To: <3532.213.233.160.46.1091649685.squirrel@ce.sharif.edu> References: <3532.213.233.160.46.1091649685.squirrel@ce.sharif.edu> Message-ID: <1091650346.6749.8.camel@nexus.verbum.private> On Thu, 2004-08-05 at 00:31 +0430, Sajed Miremadi wrote: > Hi, > > I have asked this question several times before but haven't got the answer > I really want. > I'll ask it again but more clearly: > Does anybody ever write a new policy file except those which is defult in > selinux(I mean those in /etc/security/selinux/src/policy/domains/program). Yes, of course. > When I say a policy file I mean the files with ".te". For example there > are some for "ping","innd","tcpdump" and ... . > If someone has a .te file with this condition, I would be very glad if > he/she could send me that. Every time someone posts a new .te file to selinux at tycho.nsa.gov, like Russell's postgrey policy, they are in that condition. I think the problem you are running into is that you need a .fc file corresponding to each .te file in order for the .te file to be enabled. For example, if you create domains/program/myprogram.te, you need to also create file_contexts/program/myprogram.fc. -------------- 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 miremadi at ce.sharif.edu Thu Aug 5 05:52:25 2004 From: miremadi at ce.sharif.edu (Sajed Miremadi) Date: Thu, 5 Aug 2004 10:22:25 +0430 (IRDT) Subject: about a new policy file in SELinux! In-Reply-To: <1091650346.6749.8.camel@nexus.verbum.private> References: <3532.213.233.160.46.1091649685.squirrel@ce.sharif.edu> <1091650346.6749.8.camel@nexus.verbum.private> Message-ID: <2910.81.31.164.22.1091685145.squirrel@ce.sharif.edu> Thanx a lot, > On Thu, 2004-08-05 at 00:31 +0430, Sajed Miremadi wrote: >> Hi, >> >> I have asked this question several times before but haven't got the >> answer >> I really want. >> I'll ask it again but more clearly: >> Does anybody ever write a new policy file except those which is defult >> in >> selinux(I mean those in >> /etc/security/selinux/src/policy/domains/program). > > Yes, of course. > >> When I say a policy file I mean the files with ".te". For example there >> are some for "ping","innd","tcpdump" and ... . >> If someone has a .te file with this condition, I would be very glad if >> he/she could send me that. > > Every time someone posts a new .te file to selinux at tycho.nsa.gov, like > Russell's postgrey policy, they are in that condition. So where can I get the .te files that are sent to selinux at tycho.nsa.gov? > > I think the problem you are running into is that you need a .fc file > corresponding to each .te file in order for the .te file to be enabled. > For example, if you create domains/program/myprogram.te, you need to > also create file_contexts/program/myprogram.fc. Not actually,because I have created one for "who" command and added the .fc file to but it doesn't work. So I really want a new .te file. thanx again, > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > From russell at coker.com.au Thu Aug 5 07:42:12 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 5 Aug 2004 17:42:12 +1000 Subject: about a new policy file in SELinux! In-Reply-To: <2910.81.31.164.22.1091685145.squirrel@ce.sharif.edu> References: <3532.213.233.160.46.1091649685.squirrel@ce.sharif.edu> <1091650346.6749.8.camel@nexus.verbum.private> <2910.81.31.164.22.1091685145.squirrel@ce.sharif.edu> Message-ID: <200408051742.12233.russell@coker.com.au> On Thu, 5 Aug 2004 15:52, "Sajed Miremadi" wrote: > > Every time someone posts a new .te file to selinux at tycho.nsa.gov, like > > Russell's postgrey policy, they are in that condition. > > So where can I get the .te files that are sent to selinux at tycho.nsa.gov? You can subscribe to the list or read the list archives at http://marc.theaimsgroup.com/?l=selinux&r=1&w=2 . > Not actually,because I have created one for "who" command and added the > .fc file to but it doesn't work. So I really want a new .te file. Why does "who" need it's own policy? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From russell at coker.com.au Thu Aug 5 09:07:54 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 5 Aug 2004 19:07:54 +1000 Subject: file access audits (NISPOM Chapter 8) In-Reply-To: <20040804184821.34631.qmail@web60501.mail.yahoo.com> References: <20040804184821.34631.qmail@web60501.mail.yahoo.com> Message-ID: <200408051907.54434.russell@coker.com.au> On Thu, 5 Aug 2004 04:48, david colbert wrote: > Does anyone out there have policy config files that > bring a Fedora Core 2 system into compliance with > Chapter 8 of Defense Security Service's (DSS) National > Industrial Security Program Operating Manual (NISPOM)? Firstly a disclaimer, I have not read that document, so don't take my comments to mean anything in regard to it. > The gist of my problem is that I need to get more > strict access and auditing of any attempted access to > system files by non-root users. I am trying to get > selinux to log every failed attempt of every non-root > user to r/w/x all system files. I can get it working SE Linux is based on the LSM interface which does not permit this. If an access is rejected by Unix permissions then LSM is not called and therefore SE Linux does not even get informed about the access attempt. It's only if you have Unix permissions be extremely permissive that SE Linux could audit all failed accesses. > general_file_read_access(sysadmin_t) > general_file_write_access(sysadmin_t) > general_domain_access(sysadmin_t) Probably you meant to use sysadm_t not sysadmin_t. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From russell at coker.com.au Thu Aug 5 09:24:50 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 5 Aug 2004 19:24:50 +1000 Subject: SE Linux and Fedora training Message-ID: <200408051924.50191.russell@coker.com.au> http://www.coker.com.au/selinux/talks/ibmtu-2004/ I recently gave some lectures and tutorials at the IBM Technical university in Cairns on SE Linux. At the above URL there are lecture and lab notes, the lab exercises could be completed with help from the #fedora-selinux channel. -- 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 jeroens at office.netland.nl Thu Aug 5 10:25:56 2004 From: jeroens at office.netland.nl (J. Simonetti) Date: Thu, 05 Aug 2004 12:25:56 +0200 Subject: SE Linux and Fedora training In-Reply-To: <200408051924.50191.russell@coker.com.au> References: <200408051924.50191.russell@coker.com.au> Message-ID: <1091701556.26513.9.camel@ts2.office.netland.nl> Forbidden You don't have permission to access /selinux/talks/ibmtu-2004/LINUX21.pdf on this server. Could you please fix this? Tnx! On Thu, 2004-08-05 at 11:24, Russell Coker wrote: > http://www.coker.com.au/selinux/talks/ibmtu-2004/ > > I recently gave some lectures and tutorials at the IBM Technical university in > Cairns on SE Linux. At the above URL there are lecture and lab notes, the > lab exercises could be completed with help from the #fedora-selinux channel. Jeroen Simonetti -- Netland Internet Services bedrijfsmatige internetoplossingen http://www.netland.nl Kruislaan 419 1098 VA Amsterdam info: 020-5628282 servicedesk: 020-5628280 fax: 020-5628281 Your heart is pure, and your mind clear, and your soul devout. From fedora-se-linux at dalini.de Thu Aug 5 10:43:49 2004 From: fedora-se-linux at dalini.de (Ives Steglich) Date: Thu, 05 Aug 2004 12:43:49 +0200 Subject: SE Linux and Fedora training In-Reply-To: <1091701556.26513.9.camel@ts2.office.netland.nl> References: <200408051924.50191.russell@coker.com.au> <1091701556.26513.9.camel@ts2.office.netland.nl> Message-ID: <41120F65.4020406@dalini.de> J. Simonetti wrote: > Forbidden > You don't have permission to access > /selinux/talks/ibmtu-2004/LINUX21.pdf on this server. > > Could you please fix this? Tnx! > the file: linux20.doc cant also be found/accessed would be fine if this could get possible btw: how stable is FC3T1? i would like to try get openca running in an se-linux environment, so another question would be which version i should prefer FC3 oder FC2 or maybe there is another se-linux enabled distribution which could be used? greetings dalini From russell at coker.com.au Thu Aug 5 11:37:28 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 5 Aug 2004 21:37:28 +1000 Subject: SE Linux and Fedora training In-Reply-To: <1091701556.26513.9.camel@ts2.office.netland.nl> References: <200408051924.50191.russell@coker.com.au> <1091701556.26513.9.camel@ts2.office.netland.nl> Message-ID: <200408052137.28205.russell@coker.com.au> On Thu, 5 Aug 2004 20:25, "J. Simonetti" wrote: > Forbidden > You don't have permission to access > /selinux/talks/ibmtu-2004/LINUX21.pdf on this server. > > Could you please fix this? Tnx! Done. It should work now. -- 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 Aug 5 12:43:40 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 05 Aug 2004 08:43:40 -0400 Subject: about a new policy file in SELinux! In-Reply-To: <3532.213.233.160.46.1091649685.squirrel@ce.sharif.edu> References: <3532.213.233.160.46.1091649685.squirrel@ce.sharif.edu> Message-ID: <1091709819.11061.58.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-08-04 at 16:01, Sajed Miremadi wrote: > Hi, > > I have asked this question several times before but haven't got the answer > I really want. > I'll ask it again but more clearly: > Does anybody ever write a new policy file except those which is defult in > selinux(I mean those in /etc/security/selinux/src/policy/domains/program). > When I say a policy file I mean the files with ".te". For example there > are some for "ping","innd","tcpdump" and ... . > If someone has a .te file with this condition, I would be very glad if > he/she could send me that. Most of the .te files that are in the policy today were written from scratch by external contributors and submitted on the NSA selinux mailing list, then added to the example policy. Looking at a historical snapshot of the example policy from early 2001, there were only 40 .te files in it, compared to > 180 .te files now. -- Stephen Smalley National Security Agency From selinux at comcast.net Thu Aug 5 15:13:01 2004 From: selinux at comcast.net (Tom London) Date: Thu, 05 Aug 2004 08:13:01 -0700 Subject: New AVCs from Rawhide... Message-ID: <41124E7D.3090809@comcast.net> Running strict/enforcing, and running Rawhide (selinux-policy-strict-1.15.11-1 and kernel-2.6.7-1.509), some new AVCs logged. [Sorry if I'm 'amid updates'] tom First, early in boot sequence: Aug 5 06:58:02 fedora autofs: automount startup succeeded Aug 5 06:58:02 fedora kernel: SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts Aug 5 06:58:02 fedora kernel: SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts Aug 5 06:58:02 fedora kernel: audit(1091689038.197:0): avc: denied { read write } for pid=1 exe=/sbin/init path=/dev/console dev=rootfs ino=5 scontext=system_u:system_r:init_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file Aug 5 06:58:02 fedora last message repeated 2 times Aug 5 06:58:02 fedora smartd[2124]: smartd version 5.30 Copyright (C) 2002-4 Bruce Allen Aug 5 06:58:02 fedora kernel: audit(1091689038.318:0): avc: denied { read } for pid=1 exe=/sbin/init path=/init dev=rootfs ino=14 scontext=system_u:system_r:init_t tcontext=system_u:object_r:unlabeled_t tclass=file then, many, many like these (approx. 64 of them): Aug 5 06:58:02 fedora kernel: audit(1091689040.452:0): avc: denied { dac_read_search } for pid=397 exe=/bin/bash capability=2 scontext=system_u:system_r:udev_t tcontext=system_u:system_r:udev_t tclass=capability Aug 5 06:58:02 fedora smartd[2124]: Configuration file /etc/smartd.conf parsed. Aug 5 06:58:02 fedora kernel: audit(1091689040.452:0): avc: denied { dac_read_search } for pid=411 exe=/bin/bash capability=2 scontext=system_u:system_r:udev_t tcontext=system_u:system_r:udev_t tclass=capability Aug 5 06:58:02 fedora smartd[2124]: Device: /dev/hda, opened Aug 5 06:58:02 fedora kernel: audit(1091689040.452:0): avc: denied { dac_read_search } for pid=399 exe=/bin/bash capability=2 scontext=system_u:system_r:udev_t tcontext=system_u:system_r:udev_t tclass=capability Aug 5 06:58:03 fedora smartd[2124]: Device: /dev/hda, found in smartd database. Aug 5 06:58:03 fedora kernel: audit(1091689040.452:0): avc: denied { dac_read_search } for pid=391 exe=/bin/bash capability=2 scontext=system_u:system_r:udev_t tcontext=system_u:system_r:udev_t tclass=capability Aug 5 06:58:03 fedora kernel: audit(1091689040.453:0): avc: denied { dac_read_search } for pid=398 exe=/bin/bash capability=2 scontext=system_u:system_r:udev_t tcontext=system_u:system_r:udev_t tclass=capability Aug 5 06:58:03 fedora kernel: audit(1091689040.453:0): avc: denied { dac_read_search } for pid=413 exe=/bin/bash capability=2 scontext=system_u:system_r:udev_t tcontext=system_u:system_r:udev_t tclass=capability ..... Repeat of above while bringing up USB: Aug 5 06:58:07 fedora kernel: hub 1-0:1.0: 6 ports detected Aug 5 06:58:07 fedora kernel: audit(1091714243.675:0): avc: denied { dac_read_search } for pid=775 exe=/bin/bash capability=2 scontext=system_u:system_r:udev_t tcontext=system_u:system_r:udev_t tclass=capability Aug 5 06:58:07 fedora kernel: ACPI: PCI interrupt 0000:00:03.0[A] -> GSI 5 (level, low) -> IRQ 5 Aug 5 06:58:07 fedora kernel: ohci_hcd 0000:00:03.0: OHCI Host Controller Aug 5 06:58:07 fedora kernel: ohci_hcd 0000:00:03.0: irq 5, pci mem 30848000 Aug 5 06:58:07 fedora kernel: hub 1-0:1.0: over-current change on port 3 Aug 5 06:58:07 fedora kernel: ohci_hcd 0000:00:03.0: new USB bus registered, assigned bus number 2 Aug 5 06:58:07 fedora kernel: hub 2-0:1.0: USB hub found Aug 5 06:58:07 fedora kernel: hub 2-0:1.0: 2 ports detected Aug 5 06:58:07 fedora kernel: audit(1091714244.021:0): avc: denied { dac_read_search } for pid=809 exe=/bin/bash capability=2 scontext=system_u:system_r:udev_t tcontext=system_u:system_r:udev_t tclass=capability Aug 5 06:58:07 fedora kernel: audit(1091714244.036:0): avc: denied { dac_read_search } for pid=813 exe=/bin/bash capability=2 scontext=system_u:system_r:udev_t tcontext=system_u:system_r:udev_t tclass=capability Aug 5 06:58:07 fedora kernel: ACPI: PCI interrupt 0000:00:03.1[B] -> GSI 11 (level, low) -> IRQ 11 This one also seems new....: Aug 5 06:58:07 fedora kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs Aug 5 06:58:07 fedora kernel: audit(1091714256.876:0): avc: denied { search } for pid=1476 exe=/sbin/pam_console_apply name=console dev=hda2 ino=4456494 scontext=system_u:system_r:pam_console_t tcontext=system_u:object_r:xdm_var_run_t tclass=dir Finally, some like this Aug 5 06:59:19 fedora udev[3632]: creating device node '/dev/mixer' Aug 5 06:59:19 fedora kernel: audit(1091714359.597:0): avc: denied { dac_read_search } for pid=3642 exe=/bin/bash capability=2 scontext=system_u:system_r:udev_t tcontext=system_u:system_r:udev_t tclass=capability Aug 5 06:59:19 fedora kernel: audit(1091714359.607:0): avc: denied { dac_read_search } for pid=3644 exe=/bin/bash capability=2 scontext=system_u:system_r:udev_t tcontext=system_u:system_r:udev_t tclass=capability Aug 5 06:59:19 fedora kernel: audit(1091714359.611:0): avc: denied { read write } for pid=3646 exe=/sbin/restorecon path=socket:[1168] dev=sockfs ino=1168 scontext=system_u:system_r:restorecon_t tcontext=system_u:system_r:udev_t tclass=unix_dgram_socket Aug 5 06:59:19 fedora kernel: audit(1091714359.611:0): avc: denied { read write } for pid=3646 exe=/sbin/restorecon path=socket:[1225] dev=sockfs ino=1225 scontext=system_u:system_r:restorecon_t tcontext=system_u:system_r:udev_t tclass=unix_dgram_socket Aug 5 06:59:19 fedora kernel: audit(1091714359.614:0): avc: denied { search } for pid=2754 exe=/usr/bin/dbus-daemon-1 name=console dev=hda2 ino=4456494 scontext=system_u:system_r:dbusd_t tcontext=system_u:object_r:xdm_var_run_t tclass=dir From dalini at datenschleuder.org Thu Aug 5 10:35:59 2004 From: dalini at datenschleuder.org (dalini) Date: Thu, 05 Aug 2004 12:35:59 +0200 Subject: SE Linux and Fedora training In-Reply-To: <1091701556.26513.9.camel@ts2.office.netland.nl> References: <200408051924.50191.russell@coker.com.au> <1091701556.26513.9.camel@ts2.office.netland.nl> Message-ID: <41120D8F.7030909@datenschleuder.org> J. Simonetti wrote: > Forbidden > You don't have permission to access > /selinux/talks/ibmtu-2004/LINUX21.pdf on this server. > > Could you please fix this? Tnx! > the file: linux20.doc cant also be found/accessed would be fine if this could get possible btw: how stable is FC3T1? i would like to try get openca running in an se-linux environment, so another question would be which version i should prefer FC3 oder FC2 or maybe there is another se-linux enabled distribution which could be used? greetings dalini From sds at epoch.ncsc.mil Thu Aug 5 20:00:24 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 05 Aug 2004 16:00:24 -0400 Subject: New AVCs from Rawhide... In-Reply-To: <41124E7D.3090809@comcast.net> References: <41124E7D.3090809@comcast.net> Message-ID: <1091736024.2583.179.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-08-05 at 11:13, Tom London wrote: > Running strict/enforcing, and running > Rawhide (selinux-policy-strict-1.15.11-1 and kernel-2.6.7-1.509), > some new AVCs logged. [Sorry if I'm 'amid updates'] > Aug 5 06:58:02 fedora kernel: audit(1091689038.197:0): avc: denied { > read write } for pid=1 exe=/sbin/init path=/dev/console dev=rootfs > ino=5 scontext=system_u:system_r:init_t > tcontext=system_u:object_r:unlabeled_t tclass=chr_file > Aug 5 06:58:02 fedora kernel: audit(1091689038.318:0): avc: denied { > read } for pid=1 exe=/sbin/init path=/init dev=rootfs ino=14 > scontext=system_u:system_r:init_t tcontext=system_u:object_r:unlabeled_t > tclass=file This requires a change to the SELinux kernel code to address properly; need to be able to assign security contexts to inodes unpacked from initramfs into the rootfs. -- Stephen Smalley National Security Agency From jpm8864 at verizon.net Fri Aug 6 01:08:50 2004 From: jpm8864 at verizon.net (J. P. McConnell) Date: Thu, 05 Aug 2004 21:08:50 -0400 Subject: test Message-ID: <4112DA22.7080400@verizon.net> Just making sure I'm here , sorry for the inconvenience of having to read this. From acastillo at condorweb.net Fri Aug 6 08:05:43 2004 From: acastillo at condorweb.net (Ma. Alejandra Castillo M.) Date: Fri, 6 Aug 2004 04:05:43 -0400 Subject: Politicas SElinux Message-ID: <001e01c47b8c$2c460240$800410ac@rocl.csavgroup.com> hello, it will make my thesis project on SElinux, where creale a politica not even defined so that service. By the same I look for much information on the matter. As they are the politicas already defined? where podria to find? I wait for its answers, greetings and thanks. -- Ma. Alejandra Castillo M. Chile From russell at coker.com.au Fri Aug 6 10:12:58 2004 From: russell at coker.com.au (Russell Coker) Date: Fri, 6 Aug 2004 20:12:58 +1000 Subject: Politicas SElinux In-Reply-To: <001e01c47b8c$2c460240$800410ac@rocl.csavgroup.com> References: <001e01c47b8c$2c460240$800410ac@rocl.csavgroup.com> Message-ID: <200408062012.58786.russell@coker.com.au> On Fri, 6 Aug 2004 18:05, "Ma. Alejandra Castillo M." wrote: > hello, it will make my thesis project on SElinux, where creale a politica > not even defined so that service. By the same I look for much information > on the matter. As they are the politicas already defined? where podria to > find? I wait for its answers, greetings and thanks. In an IRC conversation I suggested the creation of a Spanish language SE Linux mailing list. http://www.coker.com.au/selinux/talks/ibmtu-2004/ Regarding policy creation, the lab exercises at the above URL may help you, but you need both Fedora Core 2 and Fedora Core 3 test 1 to complete them. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From russell at coker.com.au Fri Aug 6 11:23:12 2004 From: russell at coker.com.au (Russell Coker) Date: Fri, 6 Aug 2004 21:23:12 +1000 Subject: SE Linux and Fedora training In-Reply-To: <41120F65.4020406@dalini.de> References: <200408051924.50191.russell@coker.com.au> <1091701556.26513.9.camel@ts2.office.netland.nl> <41120F65.4020406@dalini.de> Message-ID: <200408062123.12495.russell@coker.com.au> On Thu, 5 Aug 2004 20:43, Ives Steglich wrote: > btw: how stable is FC3T1? Fairly stable for a test release. I know some people who are using it in production. > i would like to try get openca running in an se-linux environment, so > another question would be which version i should prefer FC3 oder FC2 > or maybe there is another se-linux enabled distribution which could > be used? FC2 if you want stability. If you want to test things out now for a later deployment then FC3T1 may be better. There are significant SE Linux changes between FC2 and FC3T1. -- 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 monteiro at ipen.br Fri Aug 6 09:24:07 2004 From: monteiro at ipen.br (=?ISO-8859-1?Q?Carlos_An=EDsio_Monteiro?=) Date: Fri, 06 Aug 2004 06:24:07 -0300 Subject: Politicas SElinux In-Reply-To: <001e01c47b8c$2c460240$800410ac@rocl.csavgroup.com> References: <001e01c47b8c$2c460240$800410ac@rocl.csavgroup.com> Message-ID: <41134E37.1050302@ipen.br> Ma. Alejandra Castillo M. wrote: >hello, it will make my thesis project on SElinux, where creale a politica >not even defined so that service. By the same I look for much information on >the matter. As they are the politicas already defined? where podria to find? >I wait for its answers, greetings and thanks. > >-- >Ma. Alejandra Castillo M. >Chile > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > http://fedora.redhat.com/projects/selinux - SELinux for Fedora. http://www.nsa.gov/selinux - SELinux Project mainly. http://www.coker.com.au/selinux - SELinux for Debian. http://selinux.lemuria.org - SELinux for Debian. http://www.gentoo.org/proj/en/hardened/selinux/index.xml - Gentoo Linux And many others available in the Internet. The lists, too are. -- Carlos Anisio Monteiro IPEN/CNEN-SP Sao Paulo - Brasil From acastillo at condorweb.net Fri Aug 6 12:50:48 2004 From: acastillo at condorweb.net (Ma. Alejandra Castillo M.) Date: Fri, 6 Aug 2004 08:50:48 -0400 Subject: Politicas SElinux References: <001e01c47b8c$2c460240$800410ac@rocl.csavgroup.com> <41134E37.1050302@ipen.br> Message-ID: <002a01c47bb3$ff967770$800410ac@rocl.csavgroup.com> ok, that there is much information, which encantaria me is to talk and to share ideas :-) salu2 - MAC ----- Original Message ----- From: "Carlos An?sio Monteiro" To: "Fedora SELinux support list for users & developers." Sent: Friday, August 06, 2004 5:24 AM Subject: Re: Politicas SElinux > Ma. Alejandra Castillo M. wrote: > > >hello, it will make my thesis project on SElinux, where creale a politica > >not even defined so that service. By the same I look for much information on > >the matter. As they are the politicas already defined? where podria to find? > >I wait for its answers, greetings and thanks. > > > >-- > >Ma. Alejandra Castillo M. > >Chile > > > >-- > >fedora-selinux-list mailing list > >fedora-selinux-list at redhat.com > >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > > > http://fedora.redhat.com/projects/selinux - SELinux for Fedora. > http://www.nsa.gov/selinux - SELinux Project mainly. > http://www.coker.com.au/selinux - SELinux for Debian. > http://selinux.lemuria.org - SELinux for Debian. > http://www.gentoo.org/proj/en/hardened/selinux/index.xml - Gentoo Linux > > And many others available in the Internet. > The lists, too are. > > > -- > Carlos Anisio Monteiro > IPEN/CNEN-SP > Sao Paulo - Brasil > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From selinux at comcast.net Mon Aug 9 15:46:35 2004 From: selinux at comcast.net (Tom London) Date: Mon, 09 Aug 2004 08:46:35 -0700 Subject: selinux-policy-strict-sources: syntax error in Rawhide Message-ID: <41179C5B.6020200@comcast.net> Seems to be an error in the latest selinux-policy-strict-sources from Rawhide: tom selinux-policy-strict-sources 100 % done 67/459 make: Entering directory `/etc/selinux/strict/src/policy' mkdir -p /etc/selinux/strict/policy /usr/bin/checkpolicy -o /etc/selinux/strict/policy/policy.18 policy.conf /usr/bin/checkpolicy: loading policy configuration from policy.conf domains/user.te:70:ERROR 'syntax error' at token ')' on line 43573: #line 70 if () { /usr/bin/checkpolicy: error(s) encountered while parsing configuration make: *** [/etc/selinux/strict/policy/policy.18] Error 1 make: Leaving directory `/etc/selinux/strict/src/policy' From sds at epoch.ncsc.mil Mon Aug 9 15:56:49 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 09 Aug 2004 11:56:49 -0400 Subject: selinux-policy-strict-sources: syntax error in Rawhide In-Reply-To: <41179C5B.6020200@comcast.net> References: <41179C5B.6020200@comcast.net> Message-ID: <1092067009.29199.138.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2004-08-09 at 11:46, Tom London wrote: > Seems to be an error in the latest selinux-policy-strict-sources from > Rawhide: > tom > > selinux-policy-strict-sources 100 % done 67/459 > make: Entering directory `/etc/selinux/strict/src/policy' > mkdir -p /etc/selinux/strict/policy > /usr/bin/checkpolicy -o /etc/selinux/strict/policy/policy.18 policy.conf > /usr/bin/checkpolicy: loading policy configuration from policy.conf > domains/user.te:70:ERROR 'syntax error' at token ')' on line 43573: > #line 70 > if () { > /usr/bin/checkpolicy: error(s) encountered while parsing configuration > make: *** [/etc/selinux/strict/policy/policy.18] Error 1 > make: Leaving directory `/etc/selinux/strict/src/policy' Side effect of converting many of the compile-time tunables to runtime booleans - if you have a customized tunables.tun file, then it is left intact by rpm, and m4 ends up defining away the boolean in the policy sources. If you have customized your tunables, then move aside your tunable.tun file and replace it with the .rpmnew file and then customize it again. You'll also need a /etc/selinux/$SELINUXTYPE/booleans file to customize the booleans (but I don't think Dan has built a policycoreutils yet that includes the updated load_policy to pull boolean settings from it). -- Stephen Smalley National Security Agency From selinux at comcast.net Mon Aug 9 16:11:38 2004 From: selinux at comcast.net (Tom London) Date: Mon, 09 Aug 2004 09:11:38 -0700 Subject: selinux-policy-strict-sources: syntax error in Rawhide Message-ID: <4117A23A.1050502@comcast.net> Stephen, Thanks. This particular systems is running 'stock' selinux-policy-strict files (i.e., selinux-policy-strict-sources is installed, but not modified). From your response (and from my reading of the develops on selinux at tycho.nsa.gov), I'm guessing that the best thing to do is just wait for the other rpm's to 'catch up'. It appears that the 'yum' process left me with my current policy.18 file (dated Aug-1) and a policy.18.rpmnew (dated Aug-8) (from the selinux-policy-strict package, I believe), so I'm guessing I have 'valid' policy files for the 'current' (i.e., selinux-policy-strict-1.15.11) and the 'new' (i.e., selinux-policy-strict-1.15.13) environments. I should have enough to 'keep running' until the new packages come (Thanks Dan!). thanks again, tom > ------------------------------------------------------------------------ > > * /From/: Stephen Smalley > > ------------------------------------------------------------------------ > >On Mon, 2004-08-09 at 11:46, Tom London wrote: >> Seems to be an error in the latest selinux-policy-strict-sources from >> Rawhide: >> tom >> >> selinux-policy-strict-sources 100 % done 67/459 >> make: Entering directory `/etc/selinux/strict/src/policy' >> mkdir -p /etc/selinux/strict/policy >> /usr/bin/checkpolicy -o /etc/selinux/strict/policy/policy.18 policy.conf >> /usr/bin/checkpolicy: loading policy configuration from policy.conf >> domains/user.te:70:ERROR 'syntax error' at token ')' on line 43573: >> #line 70 >> if () { >> /usr/bin/checkpolicy: error(s) encountered while parsing configuration >> make: *** [/etc/selinux/strict/policy/policy.18] Error 1 >> make: Leaving directory `/etc/selinux/strict/src/policy' > >Side effect of converting many of the compile-time tunables to runtime >booleans - if you have a customized tunables.tun file, then it is left >intact by rpm, and m4 ends up defining away the boolean in the policy >sources. If you have customized your tunables, then move aside your >tunable.tun file and replace it with the .rpmnew file and then customize >it again. You'll also need a /etc/selinux/$SELINUXTYPE/booleans file to >customize the booleans (but I don't think Dan has built a >policycoreutils yet that includes the updated load_policy to pull >boolean settings from it). > >-- >Stephen Smalley >National Security Agency > > > From Fred.New at microlink.ee Wed Aug 11 08:35:43 2004 From: Fred.New at microlink.ee (Fred New) Date: Wed, 11 Aug 2004 11:35:43 +0300 Subject: dbus send_msg denials Message-ID: <345764DCB65C0C4FACC44529DE273C18615EFA@eemail1.microlink.lan> I've got an FC3T1 system with all the latest Rawhide updates using the targeted policy and I've noticed the following messages in /var/log/messages: Aug 11 07:43:28 darth dbus: avc: denied { send_msg } for scontext=user_u:system_r:unconfined_t tcontext=user_u:system_r:unconfined_t tclass=dbus Aug 11 07:44:03 darth last message repeated 7 times Aug 11 07:45:08 darth last message repeated 13 times Is anyone else getting these? Fred From walters at redhat.com Wed Aug 11 12:18:52 2004 From: walters at redhat.com (Colin Walters) Date: Wed, 11 Aug 2004 08:18:52 -0400 Subject: dbus send_msg denials In-Reply-To: <345764DCB65C0C4FACC44529DE273C18615EFA@eemail1.microlink.lan> References: <345764DCB65C0C4FACC44529DE273C18615EFA@eemail1.microlink.lan> Message-ID: <1092226732.19426.3.camel@nexus.verbum.private> On Wed, 2004-08-11 at 11:35 +0300, Fred New wrote: > I've got an FC3T1 system with all the latest Rawhide updates using the > targeted policy and I've noticed the following messages in > /var/log/messages: > > Aug 11 07:43:28 darth dbus: avc: denied { send_msg } for > scontext=user_u:system_r:unconfined_t > tcontext=user_u:system_r:unconfined_t tclass=dbus > Aug 11 07:44:03 darth last message repeated 7 times > Aug 11 07:45:08 darth last message repeated 13 times Ah, right. This patch should fix it. -------------- next part -------------- A non-text attachment was scrubbed... Name: unconfined-dbus.patch Type: text/x-patch Size: 293 bytes Desc: not available URL: -------------- 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 sds at epoch.ncsc.mil Thu Aug 12 18:55:47 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 12 Aug 2004 14:55:47 -0400 Subject: glibc updates and sshd Message-ID: <1092336946.16219.142.camel@moss-spartans.epoch.ncsc.mil> Hi, rpm runs a helper after glibc updates that does a /sbin/service sshd condrestart. The present policy doesn't properly transition domains for this restarting of sshd by rpm, so if you have updated your glibc, your sshd may be running in the wrong domain. ps -eZ | grep sshd should show a context of system_u:system_r:sshd_t. If it does not, then do a /sbin/service sshd condrestart. Policy patch below. Index: policy/domains/program/unused/rpm.te =================================================================== RCS file: /nfshome/pal/CVS/selinux-usr/policy/domains/program/unused/rpm.te,v retrieving revision 1.24 diff -u -r1.24 rpm.te --- policy/domains/program/unused/rpm.te 12 Jul 2004 16:41:48 -0000 1.24 +++ policy/domains/program/unused/rpm.te 12 Aug 2004 18:42:44 -0000 @@ -59,6 +59,7 @@ allow rpm_t devtty_t:chr_file rw_file_perms; domain_auto_trans(rpm_t, ldconfig_exec_t, ldconfig_t) +domain_auto_trans(rpm_t, initrc_exec_t, initrc_t) ifdef(`cups.te', ` r_dir_file(cupsd_t, rpm_var_lib_t) -- Stephen Smalley National Security Agency From concert at europe.com Thu Aug 12 20:54:31 2004 From: concert at europe.com (t l) Date: Thu, 12 Aug 2004 12:54:31 -0800 Subject: Braces in path field breaks audit2allow Message-ID: <20040812205431.B7C70101D9@ws1-3.us4.outblaze.com> The following AVC makes audit2allow loop: Aug 12 09:08:02 fedora kernel: audit(1092326882.229:0): avc: denied { read } for pid=4477 exe=/bin/bash path=/home/tbl/.thunderbird/default/7hvcq9as.slt/extensions/{847b3a00-7ab1-11d4-8f02-006008948af5}/chrome/enigmail-skin-tbird.jar dev=hda2 ino=3769282 scontext=user_u:user_r:user_mozilla_t tcontext=system_u:object_r:user_home_t tclass=file Notice the brace characters in the 'path=' field. Deleting the brace characters, or replacing them with some other characters makes audit2allow work again. I can fix the problem by moving the code in audit2allow that checks for various '=' fields before the parsing of the brace field, and putting in an extra case for 'path='. I don't think this is the right fix. What about other fields that may have braces, like 'exe=', etc.? Someone with better Perl skills: please help! tom [Please notice that I didn't choose the filename ;) ] --- /usr/bin/audit2allow 2004-08-11 14:29:39.000000000 -0700 +++ audit2allow 2004-08-12 13:42:32.605241853 -0700 @@ -65,6 +65,13 @@ $command=""; foreach $i(0..$#types){ next if($types[$i]!~/[=\{]/); + my($a,$b) = split /=/,$types[$i]; + + next if($a eq "pid"); + next if($a eq "dev"); + next if($a eq "ino"); + next if($a eq "path"); + if($types[$i]=~/\{/){ $j=$i+1; while($types[$j]!~/\}/){ @@ -73,11 +80,6 @@ } next; } - my($a,$b) = split /=/,$types[$i]; - - next if($a eq "pid"); - next if($a eq "dev"); - next if($a eq "ino"); if(($a eq "scontext")||($a eq "tcontext")||($a eq "tclass")){ if($a ne "tclass"){ -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From concert at europe.com Thu Aug 12 21:47:16 2004 From: concert at europe.com (t l) Date: Thu, 12 Aug 2004 13:47:16 -0800 Subject: Braces in path field breaks audit2allow (PROPOSED FIX) Message-ID: <20040812214716.7F4101F50B1@ws1-2.us4.outblaze.com> Sorry to make the first mod so complicated. After looking at the Perl a bit, this is simpler, but depends on 'important brace fields' starting with the brace character. Is that correct? If so, a patch follows. tom --- /usr/bin/audit2allow 2004-08-11 14:29:39.000000000 -0700 +++ a2a 2004-08-12 14:42:33.812606852 -0700 @@ -65,7 +65,7 @@ $command=""; foreach $i(0..$#types){ next if($types[$i]!~/[=\{]/); - if($types[$i]=~/\{/){ + if($types[$i]=~/^\{/){ $j=$i+1; while($types[$j]!~/\}/){ $command.=" $types[$j]"; -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From sds at epoch.ncsc.mil Fri Aug 13 13:28:47 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 13 Aug 2004 09:28:47 -0400 Subject: Braces in path field breaks audit2allow (PROPOSED FIX) In-Reply-To: <20040812214716.7F4101F50B1@ws1-2.us4.outblaze.com> References: <20040812214716.7F4101F50B1@ws1-2.us4.outblaze.com> Message-ID: <1092403727.23108.53.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-08-12 at 17:47, t l wrote: > Sorry to make the first mod so complicated. > > After looking at the Perl a bit, this is simpler, but > depends on 'important brace fields' starting with the > brace character. Is that correct? I think so (I didn't write this script, and am not a perl expert either). The script is just trying to extract the list of permissions, which starts with a { by itself after the avc: denied prefix. With regard to your original diff, note that audit2allow captures auxiliary audit information like path and exe for the -v option; the exceptions for pid, dev, and ino are just to omit that information, as it was viewed as too ephemeral to likely be useful when reviewing audit2allow output. -- Stephen Smalley National Security Agency From selinux at comcast.net Fri Aug 13 14:20:48 2004 From: selinux at comcast.net (Tom London) Date: Fri, 13 Aug 2004 07:20:48 -0700 Subject: Braces in path field breaks audit2allow (PROPOSED FIX) Message-ID: <411CCE40.2000303@comcast.net> Thanks. I figured the script was doing more with some of the fields, and reordering the code would break something .... If the 'we only need to consider braces at the start' assumption is wrong, I think a more complicated regular expression that just excludes braces after '=' would work too. tom > ------------------------------------------------------------------------ > > * /From/: Stephen Smalley > > ------------------------------------------------------------------------ > >On Thu, 2004-08-12 at 17:47, t l wrote: >> Sorry to make the first mod so complicated. >> >> After looking at the Perl a bit, this is simpler, but >> depends on 'important brace fields' starting with the >> brace character. Is that correct? > >I think so (I didn't write this script, and am not a perl expert >either). The script is just trying to extract the list of permissions, >which starts with a { by itself after the avc: denied prefix. With >regard to your original diff, note that audit2allow captures auxiliary >audit information like path and exe for the -v option; the exceptions >for pid, dev, and ino are just to omit that information, as it was >viewed as too ephemeral to likely be useful when reviewing audit2allow >output. > >-- >Stephen Smalley >National Security Agency > > > From parklee_sel at yahoo.com Fri Aug 13 15:26:35 2004 From: parklee_sel at yahoo.com (Park Lee) Date: Fri, 13 Aug 2004 08:26:35 -0700 (PDT) Subject: issue on 'fixfiles relabel' Message-ID: <20040813152635.28451.qmail@web51502.mail.yahoo.com> On Thu, 03 Jun 2004 10:29:17, Stephen Smalley wrote: >The policy package installs a copy of the file_contexts file to >/etc/security/selinux so that it is available for use by fixfiles, >setfiles, or restorecon even if policy sources is not available. But in <>,there is one statement: > You will need to have the policy-sources package > installed to use setfiles. Then, If policy package installs a copy of the file_contexts file to /etc/security/selinux, is it necessary to install policy-sources package in order to use setfiles? Thanks. Best regards, Park Lee --------------------------------- Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! -------------- next part -------------- An HTML attachment was scrubbed... URL: From selinux at comcast.net Fri Aug 13 15:40:15 2004 From: selinux at comcast.net (Tom London) Date: Fri, 13 Aug 2004 08:40:15 -0700 Subject: crond/mailman, .... Rawhide issues.... Message-ID: <411CE0DF.9090507@comcast.net> Latest stuff from Rawhide: crond/mailman issues again.... Here is the email (I got lots of these!): Subject: Cron /usr/bin/python -S /var/mailman/cron/gate_news X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: Traceback (most recent call last): File "/var/mailman/cron/gate_news", line 284, in ? main() File "/var/mailman/cron/gate_news", line 259, in main lock.lock(timeout=0.5) File "/var/mailman/Mailman/LockFile.py", line 243, in lock self.__write() File "/var/mailman/Mailman/LockFile.py", line 422, in __write fp = open(self.__tmpfname, 'w') IOError: [Errno 13] Permission denied: '/var/mailman/locks/gate_news.lock.fedora.XXX.3986.0' Here are the AVCs: Aug 13 08:35:01 fedora crond(pam_unix)[4065]: session opened for user mailman by (uid=0) Aug 13 08:35:01 fedora crond(pam_unix)[4068]: session opened for user root by (uid=0) Aug 13 08:35:02 fedora kernel: audit(1092411302.395:0): avc: denied { read append } for pid=4067 exe=/usr/bin/python name=error dev=hda2 ino=442471 scontext=system_u:system_r:system_crond_t tcontext=system_u:object_r:mailman_log_t tclass=file Aug 13 08:35:02 fedora kernel: audit(1092411302.397:0): avc: denied { write } for pid=4067 exe=/usr/bin/python name=locks dev=hda2 ino=442718 scontext=system_u:system_r:system_crond_t tcontext=system_u:object_r:mailman_lock_t tclass=dir Aug 13 08:35:02 fedora crond(pam_unix)[4068]: session closed for user root Aug 13 08:35:04 fedora crond(pam_unix)[4065]: session closed for user mailman audit2allow produces: allow system_crond_t mailman_lock_t:dir { write }; allow system_crond_t mailman_log_t:file { append read }; That right, (or have I broken something else)? tom [BTW, booleans now get loaded. Neat!] From sds at epoch.ncsc.mil Fri Aug 13 17:49:37 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 13 Aug 2004 13:49:37 -0400 Subject: issue on 'fixfiles relabel' In-Reply-To: <20040813152635.28451.qmail@web51502.mail.yahoo.com> References: <20040813152635.28451.qmail@web51502.mail.yahoo.com> Message-ID: <1092419377.23108.257.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-08-13 at 11:26, Park Lee wrote: > On Thu, 03 Jun 2004 10:29:17, Stephen Smalley wrote: > >The policy package installs a copy of the file_contexts file to > >/etc/security/selinux so that it is available for use by fixfiles, > >setfiles, or restorecon even if policy sources is not available. > But in <>,there is one statement: > > You will need to have the policy-sources package > > installed to use setfiles. > > Then, If policy package installs a copy of the file_contexts file to > /etc/security/selinux, is it necessary to install policy-sources > package in order to use setfiles? No, policy-sources is not required to use setfiles; you can apply setfiles to the installed file_contexts configuration file (and fixfiles is just a script that runs setfiles on it). Bug in the FAQ, please bugzilla it. -- Stephen Smalley National Security Agency From concert at europe.com Fri Aug 13 17:59:44 2004 From: concert at europe.com (t l) Date: Fri, 13 Aug 2004 09:59:44 -0800 Subject: crond/mailman, .... Rawhide issues....[FIX?] Message-ID: <20040813175944.C3A7A1CE304@ws1-6.us4.outblaze.com> These changes seem to make crond/mailman happy: allow system_crond_t mailman_lock_t:dir rw_dir_perms; allow system_crond_t mailman_lock_t:file create_file_perms; allow system_crond_t mailman_log_t:file { append read }; tom * From: Tom London Latest stuff from Rawhide: crond/mailman issues again.... Here is the email (I got lots of these!): Subject: Cron /usr/bin/python -S /var/mailman/cron/gate_news X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: Traceback (most recent call last): File "/var/mailman/cron/gate_news", line 284, in ? main() File "/var/mailman/cron/gate_news", line 259, in main lock.lock(timeout=0.5) File "/var/mailman/Mailman/LockFile.py", line 243, in lock self.__write() File "/var/mailman/Mailman/LockFile.py", line 422, in __write fp = open(self.__tmpfname, 'w') IOError: [Errno 13] Permission denied: '/var/mailman/locks/gate_news.lock.fedora.XXX.3986.0' Here are the AVCs: Aug 13 08:35:01 fedora crond(pam_unix)[4065]: session opened for user mailman by (uid=0) Aug 13 08:35:01 fedora crond(pam_unix)[4068]: session opened for user root by (uid=0) Aug 13 08:35:02 fedora kernel: audit(1092411302.395:0): avc: denied { read append } for pid=4067 exe=/usr/bin/python name=error dev=hda2 ino=442471 scontext=system_u:system_r:system_crond_t tcontext=system_u:object_r:mailman_log_t tclass=file Aug 13 08:35:02 fedora kernel: audit(1092411302.397:0): avc: denied { write } for pid=4067 exe=/usr/bin/python name=locks dev=hda2 ino=442718 scontext=system_u:system_r:system_crond_t tcontext=system_u:object_r:mailman_lock_t tclass=dir Aug 13 08:35:02 fedora crond(pam_unix)[4068]: session closed for user root Aug 13 08:35:04 fedora crond(pam_unix)[4065]: session closed for user mailman audit2allow produces: allow system_crond_t mailman_lock_t:dir { write }; allow system_crond_t mailman_log_t:file { append read }; That right, (or have I broken something else)? tom [BTW, booleans now get loaded. Neat!] -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From mayerf at tresys.com Fri Aug 13 18:34:22 2004 From: mayerf at tresys.com (Frank Mayer) Date: Fri, 13 Aug 2004 14:34:22 -0400 Subject: Preliminary Announce: First SELinux Symposium Message-ID: <005001c48164$27ff4510$ee0c010a@columbia.tresys.com> Preliminary Announcement FIRST SECURITY ENHANCED LINUX SYMPOSIUM The inaugural symposium on Security Enhanced Linux (SELinux) is being planned for March 2005 in the Washington, D.C., USA area. SELinux brings the power of type enforcement (TE), a flexible mandatory access control mechanism, to Linux. This announcement is to make the community aware of the preliminary plans for the symposium, and solicit interests in participation. The symposium will be an opportunity to learn about SELinux and share technical and application experiences. The tentative format for the symposium is a 3-day conference, with one day for tutorials and two days for technical presentations and interchange. Those interested in submitting presentation or tutorial proposals may do so at sel-symposium at tresys.com. Topics of interest include: + History and design of SELinux + Use and application of TE Enforcement in securing systems + TE policy development and analysis + Use and Configuration of MLS and RBAC in securing systems + Updates on the various Linux distributions using SELinux + Practical "root"-less system administration policies + Example system solutions using SELinux, case studies + On-going and planed enhancements to SELinux + On-going research and development activities + Tools and products supporting/using SELinux + Security evaluation and certification issues + Tutorials The exact dates, location, and cost of the symposium are to be determined. Future information will be posted in the following web site: www.tresys.com/selinux/symposium The organizing committees for the symposium are as follows: Technical Committee: Joshua Brindle, Tresys Russell Coker, Red Hat Chad Hanson, TCS Howard Holm, NSA Trent Jaeger, IBM Karl MacMillan, Tresys Frank Mayer, Tresys James Morris, Red Hat Ed Reed, Novell Doc Shankar, IBM Stephen Smalley, NSA Daniel Walsh, Red Hat Tutorial Committee: David Caplan, Tresys Howard Holm, NSA Karl MacMillan, Tresys From russell at coker.com.au Sat Aug 14 07:52:50 2004 From: russell at coker.com.au (Russell Coker) Date: Sat, 14 Aug 2004 17:52:50 +1000 Subject: crond/mailman, .... Rawhide issues....[FIX?] In-Reply-To: <20040813175944.C3A7A1CE304@ws1-6.us4.outblaze.com> References: <20040813175944.C3A7A1CE304@ws1-6.us4.outblaze.com> Message-ID: <200408141752.50396.russell@coker.com.au> On Sat, 14 Aug 2004 03:59, "t l" wrote: > These changes seem to make crond/mailman happy: > > allow system_crond_t mailman_lock_t:dir rw_dir_perms; > allow system_crond_t mailman_lock_t:file create_file_perms; > allow system_crond_t mailman_log_t:file { append read }; The problem with this is that it removes the entire point of having a policy for mailman. > Subject: Cron /usr/bin/python -S /var/mailman/cron/gate_news Above is the real problem. /usr/bin/python is run instead of /var/mailman/cron/gate_news. I presume that python is specified on the command-line to give the -S option. From the python man page: -S Disable the import of the module site and the site-dependent manipulations of sys.path that it entails. If we make the first line of each python script be: #!/usr/bin/python -S Then the "/usr/bin/python -S" part can be removed and a domain_auto_trans() rule will take place and run things in the right domain. Also the mailman.fc file was missing some things. I've attached a revised version (untested) which should work better. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -------------- next part -------------- # mailman list server /var/log/mailman(/.*)? system_u:object_r:mailman_log_t ifdef(`debian', ` /usr/lib/cgi-bin/mailman/.* -- system_u:object_r:mailman_cgi_exec_t /usr/lib/mailman/cron/.* -- system_u:object_r:mailman_queue_exec_t /usr/lib/mailman/mail/wrapper -- system_u:object_r:mailman_mail_exec_t /usr/mailman/mail/wrapper -- system_u:object_r:mailman_mail_exec_t /var/lib/mailman(/.*)? system_u:object_r:mailman_data_t /var/lib/mailman/archives(/.*)? system_u:object_r:mailman_archive_t /etc/cron\.daily/mailman -- system_u:object_r:mailman_queue_exec_t /etc/cron\.monthly/mailman -- system_u:object_r:mailman_queue_exec_t ') ifdef(`redhat', ` /var/mailman/cgi-bin/.* -- system_u:object_r:mailman_cgi_exec_t /var/mailman/data(/.*)? system_u:object_r:mailman_data_t /var/mailman/locks(/.*)? system_u:object_r:mailman_lock_t /var/mailman/cron -d system_u:object_r:bin_t /var/mailman/cron/.+ -- system_u:object_r:mailman_queue_exec_t /var/mailman/archives(/.*)? system_u:object_r:mailman_archive_t /var/mailman/scripts/mailman -- system_u:object_r:mailman_mail_exec_t /var/mailman/bin/qrunner -- system_u:object_r:mailman_queue_exec_t /var/mailman/cgi-bin/.* -- system_u:object_r:mailman_cgi_exec_t /var/mailman/mail/mailman -- system_u:object_r:mailman_mail_exec_t ') From russell at coker.com.au Sat Aug 14 08:55:12 2004 From: russell at coker.com.au (Russell Coker) Date: Sat, 14 Aug 2004 18:55:12 +1000 Subject: crond/mailman, .... Rawhide issues....[FIX?] In-Reply-To: <200408141752.50396.russell@coker.com.au> References: <20040813175944.C3A7A1CE304@ws1-6.us4.outblaze.com> <200408141752.50396.russell@coker.com.au> Message-ID: <200408141855.12436.russell@coker.com.au> On Sat, 14 Aug 2004 17:52, Russell Coker wrote: > > Subject: Cron /usr/bin/python > -S /var/mailman/cron/gate_news > > Above is the real problem. /usr/bin/python is run instead > of /var/mailman/cron/gate_news. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129920 I've filed a bugzilla report about this. -- 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 walters at redhat.com Sat Aug 14 18:19:06 2004 From: walters at redhat.com (Colin Walters) Date: Sat, 14 Aug 2004 14:19:06 -0400 Subject: some fixes to allow user roles in targeted policy Message-ID: <1092507546.4515.16.camel@nexus.verbum.private> Hi, I'm trying to create a restricted user domain with the targeted policy, e.g.: full_user_role(test) This turned up quite a number of issues. First, I had to suck in user.te from the strict policy to get the booleans. I stripped it down to just the essentials; it may make sense to add some of it back. Secondly, unconfined_t isn't completely unconfined; in particular it can't transition to arbitrary domains. So sshd (which runs as unconfined_t) can't enter the new user domain. So I added a bit to full_user_role which allows unconfined_t to transition to new user domains (via a shell) in the targeted policy. Third, there were a few missing ifdefs (likely applicable in strict policy too). Fourth, the user domain needs access to user_home_dir_t:dir. The fifth issue is access to /dev/pts. The comment above the patch should explain things. Is there a better solution here? -------------- next part -------------- A non-text attachment was scrubbed... Name: targeted-users.patch Type: text/x-patch Size: 3970 bytes Desc: not available URL: -------------- 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 bmccarty at pt-net.net Sat Aug 14 19:40:11 2004 From: bmccarty at pt-net.net (Bill McCarty) Date: Sat, 14 Aug 2004 12:40:11 -0700 Subject: Domains, interpreted languages, and Cron scripts Message-ID: <104149609.1092487211@[10.11.52.51]> Hi all, I've run into an architectural headache that someone else must already have visited, and perhaps solved. But, I find no mention of the problem in list archives or elsewhere. I have several Python scripts that run under Cron. Some of these scripts access or modify sensitive data, and so I'd like to define one or more domains by means of which to limit their privileges. However, the exe name associated with such scripts is /usr/bin/python2.3, rather than the name of the script. Consistent with the principle of least privilege, I'd prefer to define distinct domains for each script, rather than an overly broad python_t domain, for instance. Has anyone else been here already? What techniques are useful for constraining the privileges given to scripts? One idea: Would it be a good thing to modify Run-parts to transition to a domain named for the Cron script it launches? Doing so would seem to solve my problem, but it might create others . Thanks, -- Bill McCarty, Ph.D. Professor of Information Technology Azusa Pacific University From walters at redhat.com Sun Aug 15 05:46:32 2004 From: walters at redhat.com (Colin Walters) Date: Sun, 15 Aug 2004 01:46:32 -0400 Subject: rssh policy for fedora Message-ID: <1092548792.5059.10.camel@nexus.verbum.private> Hi, I've ported my rssh policy to the FC2 strict policy; it required some changes to allow sshd to enter the domain (the "userdomain" attribute), and to make pty labeling work correctly (can_create_pty and type_change). I'm a little unsure about making this domain be a userdomain, there are a lot of implications from that. But I think it was the constraints that were stopping sshd from entering it. It probably doesn't make sense to include this in the Fedora policy at the moment since we don't ship rssh in Fedora, but maybe others here will find this useful. Although, come to think of it, this approach would probably be a good way to restrict cvs+ssh too, which is a fairly common setup. -------------- next part -------------- # # Macros for Rssh domains # # Author: Colin Walters # # # rssh_domain(domain_prefix) # # Define a specific rssh domain. # # The type declaration for the executable type for this program is # provided separately in domains/program/rssh.te. # undefine(`rssh_domain') ifdef(`rssh.te', ` define(`rssh_domain',` type rssh_$1_t, domain, userdomain, privlog, privfd; role rssh_$1_r types rssh_$1_t; allow system_r rssh_$1_r; type rssh_$1_rw_t, file_type, sysadmfile; type rssh_$1_ro_t, file_type, sysadmfile; general_domain_access(rssh_$1_t); uses_shlib(rssh_$1_t); base_file_read_access(rssh_$1_t); allow rssh_$1_t var_t:dir r_dir_perms; r_dir_file(rssh_$1_t, etc_t); r_dir_file(rssh_$1_t, etc_runtime_t); r_dir_file(rssh_$1_t, locale_t); can_exec(rssh_$1_t, bin_t); allow rssh_$1_t proc_t:dir { getattr search }; allow rssh_$1_t proc_t:lnk_file { getattr read }; r_dir_file(rssh_$1_t, rssh_$1_ro_t); create_dir_file(rssh_$1_t, rssh_$1_rw_t); can_create_pty(rssh_$1, `, userpty_type, user_tty_type') # Use the type when relabeling pty devices. type_change rssh_$1_t server_pty:chr_file rssh_$1_devpts_t; ifdef(`ssh.te',` allow rssh_$1_t sshd_t:fd use; allow rssh_$1_t sshd_t:tcp_socket rw_stream_socket_perms; allow rssh_$1_t sshd_t:unix_stream_socket rw_stream_socket_perms; # For reading /home/user/.ssh r_dir_file(sshd_t, rssh_$1_ro_t); domain_trans(sshd_t, rssh_exec_t, rssh_$1_t); ') ') ', ` define(`rssh_domain',`') ') -------------- next part -------------- #DESC Rssh - Restricted (scp/sftp) only shell # # Authors: Colin Walters # X-Debian-Package: rssh # type rssh_exec_t, file_type, sysadmfile, exec_type; ifdef(`ssh.te',` allow sshd_t rssh_exec_t:file r_file_perms; ') # See rssh_macros.te for the rest. -------------- next part -------------- # rssh /usr/bin/rssh system_u:object_r:rssh_exec_t -------------- 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 Sun Aug 15 06:03:35 2004 From: walters at redhat.com (Colin Walters) Date: Sun, 15 Aug 2004 02:03:35 -0400 Subject: Domains, interpreted languages, and Cron scripts In-Reply-To: <104149609.1092487211@[10.11.52.51]> References: <104149609.1092487211@[10.11.52.51]> Message-ID: <1092549815.17378.1.camel@nexus.verbum.private> On Sat, 2004-08-14 at 12:40 -0700, Bill McCarty wrote: > I've run into an architectural headache that someone else must already have > visited, and perhaps solved. But, I find no mention of the problem in list > archives or elsewhere. Actually I think this is the same problem as the "crond/mailman" thread just above :) > I have several Python scripts that run under Cron. Some of these scripts > access or modify sensitive data, and so I'd like to define one or more > domains by means of which to limit their privileges. Definitely possible. > However, the exe name > associated with such scripts is /usr/bin/python2.3, rather than the name of > the script. You mean that you see exe=/usr/bin/python2.3 in the audit logs? That's just a side effect of the way the kernel interprets the #! header and executes the script, it doesn't mean all python scripts have to run in the same domain. > Consistent with the principle of least privilege, I'd prefer to > define distinct domains for each script, rather than an overly broad > python_t domain, for instance. After creating your domain, just be sure that the context is set correctly on the executable file, and that you execute it directly. For example: [root at monk root]# id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=root:sysadm_r:sysadm_t [root at monk root]# cat /usr/local/bin/foo.py #!/usr/bin/python2.3 import os os.system("id") [root at monk root]# ls -alZ /usr/local/bin/foo.py -rwxr-xr-x+ root root root:object_r:bin_t /usr/local/bin/foo.py [root at monk root]# /usr/local/bin/foo.py uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=root:sysadm_r:sysadm_t [root at monk root]# chcon -t unconfined_exec_t /usr/local/bin/foo.py [root at monk root]# ls -alZ /usr/local/bin/foo.py -rwxr-xr-x+ root root root:object_r:unconfined_exec_t /usr/local/bin/foo.py [root at monk root]# /usr/local/bin/foo.py uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=root:sysadm_r:unconfined_t You can see from the above that when I originally executed the script, I remained in the security context root:sysadm_r:sysadm_t. That's because the script had the bin_t type, and there is no transition. However, when I changed the type of the script to unconfined_exec_t, this caused a transition to root:sysadm_r:unconfined_t (note the different type). So what you would do is create your own domain foo_script_t, and just do: chcon -t foo_script_t /path/to/script Does that make sense? > One idea: Would it be a good thing to modify Run-parts to transition to a > domain named for the Cron script it launches? Doing so would seem to solve > my problem, but it might create others . I don't think it's necessary to modify run-parts. Instead, inside the definition of your foo_script.te file, do something like: ifdef(`crond.te', ` system_crond_entry(foo_script_exec_t, foo_script_t) ') system_crond_entry is a macro that causes the transition to happen automatically. -------------- 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 russell at coker.com.au Sun Aug 15 07:23:16 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 15 Aug 2004 17:23:16 +1000 Subject: Domains, interpreted languages, and Cron scripts In-Reply-To: <1092549815.17378.1.camel@nexus.verbum.private> References: <104149609.1092487211@[10.11.52.51]> <1092549815.17378.1.camel@nexus.verbum.private> Message-ID: <200408151723.17008.russell@coker.com.au> On Sun, 15 Aug 2004 16:03, Colin Walters wrote: > > One idea: Would it be a good thing to modify Run-parts to transition to a > > domain named for the Cron script it launches? Doing so would seem to > > solve my problem, but it might create others . > > I don't think it's necessary to modify run-parts. ?Instead, inside the > definition of your foo_script.te file, do something like: Absolutely. More than being unnecessary it's also exceedingly painful to go and modify lots of programs such as run-parts. If we did modify run-parts to use a domain name based on the file name then run-parts would need code to map the file name to the domain name thus removing policy decisions from the policy database in the kernel and putting them in the application. Someone who used to work on a different trusted OS project told me that he thought that the SE Linux design of putting everything in the policy is absolutely the right thing to do, he had considerable experience with doing these things as C code compiled into binaries and found it not to be effective. An on-going topic of discussion on the main SE Linux list for years has been about what other modifications should be made to applications. Most of the suggestions have been rejected (including some of mine). -- 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 Sun Aug 15 15:03:17 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 16 Aug 2004 01:03:17 +1000 Subject: encrypted root fs Message-ID: <200408160103.17068.russell@coker.com.au> As an experiment I setup a machine with an encrypted root fs. I have attached the patch for mkinitrd which I used. It is hard-coded for the device names that I use (/dev/V0/fc2enc for the encrypted LVM volume) because I couldn't think of a good way of storing this. For production use this would need a --encrypt-root option or maybe reading some sort of /etc/crypttab file and deducing that root encryption is needed. Also with my patch you need to put "--with=dm-crypt --with=aes" on the mkinitrd command-line. To create the encrypted device you have to run "cryptsetup -d /etc/root-key create crypto /dev/V0/fc2enc" to create the encrypted device and then dd a file system of the same size to /dev/mapper/crypto. Finally I've created a statically linked version of cryptsetup for use in the initrd and named it /usr/bin/cryptsetup.static . I've put the binary on http://www.coker.com.au/crypt/ as a temporary measure for anyone who wants to play with it. I'll release my code patches once I get them tidied up a bit. Currently the statically linked version of cryptsetup is 780K in size. The libdevmapper code drags in libselinux code which makes it overly large. I think that perhaps we need to have a statically linked version of the libdevmapper code without SE Linux support for use in the initrd (the SE Linux policy is loaded by /sbin/init so there is no possibility of doing any useful SE Linux stuff from inside the initrd). I notice that /bin/lvm in the initrd (/sbin/lvm.static on the root fs) is over 1M in size and includes SE Linux code that is of no use in the initrd. Is the statically linked version of lvm used for anything other than the initrd? If not then we should just build it with no SE Linux support because once again it can't do anything productive with SE Linux code in the initrd and it just wastes space. Please let me know what you think of these ideas. I would like to get some feedback before I start filing bugzilla reports. Finally please don't even think of testing this out on any machine that contains important data. There are lots of ways that this can go wrong and lose your data. The aim of this work is to have a system that boots from removable media and uses encryption for all block devices so that if it is stolen no data will be lost and so someone who gets temporary access to the hardware will have a much more difficult time of trying to crack it. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -------------- next part -------------- A non-text attachment was scrubbed... Name: mkinitrd.diff Type: text/x-diff Size: 1092 bytes Desc: not available URL: From bmccarty at pt-net.net Sun Aug 15 18:02:16 2004 From: bmccarty at pt-net.net (Bill McCarty) Date: Sun, 15 Aug 2004 11:02:16 -0700 Subject: Domains, interpreted languages, and Cron scripts In-Reply-To: <1092549815.17378.1.camel@nexus.verbum.private> References: <104149609.1092487211@[10.11.52.51]> <1092549815.17378.1.camel@nexus.verbum.private> Message-ID: <184674267.1092567736@[192.168.0.2]> Hi Russ, Colin, and all, --On Sunday, August 15, 2004 2:03 AM -0400 Colin Walters wrote: > Actually I think this is the same problem as the "crond/mailman" thread > just above :) Yes, I believe that the new thread appeared after I'd searched for messages. But, perhaps my search was less effective than I'd hoped . >> However, the exe name >> associated with such scripts is /usr/bin/python2.3, rather than the name >> of the script. > > You mean that you see exe=/usr/bin/python2.3 in the audit logs? That's > just a side effect of the way the kernel interprets the #! header and > executes the script, it doesn't mean all python scripts have to run in > the same domain. Ah! I hadn't considered that the behavior of a python script using a shebang (#!) and one invoking python with a script name as a an argument might differ. The distinction is obvious in retrospect. Part of my confusion arose because one of my files was incorrectly labeled. As someone wrote, it's not what you don't know that gets you, it's what you think you know that isn't really so . > I don't think it's necessary to modify run-parts. Instead, inside the > definition of your foo_script.te file, do something like: > > ifdef(`crond.te', ` > system_crond_entry(foo_script_exec_t, foo_script_t) > ') Thanks! I hadn't noticed that convenient macro. FYI, it looks like its definition already checks for crond.te: # When system_crond_t domain executes a type $1 executable then transition to # domain $2, allow $2 to interact with crond_t as well. define(`system_crond_entry', ` ifdef(`crond.te', ` domain_auto_trans(system_crond_t, $1, $2) allow $2 crond_t:fifo_file { getattr read write ioctl }; # a rule for privfd may make this obsolete allow $2 crond_t:fd use; allow $2 crond_t:process sigchld; Cheers, -- Bill McCarty, Ph.D. Professor of Information Technology Azusa Pacific University From biz7rv0y at verizon.net Sun Aug 15 20:20:06 2004 From: biz7rv0y at verizon.net (Business DSL User) Date: Sun, 15 Aug 2004 13:20:06 -0700 Subject: Snort and sysadm_devpts Message-ID: <192944028.1092576006@[192.168.0.2]> Hey all, I'm trying to run Snort 2.1.3 under Fedora Core 2, with SELinux. When I restart Snort, it dies after logging the message "pcap_loop: recvfrom: Socket operation on non-socket." When I put SELinux in permissive mode, Snort works fine. So, I know the problem is with my SELinux policy configuration. Thing is, SELinux doesn't log any AVC messages explaining Snort's death. As an experiment, I deleted the dontaudit rules from policy.conf, and built and loaded the modified policy. The resulting AVC messages identified about a half dozen operations that were failing. One of them seems to be responsible for killing Snort. Adding the rule: allow snort_t sysadm_devpts_t:chr_file { read write }; enables Snort to restart just fine. Some questions arise: 1. Is the technique of deleting dontaudit rules valid, or is there a better way? 2. Is there possibly a better policy tweak that would permit Snort to restart okay? I'm not cheerful about giving Snort access to the console. 3. What's with Snort trying to access /dev/pts? Seems to me that a daemonized program shouldn't do that. So, there's obviously something I don't know. Thanks, From mike at flyn.org Mon Aug 16 02:57:56 2004 From: mike at flyn.org (W. Michael Petullo) Date: Sun, 15 Aug 2004 21:57:56 -0500 Subject: encrypted root fs In-Reply-To: <200408160103.17068.russell@coker.com.au> References: <200408160103.17068.russell@coker.com.au> Message-ID: <20040816025756.GA4029@imp.flyn.org> > As an experiment I setup a machine with an encrypted root fs. Please see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124789. -- Mike :wq From sds at epoch.ncsc.mil Mon Aug 16 12:56:02 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 16 Aug 2004 08:56:02 -0400 Subject: some fixes to allow user roles in targeted policy In-Reply-To: <1092507546.4515.16.camel@nexus.verbum.private> References: <1092507546.4515.16.camel@nexus.verbum.private> Message-ID: <1092660962.16631.19.camel@moss-spartans.epoch.ncsc.mil> On Sat, 2004-08-14 at 14:19, Colin Walters wrote: > I'm trying to create a restricted user domain with the targeted policy, > e.g.: > > full_user_role(test) > > This turned up quite a number of issues. It seems like this will just take you down the path of turning the targeted policy into the strict policy. So why not just use the strict policy? > Fourth, the user domain needs access to user_home_dir_t:dir. Should be $1_home_dir_t, right? > The fifth issue is access to /dev/pts. The comment above the patch > should explain things. Is there a better solution here? If you want any protection between users, you need the separate types on the ptys (and ttys). But as above, you are likely to increasingly find yourself transforming the targeted policy into the strict policy to achieve real separation, so why not just use the strict policy? -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Mon Aug 16 13:07:50 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 16 Aug 2004 09:07:50 -0400 Subject: Snort and sysadm_devpts In-Reply-To: <192944028.1092576006@[192.168.0.2]> References: <192944028.1092576006@[192.168.0.2]> Message-ID: <1092661669.16631.32.camel@moss-spartans.epoch.ncsc.mil> On Sun, 2004-08-15 at 16:20, Business DSL User wrote: > As an experiment, I deleted the dontaudit rules from policy.conf, and built > and loaded the modified policy. The resulting AVC messages identified about > a half dozen operations that were failing. One of them seems to be > responsible for killing Snort. Adding the rule: > > allow snort_t sysadm_devpts_t:chr_file { read write }; > > enables Snort to restart just fine. > > Some questions arise: > > 1. Is the technique of deleting dontaudit rules valid, or is there a better > way? There is an 'enableaudit' target in the policy Makefile that does precisely that - see the Fedora SELinux FAQ. make enableaudit load, then make clean load later to revert. > 2. Is there possibly a better policy tweak that would permit Snort to > restart okay? I'm not cheerful about giving Snort access to the console. Update to the latest FC2 kernel and policy. A change was made to SELinux to re-open descriptors that it closes on exec to the null device. This avoids inducing program misbehavior when SELinux closes descriptors. > 3. What's with Snort trying to access /dev/pts? Seems to me that a > daemonized program shouldn't do that. So, there's obviously something I > don't know. The read/write checks are performed by SELinux on the exec to revalidate access to the open descriptor, so you would see the audit messages even if the program never tried to access the descriptor itself (that is why they are dontaudit'd). With regard to snort dying, a similar issue existed with apache; it would create a socket (which would get assigned descriptor 0, since SELinux had closed descriptors 0-2 to the pty), then close descriptors 0-2 (thinking that they were its stdin/stdout/stderr), then try to use the socket and fail since it had unwittingly closed it. With newer kernels, SELinux re-opens such descriptors to the null device, so that they remain assigned and any read/writes to them are harmless (e.g. diagnostic output). -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Mon Aug 16 13:14:04 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 16 Aug 2004 09:14:04 -0400 Subject: Domains, interpreted languages, and Cron scripts In-Reply-To: <1092549815.17378.1.camel@nexus.verbum.private> References: <104149609.1092487211@[10.11.52.51]> <1092549815.17378.1.camel@nexus.verbum.private> Message-ID: <1092662044.16631.37.camel@moss-spartans.epoch.ncsc.mil> On Sun, 2004-08-15 at 02:03, Colin Walters wrote: > You can see from the above that when I originally executed the script, I > remained in the security context root:sysadm_r:sysadm_t. That's because > the script had the bin_t type, and there is no transition. However, > when I changed the type of the script to unconfined_exec_t, this caused > a transition to root:sysadm_r:unconfined_t (note the different type). > > So what you would do is create your own domain foo_script_t, and just > do: > chcon -t foo_script_t /path/to/script Just as a reminder, domain transitions on scripts should only be done when shedding permissions. -- Stephen Smalley National Security Agency From walters at redhat.com Mon Aug 16 14:06:14 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 16 Aug 2004 10:06:14 -0400 Subject: some fixes to allow user roles in targeted policy In-Reply-To: <1092660962.16631.19.camel@moss-spartans.epoch.ncsc.mil> References: <1092507546.4515.16.camel@nexus.verbum.private> <1092660962.16631.19.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1092665175.5323.21.camel@nexus.verbum.private> On Mon, 2004-08-16 at 08:56 -0400, Stephen Smalley wrote: > > Fourth, the user domain needs access to user_home_dir_t:dir. > > Should be $1_home_dir_t, right? Actually that line can be scratched entirely, I think I just had the user's home directory mislabled, obviously that part is broken. > > The fifth issue is access to /dev/pts. The comment above the patch > > should explain things. Is there a better solution here? > > If you want any protection between users, you need the separate types on > the ptys (and ttys). Modulo DAC, you mean. I think in the targeted policy we're already relying heavily on DAC for protection between users, and this isn't really different. > But as above, you are likely to increasingly find > yourself transforming the targeted policy into the strict policy to > achieve real separation, so why not just use the strict policy? I just run targeted policy on my laptop to test it, and I wanted to test my hacks to the OpenSSH patch. I guess it seemed quicker to write a patch to allow user creation in the targeted policy than to wait through two relabels :) It is a bit of a unique situation, so maybe it's not worth trying to support user creation in the targeted policy. I just thought I'd send my hack along in case it was found useful. -------------- 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 biz7rv0y at verizon.net Mon Aug 16 18:09:16 2004 From: biz7rv0y at verizon.net (Business DSL User) Date: Mon, 16 Aug 2004 11:09:16 -0700 Subject: Snort and sysadm_devpts In-Reply-To: <1092661669.16631.32.camel@moss-spartans.epoch.ncsc.mil> References: <192944028.1092576006@[192.168.0.2]> <1092661669.16631.32.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <271493326.1092654556@[10.11.53.92]> Hi Stephen and all, > There is an 'enableaudit' target in the policy Makefile that does > precisely that - see the Fedora SELinux FAQ. make enableaudit load, > then make clean load later to revert. Cool! I clearly need to re-read the FAQ, since it's apparently been updated since my last reading . Good work, Karsten! >> 2. Is there possibly a better policy tweak that would permit Snort to >> restart okay? I'm not cheerful about giving Snort access to the console. > > Update to the latest FC2 kernel and policy. A change was made to > SELinux to re-open descriptors that it closes on exec to the null > device. This avoids inducing program misbehavior when SELinux closes > descriptors. Drat! No can do: The latest kernel includes a bug that restricts my Intel e1000 network adapter to about 20 kbps. So, I've been forced to regress to the next to latest kernel. Thanks, From bmccarty at pt-net.net Mon Aug 16 18:33:27 2004 From: bmccarty at pt-net.net (Bill McCarty) Date: Mon, 16 Aug 2004 11:33:27 -0700 Subject: Domains, interpreted languages, and Cron scripts In-Reply-To: <1092662044.16631.37.camel@moss-spartans.epoch.ncsc.mil> References: <104149609.1092487211@[10.11.52.51]> <1092549815.17378.1.camel@nexus.verbum.private> <1092662044.16631.37.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <272944843.1092656007@[10.11.53.92]> Hi Stephen, --On Monday, August 16, 2004 9:14 AM -0400 Stephen Smalley wrote: > Just as a reminder, domain transitions on scripts should only be done > when shedding permissions. I'm not sure that I understand. So, please pardon my flailing at the issue. I have a feeling that I'm missing important context . It does seem reasonable to avoid domain transitions whereby someone could gain permissions. But, Cron isn't all powerful and so I must allow one or more domain transitions that selectively add permissions. Otherwise, I'd have to extend Cron itself an unacceptably extensive range of permissions. Cheers, -- Bill McCarty, Ph.D. Professor of Information Technology Azusa Pacific University From sds at epoch.ncsc.mil Mon Aug 16 18:54:44 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 16 Aug 2004 14:54:44 -0400 Subject: Domains, interpreted languages, and Cron scripts In-Reply-To: <272944843.1092656007@[10.11.53.92]> References: <104149609.1092487211@[10.11.52.51]> <1092549815.17378.1.camel@nexus.verbum.private> <1092662044.16631.37.camel@moss-spartans.epoch.ncsc.mil> <272944843.1092656007@[10.11.53.92]> Message-ID: <1092682484.16631.200.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2004-08-16 at 14:33, Bill McCarty wrote: > It does seem reasonable to avoid domain transitions whereby someone could > gain permissions. But, Cron isn't all powerful and so I must allow one or > more domain transitions that selectively add permissions. Otherwise, I'd > have to extend Cron itself an unacceptably extensive range of permissions. True. A better statement would be "domain transitions on scripts should only be done when the caller is trusted not to abuse them." -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Mon Aug 16 19:28:37 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 16 Aug 2004 15:28:37 -0400 Subject: Snort and sysadm_devpts In-Reply-To: <271493326.1092654556@[10.11.53.92]> References: <192944028.1092576006@[192.168.0.2]> <1092661669.16631.32.camel@moss-spartans.epoch.ncsc.mil> <271493326.1092654556@[10.11.53.92]> Message-ID: <1092684517.16631.228.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2004-08-16 at 14:09, Business DSL User wrote: > Drat! No can do: The latest kernel includes a bug that restricts my Intel > e1000 network adapter to about 20 kbps. So, I've been forced to regress to > the next to latest kernel. That may still have the change for re-opening descriptors. If not, you can always manually redirect descriptors 0-2 to /dev/null from the shell when you start snort, in which case SELinux won't close them and snort should be fine. -- Stephen Smalley National Security Agency From bmccarty at pt-net.net Mon Aug 16 20:13:25 2004 From: bmccarty at pt-net.net (Bill McCarty) Date: Mon, 16 Aug 2004 13:13:25 -0700 Subject: Domains, interpreted languages, and Cron scripts In-Reply-To: <1092682484.16631.200.camel@moss-spartans.epoch.ncsc.mil> References: <104149609.1092487211@[10.11.52.51]> <1092549815.17378.1.camel@nexus.verbum.private> <1092662044.16631.37.camel@moss-spartans.epoch.ncsc.mil> <272944843.1092656007@[10.11.53.92]> <1092682484.16631.200.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <278941706.1092662005@[10.11.53.92]> I see--please pardon my pedanticism . Cheers, --On Monday, August 16, 2004 2:54 PM -0400 Stephen Smalley wrote: > On Mon, 2004-08-16 at 14:33, Bill McCarty wrote: >> It does seem reasonable to avoid domain transitions whereby someone >> could gain permissions. But, Cron isn't all powerful and so I must >> allow one or more domain transitions that selectively add permissions. >> Otherwise, I'd have to extend Cron itself an unacceptably extensive >> range of permissions. > > True. A better statement would be "domain transitions on scripts should > only be done when the caller is trusted not to abuse them." > > -- > 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 -- Bill McCarty, Ph.D. Professor of Information Technology Azusa Pacific University From russell at coker.com.au Tue Aug 17 01:55:07 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 17 Aug 2004 11:55:07 +1000 Subject: kernel file handle leak? Message-ID: <200408171155.07374.russell@coker.com.au> When I boot a laptop with a Cardbus Ethernet card installed I get the following avc messages related to a kernel file handle. Is this a known issue? (1092707493.572:0): avc: denied { read write } for pid=2131 exe=/sbin/ip path=socket:[921] dev=sockfs ino=921 scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t tclass=unix_dgram_socket audit(1092707493.581:0): avc: denied { read write } for pid=2133 exe=/sbin/iwconfig path=socket:[921] dev=sockfs ino=921 scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t tclass=unix_dgram_socket audit(1092707493.591:0): avc: denied { read write } for pid=2135 exe=/sbin/ethtool path=socket:[921] dev=sockfs ino=921 scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t tclass=unix_dgram_socket audit(1092707493.604:0): avc: denied { read write } for pid=2139 exe=/sbin/modprobe path=socket:[921] dev=sockfs ino=921 scontext=system_u:system_r:insmod_t tcontext=system_u:system_r:kernel_t tclass=unix_dgram_socket audit(1092707493.634:0): avc: denied { read write } for pid=2141 exe=/sbin/ip path=socket:[921] dev=sockfs ino=921 scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t tclass=unix_dgram_socket audit(1092707493.641:0): avc: denied { read write } for pid=2143 exe=/sbin/dhclient path=socket:[921] dev=sockfs ino=921 scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:kernel_t tclass=unix_dgram_socket audit(1092707498.179:0): avc: denied { read write } for pid=2316 exe=/sbin/ip path=socket:[921] dev=sockfs ino=921 scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t tclass=unix_dgram_socket audit(1092707498.188:0): avc: denied { read write } for pid=2318 exe=/sbin/ethtool path=socket:[921] dev=sockfs ino=921 scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t tclass=unix_dgram_socket audit(1092707498.195:0): avc: denied { read write } for pid=2320 exe=/sbin/ip path=socket:[921] dev=sockfs ino=921 scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t tclass=unix_dgram_socket audit(1092707498.265:0): avc: denied { read write } for pid=2331 exe=/sbin/ifconfig path=socket:[921] dev=sockfs ino=921 scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t tclass=unix_dgram_socket audit(1092707499.315:0): avc: denied { read write } for pid=2402 exe=/sbin/ip path=socket:[921] dev=sockfs ino=921 scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t tclass=unix_dgram_socket audit(1092707499.369:0): avc: denied { read write } for pid=2409 exe=/sbin/ip path=socket:[921] dev=sockfs ino=921 scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t tclass=unix_dgram_socket -- 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 concert at europe.com Tue Aug 17 02:20:06 2004 From: concert at europe.com (concert at europe.com) Date: Mon, 16 Aug 2004 18:20:06 -0800 Subject: udev leaking files/file-descriptors... Message-ID: <20040817022006.46BC51CE304@ws1-6.us4.outblaze.com> Running strict enforcing off of Rawhide, udev is still leaking fds across execs, especially execs of /sbin/restorecon. Here is an example avc showing the leak: Aug 14 19:35:38 fedora kernel: audit(1092537300.503:0): avc: denied { read write } for pid=1214 exe=/sbin/restorecon path=socket:[1188] dev=sockfs ino=1188 scontext=system_u:system_r:restorecon_t tcontext=system_u:system_r:udev_t tclass=unix_dgram_socket Probing a bit (and using Russell's suggestion to 'wrap' /sbin/restorecon), I figured out that udev is still 'leaking' open files across the exec of /etc/dev.d/default/selinux.dev. [udev is not calling fcntl(fd, F_SETFD, FD_CLOEXEC) .] I'll bugzilla this here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130100 but here is a patch to /etc/dev.d/default/selinux.dev that closes enough (all?) of the problematic file descriptors before exec-ing /sbin/restorecon. tom --- selinux.dev 2004-08-15 08:58:13.000000000 -0700 +++ /etc/dev.d/default/selinux.dev 2004-08-14 20:19:12.000000000 -0700 @@ -10,5 +10,5 @@ if [ "$UDEV_LOG" = "yes" -a -x /usr/bin/logger ]; then /usr/bin/logger -t selinux.dev -p auth.debug "Restoring file security contexts for $DEVNAME" fi - /sbin/restorecon $DEVNAME 4<&- + /sbin/restorecon $DEVNAME 3<&- 4<&- 5<&- 6<&- fi -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From sds at epoch.ncsc.mil Tue Aug 17 11:27:20 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Tue, 17 Aug 2004 07:27:20 -0400 Subject: kernel file handle leak? In-Reply-To: <200408171155.07374.russell@coker.com.au> References: <200408171155.07374.russell@coker.com.au> Message-ID: <1092742040.25650.1.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2004-08-16 at 21:55, Russell Coker wrote: > When I boot a laptop with a Cardbus Ethernet card installed I get the > following avc messages related to a kernel file handle. Is this a known > issue? > > (1092707493.572:0): avc: denied { read write } for pid=2131 exe=/sbin/ip > path=socket:[921] dev=sockfs ino=921 scontext=system_u:system_r:ifconfig_t > tcontext=system_u:system_r:kernel_t tclass=unix_dgram_socket > audit(1092707493.581:0): avc: denied { read write } for pid=2133 > exe=/sbin/iwconfig path=socket:[921] dev=sockfs ino=921 > scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t > tclass=unix_dgram_socket > audit(1092707493.591:0): avc: denied { read write } for pid=2135 > exe=/sbin/ethtool path=socket:[921] dev=sockfs ino=921 > scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t > tclass=unix_dgram_socket > audit(1092707493.604:0): avc: denied { read write } for pid=2139 > exe=/sbin/modprobe path=socket:[921] dev=sockfs ino=921 > scontext=system_u:system_r:insmod_t tcontext=system_u:system_r:kernel_t > tclass=unix_dgram_socket > audit(1092707493.634:0): avc: denied { read write } for pid=2141 > exe=/sbin/ip path=socket:[921] dev=sockfs ino=921 > scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t > tclass=unix_dgram_socket > audit(1092707493.641:0): avc: denied { read write } for pid=2143 > exe=/sbin/dhclient path=socket:[921] dev=sockfs ino=921 > scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:kernel_t > tclass=unix_dgram_socket > audit(1092707498.179:0): avc: denied { read write } for pid=2316 > exe=/sbin/ip path=socket:[921] dev=sockfs ino=921 > scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t > tclass=unix_dgram_socket > audit(1092707498.188:0): avc: denied { read write } for pid=2318 > exe=/sbin/ethtool path=socket:[921] dev=sockfs ino=921 > scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t > tclass=unix_dgram_socket > audit(1092707498.195:0): avc: denied { read write } for pid=2320 > exe=/sbin/ip path=socket:[921] dev=sockfs ino=921 > scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t > tclass=unix_dgram_socket > audit(1092707498.265:0): avc: denied { read write } for pid=2331 > exe=/sbin/ifconfig path=socket:[921] dev=sockfs ino=921 > scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t > tclass=unix_dgram_socket > audit(1092707499.315:0): avc: denied { read write } for pid=2402 > exe=/sbin/ip path=socket:[921] dev=sockfs ino=921 > scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t > tclass=unix_dgram_socket > audit(1092707499.369:0): avc: denied { read write } for pid=2409 > exe=/sbin/ip path=socket:[921] dev=sockfs ino=921 > scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t > tclass=unix_dgram_socket I've seen udev leaking a descriptor to a Unix datagram socket to its helper programs, but that is usually labeled udev_t (but would be kernel_t if you didn't install the udev policy or label udev properly, so that kernel_t failed to transition to udev_t when running udev). I've also seen the kernel leaking descriptors to rootfs entries unpacked from the initramfs to all processes; SELinux stomps on those and resets them to the null device. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Tue Aug 17 12:32:22 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Tue, 17 Aug 2004 08:32:22 -0400 Subject: kernel file handle leak? In-Reply-To: <1092742040.25650.1.camel@moss-spartans.epoch.ncsc.mil> References: <200408171155.07374.russell@coker.com.au> <1092742040.25650.1.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1092745942.25650.53.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2004-08-17 at 07:27, Stephen Smalley wrote: > I've seen udev leaking a descriptor to a Unix datagram socket to its > helper programs, but that is usually labeled udev_t (but would be > kernel_t if you didn't install the udev policy or label udev properly, > so that kernel_t failed to transition to udev_t when running udev). > > I've also seen the kernel leaking descriptors to rootfs entries unpacked > from the initramfs to all processes; SELinux stomps on those and resets > them to the null device. BTW, I don't know whether the udev helper socket inheritance is intentional (e.g. to collect output from the helper program) or an accident - I haven't looked at the code. -- Stephen Smalley National Security Agency From jmorris at redhat.com Tue Aug 17 14:01:11 2004 From: jmorris at redhat.com (James Morris) Date: Tue, 17 Aug 2004 10:01:11 -0400 (EDT) Subject: udev leaking files/file-descriptors... In-Reply-To: <20040817022006.46BC51CE304@ws1-6.us4.outblaze.com> Message-ID: On Mon, 16 Aug 2004 concert at europe.com wrote: > Probing a bit (and using Russell's suggestion to 'wrap' /sbin/restorecon), I figured > out that udev is still 'leaking' open files across the exec of > /etc/dev.d/default/selinux.dev. [udev is not calling > fcntl(fd, F_SETFD, FD_CLOEXEC) .] Wouldn't the correct way to fix this be to fix udev? - James -- James Morris From bmccarty at pt-net.net Tue Aug 17 18:29:52 2004 From: bmccarty at pt-net.net (Bill McCarty) Date: Tue, 17 Aug 2004 11:29:52 -0700 Subject: Testing cron script Message-ID: <2050268.1092742192@[10.11.53.92]> Hi all, How do folks like to test system Cron scripts, which run in the context system_u:system_r:system_crond_t? The system administrator can't simply invoke them using runcon: runcon system_u:system_r:system_crond_t /etc/cron.hourly/test.cron because the usual policies don't permit transitions from sysadm_t to system_crond_t. And, modifying the policy to permit such a transition seems to entail authorizing too many permissions, at least for my taste. I've tried running test scripts out of /etc/crontab, but I find that I waste a lot of time waiting for Cron to wake up and launch my test script. I've also tried running scripts, and test scripts, out of root's crontab, by using crontab -e. But, doing so entails extending permissions to crond_t, and I seem to end up in pretty much the same predicament. What am I missing? Cheers, -- Bill McCarty, Ph.D. Professor of Information Technology Azusa Pacific University From jim-cornette at sbcglobal.net Thu Aug 19 01:56:21 2004 From: jim-cornette at sbcglobal.net (Jim Cornette) Date: Wed, 18 Aug 2004 21:56:21 -0400 Subject: cupsd locking up system during boot - targeted mode Message-ID: <412408C5.6030004@sbcglobal.net> I just joined up to the list because I just enabled SELinux. The first thing that I did was to boot up the system in permissive mode, strict policy and into runlevel 1. I then ran fixfiles relabel at the prompt. I then changed /etc/sysconfig/selinux to reflect enforcing and use the targeted policy. Anyway, I ended up recieving the repeated error below. I posted to the test list and was guided to this list as more appropriate. This error looped and kept printing to the screen until I finally hit the ctl-alt-del key to reboot the system. I then came back into the system using selinux=0 when the grub prompt was presented. Aug 17 21:01:59 cornette-fc2 kernel: audit(1092790919.215:0): avc: denied { associate } for pid=3665 exe=/usr/sbin/cupsd name=0 scontext=user_u:object_r:unlabeled_t tcontext=system_u:object_r:fs_t tclass=filesystem I had avc errors recorded in the /var/log/messages using the strict and targeted policies. I'll submit them later through bugzilla. Jim From walters at redhat.com Thu Aug 19 14:08:51 2004 From: walters at redhat.com (Colin Walters) Date: Thu, 19 Aug 2004 10:08:51 -0400 Subject: cupsd locking up system during boot - targeted mode In-Reply-To: <412408C5.6030004@sbcglobal.net> References: <412408C5.6030004@sbcglobal.net> Message-ID: <1092924531.4245.0.camel@nexus.verbum.private> On Wed, 2004-08-18 at 21:56 -0400, Jim Cornette wrote: > I just joined up to the list because I just enabled SELinux. > > The first thing that I did was to boot up the system in permissive mode, > strict policy and into runlevel 1. I then ran fixfiles relabel at the > prompt. > > I then changed /etc/sysconfig/selinux to reflect enforcing and use the > targeted policy. Did you relabel after changing to the targeted policy? -------------- 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 rhallyx at mindspring.com Thu Aug 19 23:10:09 2004 From: rhallyx at mindspring.com (Richard Hally) Date: Thu, 19 Aug 2004 19:10:09 -0400 Subject: SELinux stops new X11? Message-ID: <41253351.7030807@mindspring.com> The new xorg-X11(6.7.99.902-1) will not start with the current strict SELinux policy(1.15.16-1) in enforcing mode. (xorg-x11-*6.7.0-7.2 works just fine). I have not tried permissive mode. It looks like something has changed in X11 that has to do with the fonts and the SE policy has not been updated to handle it but that is just speculation. from my Xorg.0.log: (II) Mouse0: ps2EnableDataReporting: succeeded Could not init font path element unix/:7100, removing from list! Fatal server error: could not open default font 'fixed' Please consult the The X.Org Foundation support at http://wiki.X.Org for help. Please also check the log file at "/var/log/Xorg.0.log" for additional information. *** If unresolved symbols were reported above, they might not *** be the reason for the server aborting. FatalError re-entered, aborting Caught signal 11. Server aborting ----------------------------------------------------------------------end of xorg log----------------------------------------- From /var/log/messages: Aug 19 17:34:53 new2 kernel: audit(1092951293.022:0): avc: denied { getattr } for pid=2578 exe=/usr/X11R6/bin/xfs path=/tmp/.font-unix dev=hda2 ino=1840549 scontext=system_u:system_r:xfs_t tcontext=system_u:object_r:initrc_tmp_t tclass=dir Aug 19 17:34:53 new2 xfs[2578]: cannot establish any listening sockets Aug 19 17:34:53 new2 xfs: xfs startup succeeded Aug 19 17:34:53 new2 xfs[2578]: ignoring font path element /usr/X11R6/lib/X11/fonts/Speedo (unreadable) Aug 19 17:35:13 new2 kernel: audit(1092951313.544:0): avc: denied { read } for pid=2995 exe=/usr/X11R6/bin/Xorg name=fb dev=hda2 ino=1061221 scontext=system_u:system_r:xdm_xserver_t tcontext=system_u:object_r:device_t tclass=lnk_file Aug 19 17:35:13 new2 last message repeated 2 times Aug 19 17:35:13 new2 kernel: audit(1092951313.545:0): avc: denied { read } for pid=2995 exe=/usr/X11R6/bin/Xorg name=fb dev=hda2 ino=1061221 scontext=system_u:system_r:xdm_xserver_t tcontext=system_u:object_r:device_t tclass=lnk_file Aug 19 17:35:13 new2 last message repeated 4 times Aug 19 17:35:15 new2 kernel: audit(1092951315.876:0): avc: denied { search } for pid=2995 exe=/usr/X11R6/bin/Xorg name=.font-unix dev=hda2 ino=1840549 scontext=system_u:system_r:xdm_xserver_t tcontext=system_u:object_r:initrc_tmp_t tclass=dir Aug 19 17:35:19 new2 kernel: audit(1092951319.457:0): avc: denied { read } for pid=3329 exe=/usr/X11R6/bin/Xorg name=fb dev=hda2 ino=1061221 scontext=system_u:system_r:xdm_xserver_t tcontext=system_u:object_r:device_t tclass=lnk_file Aug 19 17:35:19 new2 last message repeated 3 times Aug 19 17:35:19 new2 kernel: audit(1092951319.458:0): avc: denied { read } for pid=3329 exe=/usr/X11R6/bin/Xorg name=fb dev=hda2 ino=1061221 scontext=system_u:system_r:xdm_xserver_t tcontext=system_u:object_r:device_t tclass=lnk_file Aug 19 17:35:19 new2 last message repeated 3 times Aug 19 17:35:21 new2 kernel: audit(1092951321.333:0): avc: denied { search } for pid=3329 exe=/usr/X11R6/bin/Xorg name=.font-unix dev=hda2 ino=1840549 scontext=system_u:system_r:xdm_xserver_t tcontext=system_u:object_r:initrc_tmp_t tclass=dir Aug 19 17:35:21 new2 gdm[3304]: gdm_slave_xioerror_handler: Fatal X error - Restarting :0 Aug 19 17:35:24 new2 kernel: audit(1092951324.885:0): avc: denied { read } for pid=3494 exe=/usr/X11R6/bin/Xorg name=fb dev=hda2 ino=1061221 scontext=system_u:system_r:xdm_xserver_t tcontext=system_u:object_r:device_t tclass=lnk_file Aug 19 17:35:24 new2 kernel: audit(1092951324.886:0): avc: denied { read } for pid=3494 exe=/usr/X11R6/bin/Xorg name=fb dev=hda2 ino=1061221 scontext=system_u:system_r:xdm_xserver_t tcontext=system_u:object_r:device_t tclass=lnk_file Aug 19 17:35:24 new2 last message repeated 6 times FWIW Richard Hally From jim-cornette at sbcglobal.net Fri Aug 20 01:41:30 2004 From: jim-cornette at sbcglobal.net (Jim Cornette) Date: Thu, 19 Aug 2004 21:41:30 -0400 Subject: cupsd locking up system during boot - targeted mode In-Reply-To: <1092924531.4245.0.camel@nexus.verbum.private> References: <412408C5.6030004@sbcglobal.net> <1092924531.4245.0.camel@nexus.verbum.private> Message-ID: <412556CA.1040303@sbcglobal.net> Colin Walters wrote: >On Wed, 2004-08-18 at 21:56 -0400, Jim Cornette wrote: > > >>I just joined up to the list because I just enabled SELinux. >> >>The first thing that I did was to boot up the system in permissive mode, >>strict policy and into runlevel 1. I then ran fixfiles relabel at the >>prompt. >> >>I then changed /etc/sysconfig/selinux to reflect enforcing and use the >>targeted policy. >> >> > >Did you relabel after changing to the targeted policy? > > > I relabeled using the strict policy. I then changed the policy to targeted and rebooted. I believe I relabeled using targeted and permissive after the problem booting up. When I pulled the avc messages from the latest /var/log/messages, it was about 180 kb large. I also had problems installing the latest rounds of updates. I had to setenforce 0 because of this error on line 142, using up2date . Here is an excerpt from the xterm.. /etc/selinux/targeted/contexts/files/file_contexts: invalid context system_u:object_r:printer_device_t on line number 142 /etc/selinux/targeted/contexts/files/file_contexts: invalid context system_u:object_r:printer_device_t on line number 142 After completing the installation of the rpms, I'll try to relabel with latest targeted policy to see if I can boot up in enforcing w/o a looping situation. Jim From walters at redhat.com Fri Aug 20 01:52:14 2004 From: walters at redhat.com (Colin Walters) Date: Thu, 19 Aug 2004 21:52:14 -0400 Subject: cupsd locking up system during boot - targeted mode In-Reply-To: <412556CA.1040303@sbcglobal.net> References: <412408C5.6030004@sbcglobal.net> <1092924531.4245.0.camel@nexus.verbum.private> <412556CA.1040303@sbcglobal.net> Message-ID: <1092966734.29540.24.camel@nexus.verbum.private> On Thu, 2004-08-19 at 21:41 -0400, Jim Cornette wrote: > I relabeled using the strict policy. I then changed the policy to > targeted and rebooted. You need to relabel after changing the policy type, not before. > I believe I relabeled using targeted and permissive after the problem > booting up. That's the way to do it. > When I pulled the avc messages from the latest /var/log/messages, it was > about 180 kb large. Eek :) If you booted in the targeted policy with a filesystem that was labeled from a strict policy, a lot of those are probably going to just be noise. > I also had problems installing the latest rounds of updates. I had to > setenforce 0 because of this error on line 142, using up2date . Here is > an excerpt from the xterm.. > > /etc/selinux/targeted/contexts/files/file_contexts: invalid context > system_u:object_r:printer_device_t on line number 142 > /etc/selinux/targeted/contexts/files/file_contexts: invalid context > system_u:object_r:printer_device_t on line number 142 This should be fixed now in rawhide (1.15.16-2). -------------- 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 verbum.org Fri Aug 20 01:55:02 2004 From: walters at verbum.org (Colin Walters) Date: Thu, 19 Aug 2004 21:55:02 -0400 Subject: Testing cron script In-Reply-To: <2050268.1092742192@[10.11.53.92]> References: <2050268.1092742192@[10.11.53.92]> Message-ID: <1092965518.29540.10.camel@nexus.verbum.private> On Tue, 2004-08-17 at 11:29 -0700, Bill McCarty wrote: > Hi all, > > How do folks like to test system Cron scripts, which run in the context > system_u:system_r:system_crond_t? The system administrator can't simply > invoke them using runcon: > > runcon system_u:system_r:system_crond_t /etc/cron.hourly/test.cron > > because the usual policies don't permit transitions from sysadm_t to > system_crond_t. Right. > And, modifying the policy to permit such a transition seems to entail > authorizing too many permissions, at least for my taste. The following would probably be sufficient as a hack: role sysadm_r types system_crond_t; domain_trans(sysadm_t, bin_t, system_crond_t) Then invoke runcon like this: runcon system_u:system_r:system_crond_t /bin/sh /etc/cron.daily/prelink (We use /bin/sh because etc_t cannot be an entrypoint) > What am I missing? Nothing - I think that the major goal of the strict policy is to deny any interactions on the system that aren't part of "normal" operation. So normally, the system administrator wouldn't be debugging cron scripts. However, now that we have the boolean support, I think it would be nice to have a "debug" boolean or the like. This would enable things like the system administrator running cron scripts directly. To do this correctly, I think we would need to have runcon labeled specially, similar to newrole, so it can be a specific entrypoint for the cron types, instead of just using bin_t above. From sds at epoch.ncsc.mil Fri Aug 20 11:20:42 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 20 Aug 2004 07:20:42 -0400 Subject: SELinux stops new X11? In-Reply-To: <41253351.7030807@mindspring.com> References: <41253351.7030807@mindspring.com> Message-ID: <1093000842.16585.3.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-08-19 at 19:10, Richard Hally wrote: > The new xorg-X11(6.7.99.902-1) will not start with the current strict > SELinux policy(1.15.16-1) in enforcing mode. (xorg-x11-*6.7.0-7.2 works > just fine). I have not tried permissive mode. > It looks like something has changed in X11 that has to do with the > fonts and the SE policy has not been updated to handle it but that is > just speculation. I applied the patch below to my /etc/init.d/xfs to fix. This patch restores the type on /tmp/.font-unix when it is re-created by /etc/init.d/xfs. I assume that previously xfs was directly creating the directory itself, so that the file_type_auto_trans rule for xfs_t was sufficient to label it, but since it is now being created by the init script, it is getting a different type. --- /etc/init.d/xfs.old 2004-08-18 14:45:54.000000000 -0400 +++ /etc/init.d/xfs 2004-08-20 07:16:01.539914488 -0400 @@ -78,6 +78,7 @@ mkdir $FONT_UNIX_DIR chown root:root $FONT_UNIX_DIR chmod 1777 $FONT_UNIX_DIR + restorecon $FONT_UNIX_DIR daemon xfs -droppriv -daemon ret=$? -- Stephen Smalley National Security Agency From russell at coker.com.au Fri Aug 20 12:58:11 2004 From: russell at coker.com.au (Russell Coker) Date: Fri, 20 Aug 2004 22:58:11 +1000 Subject: SELinux stops new X11? In-Reply-To: <1093000842.16585.3.camel@moss-spartans.epoch.ncsc.mil> References: <41253351.7030807@mindspring.com> <1093000842.16585.3.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200408202258.11262.russell@coker.com.au> On Fri, 20 Aug 2004 21:20, Stephen Smalley wrote: > I applied the patch below to my /etc/init.d/xfs to fix. This patch > restores the type on /tmp/.font-unix when it is re-created by > /etc/init.d/xfs. I assume that previously xfs was directly creating the > directory itself, so that the file_type_auto_trans rule for xfs_t was > sufficient to label it, but since it is now being created by the init > script, it is getting a different type. I created a bugzilla entry: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130421 -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From russell at coker.com.au Fri Aug 20 13:02:55 2004 From: russell at coker.com.au (Russell Coker) Date: Fri, 20 Aug 2004 23:02:55 +1000 Subject: SELinux stops new X11? In-Reply-To: <41253351.7030807@mindspring.com> References: <41253351.7030807@mindspring.com> Message-ID: <200408202302.55276.russell@coker.com.au> On Fri, 20 Aug 2004 09:10, Richard Hally wrote: > Aug 19 17:35:13 new2 kernel: audit(1092951313.544:0): avc: denied { > read } for pid=2995 exe=/usr/X11R6/bin/Xorg name=fb dev=hda2 > ino=1061221 scontext=system_u:system_r:xdm_xserver_t > tcontext=system_u:object_r:device_t tclass=lnk_file The attached policy patch xserv.diff fixes this. The other is fixed by restorecon. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -------------- next part -------------- A non-text attachment was scrubbed... Name: xserv.diff Type: text/x-diff Size: 534 bytes Desc: not available URL: From binabin at libero.it Fri Aug 20 17:48:06 2004 From: binabin at libero.it (Pietro R.A. Binetti) Date: Fri, 20 Aug 2004 19:48:06 +0200 Subject: new Fedora user asks help Message-ID: <1093024085.2503.5.camel@localhost.localdomain> hello everyone, i am a new user of Fedora core 2, and a newer of linux-like OS as well. 2 days ago i installed Fedora on my notebook: acer travel mate 212T. i already have some problems that i can't solve: 1) Can't change the Screen resolution when i installed the OS, my screen hadn't been recognized, so i chose "generic LCD monitor" with a resolution of 800x600. once installed, i changed my mind and i wanted to switch into 1024x768 (supported by my hardware, for sure). to do that, i opened the Display window, from System Settings menu icon. here i configured a generic LCD panel with 1024x768 resolution from the Hardware folder and rebooted the PC. then, in the display window i had the possibility to choose the wanted resolution. doing that and rebooting i can see 1024x768 as the selected screen resolution, but looking at the screen things haven't changed: i always have the old 800x600. what should i do? 2)Touch pad the touch pad of my pc is correctly working, even if the click must be done pressing the left button and can't be done with the "touch". i can't find where i can configure or change the settings of my touch pad. can i? thanks in advance for your help. regards, Pietro -------------- next part -------------- An HTML attachment was scrubbed... URL: From electroblast at oricom.ca Fri Aug 20 23:29:32 2004 From: electroblast at oricom.ca (=?iso-8859-1?Q?Jean_L=E9tourneau?=) Date: Fri, 20 Aug 2004 19:29:32 -0400 Subject: new to Fedora Message-ID: Good day all, It's been a long time since I used any Linux, last was slackware 2.3, Anyway I found a umongus changes, well done to all devloppers.. This question is about several ports 21, (FTP) 25, (SMTP) and 110 (Pop) did I mist something while I was away? None of them work from the network, port 25 work from the fedora machine but not any others. Yes Postfix is installed. Sendmail and Spamassasin are also installed and running. I am running NO firewall for this testing. I am trying to figure out what is the command to install the pop and FTP server. From the GUY server setting, there is no MAIL, or FTP... at the add/remouve application I did install all services.. DOVECOT is installed and the IMap is working, but ni POP... Any one can put some light on this??? Thanks, Jean From walters at redhat.com Sat Aug 21 02:22:45 2004 From: walters at redhat.com (Colin Walters) Date: Fri, 20 Aug 2004 22:22:45 -0400 Subject: new Fedora user asks help In-Reply-To: <1093024085.2503.5.camel@localhost.localdomain> References: <1093024085.2503.5.camel@localhost.localdomain> Message-ID: <1093054965.4212.21.camel@nexus.verbum.private> On Fri, 2004-08-20 at 19:48 +0200, Pietro R.A. Binetti wrote: > hello everyone, > > i am a new user of Fedora core 2, and a newer of linux-like OS as > well. > 2 days ago i installed Fedora on my notebook: acer travel mate 212T. > i already have some problems that i can't solve: Did you enable SELinux? If not, you should try fedora-list, which is for general issues with Fedora. http://www.redhat.com/mailman/listinfo/fedora-list This list is about Security-Enhanced Linux in Fedora. -------------- 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 Sat Aug 21 02:23:58 2004 From: walters at redhat.com (Colin Walters) Date: Fri, 20 Aug 2004 22:23:58 -0400 Subject: new to Fedora In-Reply-To: References: Message-ID: <1093055038.4212.23.camel@nexus.verbum.private> Hi, This list is about Security-Enhanced Linux in Fedora. You want the general fedora-list for these issues. http://www.redhat.com/mailman/listinfo/fedora-list -------------- 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 bmccarty at pt-net.net Sat Aug 21 07:44:31 2004 From: bmccarty at pt-net.net (Bill McCarty) Date: Sat, 21 Aug 2004 00:44:31 -0700 Subject: Testing cron script In-Reply-To: <1092965518.29540.10.camel@nexus.verbum.private> References: <2050268.1092742192@[10.11.53.92]> <1092965518.29540.10.camel@nexus.verbum.private> Message-ID: <308926853.1093049070@[10.11.54.29]> Hi Colin and all, Thanks, Colin, for your suggestion. --On Thursday, August 19, 2004 9:55 PM -0400 Colin Walters wrote: > However, now that we have the boolean support, I think it would be nice > to have a "debug" boolean or the like. This would enable things like > the system administrator running cron scripts directly. To do this > correctly, I think we would need to have runcon labeled specially, > similar to newrole, so it can be a specific entrypoint for the cron > types, instead of just using bin_t above. Seems to me it also couldn't hurt to label /etc/cron.daily/* and friends with something other than etc_t. But, then again, I suppose that a specific label isn't reasonable for scripts referenced in /etc/crontab. So, I guess the effort would come to nothing. Cheers, -- Bill McCarty, Ph.D. Professor of Information Technology Azusa Pacific University From selinux at comcast.net Sat Aug 21 16:53:51 2004 From: selinux at comcast.net (Tom London) Date: Sat, 21 Aug 2004 09:53:51 -0700 Subject: avcs from install of initscripts/kernel ? Message-ID: <41277E1F.2060403@comcast.net> I noticed the following 2 avc's while doing a 'yum update' off of Rawhide today (running strict/enforcing): Aug 21 09:43:36 fedora kernel: audit(1093106616.786:0): avc: denied { dac_read_search } for pid=4292 exe=/bin/bash capability=2 scontext=root:sysadm_r:bootloader_t tcontext=root:sysadm_r:bootloader_t tclass=capability Aug 21 09:43:37 fedora kernel: audit(1093106617.979:0): avc: denied { transition } for pid=4331 exe=/bin/bash path=/sbin/dmsetup dev=hda2 ino=2310451 scontext=root:sysadm_r:bootloader_t tcontext=root:system_r:lvm_t tclass=process Looks like the second one occurs with a install of a new kernel, I'm guessing that the first one occurs during install of initscripts. Anything to be concerned about? tom From selinux at comcast.net Sat Aug 21 18:43:29 2004 From: selinux at comcast.net (Tom London) Date: Sat, 21 Aug 2004 11:43:29 -0700 Subject: .525 kernel and strict/enforcing (!?!?) Message-ID: <412797D1.2090209@comcast.net> Wow, the new kernel (.525) seems to not quite work with strict/enforcing. (Took me a while to recover, so tread carefully!) It manages to boot with strict/permissive, but there are hordes of avc messages.... Here are just the first.... Also, I notice that the initrd for .525 is about 625KB, compared with about 180KB for previous versions. Is it running udev, etc., off of the initrd? tom > Aug 21 11:28:46 fedora kernel: SELinux: initialized (dev rootfs, type > rootfs), uses genfs_contexts > Aug 21 11:28:46 fedora kernel: SELinux: initialized (dev sysfs, type > sysfs), uses genfs_contexts > Aug 21 11:28:46 fedora kernel: audit(1093087655.962:0): avc: denied > { read write } for pid=1 exe=/sbin/init path=/dev/console dev=ramfs > ino=847 scontext=system_u:system_r:init_t > tcontext=system_u:object_r:unlabeled_t tclass=chr_file > Aug 21 11:28:46 fedora kernel: audit(1093087655.962:0): avc: denied > { read } for pid=1 exe=/sbin/init path=/init dev=rootfs ino=17 > scontext=system_u:system_r:init_t > tcontext=system_u:object_r:unlabeled_t tclass=file > Aug 21 11:28:46 fedora kernel: audit(1093087655.963:0): avc: denied > { ioctl } for pid=1 exe=/sbin/init path=/dev/tty0 dev=ramfs ino=1126 > scontext=system_u:system_r:init_t > tcontext=system_u:object_r:unlabeled_t tclass=chr_file > Aug 21 11:28:46 fedora kernel: audit(1093087656.509:0): avc: denied > { write } for pid=1 exe=/sbin/init dev=ramfs ino=846 > scontext=system_u:system_r:init_t tcontext=system_u:object_r:ramfs_t > tclass=dir > Aug 21 11:28:46 fedora kernel: audit(1093087656.509:0): avc: denied > { add_name } for pid=1 exe=/sbin/init name=initctl > scontext=system_u:system_r:init_t tcontext=system_u:object_r:ramfs_t > tclass=dir > Aug 21 11:28:46 fedora kernel: audit(1093087656.509:0): avc: denied > { create } for pid=1 exe=/sbin/init name=initctl > scontext=system_u:system_r:init_t tcontext=system_u:object_r:ramfs_t > tclass=fifo_file > Aug 21 11:28:46 fedora kernel: audit(1093087656.509:0): avc: denied > { read write } for pid=1 exe=/sbin/init name=initctl dev=ramfs > ino=1787 scontext=system_u:system_r:init_t > tcontext=system_u:object_r:ramfs_t tclass=fifo_file > Aug 21 11:28:46 fedora kernel: audit(1093087656.509:0): avc: denied > { getattr } for pid=1 exe=/sbin/init path=/dev/initctl dev=ramfs > ino=1787 scontext=system_u:system_r:init_t > tcontext=system_u:object_r:ramfs_t tclass=fifo_file > Aug 21 11:28:46 fedora kernel: audit(1093087657.094:0): avc: denied > { read write } for pid=403 exe=/bin/hostname path=/dev/console > dev=ramfs ino=847 scontext=system_u:system_r:hostname_t > tcontext=system_u:object_r:unlabeled_t tclass=chr_file > Aug 21 11:28:46 fedora kernel: audit(1093087657.565:0): avc: denied > { read write } for pid=449 exe=/bin/mount path=/dev/console dev=ramfs > ino=847 scontext=system_u:system_r:mount_t > tcontext=system_u:object_r:unlabeled_t tclass=chr_file > Aug 21 11:28:46 fedora kernel: audit(1093087657.566:0): avc: denied > { search } for pid=449 exe=/bin/mount dev=ramfs ino=846 > scontext=system_u:system_r:mount_t tcontext=system_u:object_r:ramfs_t > tclass=dir > Aug 21 11:28:46 fedora kernel: audit(1093087657.640:0): avc: denied > { search } for pid=451 exe=/bin/bash dev=ramfs ino=846 > scontext=system_u:system_r:udev_t tcontext=system_u:object_r:ramfs_t > tclass=dir > Aug 21 11:28:46 fedora kernel: audit(1093087657.640:0): avc: denied > { read write } for pid=451 exe=/bin/bash name=tty dev=ramfs ino=1120 > scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:unlabeled_t tclass=chr_file > Aug 21 11:28:46 fedora kernel: audit(1093087657.898:0): avc: denied > { read write } for pid=513 exe=/sbin/consoletype path=/dev/console > dev=ramfs ino=847 scontext=system_u:system_r:consoletype_t > tcontext=system_u:object_r:unlabeled_t tclass=chr_file > Aug 21 11:28:46 fedora kernel: audit(1093087657.899:0): avc: denied > { getattr } for pid=513 exe=/sbin/consoletype path=/dev/console > dev=ramfs ino=847 scontext=system_u:system_r:consoletype_t > tcontext=system_u:object_r:unlabeled_t tclass=chr_file > Aug 21 11:28:46 fedora kernel: audit(1093087657.900:0): avc: denied > { ioctl } for pid=513 exe=/sbin/consoletype path=/dev/console > dev=ramfs ino=847 scontext=system_u:system_r:consoletype_t > tcontext=system_u:object_r:unlabeled_t tclass=chr_file > Aug 21 11:28:46 fedora kernel: audit(1093087658.598:0): avc: denied > { read write } for pid=536 exe=/sbin/minilogd path=/dev/null > dev=ramfs ino=848 scontext=system_u:system_r:syslogd_t > tcontext=system_u:object_r:unlabeled_t tclass=chr_file > Aug 21 11:28:46 fedora kernel: audit(1093087658.598:0): avc: denied > { use } for pid=536 exe=/sbin/minilogd path=/init dev=rootfs ino=17 > scontext=system_u:system_r:syslogd_t > tcontext=system_u:system_r:kernel_t tclass=fd > Aug 21 11:28:46 fedora kernel: audit(1093087658.598:0): avc: denied > { search } for pid=536 exe=/sbin/minilogd dev=ramfs ino=846 > scontext=system_u:system_r:syslogd_t > tcontext=system_u:object_r:ramfs_t tclass=dir > Aug 21 11:28:46 fedora kernel: audit(1093087658.599:0): avc: denied > { write } for pid=536 exe=/sbin/minilogd dev=ramfs ino=846 > scontext=system_u:system_r:syslogd_t > tcontext=system_u:object_r:ramfs_t tclass=dir > Aug 21 11:28:46 fedora kernel: audit(1093087658.599:0): avc: denied > { add_name } for pid=536 exe=/sbin/minilogd name=log > scontext=system_u:system_r:syslogd_t > tcontext=system_u:object_r:ramfs_t tclass=dir > Aug 21 11:28:46 fedora kernel: audit(1093087658.599:0): avc: denied > { create } for pid=536 exe=/sbin/minilogd name=log > scontext=system_u:system_r:syslogd_t > tcontext=system_u:object_r:ramfs_t tclass=sock_file > Aug 21 11:28:46 fedora kernel: audit(1093087658.599:0): avc: denied > { getattr } for pid=540 exe=/sbin/minilogd path=/dev/log dev=ramfs > ino=2057 scontext=system_u:system_r:syslogd_t > tcontext=system_u:object_r:ramfs_t tclass=sock_file > Aug 21 11:28:46 fedora kernel: audit(1093087658.614:0): avc: denied > { read write } for pid=538 exe=/sbin/udev name=.udev.tdb dev=ramfs > ino=855 scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:unlabeled_t tclass=file > Aug 21 11:28:46 fedora kernel: audit(1093087658.614:0): avc: denied > { lock } for pid=538 exe=/sbin/udev path=/dev/.udev.tdb dev=ramfs > ino=855 scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:unlabeled_t tclass=file > Aug 21 11:28:46 fedora kernel: audit(1093087658.614:0): avc: denied > { getattr } for pid=538 exe=/sbin/udev path=/dev/.udev.tdb dev=ramfs > ino=855 scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:unlabeled_t tclass=file > Aug 21 11:28:46 fedora kernel: audit(1093087658.665:0): avc: denied > { write } for pid=538 exe=/sbin/udev name=log dev=ramfs ino=2057 > scontext=system_u:system_r:udev_t tcontext=system_u:object_r:ramfs_t > tclass=sock_file > Aug 21 11:28:46 fedora kernel: audit(1093087658.666:0): avc: denied > { write } for pid=538 exe=/sbin/udev dev=ramfs ino=846 > scontext=system_u:system_r:udev_t tcontext=system_u:object_r:ramfs_t > tclass=dir > Aug 21 11:28:46 fedora kernel: audit(1093087658.666:0): avc: denied > { add_name } for pid=538 exe=/sbin/udev name=input > scontext=system_u:system_r:udev_t tcontext=system_u:object_r:ramfs_t > tclass=dir > Aug 21 11:28:46 fedora kernel: audit(1093087658.666:0): avc: denied > { create } for pid=538 exe=/sbin/udev name=input > scontext=system_u:system_r:udev_t tcontext=system_u:object_r:ramfs_t > tclass=dir > Aug 21 11:28:46 fedora kernel: audit(1093087658.679:0): avc: denied > { create } for pid=538 exe=/sbin/udev name=event0 > scontext=system_u:system_r:udev_t tcontext=system_u:object_r:ramfs_t > tclass=chr_file > Aug 21 11:28:46 fedora kernel: audit(1093087658.679:0): avc: denied > { setattr } for pid=538 exe=/sbin/udev name=event0 dev=ramfs ino=2069 > scontext=system_u:system_r:udev_t tcontext=system_u:object_r:ramfs_t > tclass=chr_file > Aug 21 11:28:46 fedora kernel: audit(1093087659.059:0): avc: denied > { read write } for pid=546 exe=/sbin/restorecon path=/dev/console > dev=ramfs ino=847 scontext=system_u:system_r:restorecon_t > tcontext=system_u:object_r:unlabeled_t tclass=chr_file > Aug 21 11:28:46 fedora kernel: audit(1093087659.061:0): avc: denied > { getattr } for pid=546 exe=/sbin/restorecon path=/dev/input/event0 > dev=ramfs ino=2069 scontext=system_u:system_r:restorecon_t > tcontext=system_u:object_r:ramfs_t tclass=chr_file > Aug 21 11:28:46 fedora kernel: audit(1093087659.226:0): avc: denied > { getattr } for pid=547 exe=/sbin/udev path=/dev/input dev=ramfs > ino=2066 scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:ramfs_t tclass=dir > Aug 21 11:28:46 fedora kernel: audit(1093087661.046:0): avc: denied > { write } for pid=540 exe=/sbin/minilogd name=log dev=ramfs ino=2057 > scontext=system_u:system_r:syslogd_t > tcontext=system_u:object_r:ramfs_t tclass=sock_file > Aug 21 11:28:46 fedora kernel: audit(1093087661.320:0): avc: denied > { getattr } for pid=568 exe=/sbin/udev path=/dev/full dev=ramfs > ino=883 scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:unlabeled_t tclass=chr_file > Aug 21 11:28:46 fedora kernel: audit(1093087661.320:0): avc: denied > { setattr } for pid=568 exe=/sbin/udev name=full dev=ramfs ino=883 > scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:unlabeled_t tclass=chr_file > Aug 21 11:28:46 fedora kernel: audit(1093087661.893:0): avc: denied > { create } for pid=596 exe=/sbin/udev name=XOR > scontext=system_u:system_r:udev_t tcontext=system_u:object_r:ramfs_t > tclass=lnk_file > Aug 21 11:28:46 fedora kernel: audit(1093087667.935:0): avc: denied > { remove_name } for pid=897 exe=/sbin/udev name=vcs1 dev=ramfs > ino=1564 scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:ramfs_t tclass=dir > Aug 21 11:28:46 fedora kernel: audit(1093087667.935:0): avc: denied > { unlink } for pid=897 exe=/sbin/udev name=vcs1 dev=ramfs ino=1564 > scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:unlabeled_t tclass=chr_file > Aug 21 11:28:46 fedora kernel: audit(1093087668.270:0): avc: denied > { unlink } for pid=919 exe=/sbin/udev name=vcsa1 dev=ramfs ino=2889 > scontext=system_u:system_r:udev_t tcontext=system_u:object_r:ramfs_t > tclass=chr_file > Aug 21 11:28:46 fedora kernel: audit(1093087679.159:0): avc: denied > { getattr } for pid=1476 exe=/sbin/udev path=/dev/vcs1 dev=ramfs > ino=3133 scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:ramfs_t tclass=chr_file > Aug 21 11:28:46 fedora kernel: audit(1093087679.590:0): avc: denied > { getattr } for pid=1497 exe=/sbin/udev path=/dev/hda dev=ramfs > ino=1582 scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:unlabeled_t tclass=blk_file > Aug 21 11:28:46 fedora kernel: audit(1093087679.590:0): avc: denied > { setattr } for pid=1497 exe=/sbin/udev name=hda dev=ramfs ino=1582 > scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:unlabeled_t tclass=blk_file > Aug 21 11:28:46 fedora kernel: audit(1093087682.418:0): avc: denied > { remove_name } for pid=1637 exe=/sbin/minilogd name=log dev=ramfs > ino=2057 scontext=system_u:system_r:syslogd_t > tcontext=system_u:object_r:ramfs_t tclass=dir > Aug 21 11:28:46 fedora kernel: audit(1093087682.418:0): avc: denied > { unlink } for pid=1637 exe=/sbin/minilogd name=log dev=ramfs > ino=2057 scontext=system_u:system_r:syslogd_t > tcontext=system_u:object_r:ramfs_t tclass=sock_file > Aug 21 11:28:46 fedora kernel: audit(1093087683.376:0): avc: denied > { read write } for pid=1836 exe=/bin/dmesg path=/dev/console > dev=ramfs ino=847 scontext=system_u:system_r:dmesg_t > tcontext=system_u:object_r:unlabeled_t tclass=chr_file > Aug 21 11:28:46 fedora kernel: audit(1093087683.406:0): avc: denied > { mounton } for pid=1837 exe=/bin/mount path=/dev/pts dev=ramfs > ino=850 scontext=system_u:system_r:mount_t > tcontext=system_u:object_r:unlabeled_t tclass=dir > Aug 21 11:28:46 fedora kernel: audit(1093087683.700:0): avc: denied > { read write } for pid=1849 exe=/sbin/hwclock path=/dev/console > dev=ramfs ino=847 scontext=system_u:system_r:hwclock_t > tcontext=system_u:object_r:unlabeled_t tclass=chr_file > Aug 21 11:28:46 fedora kernel: audit(1093087683.701:0): avc: denied > { search } for pid=1849 exe=/sbin/hwclock dev=ramfs ino=846 > scontext=system_u:system_r:hwclock_t > tcontext=system_u:object_r:ramfs_t tclass=dir > Aug 21 11:28:46 fedora kernel: audit(1093087683.701:0): avc: denied > { ioctl } for pid=1849 exe=/sbin/hwclock path=/dev/rtc dev=ramfs > ino=941 scontext=system_u:system_r:hwclock_t > tcontext=system_u:object_r:unlabeled_t tclass=chr_file > Aug 21 11:28:46 fedora kernel: ACPI: Power Button (FF) [PWRF] From selinux at comcast.net Sun Aug 22 00:29:54 2004 From: selinux at comcast.net (Tom London) Date: Sat, 21 Aug 2004 17:29:54 -0700 Subject: /dev/cpu/0/microcode....link mislabeled? Message-ID: <4127E902.6070407@comcast.net> I'm noticing the following messages showing up for the past few days (strict/enforcing): Aug 21 13:31:15 fedora kernel: audit(1093120250.606:0): avc: denied { read } for pid=1558 exe=/sbin/microcode_ctl name=microcode dev=hda2 ino=2689367 scontext=system_u:system_r:cpucontrol_t tcontext=system_u:object_r:device_t tclass=lnk_file Aug 21 13:31:15 fedora kernel: microcode: No new microdata for cpu 0 'ls -lZ /dev/cpu/0/microcode' yields: lrwxrwxrwx root root system_u:object_r:device_t /dev/cpu/0/microcode -> ../../microcode Does this link need to be labeled cpu_device_t, or does 'allow cpucontrol_t device_t:lnk_file { read };' need to be added to cpucontrol.te, or .... ? tom [I sort of remember this being fixed a while back .....] From russell at coker.com.au Sun Aug 22 09:07:46 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 22 Aug 2004 19:07:46 +1000 Subject: /dev/cpu/0/microcode....link mislabeled? In-Reply-To: <4127E902.6070407@comcast.net> References: <4127E902.6070407@comcast.net> Message-ID: <200408221907.46690.russell@coker.com.au> On Sun, 22 Aug 2004 10:29, Tom London wrote: > Aug 21 13:31:15 fedora kernel: audit(1093120250.606:0): avc: denied { > read } for pid=1558 exe=/sbin/microcode_ctl name=microcode dev=hda2 > ino=2689367 scontext=system_u:system_r:cpucontrol_t > tcontext=system_u:object_r:device_t tclass=lnk_file > Aug 21 13:31:15 fedora kernel: microcode: No new microdata for cpu 0 > > 'ls -lZ /dev/cpu/0/microcode' yields: > lrwxrwxrwx root root system_u:object_r:device_t > /dev/cpu/0/microcode -> ../../microcode > > Does this link need to be labeled cpu_device_t, or > does 'allow cpucontrol_t device_t:lnk_file { read };' need > to be added to cpucontrol.te, or .... ? Symbolic links under /dev should have type device_t. So an allow line such as the one you suggest should be added to the policy. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From russell at coker.com.au Sun Aug 22 09:42:15 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 22 Aug 2004 19:42:15 +1000 Subject: avcs from install of initscripts/kernel ? In-Reply-To: <41277E1F.2060403@comcast.net> References: <41277E1F.2060403@comcast.net> Message-ID: <200408221942.15922.russell@coker.com.au> On Sun, 22 Aug 2004 02:53, Tom London wrote: > Aug 21 09:43:36 fedora kernel: audit(1093106616.786:0): avc: denied { > dac_read_search } for pid=4292 exe=/bin/bash capability=2 > scontext=root:sysadm_r:bootloader_t tcontext=root:sysadm_r:bootloader_t > tclass=capability No harm in adding this as capability chown is already granted. > Aug 21 09:43:37 fedora kernel: audit(1093106617.979:0): avc: denied { > transition } for pid=4331 exe=/bin/bash path=/sbin/dmsetup dev=hda2 > ino=2310451 scontext=root:sysadm_r:bootloader_t > tcontext=root:system_r:lvm_t tclass=process The constraints file has the following (I've cut bits about crond and userhelper for clarity): constrain process transition ( r1 == r2 or ( t1 == privrole and t2 == userdomain ) or (t1 == priv_system_role and r2 == system_r ) ); We have the following policy from global_macros.te: role_transition sysadm_r lvm_exec_t system_r; This causes the tcontext to have role system_r, and by the constraint we have to have the attribute priv_system_role on the source domain (bootloader_t). I've attached a patch to bootloader.te that fixes these things and a couple of other minor issues. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -------------- next part -------------- A non-text attachment was scrubbed... Name: diff Type: text/x-diff Size: 1494 bytes Desc: not available URL: From russell at coker.com.au Sun Aug 22 11:25:38 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 22 Aug 2004 21:25:38 +1000 Subject: Fedora and udev Message-ID: <200408222125.38169.russell@coker.com.au> It seems that udev is now virtually mandatory as of the latest rawhide update. udev uses ramfs for /tmp, ramfs (as of the latest Fedora kernel 2.6.8-1.525) has no support for file labelling and breaks everything. Can we get ramfs labelling working in the next few days or do we have to change things to not depend on udev? -- 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 aoliva at redhat.com Sun Aug 22 14:00:50 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 22 Aug 2004 11:00:50 -0300 Subject: Fedora and udev In-Reply-To: <200408222125.38169.russell@coker.com.au> References: <200408222125.38169.russell@coker.com.au> Message-ID: On Aug 22, 2004, Russell Coker wrote: > It seems that udev is now virtually mandatory as of the latest > rawhide update. This is what makes it, like, mandatory: /etc/udev/udev.conf: UDEV_INITRD="yes" Change it to `no' and hopefully everything will work again. It breaks more than SELinux. -- 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 dennis at ausil.us Sun Aug 22 14:57:29 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 22 Aug 2004 09:57:29 -0500 Subject: Fedora and udev In-Reply-To: References: <200408222125.38169.russell@coker.com.au> Message-ID: <200408220957.35639.dennis@ausil.us> Once upon a time Sunday 22 August 2004 9:00 am, Alexandre Oliva wrote: > On Aug 22, 2004, Russell Coker wrote: > > It seems that udev is now virtually mandatory as of the latest > > rawhide update. > > This is what makes it, like, mandatory: > > /etc/udev/udev.conf: > UDEV_INITRD="yes" it likes to chew cpu time as well. i have had to disable it completly Dennis From russell at coker.com.au Mon Aug 23 02:09:01 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 23 Aug 2004 12:09:01 +1000 Subject: Fedora and udev In-Reply-To: References: <200408222125.38169.russell@coker.com.au> Message-ID: <200408231209.01521.russell@coker.com.au> On Mon, 23 Aug 2004 00:00, Alexandre Oliva wrote: > On Aug 22, 2004, Russell Coker wrote: > > It seems that udev is now virtually mandatory as of the latest > > rawhide update. > > This is what makes it, like, mandatory: > > /etc/udev/udev.conf: > UDEV_INITRD="yes" > > Change it to `no' and hopefully everything will work again. It breaks > more than SELinux. Thanks for that advice. Once I looked at that I noticed that there's an option UDEV_RAMFS in the same file which must be set to "no". I'm not sure whether UDEV_RAMFS="no" would allow it to work on SE Linux with UDEV_INITRD="yes" but don't have any plans to test this at the moment. We either need to get ramfs working in the Fedora kernels or make some changes to the udev plans. One option would be to use an ext2 file system on a ram disk for udev. It would do all the same stuff as ramfs (at a slightly higher memory cost) and work perfectly with SE Linux. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From jmorris at redhat.com Mon Aug 23 02:33:34 2004 From: jmorris at redhat.com (James Morris) Date: Sun, 22 Aug 2004 22:33:34 -0400 (EDT) Subject: Fedora and udev In-Reply-To: <200408222125.38169.russell@coker.com.au> Message-ID: On Sun, 22 Aug 2004, Russell Coker wrote: > Can we get ramfs labelling working in the next few days or do we have to > change things to not depend on udev? I'm working on some upstream kernel patches. - James -- James Morris From mike at flyn.org Mon Aug 23 04:01:31 2004 From: mike at flyn.org (W. Michael Petullo) Date: Sun, 22 Aug 2004 23:01:31 -0500 Subject: Fedora and udev In-Reply-To: References: <200408222125.38169.russell@coker.com.au> Message-ID: <20040823040131.GA5542@imp.flyn.org> >> Can we get ramfs labelling working in the next few days or do we have to >> change things to not depend on udev? > > I'm working on some upstream kernel patches. Ramfs/udev does not support SELinux EA's: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130619 -- Mike :wq From jmorris at redhat.com Mon Aug 23 05:40:10 2004 From: jmorris at redhat.com (James Morris) Date: Mon, 23 Aug 2004 01:40:10 -0400 (EDT) Subject: Fedora and udev In-Reply-To: <20040823040131.GA5542@imp.flyn.org> Message-ID: On Sun, 22 Aug 2004, W. Michael Petullo wrote: > >> Can we get ramfs labelling working in the next few days or do we have to > >> change things to not depend on udev? > > > > I'm working on some upstream kernel patches. > > Ramfs/udev does not support SELinux EA's: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130619 That is the purpose of the patches, to provide support. They're currently being reviewed. - James -- James Morris From russell at coker.com.au Mon Aug 23 06:47:21 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 23 Aug 2004 16:47:21 +1000 Subject: udev strange-ness Message-ID: <200408231647.21379.russell@coker.com.au> Why is bash accessing iptables, and arping on behalf of udev? I expect that the dhclient-eth0.conf file is just from an inherited file handle (although I don't know why it was opened, I don't have dhclient installed any more, maybe a bug in hotplug). audit(1093243252.247:0): avc: denied { getattr } for pid=2193 exe=/bin/bash path=/sbin/iptables dev=dm-0 ino=196433 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:iptables_exec_t tclass=file audit(1093243252.280:0): avc: denied { write } for pid=2113 exe=/bin/bash name=dhclient-eth0.conf dev=dm-0 ino=572328 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:dhcp_etc_t tclass=file audit(1093243252.299:0): avc: denied { getattr } for pid=2113 exe=/bin/bash path=/sbin/arping dev=dm-0 ino=196244 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:netutils_exec_t tclass=file audit(1093243252.300:0): avc: denied { getattr } for pid=2113 exe=/bin/bash path=/sbin/arping dev=dm-0 ino=196244 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:netutils_exec_t tclass=file -- 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 Mon Aug 23 13:04:44 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 23 Aug 2004 09:04:44 -0400 Subject: Fedora and udev In-Reply-To: <4128BBE6.6050207@tresys.com> References: <200408222125.38169.russell@coker.com.au> <20040822144016.GA13842@lkcl.net> <4128BBE6.6050207@tresys.com> Message-ID: <1093266284.27211.32.camel@moss-spartans.epoch.ncsc.mil> On Sun, 2004-08-22 at 11:29, Joshua Brindle wrote: > When we were experimenting with udev it only took ramfs xattr support, > add ramfs to fs_use as an xattr filesystem and set up udev with selinux > support. When it runs it creates the nodes and then labels them via the > libselinux api which reads file_contexts. Aside from the problems I've > already mentioned there should be no problems running udev. > > If the tmpfs context support is something different from this then it > should not be used (I have not looked at tmpfs support at all but have > personal experience that ramfs xattr works as expected). tmpfs is preferable to ramfs, as tmpfs uses swap and honors resource limits. But separate tmpfs instances can be used for diverse purposes by userspace (/tmp, /dev, /dev/shm) and a tmpfs instance is always used internally by the kernel for shared memory, so we want to be able to assign different filesystem security contexts to different tmpfs instances. That requires extending fscontext= support to it, so that we can specify the context on a per-mount basis. -- Stephen Smalley National Security Agency From russell at coker.com.au Mon Aug 23 13:44:23 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 23 Aug 2004 23:44:23 +1000 Subject: glibc post upgrade Message-ID: <200408232344.23345.russell@coker.com.au> avc: denied { search } for pid=3019 exe=/usr/sbin/glibc_post_upgrade name=1 dev=proc ino=65538 scontext=root:sysadm_r:rpm_t tcontext=system_u:system_r:init_t tclass=dir Jeff, it seems that the glibc post upgrade script run when a new glibc package is installed gets run as rpm_t not rpm_script_t. Do you have any ideas why this is? -- 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 Mon Aug 23 13:52:23 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 23 Aug 2004 09:52:23 -0400 Subject: glibc post upgrade In-Reply-To: <200408232344.23345.russell@coker.com.au> References: <200408232344.23345.russell@coker.com.au> Message-ID: <1093269143.27211.50.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2004-08-23 at 09:44, Russell Coker wrote: > avc: denied { search } for pid=3019 exe=/usr/sbin/glibc_post_upgrade name=1 > dev=proc ino=65538 scontext=root:sysadm_r:rpm_t > tcontext=system_u:system_r:init_t tclass=dir > > Jeff, it seems that the glibc post upgrade script run when a new glibc package > is installed gets run as rpm_t not rpm_script_t. Do you have any ideas why > this is? The same issue came up with regard to the restarting of sshd by glibc_post_upgrade; that was leaving sshd in rpm_t until I added a direct transition from rpm_t to the policy. At that time, Jeff said that rpm is only running shell interpreters in rpm_script_t, not executable helper programs like glibc_post_upgrade. I think that should be changed; any commands executed from the package spec file should be run in rpm_script_t (but note that this may require changes to the policy to allow entrypoint permission between rpm_script_t and other executable types). -- Stephen Smalley National Security Agency From selinux at comcast.net Mon Aug 23 15:31:12 2004 From: selinux at comcast.net (Tom London) Date: Mon, 23 Aug 2004 08:31:12 -0700 Subject: latest policy: in.comsat, dbskkd-cdb, ktalkd, ... Message-ID: <412A0DC0.8070006@comcast.net> Latest Rawhide policy seems to 'reverse the labeling' of programs started from xinetd, like in.comsat, ... (strict/enforcing) tom Aug 23 08:20:16 fedora kernel: audit(1093274416.210:0): avc: denied { execute } for pid=2505 exe=/usr/sbin/xinetd name=in.comsat dev=hda2 ino=4123335 scontext=system_u:system_r:inetd_t tcontext=system_u:object_r:sbin_t tclass=file Aug 23 08:20:16 fedora xinetd[2505]: Server /usr/sbin/in.comsat is not executable [file=/etc/xinetd.d/comsat] [line=9] Aug 23 08:20:16 fedora xinetd[2505]: Error parsing attribute server - DISABLING SERVICE [file=/etc/xinetd.d/comsat] [line=9] Aug 23 08:20:16 fedora ntpd: succeeded Aug 23 08:20:16 fedora kernel: audit(1093274416.397:0): avc: denied { execute } for pid=2505 exe=/usr/sbin/xinetd name=dbskkd-cdb dev=hda2 ino=4119210 scontext=system_u:system_r:inetd_t tcontext=system_u:object_r:sbin_t tclass=file Aug 23 08:20:16 fedora xinetd[2505]: Server /usr/sbin/dbskkd-cdb is not executable [file=/etc/xinetd.d/dbskkd-cdb] [line=12] Aug 23 08:20:16 fedora xinetd[2505]: Error parsing attribute server - DISABLING SERVICE [file=/etc/xinetd.d/dbskkd-cdb] [line=12] Aug 23 08:20:16 fedora kernel: audit(1093274416.614:0): avc: denied { execute } for pid=2505 exe=/usr/sbin/xinetd name=ktalkd dev=hda2 ino=4122498 scontext=system_u:system_r:inetd_t tcontext=system_u:object_r:bin_t tclass=file Aug 23 08:20:16 fedora xinetd[2505]: Server /usr/bin/ktalkd is not executable [file=/etc/xinetd.d/ktalk] [line=11] Aug 23 08:20:16 fedora xinetd[2505]: Error parsing attribute server - DISABLING SERVICE [file=/etc/xinetd.d/ktalk] [line=11] Aug 23 08:20:16 fedora kernel: audit(1093274416.869:0): avc: denied { execute } for pid=2505 exe=/usr/sbin/xinetd name=rsync dev=hda2 ino=426723 scontext=system_u:system_r:inetd_t tcontext=system_u:object_r:bin_t tclass=file Aug 23 08:20:16 fedora xinetd[2505]: Server /usr/bin/rsync is not executable [file=/etc/xinetd.d/rsync] [line=10] Aug 23 08:20:16 fedora xinetd[2505]: Error parsing attribute server - DISABLING SERVICE [file=/etc/xinetd.d/rsync] [line=10] Aug 23 08:20:16 fedora kernel: audit(1093274416.935:0): avc: denied { execute } for pid=2505 exe=/usr/sbin/xinetd name=swat dev=hda2 ino=279060 scontext=system_u:system_r:inetd_t tcontext=system_u:object_r:sbin_t tclass=file Aug 23 08:20:16 fedora xinetd[2505]: Server /usr/sbin/swat is not executable [file=/etc/xinetd.d/swat] [line=12] Aug 23 08:20:16 fedora xinetd[2505]: Error parsing attribute server - DISABLING SERVICE [file=/etc/xinetd.d/swat] [line=12] From selinux at comcast.net Mon Aug 23 15:34:11 2004 From: selinux at comcast.net (Tom London) Date: Mon, 23 Aug 2004 08:34:11 -0700 Subject: rpc.mountd failure... Message-ID: <412A0E73.5020001@comcast.net> Noticed the following, running .524 kernel and latest policy from Rawhide. tom > Aug 23 08:20:18 fedora nfs: Starting NFS services: succeeded > Aug 23 08:20:18 fedora nfs: rpc.rquotad startup succeeded > Aug 23 08:20:18 fedora nfs: rpc.nfsd startup succeeded > Aug 23 08:20:18 fedora kernel: audit(1093274418.647:0): avc: denied > { name_bind } for pid=2564 exe=/usr/sbin/rpc.mountd > scontext=system_u:system_r:nfsd_t > tcontext=system_u:object_r:ipp_port_t tclass=udp_socket > Aug 23 08:20:18 fedora portmap[2565]: connect from 127.0.0.1 to > set(mountd): request from unprivileged port > Aug 23 08:20:18 fedora rpc.mountd: unable to register (mountd, 3, udp). > Aug 23 08:20:18 fedora nfs: rpc.mountd startup failed > Aug 23 08:20:18 fedora rpcidmapd: rpc.idmapd -SIGHUP succeeded From selinux at comcast.net Mon Aug 23 15:49:21 2004 From: selinux at comcast.net (Tom London) Date: Mon, 23 Aug 2004 08:49:21 -0700 Subject: hald startup ? Message-ID: <412A1201.7050006@comcast.net> When hald starts (strict/enforcing) I get the following avc: Aug 23 08:20:29 fedora messagebus: messagebus startup succeeded Aug 23 08:20:29 fedora kernel: audit(1093274429.575:0): avc: denied { create } for pid=2796 exe=/usr/sbin/hald scontext=system_u:system_r:hald_t tcontext=system_u:system_r:hald_t tclass=unix_dgram_socket hald appears to die quietly. Is this needed, or are my problems with hald unrelated..... tom From selinux at comcast.net Mon Aug 23 15:54:42 2004 From: selinux at comcast.net (Tom London) Date: Mon, 23 Aug 2004 08:54:42 -0700 Subject: mdmpd.... Message-ID: <412A1342.6020500@comcast.net> Each time mdmpd tries to start, I get this: Aug 23 08:20:32 fedora kernel: audit(1093274432.627:0): avc: denied { write } for pid=2901 exe=/sbin/mdmpd name=mdstat dev=proc ino=-268435099 scontext=system_u:system_r:mdadm_t tcontext=system_u:object_r:proc_t tclass=file Aug 23 08:20:32 fedora mdmpd: Failed to open /proc/mdstat Aug 23 08:20:32 fedora mdmpd: mdmpd startup failed Aug 23 08:20:32 fedora mdmpd: mdmpd failed Does this need to be added? (Sorry, I don't know how mdmpd is doing its thing....) tom [This seems to be an 'old' avc, not related to recent policy changes.] From binabin at libero.it Mon Aug 23 16:04:14 2004 From: binabin at libero.it (binabin at libero.it) Date: Mon, 23 Aug 2004 18:04:14 +0200 Subject: my first steps in Fedora Message-ID: hello everyone, i am a new user of Fedora core 2, and a newer of linux-like OS as well. 2 days ago i installed Fedora on my notebook: acer travel mate 212T. i already have some problems that i can't solve: 1) Can't change the Screen resolution when i installed the OS, my screen hadn't been recognized, so i chose "generic LCD monitor" with a resolution of 800x600. once installed, i changed my mind and i wanted to switch into 1024x768 (supported by my hardware, for sure). to do that, i opened the Display window, from System Settings menu icon. here i configured a generic LCD panel with 1024x768 resolution from the Hardware folder and rebooted the PC. then, in the display window i had the possibility to choose the wanted resolution. doing that and rebooting i can see 1024x768 as the selected screen resolution, but looking at the screen things haven't changed: i always have the old 800x600. what should i do? 2)Touch pad the touch pad of my pc is correctly working, even if the click must be done pressing the left button and can't be done with the "touch". i can't find where i can configure or change the settings of my touch pad. can i? thanks in advance for your help. regards, Pietro From sds at epoch.ncsc.mil Mon Aug 23 16:04:31 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 23 Aug 2004 12:04:31 -0400 Subject: latest policy: in.comsat, dbskkd-cdb, ktalkd, ... In-Reply-To: <412A0DC0.8070006@comcast.net> References: <412A0DC0.8070006@comcast.net> Message-ID: <1093277071.27211.114.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2004-08-23 at 11:31, Tom London wrote: > Latest Rawhide policy seems to 'reverse the labeling' of programs > started from xinetd, like in.comsat, ... (strict/enforcing) inetd.fc entries removed at Russell's request, as the inetd_child_t domain wasn't sufficient anyway to allow those programs to run properly, and labeling them inetd_child_exec_t merely masked the lack of proper security domains for those programs and encouraged bleeding permissions into inetd_child_t. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Mon Aug 23 16:23:18 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 23 Aug 2004 12:23:18 -0400 Subject: mdmpd.... In-Reply-To: <412A1342.6020500@comcast.net> References: <412A1342.6020500@comcast.net> Message-ID: <1093278197.27211.129.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2004-08-23 at 11:54, Tom London wrote: > Each time mdmpd tries to start, I get this: > > Aug 23 08:20:32 fedora kernel: audit(1093274432.627:0): avc: denied { > write } > for pid=2901 exe=/sbin/mdmpd name=mdstat dev=proc ino=-268435099 > scontext=system_u:system_r:mdadm_t tcontext=system_u:object_r:proc_t > tclass=file > Aug 23 08:20:32 fedora mdmpd: Failed to open /proc/mdstat > Aug 23 08:20:32 fedora mdmpd: mdmpd startup failed > Aug 23 08:20:32 fedora mdmpd: mdmpd failed > > Does this need to be added? (Sorry, I don't know how mdmpd is > doing its thing....) > tom > > [This seems to be an 'old' avc, not related to recent policy changes.] /proc/mdstat presently only supports reading anyway. But I see that there is a patch pending to allow writes, see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117498. -- Stephen Smalley National Security Agency From n3npq at nc.rr.com Mon Aug 23 16:56:06 2004 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 23 Aug 2004 12:56:06 -0400 Subject: glibc post upgrade In-Reply-To: <200408232344.23345.russell@coker.com.au> References: <200408232344.23345.russell@coker.com.au> Message-ID: <412A21A6.7040203@nc.rr.com> Russell Coker wrote: >avc: denied { search } for pid=3019 exe=/usr/sbin/glibc_post_upgrade name=1 >dev=proc ino=65538 scontext=root:sysadm_r:rpm_t >tcontext=system_u:system_r:init_t tclass=dir > >Jeff, it seems that the glibc post upgrade script run when a new glibc package >is installed gets run as rpm_t not rpm_script_t. Do you have any ideas why >this is? > > > Yes, rpm_script_t is applied only for /bin/sh, not for other helpers like /sbin/ldconfig, and /usr/sbin/{glibc,libgcc}_post_upgrade, to name the other known helpers. I can certainly change that behavior, and have asked several times if I should, with no answer. 73 de Jeff From sds at epoch.ncsc.mil Mon Aug 23 17:21:16 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 23 Aug 2004 13:21:16 -0400 Subject: glibc post upgrade In-Reply-To: <412A21A6.7040203@nc.rr.com> References: <200408232344.23345.russell@coker.com.au> <412A21A6.7040203@nc.rr.com> Message-ID: <1093281676.27211.159.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2004-08-23 at 12:56, Jeff Johnson wrote: > Yes, rpm_script_t is applied only for /bin/sh, not for other helpers > like /sbin/ldconfig, and > /usr/sbin/{glibc,libgcc}_post_upgrade, to name the other known helpers. > > I can certainly change that behavior, and have asked several times if I > should, with no answer. I think it should change. For now, I'd say just use rpm_script_t for all commands executed from the scriptlets specified in the spec file, whether run via an interpreter or as a direct executable. Note that on the policy side, the domain_trans(rpm_t, shell_exec_t, rpm_script_t) rule should be changed to include any of the possible entrypoint types. However, it should work even without that change in the Fedora policy, because the unlimitedRPM tunable is enabled by default. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Mon Aug 23 18:27:13 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 23 Aug 2004 14:27:13 -0400 Subject: glibc post upgrade In-Reply-To: <1093281676.27211.159.camel@moss-spartans.epoch.ncsc.mil> References: <200408232344.23345.russell@coker.com.au> <412A21A6.7040203@nc.rr.com> <1093281676.27211.159.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <412A3701.2020401@redhat.com> Stephen Smalley wrote: >On Mon, 2004-08-23 at 12:56, Jeff Johnson wrote: > > >>Yes, rpm_script_t is applied only for /bin/sh, not for other helpers >>like /sbin/ldconfig, and >>/usr/sbin/{glibc,libgcc}_post_upgrade, to name the other known helpers. >> >>I can certainly change that behavior, and have asked several times if I >>should, with no answer. >> >> > >I think it should change. For now, I'd say just use rpm_script_t for >all commands executed from the scriptlets specified in the spec file, >whether run via an interpreter or as a direct executable. Note that on >the policy side, the domain_trans(rpm_t, shell_exec_t, rpm_script_t) >rule should be changed to include any of the possible entrypoint types. >However, it should work even without that change in the Fedora policy, >because the unlimitedRPM tunable is enabled by default. > > > I agree, make the change. Dan From katzj at redhat.com Mon Aug 23 18:49:12 2004 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 23 Aug 2004 14:49:12 -0400 Subject: Fedora and udev In-Reply-To: <200408231209.01521.russell@coker.com.au> References: <200408222125.38169.russell@coker.com.au> <200408231209.01521.russell@coker.com.au> Message-ID: <1093286952.4101.47.camel@bree.local.net> On Mon, 2004-08-23 at 12:09 +1000, Russell Coker wrote: > Thanks for that advice. Once I looked at that I noticed that there's an > option UDEV_RAMFS in the same file which must be set to "no". I'm not sure > whether UDEV_RAMFS="no" would allow it to work on SE Linux with > UDEV_INITRD="yes" but don't have any plans to test this at the moment. > > We either need to get ramfs working in the Fedora kernels or make some changes > to the udev plans. > > One option would be to use an ext2 file system on a ram disk for udev. It > would do all the same stuff as ramfs (at a slightly higher memory cost) and > work perfectly with SE Linux. It has a number of other, not really desired side effects as well. 1) Kernel people don't really like ramdisks anymore 2) Doing this requires mke2fs in the initramfs. Bleah. 3) It puts an artificial cap on the size of your /dev that then has to be adjustable. And the cap is related to an overhead of memory usage. This is ugly to get "right" Jeremy From vineetbillorey at yahoo.com Sun Aug 8 17:35:17 2004 From: vineetbillorey at yahoo.com (Vineet Billorey) Date: Sun, 08 Aug 2004 17:35:17 -0000 Subject: booting fedora core 2 Message-ID: <20040808173509.33901.qmail@web11202.mail.yahoo.com> Respected Sir, i recently installed fedora core 2 in my machine(celeron 1.7, 128mb ram). it installed completey but afterewards it simply shows a grub prompt which does not do anything. also grub.conf file is not available. kinldy guide me immediately. vineetbillorey at yahoo.com __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail From binabin at libero.it Fri Aug 20 07:49:22 2004 From: binabin at libero.it (Pietro R.A. Binetti) Date: Fri, 20 Aug 2004 09:49:22 +0200 Subject: new Fedora user asks help Message-ID: <1092988161.2519.20.camel@localhost.localdomain> hello everyone, i am a new user of Fedora core 2, and a newer of linux-like OS as well. 2 days ago i installed Fedora on my notebook: acer travel mate 212T. i already have some problems that i can't solve: 1) Can't change the Screen resolution when i installed the OS, my screen hadn't been recognized, so i chose "generic LCD monitor" with a resolution of 800x600. once installed, i changed my mind and i wanted to switch into 1024x768 (supported by my hardware, for sure). to do that, i opened the Display window, from System Settings menu icon. here i configured a generic LCD panel with 1024x768 resolution from the Hardware folder and rebooted the PC. then, in the display window i had the possibility to choose the wanted resolution. doing that and rebooting i can see 1024x768 as the selected screen resolution, but looking at the screen things haven't changed: i always have the old 800x600. what should i do? 2)Touch pad the touch pad of my pc is correctly working, even if the click must be done pressing the left button and can't be done with the "touch". i can't find where i can configure or change the settings of my touch pad. can i? thanks in advance for your help. regards, Pietro -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkcl at lkcl.net Sun Aug 22 14:40:16 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 22 Aug 2004 15:40:16 +0100 Subject: Fedora and udev In-Reply-To: <200408222125.38169.russell@coker.com.au> References: <200408222125.38169.russell@coker.com.au> Message-ID: <20040822144016.GA13842@lkcl.net> On Sun, Aug 22, 2004 at 09:25:38PM +1000, Russell Coker wrote: > It seems that udev is now virtually mandatory as of the latest rawhide update. > > udev uses ramfs for /tmp, ramfs (as of the latest Fedora kernel 2.6.8-1.525) > has no support for file labelling and breaks everything. > > Can we get ramfs labelling working in the next few days or do we have to > change things to not depend on udev? chris pebenito of gentoo/hardened i believe has written a ramfs patch already (2.6.6) it was what i based the shmfs one off of. or maybe that's the other way round, i dunno. can't remember. remember that just getting ramfs / tmpfs working is not enough, you must also: - patch selinux/hooks.c to allow mount -o fscontext=system_u:object_r:device_t on a tmpfs or shmfs or add an extra option to hooks.c _similar_ to fscontext but without the bit that says "stop if this filesystem supports xattrs". - modify /etc/init.d/udev to then mount /dev with the default context of device_t which whill FAIL if you DO NOT patch hooks.c as above: mount -n -o fscontext=system_u:object_r:device_t,size=$tmpfs_size,mode=0755 -t tmpfs none /dev - add in an equivalent of my extra post-udev-and-hotplug duplicate of /etc/init.d/modutils that will load things like nvidia, ppp_generic and stuff that are not yet fully 2.6-compliant drivers (i.e. they don't grok /sys and consequently don't generate hotplug events) . i assume that rawhide, given that it is using udev already, is perfectly capable of doing a proper and far superior job to what i have hacked up. - run a restorecon on ALL DEVICE NODES CREATED PRIOR TO /etc/init.d/udev RUNNING. i got bored of doing this regularly and manually and so wrote a small script (/sbin/restoredevicefiles) which does this for me. badly. it uses ls (really must use commands NOT from /usr and must use commands that DO NOT a require /dev/null or access to /dev/fd/*) i believe i had to copy cut from /usr/bin/cut to /bin/cut (!!) hey there are probably people out there who could do this as c-code or with sed or something more appropriate, to be honest i haven't got time to DoItRight(tm) so the ItWorksForMe(tm) approach is fine for me until _someone else_ does the DoItRight(tm) approach. - udev, udevd _and_ udevsend (_why_ is udev split into three separate programs??????) _all_ need to be hacked up to run setfiles -q -s on a pipe which udev(d?) will communicate the name of the inode to. russell advised me that using popen would be suitable for this: however i am not sure whether it should be put in udev or in udevd and i haven't the TimeRightNow(tm) to focus on MakingItNice(tm) alternatively, a patch (also attached) to add selinux "restorecon" stuff to udevsend is included which, although it still has a 1/4 second delay per inode added, at least works. patch is against udev-0.030. udev-0.030 has had the /etc/udev.d/default/selinux script removed which is a complete pain but hey, if linux-hotplug-devel say it don't work, it don't work. it's taken me about three maybe four weeks to get this hacked up to a working / reasonably acceptable (for me at least) point. i'm assuming that you would like the kernel patches: if you would like me to place a copy of my hacked-up policy files at hands.com/~lkcl/selinux please let me know because they are not very pretty but will save you a lot of time: because i don't know any better it has taken me somewhere in excess of 100 reboots to get a working udev-tmpfs-enabled policy plus initscripts hacks. if someone can inform me of the appropriate cvs-based diff command that will allow me to include fs/ramfs/xattr.c and fs/ramfs/xattr-security.c in the patch i would be most grateful, otherwise people will just have to manually blat those two files (attached) into the appropriate locations. i'd _really_ appreciate it if people _could_ say "hey, yes, we really need tmpfs-enabled udev in fc" because then i wouldn't have so much crap hanging around on my debian/selinux system: i'd far rather it had already been done and i could have copied or relied on the work of more experienced individuals. l. -------------- next part -------------- Index: fs/Kconfig =================================================================== RCS file: /cvsroot/selinux/nsa/linux-2.6/fs/Kconfig,v retrieving revision 1.8 diff -u -u -r1.8 Kconfig --- fs/Kconfig 18 Jun 2004 20:37:21 -0000 1.8 +++ fs/Kconfig 22 Aug 2004 14:06:10 -0000 @@ -925,6 +925,27 @@ See for details. +config TMPFS_FS_XATTR + bool "tmpfs Extended Attributes" + help + Extended attributes are name:value pairs associated with inodes by + the kernel or by users (see the attr(5) manual page, or visit + for details). + + If unsure, say N. + +config TMPFS_FS_SECURITY + bool "tmpfs Security Labels" + depends on TMPFS_FS_XATTR + help + Security labels support alternative access control models + implemented by security modules like SELinux. This option + enables an extended attribute handler for file security + labels in the tmpfs filesystem. + + If you are not using a security module that requires using + extended attributes for file security labels, say N. + config HUGETLBFS bool "HugeTLB file system support" depends X86 || IA64 || PPC64 || SPARC64 || SUPERH || X86_64 || BROKEN Index: fs/ramfs/Makefile =================================================================== RCS file: /cvsroot/selinux/nsa/linux-2.6/fs/ramfs/Makefile,v retrieving revision 1.1.1.1 diff -u -u -r1.1.1.1 Makefile --- fs/ramfs/Makefile 14 Aug 2003 12:08:40 -0000 1.1.1.1 +++ fs/ramfs/Makefile 22 Aug 2004 14:06:10 -0000 @@ -5,3 +5,6 @@ obj-$(CONFIG_RAMFS) += ramfs.o ramfs-objs := inode.o +ramfs-$(CONFIG_RAMFS_FS_XATTR) += xattr.o +ramfs-$(CONFIG_RAMFS_FS_SECURITY) += xattr_security.o + Index: fs/ramfs/inode.c =================================================================== RCS file: /cvsroot/selinux/nsa/linux-2.6/fs/ramfs/inode.c,v retrieving revision 1.1.1.4 diff -u -u -r1.1.1.4 inode.c --- fs/ramfs/inode.c 18 Jun 2004 19:30:21 -0000 1.1.1.4 +++ fs/ramfs/inode.c 22 Aug 2004 14:06:11 -0000 @@ -31,6 +31,7 @@ #include #include #include +#include "xattr.h" #include @@ -157,6 +158,10 @@ static struct inode_operations ramfs_file_inode_operations = { .getattr = simple_getattr, + .setxattr = ramfs_setxattr, + .getxattr = ramfs_getxattr, + .listxattr = ramfs_listxattr, + .removexattr = ramfs_removexattr, }; static struct inode_operations ramfs_dir_inode_operations = { @@ -169,6 +174,10 @@ .rmdir = simple_rmdir, .mknod = ramfs_mknod, .rename = simple_rename, + .setxattr = ramfs_setxattr, + .getxattr = ramfs_getxattr, + .listxattr = ramfs_listxattr, + .removexattr = ramfs_removexattr, }; static struct super_operations ramfs_ops = { @@ -224,12 +233,17 @@ static int __init init_ramfs_fs(void) { + int err = init_ramfs_xattr(); + if (err) + return err; + return register_filesystem(&ramfs_fs_type); } static void __exit exit_ramfs_fs(void) { unregister_filesystem(&ramfs_fs_type); + exit_ramfs_xattr(); } module_init(init_ramfs_fs) Index: mm/Makefile =================================================================== RCS file: /cvsroot/selinux/nsa/linux-2.6/mm/Makefile,v retrieving revision 1.1.1.4 diff -u -u -r1.1.1.4 Makefile --- mm/Makefile 18 Jun 2004 19:31:02 -0000 1.1.1.4 +++ mm/Makefile 22 Aug 2004 14:06:12 -0000 @@ -15,3 +15,6 @@ obj-$(CONFIG_SWAP) += page_io.o swap_state.o swapfile.o obj-$(CONFIG_HUGETLBFS) += hugetlb.o obj-$(CONFIG_NUMA) += mempolicy.o + +obj-$(CONFIG_TMPFS_FS_XATTR) += xattr.o +obj-$(CONFIG_TMPFS_FS_SECURITY) += xattr_security.o Index: mm/shmem.c =================================================================== RCS file: /cvsroot/selinux/nsa/linux-2.6/mm/shmem.c,v retrieving revision 1.1.1.8 diff -u -u -r1.1.1.8 shmem.c --- mm/shmem.c 18 Jun 2004 19:31:03 -0000 1.1.1.8 +++ mm/shmem.c 22 Aug 2004 14:06:12 -0000 @@ -44,6 +44,8 @@ #include #include +#include "xattr.h" + /* This magic number is used in glibc for posix shared memory */ #define TMPFS_MAGIC 0x01021994 @@ -168,6 +170,8 @@ static struct file_operations shmem_file_operations; static struct inode_operations shmem_inode_operations; static struct inode_operations shmem_dir_inode_operations; +static struct inode_operations shmfs_special_inode_operations; +static struct inode_operations shmem_symlink_inode_operations; static struct vm_operations_struct shmem_vm_ops; static struct backing_dev_info shmem_backing_dev_info = { @@ -1212,6 +1216,7 @@ mpol_shared_policy_init(&info->policy); switch (mode & S_IFMT) { default: + inode->i_op = &shmfs_special_inode_operations; init_special_inode(inode, mode, dev); break; case S_IFREG: @@ -1229,6 +1234,7 @@ inode->i_fop = &simple_dir_operations; break; case S_IFLNK: + inode->i_op = &shmem_symlink_inode_operations; break; } } @@ -1261,7 +1267,6 @@ #ifdef CONFIG_TMPFS -static struct inode_operations shmem_symlink_inode_operations; static struct inode_operations shmem_symlink_inline_operations; /* @@ -1715,12 +1720,33 @@ static struct inode_operations shmem_symlink_inline_operations = { .readlink = shmem_readlink_inline, .follow_link = shmem_follow_link_inline, +#ifdef CONFIG_TMPFS + .setxattr = shmfs_setxattr, + .getxattr = shmfs_getxattr, + .listxattr = shmfs_listxattr, + .removexattr = shmfs_removexattr, +#endif +}; + +static struct inode_operations shmfs_special_inode_operations = { +#ifdef CONFIG_TMPFS + .setxattr = shmfs_setxattr, + .getxattr = shmfs_getxattr, + .listxattr = shmfs_listxattr, + .removexattr = shmfs_removexattr, +#endif }; static struct inode_operations shmem_symlink_inode_operations = { .truncate = shmem_truncate, .readlink = shmem_readlink, .follow_link = shmem_follow_link, +#ifdef CONFIG_TMPFS + .setxattr = shmfs_setxattr, + .getxattr = shmfs_getxattr, + .listxattr = shmfs_listxattr, + .removexattr = shmfs_removexattr, +#endif }; static int shmem_parse_options(char *options, int *mode, uid_t *uid, gid_t *gid, unsigned long *blocks, unsigned long *inodes) @@ -1939,6 +1965,12 @@ static struct inode_operations shmem_inode_operations = { .truncate = shmem_truncate, .setattr = shmem_notify_change, +#ifdef CONFIG_TMPFS + .setxattr = shmfs_setxattr, + .getxattr = shmfs_getxattr, + .listxattr = shmfs_listxattr, + .removexattr = shmfs_removexattr, +#endif }; static struct inode_operations shmem_dir_inode_operations = { @@ -1952,6 +1984,10 @@ .rmdir = shmem_rmdir, .mknod = shmem_mknod, .rename = shmem_rename, + .setxattr = shmfs_setxattr, + .getxattr = shmfs_getxattr, + .listxattr = shmfs_listxattr, + .removexattr = shmfs_removexattr, #endif }; @@ -1993,6 +2029,9 @@ static int __init init_tmpfs(void) { int error; + int err = init_shmfs_xattr(); + if (err) + return err; error = init_inodecache(); if (error) Index: security/selinux/hooks.c =================================================================== RCS file: /cvsroot/selinux/nsa/linux-2.6/security/selinux/hooks.c,v retrieving revision 1.15 diff -u -u -r1.15 hooks.c --- security/selinux/hooks.c 27 Jul 2004 17:43:11 -0000 1.15 +++ security/selinux/hooks.c 22 Aug 2004 14:06:13 -0000 @@ -385,6 +385,14 @@ break; case Opt_fscontext: + /* lkcl: allow fscontext on file systems with xattr + * in order to be able to mount an xattr-enabled tmpfs + * on /dev with a different fscontext. + * reason: shmfs and tmpfs are mapped to two types + * but we need a third (e.g. udevfs_t) in order to + * not interfere with / have-to-add-to either tmp_t + * or shmfs_t + * if (sbsec->behavior != SECURITY_FS_USE_XATTR) { rc = -EINVAL; printk(KERN_WARNING "SELinux: " @@ -392,6 +400,7 @@ " this filesystem type\n"); goto out_free; } + */ if (seen & (Opt_context|Opt_fscontext)) { rc = -EINVAL; printk(KERN_WARNING SEL_MOUNT_FAIL_MSG); -------------- next part -------------- Index: security/selinux/hooks.c =================================================================== RCS file: /cvsroot/selinux/nsa/linux-2.6/security/selinux/hooks.c,v retrieving revision 1.15 diff -u -u -r1.15 hooks.c --- security/selinux/hooks.c 27 Jul 2004 17:43:11 -0000 1.15 +++ security/selinux/hooks.c 22 Aug 2004 14:01:46 -0000 @@ -385,6 +385,14 @@ break; case Opt_fscontext: + /* lkcl: allow fscontext on file systems with xattr + * in order to be able to mount an xattr-enabled tmpfs + * on /dev with a different fscontext. + * reason: shmfs and tmpfs are mapped to two types + * but we need a third (e.g. udevfs_t) in order to + * not interfere with / have-to-add-to either tmp_t + * or shmfs_t + * if (sbsec->behavior != SECURITY_FS_USE_XATTR) { rc = -EINVAL; printk(KERN_WARNING "SELinux: " @@ -392,6 +400,7 @@ " this filesystem type\n"); goto out_free; } + */ if (seen & (Opt_context|Opt_fscontext)) { rc = -EINVAL; printk(KERN_WARNING SEL_MOUNT_FAIL_MSG); -------------- next part -------------- A non-text attachment was scrubbed... Name: xattr.c Type: text/x-csrc Size: 4540 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: xattr_security.c Type: text/x-csrc Size: 971 bytes Desc: not available URL: -------------- next part -------------- #!/bin/sh # # lkcl 2004aug08 # # restore contexts on anything in /dev which has the default device_t # file context. # # some things are meant to have device_t: hey, we set them too, makes # no odds. # # we pass all of the devs to restorecon on one line because restorecon # caches the lookups of the filecontexts: doing a restorecon one at a # time takes 1/4 sec per device/dir/symlink... devs='' #for x in `ls -altrZ /dev/ | grep -v initctl | grep device_t | grep -v "_device_t" | cut -c64-`; do for x in `ls -altrZ /dev/ | grep device_t | grep -v "_device_t" | cut -c64-`; do echo $x devs="$devs /dev/$x" done; echo $devs /sbin/restorecon $devs -------------- next part -------------- --- udev-add.c.orig 2004-07-09 18:59:09.000000000 +0100 +++ udev-add.c 2004-08-03 16:21:59.000000000 +0100 @@ -50,6 +50,10 @@ #define LOCAL_USER "$local" +#ifdef WITH_SELINUX +#include +#endif + /* * Right now the major/minor of a device is stored in a file called * "dev" in sysfs. @@ -92,7 +96,31 @@ break; *pos = 0x00; if (stat(p, &stats)) { +#ifdef WITH_SELINUX + int seretval = 0; + security_context_t scontext; + if (is_selinux_enabled() > 0) + { + seretval = matchpathcon(p, S_IFDIR, &scontext); + if (seretval < 0) { + dbg("matchpathcon(%s) failed\n", p); + } else { + seretval=setfscreatecon(scontext); + if (seretval < 0) + dbg("setfiles %s failed with error '%s'", + p, strerror(errno)); + } + } +#endif retval = mkdir(p, 0755); +#ifdef WITH_SELINUX + if (is_selinux_enabled() > 0) + { + /* after mkdir, free the context */ + freecon(scontext); + } +#endif + if (retval != 0) { dbg("mkdir(%s) failed with error '%s'", p, strerror(errno)); @@ -109,6 +137,10 @@ { struct stat stats; int retval = 0; + int seretval = 0; +#ifdef WITH_SELINUX + security_context_t scontext; +#endif if (stat(file, &stats) != 0) goto create; @@ -117,6 +149,24 @@ if (((stats.st_mode & S_IFMT) == S_IFBLK || (stats.st_mode & S_IFMT) == S_IFCHR) && (stats.st_rdev == makedev(major, minor))) { dbg("preserve file '%s', cause it has correct dev_t", file); +#ifdef WITH_SELINUX + /* lkcl: maybe someone would like to do the same thing with se/linux + * security contexts (check they are the same) but hey, not me! + */ + if (is_selinux_enabled() > 0) + { + retval = matchpathcon(file, mode, &scontext); + if (retval < 0) { + dbg("matchpathcon(%s) failed\n", file); + } else { + retval=setfilecon(scontext, file); + if (retval < 0) + dbg("setfiles %s failed with error '%s'", + file, strerror(errno)); + freecon(scontext); + } + } +#endif goto perms; } @@ -126,6 +176,21 @@ dbg("already present file '%s' unlinked", file); create: +#ifdef WITH_SELINUX + if (is_selinux_enabled() > 0) + { + seretval = matchpathcon(file, mode, &scontext); + if (seretval < 0) { + dbg("matchpathcon(%s) failed\n", file); + } else { + retval=setfscreatecon(scontext); + if (retval < 0) + dbg("setfiles %s failed with error '%s'", + file, strerror(errno)); + } + } +#endif + retval = mknod(file, mode, makedev(major, minor)); if (retval != 0) { dbg("mknod(%s, %#o, %u, %u) failed with error '%s'", @@ -133,6 +198,15 @@ goto exit; } +#ifdef WITH_SELINUX + if (is_selinux_enabled() > 0) + { + /* after mknod, free the context */ + if (seretval == 0) + freecon(scontext); + } +#endif + perms: dbg("chmod(%s, %#o)", file, mode); if (chmod(file, mode) != 0) { @@ -150,7 +224,11 @@ } exit: +#ifdef WITH_SELINUX + return retval < 0 ? retval : seretval; +#else return retval; +#endif } /* get the local logged in user */ @@ -304,10 +382,36 @@ dbg("symlink(%s, %s)", linktarget, filename); if (!fake) { +#ifdef WITH_SELINUX + int seretval = 0; + security_context_t scontext; + if (is_selinux_enabled() > 0) + { + seretval = matchpathcon(filename, S_IFLNK, &scontext); + if (seretval < 0) { + dbg("matchpathcon(%s) failed\n", filename); + } else { + seretval=setfscreatecon(scontext); + if (seretval < 0) + dbg("setfiles %s failed with error '%s'", + filename, strerror(errno)); + } + } +#endif + + unlink(filename); if (symlink(linktarget, filename) != 0) dbg("symlink(%s, %s) failed with error '%s'", linktarget, filename, strerror(errno)); +#ifdef WITH_SELINUX + if (is_selinux_enabled() > 0) + { + /* after symlink, free the context */ + freecon(scontext); + } +#endif + } } @@ -403,6 +507,11 @@ char *pos; int retval; +#ifdef WITH_SELINUX + int seretval; + security_context_t prev_scontext; +#endif + memset(&dev, 0x00, sizeof(dev)); dev.type = get_device_type(path, subsystem); @@ -438,6 +547,23 @@ dbg("name='%s'", dev.name); +#ifdef WITH_SELINUX + /* record the present security context, for file-creation + * restoration creation purposes. + * + * we're going to assume that between now and the time that + * this context is restored that the only filecreation of any + * kind to occur will be mknod, symlink and mkdirs. + */ + + if (is_selinux_enabled() > 0) + { + seretval = getfscreatecon(&prev_scontext); + if (seretval < 0) { + dbg("getfscreatecon failed\n"); + } + } +#endif switch (dev.type) { case 'b': case 'c': @@ -474,6 +600,16 @@ break; } +#ifdef WITH_SELINUX + if (is_selinux_enabled() > 0) + { + /* reset the file create context to its former glory */ + if (seretval == 0) + seretval=setfscreatecon(prev_scontext); + freecon(prev_scontext); + } +#endif + exit: sysfs_close_class_device(class_dev); --- Makefile.orig 2004-08-02 22:23:58.000000000 +0100 +++ Makefile 2004-08-02 22:24:01.000000000 +0100 @@ -25,6 +25,8 @@ # Leave this set to `false' for production use. DEBUG = true +# Set this to compile with Security-Enhanced Linux support. +WITH_SELINUX = true ROOT = udev DAEMON = udevd @@ -39,6 +41,7 @@ LOCAL_CFG_DIR = etc/udev HOTPLUG_EXEC = $(ROOT) + DESTDIR = KERNEL_DIR = /lib/modules/${shell uname -r}/build @@ -172,6 +175,13 @@ CFLAGS += -I$(PWD)/libsysfs +ifeq ($(strip $(WITH_SELINUX)),true) + LIB_OBJS += \ + -lselinux + CFLAGS += \ + -DWITH_SELINUX +endif + all: $(ROOT) $(SENDER) $(DAEMON) $(INFO) $(TESTER) $(STARTER) @extras="$(EXTRAS)" ; for target in $$extras ; do \ echo $$target ; \ From jbrindle at tresys.com Sun Aug 22 15:05:27 2004 From: jbrindle at tresys.com (Joshua Brindle) Date: Sun, 22 Aug 2004 11:05:27 -0400 Subject: Fedora and udev In-Reply-To: <200408222125.38169.russell@coker.com.au> References: <200408222125.38169.russell@coker.com.au> Message-ID: <4128B637.8040900@tresys.com> I posted a patch here that pebenito did a while back for ramfs and lkcl also did one for tmpfs (which may be better for /dev since it's swappable) both are mostly cut and paste jobs but they add the necessary support. I'd like to reiterate though, that udev support for selinux is *broken*! if the correct policy isn't in place you will cause race conditions Joshua Russell Coker wrote: >It seems that udev is now virtually mandatory as of the latest rawhide update. > >udev uses ramfs for /tmp, ramfs (as of the latest Fedora kernel 2.6.8-1.525) >has no support for file labelling and breaks everything. > >Can we get ramfs labelling working in the next few days or do we have to >change things to not depend on udev? > > > From jbrindle at tresys.com Sun Aug 22 15:29:42 2004 From: jbrindle at tresys.com (Joshua Brindle) Date: Sun, 22 Aug 2004 11:29:42 -0400 Subject: Fedora and udev In-Reply-To: <20040822144016.GA13842@lkcl.net> References: <200408222125.38169.russell@coker.com.au> <20040822144016.GA13842@lkcl.net> Message-ID: <4128BBE6.6050207@tresys.com> None of this restorecon voodoo nor mount context is necessary when udev is implemented correctly. When we were experimenting with udev it only took ramfs xattr support, add ramfs to fs_use as an xattr filesystem and set up udev with selinux support. When it runs it creates the nodes and then labels them via the libselinux api which reads file_contexts. Aside from the problems I've already mentioned there should be no problems running udev. If the tmpfs context support is something different from this then it should not be used (I have not looked at tmpfs support at all but have personal experience that ramfs xattr works as expected). Joshua Luke Kenneth Casson Leighton wrote: >On Sun, Aug 22, 2004 at 09:25:38PM +1000, Russell Coker wrote: > > >>It seems that udev is now virtually mandatory as of the latest rawhide update. >> >>udev uses ramfs for /tmp, ramfs (as of the latest Fedora kernel 2.6.8-1.525) >>has no support for file labelling and breaks everything. >> >>Can we get ramfs labelling working in the next few days or do we have to >>change things to not depend on udev? >> >> > > chris pebenito of gentoo/hardened i believe has written a ramfs patch > already (2.6.6) > > it was what i based the shmfs one off of. > > or maybe that's the other way round, i dunno. can't remember. > > > remember that just getting ramfs / tmpfs working is not enough, you > must also: > > - patch selinux/hooks.c to allow mount -o fscontext=system_u:object_r:device_t > on a tmpfs or shmfs or add an extra option to hooks.c _similar_ to > fscontext but without the bit that says "stop if this filesystem > supports xattrs". > > - modify /etc/init.d/udev to then mount /dev with the default context > of device_t which whill FAIL if you DO NOT patch hooks.c as above: > > mount -n -o > fscontext=system_u:object_r:device_t,size=$tmpfs_size,mode=0755 > -t tmpfs none /dev > > - add in an equivalent of my extra post-udev-and-hotplug duplicate of > /etc/init.d/modutils that will load things like nvidia, ppp_generic > and stuff that are not yet fully 2.6-compliant drivers (i.e. they > don't grok /sys and consequently don't generate hotplug events) . > > i assume that rawhide, given that it is using udev already, is > perfectly capable of doing a proper and far superior job to what > i have hacked up. > > - run a restorecon on ALL DEVICE NODES CREATED PRIOR TO /etc/init.d/udev > RUNNING. > > i got bored of doing this regularly and manually and so wrote a > small script (/sbin/restoredevicefiles) which does this for me. > badly. it uses ls (really must use commands NOT from /usr and must > use commands that DO NOT a require /dev/null or access to /dev/fd/*) > > i believe i had to copy cut from /usr/bin/cut to /bin/cut (!!) hey > there are probably people out there who could do this as c-code > or with sed or something more appropriate, to be honest i haven't > got time to DoItRight(tm) so the ItWorksForMe(tm) approach is fine > for me until _someone else_ does the DoItRight(tm) approach. > > - udev, udevd _and_ udevsend (_why_ is udev split into three separate > programs??????) _all_ need to be hacked up to run setfiles -q -s on a > pipe which udev(d?) will communicate the name of the inode to. > > russell advised me that using popen would be suitable for this: > however i am not sure whether it should be put in udev or in > udevd and i haven't the TimeRightNow(tm) to focus on > MakingItNice(tm) > > alternatively, a patch (also attached) to add selinux "restorecon" > stuff to udevsend is included which, although it still has a 1/4 > second delay per inode added, at least works. > > patch is against udev-0.030. udev-0.030 has had the > /etc/udev.d/default/selinux script removed which is a complete pain > but hey, if linux-hotplug-devel say it don't work, it don't work. > > > it's taken me about three maybe four weeks to get this hacked up to > a working / reasonably acceptable (for me at least) point. > > i'm assuming that you would like the kernel patches: if you would like > me to place a copy of my hacked-up policy files at hands.com/~lkcl/selinux > please let me know because they are not very pretty but will save you a > lot of time: because i don't know any better it has taken me somewhere > in excess of 100 reboots to get a working udev-tmpfs-enabled policy > plus initscripts hacks. > > if someone can inform me of the appropriate cvs-based diff > command that will allow me to include fs/ramfs/xattr.c > and fs/ramfs/xattr-security.c in the patch i would be most > grateful, otherwise people will just have to manually blat > those two files (attached) into the appropriate locations. > > i'd _really_ appreciate it if people _could_ say "hey, yes, we > really need tmpfs-enabled udev in fc" because then i wouldn't > have so much crap hanging around on my debian/selinux system: > i'd far rather it had already been done and i could have > copied or relied on the work of more experienced individuals. > > l. > > > >------------------------------------------------------------------------ > >Index: fs/Kconfig >=================================================================== >RCS file: /cvsroot/selinux/nsa/linux-2.6/fs/Kconfig,v >retrieving revision 1.8 >diff -u -u -r1.8 Kconfig >--- fs/Kconfig 18 Jun 2004 20:37:21 -0000 1.8 >+++ fs/Kconfig 22 Aug 2004 14:06:10 -0000 >@@ -925,6 +925,27 @@ > > See for details. > >+config TMPFS_FS_XATTR >+ bool "tmpfs Extended Attributes" >+ help >+ Extended attributes are name:value pairs associated with inodes by >+ the kernel or by users (see the attr(5) manual page, or visit >+ for details). >+ >+ If unsure, say N. >+ >+config TMPFS_FS_SECURITY >+ bool "tmpfs Security Labels" >+ depends on TMPFS_FS_XATTR >+ help >+ Security labels support alternative access control models >+ implemented by security modules like SELinux. This option >+ enables an extended attribute handler for file security >+ labels in the tmpfs filesystem. >+ >+ If you are not using a security module that requires using >+ extended attributes for file security labels, say N. >+ > config HUGETLBFS > bool "HugeTLB file system support" > depends X86 || IA64 || PPC64 || SPARC64 || SUPERH || X86_64 || BROKEN >Index: fs/ramfs/Makefile >=================================================================== >RCS file: /cvsroot/selinux/nsa/linux-2.6/fs/ramfs/Makefile,v >retrieving revision 1.1.1.1 >diff -u -u -r1.1.1.1 Makefile >--- fs/ramfs/Makefile 14 Aug 2003 12:08:40 -0000 1.1.1.1 >+++ fs/ramfs/Makefile 22 Aug 2004 14:06:10 -0000 >@@ -5,3 +5,6 @@ > obj-$(CONFIG_RAMFS) += ramfs.o > > ramfs-objs := inode.o >+ramfs-$(CONFIG_RAMFS_FS_XATTR) += xattr.o >+ramfs-$(CONFIG_RAMFS_FS_SECURITY) += xattr_security.o >+ >Index: fs/ramfs/inode.c >=================================================================== >RCS file: /cvsroot/selinux/nsa/linux-2.6/fs/ramfs/inode.c,v >retrieving revision 1.1.1.4 >diff -u -u -r1.1.1.4 inode.c >--- fs/ramfs/inode.c 18 Jun 2004 19:30:21 -0000 1.1.1.4 >+++ fs/ramfs/inode.c 22 Aug 2004 14:06:11 -0000 >@@ -31,6 +31,7 @@ > #include > #include > #include >+#include "xattr.h" > > #include > >@@ -157,6 +158,10 @@ > > static struct inode_operations ramfs_file_inode_operations = { > .getattr = simple_getattr, >+ .setxattr = ramfs_setxattr, >+ .getxattr = ramfs_getxattr, >+ .listxattr = ramfs_listxattr, >+ .removexattr = ramfs_removexattr, > }; > > static struct inode_operations ramfs_dir_inode_operations = { >@@ -169,6 +174,10 @@ > .rmdir = simple_rmdir, > .mknod = ramfs_mknod, > .rename = simple_rename, >+ .setxattr = ramfs_setxattr, >+ .getxattr = ramfs_getxattr, >+ .listxattr = ramfs_listxattr, >+ .removexattr = ramfs_removexattr, > }; > > static struct super_operations ramfs_ops = { >@@ -224,12 +233,17 @@ > > static int __init init_ramfs_fs(void) > { >+ int err = init_ramfs_xattr(); >+ if (err) >+ return err; >+ > return register_filesystem(&ramfs_fs_type); > } > > static void __exit exit_ramfs_fs(void) > { > unregister_filesystem(&ramfs_fs_type); >+ exit_ramfs_xattr(); > } > > module_init(init_ramfs_fs) >Index: mm/Makefile >=================================================================== >RCS file: /cvsroot/selinux/nsa/linux-2.6/mm/Makefile,v >retrieving revision 1.1.1.4 >diff -u -u -r1.1.1.4 Makefile >--- mm/Makefile 18 Jun 2004 19:31:02 -0000 1.1.1.4 >+++ mm/Makefile 22 Aug 2004 14:06:12 -0000 >@@ -15,3 +15,6 @@ > obj-$(CONFIG_SWAP) += page_io.o swap_state.o swapfile.o > obj-$(CONFIG_HUGETLBFS) += hugetlb.o > obj-$(CONFIG_NUMA) += mempolicy.o >+ >+obj-$(CONFIG_TMPFS_FS_XATTR) += xattr.o >+obj-$(CONFIG_TMPFS_FS_SECURITY) += xattr_security.o >Index: mm/shmem.c >=================================================================== >RCS file: /cvsroot/selinux/nsa/linux-2.6/mm/shmem.c,v >retrieving revision 1.1.1.8 >diff -u -u -r1.1.1.8 shmem.c >--- mm/shmem.c 18 Jun 2004 19:31:03 -0000 1.1.1.8 >+++ mm/shmem.c 22 Aug 2004 14:06:12 -0000 >@@ -44,6 +44,8 @@ > #include > #include > >+#include "xattr.h" >+ > /* This magic number is used in glibc for posix shared memory */ > #define TMPFS_MAGIC 0x01021994 > >@@ -168,6 +170,8 @@ > static struct file_operations shmem_file_operations; > static struct inode_operations shmem_inode_operations; > static struct inode_operations shmem_dir_inode_operations; >+static struct inode_operations shmfs_special_inode_operations; >+static struct inode_operations shmem_symlink_inode_operations; > static struct vm_operations_struct shmem_vm_ops; > > static struct backing_dev_info shmem_backing_dev_info = { >@@ -1212,6 +1216,7 @@ > mpol_shared_policy_init(&info->policy); > switch (mode & S_IFMT) { > default: >+ inode->i_op = &shmfs_special_inode_operations; > init_special_inode(inode, mode, dev); > break; > case S_IFREG: >@@ -1229,6 +1234,7 @@ > inode->i_fop = &simple_dir_operations; > break; > case S_IFLNK: >+ inode->i_op = &shmem_symlink_inode_operations; > break; > } > } >@@ -1261,7 +1267,6 @@ > > #ifdef CONFIG_TMPFS > >-static struct inode_operations shmem_symlink_inode_operations; > static struct inode_operations shmem_symlink_inline_operations; > > /* >@@ -1715,12 +1720,33 @@ > static struct inode_operations shmem_symlink_inline_operations = { > .readlink = shmem_readlink_inline, > .follow_link = shmem_follow_link_inline, >+#ifdef CONFIG_TMPFS >+ .setxattr = shmfs_setxattr, >+ .getxattr = shmfs_getxattr, >+ .listxattr = shmfs_listxattr, >+ .removexattr = shmfs_removexattr, >+#endif >+}; >+ >+static struct inode_operations shmfs_special_inode_operations = { >+#ifdef CONFIG_TMPFS >+ .setxattr = shmfs_setxattr, >+ .getxattr = shmfs_getxattr, >+ .listxattr = shmfs_listxattr, >+ .removexattr = shmfs_removexattr, >+#endif > }; > > static struct inode_operations shmem_symlink_inode_operations = { > .truncate = shmem_truncate, > .readlink = shmem_readlink, > .follow_link = shmem_follow_link, >+#ifdef CONFIG_TMPFS >+ .setxattr = shmfs_setxattr, >+ .getxattr = shmfs_getxattr, >+ .listxattr = shmfs_listxattr, >+ .removexattr = shmfs_removexattr, >+#endif > }; > > static int shmem_parse_options(char *options, int *mode, uid_t *uid, gid_t *gid, unsigned long *blocks, unsigned long *inodes) >@@ -1939,6 +1965,12 @@ > static struct inode_operations shmem_inode_operations = { > .truncate = shmem_truncate, > .setattr = shmem_notify_change, >+#ifdef CONFIG_TMPFS >+ .setxattr = shmfs_setxattr, >+ .getxattr = shmfs_getxattr, >+ .listxattr = shmfs_listxattr, >+ .removexattr = shmfs_removexattr, >+#endif > }; > > static struct inode_operations shmem_dir_inode_operations = { >@@ -1952,6 +1984,10 @@ > .rmdir = shmem_rmdir, > .mknod = shmem_mknod, > .rename = shmem_rename, >+ .setxattr = shmfs_setxattr, >+ .getxattr = shmfs_getxattr, >+ .listxattr = shmfs_listxattr, >+ .removexattr = shmfs_removexattr, > #endif > }; > >@@ -1993,6 +2029,9 @@ > static int __init init_tmpfs(void) > { > int error; >+ int err = init_shmfs_xattr(); >+ if (err) >+ return err; > > error = init_inodecache(); > if (error) >Index: security/selinux/hooks.c >=================================================================== >RCS file: /cvsroot/selinux/nsa/linux-2.6/security/selinux/hooks.c,v >retrieving revision 1.15 >diff -u -u -r1.15 hooks.c >--- security/selinux/hooks.c 27 Jul 2004 17:43:11 -0000 1.15 >+++ security/selinux/hooks.c 22 Aug 2004 14:06:13 -0000 >@@ -385,6 +385,14 @@ > break; > > case Opt_fscontext: >+ /* lkcl: allow fscontext on file systems with xattr >+ * in order to be able to mount an xattr-enabled tmpfs >+ * on /dev with a different fscontext. >+ * reason: shmfs and tmpfs are mapped to two types >+ * but we need a third (e.g. udevfs_t) in order to >+ * not interfere with / have-to-add-to either tmp_t >+ * or shmfs_t >+ * > if (sbsec->behavior != SECURITY_FS_USE_XATTR) { > rc = -EINVAL; > printk(KERN_WARNING "SELinux: " >@@ -392,6 +400,7 @@ > " this filesystem type\n"); > goto out_free; > } >+ */ > if (seen & (Opt_context|Opt_fscontext)) { > rc = -EINVAL; > printk(KERN_WARNING SEL_MOUNT_FAIL_MSG); > > >------------------------------------------------------------------------ > >Index: security/selinux/hooks.c >=================================================================== >RCS file: /cvsroot/selinux/nsa/linux-2.6/security/selinux/hooks.c,v >retrieving revision 1.15 >diff -u -u -r1.15 hooks.c >--- security/selinux/hooks.c 27 Jul 2004 17:43:11 -0000 1.15 >+++ security/selinux/hooks.c 22 Aug 2004 14:01:46 -0000 >@@ -385,6 +385,14 @@ > break; > > case Opt_fscontext: >+ /* lkcl: allow fscontext on file systems with xattr >+ * in order to be able to mount an xattr-enabled tmpfs >+ * on /dev with a different fscontext. >+ * reason: shmfs and tmpfs are mapped to two types >+ * but we need a third (e.g. udevfs_t) in order to >+ * not interfere with / have-to-add-to either tmp_t >+ * or shmfs_t >+ * > if (sbsec->behavior != SECURITY_FS_USE_XATTR) { > rc = -EINVAL; > printk(KERN_WARNING "SELinux: " >@@ -392,6 +400,7 @@ > " this filesystem type\n"); > goto out_free; > } >+ */ > if (seen & (Opt_context|Opt_fscontext)) { > rc = -EINVAL; > printk(KERN_WARNING SEL_MOUNT_FAIL_MSG); > > >------------------------------------------------------------------------ > >/* > File: fs/ramfs/xattr.c > > Derived from fs/ext3/xattr.c, changed in the following ways: > drop everything related to persistent storage of EAs > pass dentry rather than inode to internal methods > only presently define a handler for security modules >*/ > >#include >#include >#include >#include >#include >#include "xattr.h" > >static struct ramfs_xattr_handler *ramfs_xattr_handlers[RAMFS_XATTR_INDEX_MAX]; >static rwlock_t ramfs_handler_lock = RW_LOCK_UNLOCKED; > >int >ramfs_xattr_register(int name_index, struct ramfs_xattr_handler *handler) >{ > int error = -EINVAL; > > if (name_index > 0 && name_index <= RAMFS_XATTR_INDEX_MAX) { > write_lock(&ramfs_handler_lock); > if (!ramfs_xattr_handlers[name_index-1]) { > ramfs_xattr_handlers[name_index-1] = handler; > error = 0; > } > write_unlock(&ramfs_handler_lock); > } > return error; >} > >void >ramfs_xattr_unregister(int name_index, struct ramfs_xattr_handler *handler) >{ > if (name_index > 0 || name_index <= RAMFS_XATTR_INDEX_MAX) { > write_lock(&ramfs_handler_lock); > ramfs_xattr_handlers[name_index-1] = NULL; > write_unlock(&ramfs_handler_lock); > } >} > >static inline const char * >strcmp_prefix(const char *a, const char *a_prefix) >{ > while (*a_prefix && *a == *a_prefix) { > a++; > a_prefix++; > } > return *a_prefix ? NULL : a; >} > >/* > * Decode the extended attribute name, and translate it into > * the name_index and name suffix. > */ >static inline struct ramfs_xattr_handler * >ramfs_xattr_resolve_name(const char **name) >{ > struct ramfs_xattr_handler *handler = NULL; > int i; > > if (!*name) > return NULL; > read_lock(&ramfs_handler_lock); > for (i=0; i if (ramfs_xattr_handlers[i]) { > const char *n = strcmp_prefix(*name, > ramfs_xattr_handlers[i]->prefix); > if (n) { > handler = ramfs_xattr_handlers[i]; > *name = n; > break; > } > } > } > read_unlock(&ramfs_handler_lock); > return handler; >} > >static inline struct ramfs_xattr_handler * >ramfs_xattr_handler(int name_index) >{ > struct ramfs_xattr_handler *handler = NULL; > if (name_index > 0 && name_index <= RAMFS_XATTR_INDEX_MAX) { > read_lock(&ramfs_handler_lock); > handler = ramfs_xattr_handlers[name_index-1]; > read_unlock(&ramfs_handler_lock); > } > return handler; >} > >/* > * Inode operation getxattr() > * > * dentry->d_inode->i_sem down > */ >ssize_t >ramfs_getxattr(struct dentry *dentry, const char *name, > void *buffer, size_t size) >{ > struct ramfs_xattr_handler *handler; > > handler = ramfs_xattr_resolve_name(&name); > if (!handler) > return -EOPNOTSUPP; > return handler->get(dentry, name, buffer, size); >} > >/* > * Inode operation listxattr() > * > * dentry->d_inode->i_sem down > */ >ssize_t >ramfs_listxattr(struct dentry *dentry, char *buffer, size_t buffer_size) >{ > struct ramfs_xattr_handler *handler = NULL; > int i, error = 0; > unsigned int size = 0; > char *buf; > > read_lock(&ramfs_handler_lock); > > for (i=0; i handler = ramfs_xattr_handlers[i]; > if (handler) > size += handler->list(dentry, NULL); > } > > if (!buffer) { > error = size; > goto out; > } else { > error = -ERANGE; > if (size > buffer_size) > goto out; > } > > buf = buffer; > for (i=0; i handler = ramfs_xattr_handlers[i]; > if (handler) > buf += handler->list(dentry, buf); > } > error = size; > >out: > read_unlock(&ramfs_handler_lock); > return size; >} > >/* > * Inode operation setxattr() > * > * dentry->d_inode->i_sem down > */ >int >ramfs_setxattr(struct dentry *dentry, const char *name, > const void *value, size_t size, int flags) >{ > struct ramfs_xattr_handler *handler; > > if (size == 0) > value = ""; /* empty EA, do not remove */ > handler = ramfs_xattr_resolve_name(&name); > if (!handler) > return -EOPNOTSUPP; > return handler->set(dentry, name, value, size, flags); >} > >/* > * Inode operation removexattr() > * > * dentry->d_inode->i_sem down > */ >int >ramfs_removexattr(struct dentry *dentry, const char *name) >{ > struct ramfs_xattr_handler *handler; > > handler = ramfs_xattr_resolve_name(&name); > if (!handler) > return -EOPNOTSUPP; > return handler->set(dentry, name, NULL, 0, XATTR_REPLACE); >} > >int __init >init_ramfs_xattr(void) >{ >#ifdef CONFIG_RAMFS_FS_SECURITY > int err; > > err = ramfs_xattr_register(RAMFS_XATTR_INDEX_SECURITY, > &ramfs_xattr_security_handler); > if (err) > return err; >#endif > > return 0; >} > >void >exit_ramfs_xattr(void) >{ >#ifdef CONFIG_RAMFS_FS_SECURITY > ramfs_xattr_unregister(RAMFS_XATTR_INDEX_SECURITY, > &ramfs_xattr_security_handler); >#endif > >} > > >------------------------------------------------------------------------ > >/* > * File: fs/ramfs/xattr_security.c > */ > >#include >#include >#include >#include >#include "xattr.h" > >static size_t >ramfs_xattr_security_list(struct dentry *dentry, char *buffer) >{ > return security_inode_listsecurity(dentry, buffer); >} > >static int >ramfs_xattr_security_get(struct dentry *dentry, const char *name, > void *buffer, size_t size) >{ > if (strcmp(name, "") == 0) > return -EINVAL; > return security_inode_getsecurity(dentry, name, buffer, size); >} > >static int >ramfs_xattr_security_set(struct dentry *dentry, const char *name, > const void *value, size_t size, int flags) >{ > if (strcmp(name, "") == 0) > return -EINVAL; > return security_inode_setsecurity(dentry, name, value, size, flags); >} > >struct ramfs_xattr_handler ramfs_xattr_security_handler = { > .prefix = XATTR_SECURITY_PREFIX, > .list = ramfs_xattr_security_list, > .get = ramfs_xattr_security_get, > .set = ramfs_xattr_security_set, >}; > > >------------------------------------------------------------------------ > >#!/bin/sh ># ># lkcl 2004aug08 ># ># restore contexts on anything in /dev which has the default device_t ># file context. ># ># some things are meant to have device_t: hey, we set them too, makes ># no odds. ># ># we pass all of the devs to restorecon on one line because restorecon ># caches the lookups of the filecontexts: doing a restorecon one at a ># time takes 1/4 sec per device/dir/symlink... > >devs='' >#for x in `ls -altrZ /dev/ | grep -v initctl | grep device_t | grep -v "_device_t" | cut -c64-`; do >for x in `ls -altrZ /dev/ | grep device_t | grep -v "_device_t" | cut -c64-`; do > echo $x > devs="$devs /dev/$x" >done; >echo $devs >/sbin/restorecon $devs > > >------------------------------------------------------------------------ > >--- udev-add.c.orig 2004-07-09 18:59:09.000000000 +0100 >+++ udev-add.c 2004-08-03 16:21:59.000000000 +0100 >@@ -50,6 +50,10 @@ > > #define LOCAL_USER "$local" > >+#ifdef WITH_SELINUX >+#include >+#endif >+ > /* > * Right now the major/minor of a device is stored in a file called > * "dev" in sysfs. >@@ -92,7 +96,31 @@ > break; > *pos = 0x00; > if (stat(p, &stats)) { >+#ifdef WITH_SELINUX >+ int seretval = 0; >+ security_context_t scontext; >+ if (is_selinux_enabled() > 0) >+ { >+ seretval = matchpathcon(p, S_IFDIR, &scontext); >+ if (seretval < 0) { >+ dbg("matchpathcon(%s) failed\n", p); >+ } else { >+ seretval=setfscreatecon(scontext); >+ if (seretval < 0) >+ dbg("setfiles %s failed with error '%s'", >+ p, strerror(errno)); >+ } >+ } >+#endif > retval = mkdir(p, 0755); >+#ifdef WITH_SELINUX >+ if (is_selinux_enabled() > 0) >+ { >+ /* after mkdir, free the context */ >+ freecon(scontext); >+ } >+#endif >+ > if (retval != 0) { > dbg("mkdir(%s) failed with error '%s'", > p, strerror(errno)); >@@ -109,6 +137,10 @@ > { > struct stat stats; > int retval = 0; >+ int seretval = 0; >+#ifdef WITH_SELINUX >+ security_context_t scontext; >+#endif > > if (stat(file, &stats) != 0) > goto create; >@@ -117,6 +149,24 @@ > if (((stats.st_mode & S_IFMT) == S_IFBLK || (stats.st_mode & S_IFMT) == S_IFCHR) && > (stats.st_rdev == makedev(major, minor))) { > dbg("preserve file '%s', cause it has correct dev_t", file); >+#ifdef WITH_SELINUX >+ /* lkcl: maybe someone would like to do the same thing with se/linux >+ * security contexts (check they are the same) but hey, not me! >+ */ >+ if (is_selinux_enabled() > 0) >+ { >+ retval = matchpathcon(file, mode, &scontext); >+ if (retval < 0) { >+ dbg("matchpathcon(%s) failed\n", file); >+ } else { >+ retval=setfilecon(scontext, file); >+ if (retval < 0) >+ dbg("setfiles %s failed with error '%s'", >+ file, strerror(errno)); >+ freecon(scontext); >+ } >+ } >+#endif > goto perms; > } > >@@ -126,6 +176,21 @@ > dbg("already present file '%s' unlinked", file); > > create: >+#ifdef WITH_SELINUX >+ if (is_selinux_enabled() > 0) >+ { >+ seretval = matchpathcon(file, mode, &scontext); >+ if (seretval < 0) { >+ dbg("matchpathcon(%s) failed\n", file); >+ } else { >+ retval=setfscreatecon(scontext); >+ if (retval < 0) >+ dbg("setfiles %s failed with error '%s'", >+ file, strerror(errno)); >+ } >+ } >+#endif >+ > retval = mknod(file, mode, makedev(major, minor)); > if (retval != 0) { > dbg("mknod(%s, %#o, %u, %u) failed with error '%s'", >@@ -133,6 +198,15 @@ > goto exit; > } > >+#ifdef WITH_SELINUX >+ if (is_selinux_enabled() > 0) >+ { >+ /* after mknod, free the context */ >+ if (seretval == 0) >+ freecon(scontext); >+ } >+#endif >+ > perms: > dbg("chmod(%s, %#o)", file, mode); > if (chmod(file, mode) != 0) { >@@ -150,7 +224,11 @@ > } > > exit: >+#ifdef WITH_SELINUX >+ return retval < 0 ? retval : seretval; >+#else > return retval; >+#endif > } > > /* get the local logged in user */ >@@ -304,10 +382,36 @@ > > dbg("symlink(%s, %s)", linktarget, filename); > if (!fake) { >+#ifdef WITH_SELINUX >+ int seretval = 0; >+ security_context_t scontext; >+ if (is_selinux_enabled() > 0) >+ { >+ seretval = matchpathcon(filename, S_IFLNK, &scontext); >+ if (seretval < 0) { >+ dbg("matchpathcon(%s) failed\n", filename); >+ } else { >+ seretval=setfscreatecon(scontext); >+ if (seretval < 0) >+ dbg("setfiles %s failed with error '%s'", >+ filename, strerror(errno)); >+ } >+ } >+#endif >+ >+ > unlink(filename); > if (symlink(linktarget, filename) != 0) > dbg("symlink(%s, %s) failed with error '%s'", > linktarget, filename, strerror(errno)); >+#ifdef WITH_SELINUX >+ if (is_selinux_enabled() > 0) >+ { >+ /* after symlink, free the context */ >+ freecon(scontext); >+ } >+#endif >+ > } > } > >@@ -403,6 +507,11 @@ > char *pos; > int retval; > >+#ifdef WITH_SELINUX >+ int seretval; >+ security_context_t prev_scontext; >+#endif >+ > memset(&dev, 0x00, sizeof(dev)); > > dev.type = get_device_type(path, subsystem); >@@ -438,6 +547,23 @@ > > dbg("name='%s'", dev.name); > >+#ifdef WITH_SELINUX >+ /* record the present security context, for file-creation >+ * restoration creation purposes. >+ * >+ * we're going to assume that between now and the time that >+ * this context is restored that the only filecreation of any >+ * kind to occur will be mknod, symlink and mkdirs. >+ */ >+ >+ if (is_selinux_enabled() > 0) >+ { >+ seretval = getfscreatecon(&prev_scontext); >+ if (seretval < 0) { >+ dbg("getfscreatecon failed\n"); >+ } >+ } >+#endif > switch (dev.type) { > case 'b': > case 'c': >@@ -474,6 +600,16 @@ > break; > } > >+#ifdef WITH_SELINUX >+ if (is_selinux_enabled() > 0) >+ { >+ /* reset the file create context to its former glory */ >+ if (seretval == 0) >+ seretval=setfscreatecon(prev_scontext); >+ freecon(prev_scontext); >+ } >+#endif >+ > exit: > sysfs_close_class_device(class_dev); > >--- Makefile.orig 2004-08-02 22:23:58.000000000 +0100 >+++ Makefile 2004-08-02 22:24:01.000000000 +0100 >@@ -25,6 +25,8 @@ > # Leave this set to `false' for production use. > DEBUG = true > >+# Set this to compile with Security-Enhanced Linux support. >+WITH_SELINUX = true > > ROOT = udev > DAEMON = udevd >@@ -39,6 +41,7 @@ > LOCAL_CFG_DIR = etc/udev > HOTPLUG_EXEC = $(ROOT) > >+ > DESTDIR = > > KERNEL_DIR = /lib/modules/${shell uname -r}/build >@@ -172,6 +175,13 @@ > > CFLAGS += -I$(PWD)/libsysfs > >+ifeq ($(strip $(WITH_SELINUX)),true) >+ LIB_OBJS += \ >+ -lselinux >+ CFLAGS += \ >+ -DWITH_SELINUX >+endif >+ > all: $(ROOT) $(SENDER) $(DAEMON) $(INFO) $(TESTER) $(STARTER) > @extras="$(EXTRAS)" ; for target in $$extras ; do \ > echo $$target ; \ > > From lkcl at lkcl.net Sun Aug 22 16:23:47 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 22 Aug 2004 17:23:47 +0100 Subject: Fedora and udev In-Reply-To: <4128BBE6.6050207@tresys.com> References: <200408222125.38169.russell@coker.com.au> <20040822144016.GA13842@lkcl.net> <4128BBE6.6050207@tresys.com> Message-ID: <20040822162347.GC13842@lkcl.net> On Sun, Aug 22, 2004 at 11:29:42AM -0400, Joshua Brindle wrote: > None of this restorecon voodoo nor mount context is necessary when udev > is implemented correctly. i would be delighted to have avoided the problems i encountered and the floundering solutions i attempted. > When we were experimenting with udev it only took ramfs xattr support, > add ramfs to fs_use as an xattr filesystem and set up udev with selinux > support. When it runs it creates the nodes and then labels them via the > libselinux api which reads file_contexts. Aside from the problems I've > already mentioned there should be no problems running udev. > > If the tmpfs context support is something different from this then it > should not be used (I have not looked at tmpfs support at all but have > personal experience that ramfs xattr works as expected). tmpfs is a little different because it is also shmfs and it is not possible to distinguish between the two in some way that i cannot at present recall: a potential solution was to add that patch to selinux hooks.c and over-ride the purpose of fscontext= in order to specify the correct context. i believe i am correct in saying that it is inappropriate to change the types for shmfs and/or tmpfs in fs_use: fs_use_trans tmpfs system_u:object_r:tmpfs_t; fs_use_trans shm system_u:object_r:tmpfs_t; the reason why it i believe it to be inappropriate is because the policy files make assumptions about the use of tmpfs and shm filesystems and these assumptions are that "it's tmpfs_t" as above. that is why i understand mount -o fscontext=somethingelse_t to have been invented, to make it possible to over-ride this "default" context. however, the ramfs is only in a SLIGHTLY different situation: namely that it has NOT been used for any purpose in SE/Linux, on account of noone having done the xattrs patch before now. therefore, the work that you did, joshua, namely to add ramfs to fs_use as an xattr filesystem, happened to be a suitable solution because nobody happened to have ever used ramfs in SE/Linux before now. IN THE FUTURE, however, that will change. therefore, it will also be necessary to be able to have both a default context (as listed in fs_use) and also to over-ride that default (by using a mount -o (???)context=somethingelse_t option). still with me so far? :) now. okay. the way that fscontext= works is that it ONLY works on filesystems that are NOT xattr-enabled. [there is another option, context=, which does something else, it was inappropriate for use, can't remember why.] so, as i said, the whole reason why a _new_ ??context= option (or a patched fscontext= option) will be needed is because for xattr-enabled non-persistent filesystems you NEED to be able to over-ride the initial filecontext given to the root of the mounted filesystem. and the selinux/hooks.c patch that i attached simply removes the check "is this filesystem a non-xattr-enabled one, because if it's an xattr-enabled one then we don't want people to use fscontext=" so, irrespective of whether shmfs, tmpfs or ramfs is used, i believe that it WILL be necessary to have this enhanced fscontext= capability or to have some new option ??context= also, i asked stephen smalley's advice about the use of mount -t tmpfs -o fscontext=system_u:object_r:device_t and he said yep, device_t is as good a choice as any. so, consequently, i started to go through the policy files adding in extra device_t-related stuff that broke during the boot-up sequence. e.g: allow init_t device_t:file { ioctl read write } to allow /sbin/init to access /dev/null prior to when udev has been run! allow device_t self:filesystem { associate }; for udev to do something to /dev/null and /dev/snd (don't know what, don't care what) allow udev_tbl_t device_t:filesystem { associate }; because /dev/.udev.tdb is now on a shmfs and it's non-persistent. allow mount_t tmpfs_t:filesystem { relabelfrom }; i _really_ don't know what this one's for. allow initrc_t device_t:dir { create setattr} this is for /etc/init.d/udev to create /dev/pts and for it to do a touch on / allow initrc_t device_t:lnk_file { create } this is to allow /dev/fd to be created. the list continues with a few more entries. also i think i had to add something to types/file.te errr i forget what. y'know, it would make a _lot_ of sense i believe to have a separate domain for /etc/init.d/udev. if anyone knows of a better way to do - or to have done - this, i would REALLY like to know, because it will save me some maintenance headaches later. btw as you might have noticed, after i heard a few months back that someone thought that everything i say and do is gospel, i decided to qualify and quantify and prefix everything that i write with very unambigous and clear "this is what i tried, it worked mostly" words such as "i believe" and "it works for me". whilst this is as boring for me to have to do as it most likely is for you to have to repeatedly read, there isn't anything i can do about it: i am endeavouring to get a debian selinux system and running as quickly as possible, and am having to learn on-the-fly and avoid things like "it would be nice if". l. > Joshua > > Luke Kenneth Casson Leighton wrote: > > >On Sun, Aug 22, 2004 at 09:25:38PM +1000, Russell Coker wrote: > > > > > >>It seems that udev is now virtually mandatory as of the latest rawhide > >>update. > >> > >>udev uses ramfs for /tmp, ramfs (as of the latest Fedora kernel > >>2.6.8-1.525) has no support for file labelling and breaks everything. > >> > >>Can we get ramfs labelling working in the next few days or do we have to > >>change things to not depend on udev? > >> > >> From lkcl at lkcl.net Sun Aug 22 17:34:57 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 22 Aug 2004 18:34:57 +0100 Subject: Fedora and udev In-Reply-To: <4128B637.8040900@tresys.com> References: <200408222125.38169.russell@coker.com.au> <4128B637.8040900@tresys.com> Message-ID: <20040822173457.GD13842@lkcl.net> On Sun, Aug 22, 2004 at 11:05:27AM -0400, Joshua Brindle wrote: > I posted a patch here that pebenito did a while back for ramfs and lkcl > also did one for tmpfs (which may be better for /dev since it's swappable) > both are mostly cut and paste jobs but they add the necessary support. > > I'd like to reiterate though, that udev support for selinux is *broken*! > if the correct policy isn't in place you will cause race conditions udev is so completely full of race conditions - known to the developers even _without_ selinux - that the general consensus seems to be that a few more really won't hurt. plus, i patched udev (0.030) to add in proper support for selinux (attached previously in first response to russell's post). that patch ensures (without saving any extra time) that the device inodes created, and any directories, _and_ any symlinks (which the /etc/udev/default/selinux thing most definitely didn't do) all use setfscreatecon rather than doing a restorecon-or-equiv. without this patch you will most likely come across issues or end up developing an incorrect policy (that ended up with a mismatch of default permissions from file_contexts for subdirectories and symlinks). joshua, when you used ramfs, can you remember what the fscontext was for /dev when it was mounted? l. From lkcl at lkcl.net Mon Aug 23 08:56:48 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 23 Aug 2004 09:56:48 +0100 Subject: Fedora and udev In-Reply-To: <200408231209.01521.russell@coker.com.au> References: <200408222125.38169.russell@coker.com.au> <200408231209.01521.russell@coker.com.au> Message-ID: <20040823085648.GC15972@lkcl.net> On Mon, Aug 23, 2004 at 12:09:01PM +1000, Russell Coker wrote: > On Mon, 23 Aug 2004 00:00, Alexandre Oliva wrote: > > On Aug 22, 2004, Russell Coker wrote: > > > It seems that udev is now virtually mandatory as of the latest > > > rawhide update. > > > > This is what makes it, like, mandatory: > > > > /etc/udev/udev.conf: > > UDEV_INITRD="yes" > > > > Change it to `no' and hopefully everything will work again. It breaks > > more than SELinux. > > Thanks for that advice. Once I looked at that I noticed that there's an > option UDEV_RAMFS in the same file which must be set to "no". I'm not sure > whether UDEV_RAMFS="no" would allow it to work on SE Linux with > UDEV_INITRD="yes" but don't have any plans to test this at the moment. where does that option come from? on debian, all the options in 0.030's config file are lower-case, and there's no udev_initrd="yes" or "no". > We either need to get ramfs working in the Fedora kernels or make some changes > to the udev plans. > > One option would be to use an ext2 file system on a ram disk for udev. It > would do all the same stuff as ramfs (at a slightly higher memory cost) and > work perfectly with SE Linux. *whew*. l. From lkcl at lkcl.net Mon Aug 23 12:04:41 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 23 Aug 2004 13:04:41 +0100 Subject: Fedora and udev In-Reply-To: <20040823085648.GC15972@lkcl.net> References: <200408222125.38169.russell@coker.com.au> <200408231209.01521.russell@coker.com.au> <20040823085648.GC15972@lkcl.net> Message-ID: <20040823120441.GG13842@lkcl.net> On Mon, Aug 23, 2004 at 09:56:48AM +0100, Luke Kenneth Casson Leighton wrote: > > We either need to get ramfs working in the Fedora kernels or make some changes > > to the udev plans. > > > > One option would be to use an ext2 file system on a ram disk for udev. It > > would do all the same stuff as ramfs (at a slightly higher memory cost) and > > work perfectly with SE Linux. ... but it would still leave you with the patches to udev to apply [to do symlinks and directories as well as inodes] and also would leave you with an "initial startup" issue to set up initial perms on /dev/null, /dev/initctl, rights to create /dev/fd/ etc. all the stuff that the /etc/init.d/udev "hacks" do. ... just because you're using a persistent ext2 filesystem with xattr permissions storable on a ramdisk it doesn't mean you'd have initial setup issues! but yes, those could be set up once, in permissive mode, and consequently the problem is avoided. l. From walters at redhat.com Mon Aug 23 19:37:36 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 23 Aug 2004 15:37:36 -0400 Subject: trouble shutting down avc netlink socket Message-ID: <1093289856.5353.5.camel@nexus.verbum.private> Hi, I'm having a problem where calling avc_destroy doesn't seem to close the netlink socket, because a subsequent avc_init is unable to bind to the socket, and gets an error "Address already in use". The attached test program lets me reproduce the problem - the very interesting thing is it seems to only happen about 50% of the time. Is there some race here in the kernel? As far as I can tell the close() is being called so the socket should be shut down. -------------- next part -------------- A non-text attachment was scrubbed... Name: selinux-netlink-test.c Type: text/x-csrc Size: 6365 bytes Desc: not available URL: -------------- 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 sds at epoch.ncsc.mil Mon Aug 23 20:17:15 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 23 Aug 2004 16:17:15 -0400 Subject: trouble shutting down avc netlink socket In-Reply-To: <1093289856.5353.5.camel@nexus.verbum.private> References: <1093289856.5353.5.camel@nexus.verbum.private> Message-ID: <1093292235.27211.277.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2004-08-23 at 15:37, Colin Walters wrote: > Hi, > > I'm having a problem where calling avc_destroy doesn't seem to close the > netlink socket, because a subsequent avc_init is unable to bind to the > socket, and gets an error "Address already in use". > > The attached test program lets me reproduce the problem - the very > interesting thing is it seems to only happen about 50% of the time. Is > there some race here in the kernel? > > As far as I can tell the close() is being called so the socket should be > shut down. Changing libselinux to not set the pid in the socket address (so that the kernel auto-binds the socket) seems to avoid the problem, but this may just be covering the underlying bug. Index: libselinux/src/avc_internal.c =================================================================== RCS file: /nfshome/pal/CVS/selinux-usr/libselinux/src/avc_internal.c,v retrieving revision 1.14 diff -u -r1.14 avc_internal.c --- libselinux/src/avc_internal.c 15 Jun 2004 18:47:10 -0000 1.14 +++ libselinux/src/avc_internal.c 23 Aug 2004 20:11:31 -0000 @@ -69,7 +69,6 @@ memset(&addr, 0, len); addr.nl_family = AF_NETLINK; - addr.nl_pid = getpid(); addr.nl_groups = SELNL_GRP_AVC; if (bind(fd, (struct sockaddr *)&addr, len) < 0) { -- Stephen Smalley National Security Agency From kwade at redhat.com Mon Aug 23 21:24:45 2004 From: kwade at redhat.com (Karsten Wade) Date: Mon, 23 Aug 2004 14:24:45 -0700 Subject: issue on 'fixfiles relabel' In-Reply-To: <1092419377.23108.257.camel@moss-spartans.epoch.ncsc.mil> References: <20040813152635.28451.qmail@web51502.mail.yahoo.com> <1092419377.23108.257.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1093296284.17095.30329.camel@erato.phig.org> On Fri, 2004-08-13 at 10:49, Stephen Smalley wrote: > On Fri, 2004-08-13 at 11:26, Park Lee wrote: > > On Thu, 03 Jun 2004 10:29:17, Stephen Smalley wrote: > > >The policy package installs a copy of the file_contexts file to > > >/etc/security/selinux so that it is available for use by fixfiles, > > >setfiles, or restorecon even if policy sources is not available. > > But in <>,there is one statement: > > > You will need to have the policy-sources package > > > installed to use setfiles. > > > > Then, If policy package installs a copy of the file_contexts file to > > /etc/security/selinux, is it necessary to install policy-sources > > package in order to use setfiles? > > No, policy-sources is not required to use setfiles; you can apply > setfiles to the installed file_contexts configuration file (and fixfiles > is just a script that runs setfiles on it). Bug in the FAQ, please > bugzilla it. I'm including this update in the FAQ update (1.2-8), along with several others. The FC2 SELinux FAQ should then be current. I'm working on an FC3test1 FAQ, as there have been some noteworthy changes since FC2. - Karsten -- Karsten Wade, RHCE, 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 paolo_cavarretta at yahoo.it Mon Aug 23 22:09:30 2004 From: paolo_cavarretta at yahoo.it (=?iso-8859-1?q?Paolo=20Cavarretta?=) Date: Tue, 24 Aug 2004 00:09:30 +0200 (CEST) Subject: policy management tools Message-ID: <20040823220930.92896.qmail@web53104.mail.yahoo.com> Hi everyone, I red about some nice gui tools for managing policies at http://www.tresys.com/selinux/selinux_policy_tools.html I would like to know if You have experience with these programs and if You think it could be a good idea to install it for an easier policy management thanks everyone, Paolo ___________________________________ Yahoo! Companion - Scarica gratis la toolbar di Ricerca di Yahoo! http://companion.yahoo.it From n3npq at nc.rr.com Mon Aug 23 22:23:10 2004 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 23 Aug 2004 18:23:10 -0400 Subject: glibc post upgrade In-Reply-To: <412A3701.2020401@redhat.com> References: <200408232344.23345.russell@coker.com.au> <412A21A6.7040203@nc.rr.com> <1093281676.27211.159.camel@moss-spartans.epoch.ncsc.mil> <412A3701.2020401@redhat.com> Message-ID: <412A6E4E.5080600@nc.rr.com> Daniel J Walsh wrote: > Stephen Smalley wrote: > >> On Mon, 2004-08-23 at 12:56, Jeff Johnson wrote: >> >> >>> Yes, rpm_script_t is applied only for /bin/sh, not for other helpers >>> like /sbin/ldconfig, and >>> /usr/sbin/{glibc,libgcc}_post_upgrade, to name the other known helpers. >>> >>> I can certainly change that behavior, and have asked several times >>> if I should, with no answer. >>> >> >> >> I think it should change. For now, I'd say just use rpm_script_t for >> all commands executed from the scriptlets specified in the spec file, >> whether run via an interpreter or as a direct executable. Note that on >> the policy side, the domain_trans(rpm_t, shell_exec_t, rpm_script_t) >> rule should be changed to include any of the possible entrypoint >> types. However, it should work even without that change in the Fedora >> policy, >> because the unlimitedRPM tunable is enabled by default. >> >> >> > I agree, make the change. Well, it's not that simple. On a parallel, multilib install battle front, /usr/bin/{glibc,libgcc} have also been causing rpm pain. The packaging requirements are that these packages must be installable into an empty chroot, i.e. no /bin/sh, hence statically linked helpers. Unfortunately, the statically linked helpers are installed on the same path, but are platform dependent. The statically linked helpers are also quite mysterious, e.g. this isn't the first time that the rpm_t vs. rpm_script_t has been raised. One approach to a multilib packaging solution is to use embedded lua to avoid platform dependent helpers that are on conflicting paths. But that then means that embedded lua will be run as "rpm_t", not "rpm_script_t", as this is rpm running in a nearly empty chroot. There are no easy answers for conflicting needs. Something has to give, either selinux policy or multilib paths. 73 de Jeff > > Dan > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > From bam at snoopy.apana.org.au Mon Aug 23 22:34:54 2004 From: bam at snoopy.apana.org.au (Brian May) Date: Tue, 24 Aug 2004 08:34:54 +1000 Subject: Fedora and udev In-Reply-To: <20040822173457.GD13842@lkcl.net> (Luke Kenneth Casson Leighton's message of "Sun, 22 Aug 2004 18:34:57 +0100") References: <200408222125.38169.russell@coker.com.au> <4128B637.8040900@tresys.com> <20040822173457.GD13842@lkcl.net> Message-ID: >>>>> "Luke" == Luke Kenneth Casson Leighton writes: Luke> udev is so completely full of race conditions - known to the Luke> developers even _without_ selinux - that the general Luke> consensus seems to be that a few more really won't hurt. Wasn't one of the major selling points of udev that it would have fewer race conditions then devfs? -- Brian May From greg at kroah.com Mon Aug 23 22:44:44 2004 From: greg at kroah.com (Greg KH) Date: Mon, 23 Aug 2004 15:44:44 -0700 Subject: Fedora and udev In-Reply-To: <20040822173457.GD13842@lkcl.net> References: <200408222125.38169.russell@coker.com.au> <4128B637.8040900@tresys.com> <20040822173457.GD13842@lkcl.net> Message-ID: <20040823224444.GI4694@kroah.com> On Sun, Aug 22, 2004 at 06:34:57PM +0100, Luke Kenneth Casson Leighton wrote: > On Sun, Aug 22, 2004 at 11:05:27AM -0400, Joshua Brindle wrote: > > I posted a patch here that pebenito did a while back for ramfs and lkcl > > also did one for tmpfs (which may be better for /dev since it's swappable) > > both are mostly cut and paste jobs but they add the necessary support. > > > > I'd like to reiterate though, that udev support for selinux is *broken*! > > if the correct policy isn't in place you will cause race conditions > > udev is so completely full of race conditions - known to the > developers even _without_ selinux - that the general consensus > seems to be that a few more really won't hurt. Huh? I know of no such thing. Without SELinux, and with the recent patch on the hotplug mailing list, I know of no race conditions in the current udev code. Please let me know what you are talking about (and don't use my gentoo.org address, it's not my main one at all...) > plus, i patched udev (0.030) to add in proper support for selinux > (attached previously in first response to russell's post). Please fix that patch up to: - not have any ifdef in the .c files - use the proper coding style - use the same convention as the other build flags have. Actually, what was wrong with the older selinux support in udev that was there? Why not just dig that stuff up and see if it works or not (I bet it does...) If so, I'll be glad to add it back in, it's just that too many people complained about it when it was in there... Oh, and udev does not require a ramfs, or tmpfs at all, that's just how the distro decided to use it. thanks, greg k-h From jbrindle at tresys.com Mon Aug 23 22:50:14 2004 From: jbrindle at tresys.com (Joshua Brindle) Date: Mon, 23 Aug 2004 18:50:14 -0400 Subject: Fedora and udev In-Reply-To: <20040823224444.GI4694@kroah.com> References: <200408222125.38169.russell@coker.com.au> <4128B637.8040900@tresys.com> <20040822173457.GD13842@lkcl.net> <20040823224444.GI4694@kroah.com> Message-ID: <412A74A6.9070206@tresys.com> Greg KH wrote: >Please fix that patch up to: > - not have any ifdef in the .c files > - use the proper coding style > - use the same convention as the other build flags have. > >Actually, what was wrong with the older selinux support in udev that was >there? Why not just dig that stuff up and see if it works or not (I bet >it does...) If so, I'll be glad to add it back in, it's just that too >many people complained about it when it was in there... > > Who complained and why? When selinux support wasn't built in the functions were just stubs, how could that have possibly had any effect whatsoever on anyone else? If you could, please paste a patch from the older version so that we can see here whether it should work right (it's possible that the libselinux api changed between then and now) >Oh, and udev does not require a ramfs, or tmpfs at all, that's just how >the distro decided to use it. > > > Joshua Brindle From greg at kroah.com Mon Aug 23 23:07:32 2004 From: greg at kroah.com (Greg KH) Date: Mon, 23 Aug 2004 16:07:32 -0700 Subject: Fedora and udev In-Reply-To: <412A74A6.9070206@tresys.com> References: <200408222125.38169.russell@coker.com.au> <4128B637.8040900@tresys.com> <20040822173457.GD13842@lkcl.net> <20040823224444.GI4694@kroah.com> <412A74A6.9070206@tresys.com> Message-ID: <20040823230732.GL4694@kroah.com> On Mon, Aug 23, 2004 at 06:50:14PM -0400, Joshua Brindle wrote: > Greg KH wrote: > > >Please fix that patch up to: > > - not have any ifdef in the .c files > > - use the proper coding style > > - use the same convention as the other build flags have. > > > >Actually, what was wrong with the older selinux support in udev that was > >there? Why not just dig that stuff up and see if it works or not (I bet > >it does...) If so, I'll be glad to add it back in, it's just that too > >many people complained about it when it was in there... > > > > > Who complained and why? When selinux support wasn't built in the > functions were just stubs, how could that have possibly had any effect > whatsoever on anyone else? I had complaints from SELinux users, not anyone else. I don't remember the exact complaints, sorry. > If you could, please paste a patch from the older version so that we can > see here whether it should work right (it's possible that the libselinux > api changed between then and now) Hm, it's a bit hard to dig that up. But here's a patch that you can reverse that should add the support back in. You'll have to just dig out the udev_selinux.c file from an older version of udev to see the code there. If you want me to put the code back, I'll be glad to, just structure it properly and I have no problems with it. thanks, greg k-h diff -Nru a/udev-add.c b/udev-add.c --- a/udev-add.c 2004-08-23 16:05:17 -07:00 +++ b/udev-add.c 2004-08-23 16:05:17 -07:00 @@ -39,7 +39,6 @@ #include "udev.h" #include "udev_lib.h" #include "udev_version.h" -#include "udev_selinux.h" #include "logging.h" #include "namedev.h" #include "udevdb.h" @@ -276,9 +275,6 @@ } } } - - if (!fake) - selinux_add_node(filename); /* create symlink if requested */ foreach_strpart(dev->symlink, " ", pos, len) { diff -Nru a/udev_selinux.h b/udev_selinux.h --- a/udev_selinux.h 2004-08-23 16:05:17 -07:00 +++ /dev/null Wed Dec 31 16:00:00 196900 @@ -1,10 +0,0 @@ -#ifndef UDEV_SELINUX_H -#define UDEV_SELINUX_H - -#ifdef USE_SELINUX -extern void selinux_add_node(char *filename); -#else -static void selinux_add_node(char *filename) { } -#endif - -#endif From greg at kroah.com Mon Aug 23 23:39:39 2004 From: greg at kroah.com (Greg KH) Date: Mon, 23 Aug 2004 16:39:39 -0700 Subject: udev strange-ness In-Reply-To: <200408231647.21379.russell@coker.com.au> References: <200408231647.21379.russell@coker.com.au> Message-ID: <20040823233939.GN4694@kroah.com> On Mon, Aug 23, 2004 at 04:47:21PM +1000, Russell Coker wrote: > Why is bash accessing iptables, and arping on behalf of udev? > > I expect that the dhclient-eth0.conf file is just from an inherited file > handle (although I don't know why it was opened, I don't have dhclient > installed any more, maybe a bug in hotplug). Odds are you have a rule that renames a network device, which causes the script in /etc/dev.d/net/hotplug.dev to be run by udev, which calls back into the hotplug network script file. Ah, what a tangled web... greg k-h From russell at coker.com.au Tue Aug 24 07:25:07 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 24 Aug 2004 17:25:07 +1000 Subject: Fedora and udev In-Reply-To: <1093286952.4101.47.camel@bree.local.net> References: <200408222125.38169.russell@coker.com.au> <200408231209.01521.russell@coker.com.au> <1093286952.4101.47.camel@bree.local.net> Message-ID: <200408241725.07093.russell@coker.com.au> On Tue, 24 Aug 2004 04:49, Jeremy Katz wrote: > > One option would be to use an ext2 file system on a ram disk for udev. > > It would do all the same stuff as ramfs (at a slightly higher memory > > cost) and work perfectly with SE Linux. > > It has a number of other, not really desired side effects as well. > 1) Kernel people don't really like ramdisks anymore > 2) Doing this requires mke2fs in the initramfs. Bleah. > 3) It puts an artificial cap on the size of your /dev that then has to > be adjustable. And the cap is related to an overhead of memory usage. > This is ugly to get "right" I agree that ext2 is not a long-term solution to this problem. However at the moment we have a default configuration that's grossly broken with regard to SE Linux. If you upgrade a machine which runs the "targeted" policy to rawhide then several important daemons (including syslogd) stop working. If you upgrade a machine which runs the "strict" policy then it will fail to boot. If we were unable to get ramfs working in a reasonable amount of time then ext2 would be a good option to consider IMHO. -- 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 laroche at redhat.com Tue Aug 24 07:30:09 2004 From: laroche at redhat.com (Florian La Roche) Date: Tue, 24 Aug 2004 09:30:09 +0200 Subject: Fedora and udev In-Reply-To: <200408241725.07093.russell@coker.com.au> References: <200408222125.38169.russell@coker.com.au> <200408231209.01521.russell@coker.com.au> <1093286952.4101.47.camel@bree.local.net> <200408241725.07093.russell@coker.com.au> Message-ID: <20040824073009.GA10773@dudweiler.stuttgart.redhat.com> On Tue, Aug 24, 2004 at 05:25:07PM +1000, Russell Coker wrote: > On Tue, 24 Aug 2004 04:49, Jeremy Katz wrote: > > > One option would be to use an ext2 file system on a ram disk for udev. > > > It would do all the same stuff as ramfs (at a slightly higher memory > > > cost) and work perfectly with SE Linux. > > > > It has a number of other, not really desired side effects as well. > > 1) Kernel people don't really like ramdisks anymore > > 2) Doing this requires mke2fs in the initramfs. Bleah. > > 3) It puts an artificial cap on the size of your /dev that then has to > > be adjustable. And the cap is related to an overhead of memory usage. > > This is ugly to get "right" > > I agree that ext2 is not a long-term solution to this problem. > > However at the moment we have a default configuration that's grossly broken > with regard to SE Linux. If you upgrade a machine which runs the "targeted" > policy to rawhide then several important daemons (including syslogd) stop > working. If you upgrade a machine which runs the "strict" policy then it > will fail to boot. > > If we were unable to get ramfs working in a reasonable amount of time then > ext2 would be a good option to consider IMHO. It's nice if people experiment with the ramdisk setup, but given the many limitations of it I doubt this should be the default setup or something we encourage people to use. greetings, Florian La Roche From russell at coker.com.au Tue Aug 24 10:06:41 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 24 Aug 2004 20:06:41 +1000 Subject: Fedora and udev In-Reply-To: <20040824092853.GD25356@lkcl.net> References: <200408222125.38169.russell@coker.com.au> <412A74A6.9070206@tresys.com> <20040824092853.GD25356@lkcl.net> Message-ID: <200408242006.41591.russell@coker.com.au> On Tue, 24 Aug 2004 19:28, Luke Kenneth Casson Leighton wrote: > 2) it ONLY set the permissions on the inode NOT on any symlinks and NOT > on any directories or subdirectories created. This part is OK. We have moved to using device_t (the default) as the context for all directories and sym-links under /dev. > what _should_ be done is that udev (or udevd) should be patched to > popen("setfiles -q -s", "w") and then when each device inode is > created (and a udevsend is exec'd to do it), the filename of the > device inode is ALSO sent down the pipe to setfiles. > > i say should, what i mean is, this is the most non-nasty solution > with the tools and options presently available. Sounds good to me. > if the file_contexts stuff was somehow pre-munged and > transferred into kernel, and the regexp matching code (or > something similar) was _also_ transferred into the kernel, > then this problem would go away. I think it's already been decided not to do that. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From sds at epoch.ncsc.mil Tue Aug 24 11:23:39 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Tue, 24 Aug 2004 07:23:39 -0400 Subject: policy management tools In-Reply-To: <20040823220930.92896.qmail@web53104.mail.yahoo.com> References: <20040823220930.92896.qmail@web53104.mail.yahoo.com> Message-ID: <1093346619.1800.28.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2004-08-23 at 18:09, Paolo Cavarretta wrote: > Hi everyone, > > I red about some nice gui tools for managing policies > at > http://www.tresys.com/selinux/selinux_policy_tools.html > > I would like to know if You have experience with these > programs and if You think it could be a good idea to > install it for an easier policy management They are already packaged for Fedora; yum install setools setools-gui. They are helpful, but better tools are still needed to make SELinux more accessible to a typical Linux/Unix sysadmin. -- Stephen Smalley National Security Agency From russell at coker.com.au Tue Aug 24 11:28:26 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 24 Aug 2004 21:28:26 +1000 Subject: hald startup ? In-Reply-To: <412A1201.7050006@comcast.net> References: <412A1201.7050006@comcast.net> Message-ID: <200408242128.26687.russell@coker.com.au> On Tue, 24 Aug 2004 01:49, Tom London wrote: > When hald starts (strict/enforcing) I get the following avc: > > Aug 23 08:20:29 fedora messagebus: messagebus startup succeeded > Aug 23 08:20:29 fedora kernel: audit(1093274429.575:0): avc: denied { > create } for pid=2796 exe=/usr/sbin/hald > scontext=system_u:system_r:hald_t tcontext=system_u:system_r:hald_t > tclass=unix_dgram_socket > > hald appears to die quietly. You need it. The new version of hald which just appeared in rawhide needs much more access. I've already sent a policy patch to the main SE Linux list, but I've attached the hald.te I'm using to this message to save you hunting it down. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -------------- next part -------------- #DESC hald - server for device info # # Author: Russell Coker # X-Debian-Packages: # ################################# # # Rules for the hald_t domain. # # hald_exec_t is the type of the hald executable. # daemon_domain(hald, `, dbus_client_domain, fs_domain') allow hald_t { etc_t etc_runtime_t }:file { getattr read }; allow hald_t self:unix_stream_socket create_stream_socket_perms; allow hald_t self:unix_dgram_socket create_socket_perms; allow hald_t dbusd_t:dbus { acquire_svc }; allow hald_t { self proc_t }:file { getattr read }; allow hald_t { bin_t sbin_t }:dir search; allow hald_t hald_t:fifo_file rw_file_perms; allow hald_t usr_t:file { getattr read }; allow hald_t bin_t:file { getattr }; allow hald_t self:netlink_route_socket r_netlink_socket_perms; allow hald_t self:capability { net_admin sys_admin }; can_network(hald_t) allow hald_t fixed_disk_device_t:blk_file { getattr read }; allow hald_t event_device_t:chr_file { getattr read }; ifdef(`updfstab.te', `domain_auto_trans(hald_t, updfstab_exec_t, updfstab_t)') ifdef(`udev.te', ` domain_auto_trans(hald_t, udev_exec_t, udev_t) allow udev_t hald_t:unix_dgram_socket sendto; ') allow hald_t usbdevfs_t:dir search; allow hald_t usbdevfs_t:file { getattr read }; From russell at coker.com.au Tue Aug 24 11:34:22 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 24 Aug 2004 21:34:22 +1000 Subject: latest policy: in.comsat, dbskkd-cdb, ktalkd, ... In-Reply-To: <1093277071.27211.114.camel@moss-spartans.epoch.ncsc.mil> References: <412A0DC0.8070006@comcast.net> <1093277071.27211.114.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200408242134.22290.russell@coker.com.au> On Tue, 24 Aug 2004 02:04, Stephen Smalley wrote: > On Mon, 2004-08-23 at 11:31, Tom London wrote: > > Latest Rawhide policy seems to 'reverse the labeling' of programs > > started from xinetd, like in.comsat, ... (strict/enforcing) > > inetd.fc entries removed at Russell's request, as the inetd_child_t > domain wasn't sufficient anyway to allow those programs to run properly, > and labeling them inetd_child_exec_t merely masked the lack of proper > security domains for those programs and encouraged bleeding permissions > into inetd_child_t. Some of those programs need to have policy written for them. Some need to be re-written, reconfigured, or replaced. At least now they won't be forgotten. Tom, if you would like to contribute policy for any of these... -- 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 Tue Aug 24 11:50:51 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Tue, 24 Aug 2004 07:50:51 -0400 Subject: Fedora and udev In-Reply-To: <20040824092853.GD25356@lkcl.net> References: <200408222125.38169.russell@coker.com.au> <4128B637.8040900@tresys.com> <20040822173457.GD13842@lkcl.net> <20040823224444.GI4694@kroah.com> <412A74A6.9070206@tresys.com> <20040824092853.GD25356@lkcl.net> Message-ID: <1093348251.1800.40.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2004-08-24 at 05:28, Luke Kenneth Casson Leighton wrote: > if the file_contexts stuff was somehow pre-munged and > transferred into kernel, and the regexp matching code (or > something similar) was _also_ transferred into the kernel, > then this problem would go away. Bad idea. The kernel only deals with file contexts via attributes on inodes that are set by some userspace entity; it does not deal with the file contexts configuration, nor should it. -- Stephen Smalley National Security Agency From selinux at comcast.net Tue Aug 24 14:17:48 2004 From: selinux at comcast.net (Tom London) Date: Tue, 24 Aug 2004 07:17:48 -0700 Subject: latest policy: in.comsat, dbskkd-cdb, ktalkd, .. Message-ID: <412B4E0C.4090907@comcast.net> Russell, Understood. Let me dig into it. tom > ------------------------------------------------------------------------ > > * /From/: Russell Coker > > ------------------------------------------------------------------------ > >On Tue, 24 Aug 2004 02:04, Stephen Smalley wrote: >> On Mon, 2004-08-23 at 11:31, Tom London wrote: >> > Latest Rawhide policy seems to 'reverse the labeling' of programs >> > started from xinetd, like in.comsat, ... (strict/enforcing) >> >> inetd.fc entries removed at Russell's request, as the inetd_child_t >> domain wasn't sufficient anyway to allow those programs to run properly, >> and labeling them inetd_child_exec_t merely masked the lack of proper >> security domains for those programs and encouraged bleeding permissions >> into inetd_child_t. > >Some of those programs need to have policy written for them. Some need to be >re-written, reconfigured, or replaced. At least now they won't be forgotten. > >Tom, if you would like to contribute policy for any of these... > From lkcl at lkcl.net Tue Aug 24 09:17:11 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 24 Aug 2004 10:17:11 +0100 Subject: Fedora and udev In-Reply-To: <412A74A6.9070206@tresys.com> References: <200408222125.38169.russell@coker.com.au> <4128B637.8040900@tresys.com> <20040822173457.GD13842@lkcl.net> <20040823224444.GI4694@kroah.com> <412A74A6.9070206@tresys.com> Message-ID: <20040824091710.GC25356@lkcl.net> On Mon, Aug 23, 2004 at 06:50:14PM -0400, Joshua Brindle wrote: > Greg KH wrote: > > >Please fix that patch up to: > > - not have any ifdef in the .c files > > - use the proper coding style > > - use the same convention as the other build flags have. dear greg, given that you do not appear to work for redhat, you will not be aware of some things, and therefore i should make some explanation. 1) i am in a hurry. i am doing a demo for some customers and it's gotta work and it's gotta look good. 2) i don't get paid to do this, i'm doing it on the strength of the possibility that the demo will be good enough. 3) i used to work on samba, providing NT domains compatibility, samba as you are no doubt aware is a program that allowed all those corporate linux companies who applied for IPOs in 1998-2000 to "tick the boxes" when approaching potential customers (windows-only shops) where the most important box to tick was "file print and logon services". NOT ONE of those companies included me in their IPOs: i had someone come up to me in 1998 saying "i wrote a mouse howto for the linux kernel, and got enough money from redhat's IPO to pay off my mortgage - you worked on samba _you_ must have got a lot" and the guy was terribly embarrassed when i told him that i didn't get a penny. that trend continued right through caldera's IPO, valinux's IPO etc. even though i was working in the U.S. basically, what i am getting round to saying is that i'm sending what i have done here to the selinux mailing lists, and should it prove useful, feel free to use it. in several months time, i _might_ not have gone bankrupt, such that i _might_ be in a position to tidy things up. in the mean-time i'm sending what i have done: 1) as a favour to redhat (and i am trying to forget 3 above) and 2) because if other people do similar or same as i have, it makes my life easier for maintenance later on. l. -- -- Truth, honesty and respect are rare commodities that all spring from the same well: Love. If you love yourself and everyone and everything around you, funnily and coincidentally enough, life gets a lot better. -- lkcl.net
lkcl at lkcl.net
From lkcl at lkcl.net Tue Aug 24 09:41:57 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 24 Aug 2004 10:41:57 +0100 Subject: Fedora and udev In-Reply-To: <412A74A6.9070206@tresys.com> References: <200408222125.38169.russell@coker.com.au> <4128B637.8040900@tresys.com> <20040822173457.GD13842@lkcl.net> <20040823224444.GI4694@kroah.com> <412A74A6.9070206@tresys.com> Message-ID: <20040824094157.GF25356@lkcl.net> dear fedora-selinux people, i am not subscribed to the fedora-selinux list so am just going through the archives looking for bits i may have missed. regarding this: > > udev is so completely full of race conditions - known to the > > developers even _without_ selinux - that the general consensus > > seems to be that a few more really won't hurt. > Huh? I know of no such thing. > Without SELinux, and with the recent patch on the hotplug mailing list, > I know of no race conditions in the current udev code. the present (0.030's /etc/udev.d/default/selinux script and past (0.024 built-in)selinux udev support allows for a race condition in between the creation of the inode (with its default, per-directory selinux context being used) and the context being properly set (with /sbin/restorecon in the case of 0.030 and with setfilecon() in the case of 0.024). that's why i added code to use setfscreatecon(). the debian maintainer for udev is under the impression that udev has stacks of race conditions: if that isn't actually the case, then great! l. From lkcl at lkcl.net Tue Aug 24 09:28:53 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 24 Aug 2004 10:28:53 +0100 Subject: Fedora and udev In-Reply-To: <412A74A6.9070206@tresys.com> References: <200408222125.38169.russell@coker.com.au> <4128B637.8040900@tresys.com> <20040822173457.GD13842@lkcl.net> <20040823224444.GI4694@kroah.com> <412A74A6.9070206@tresys.com> Message-ID: <20040824092853.GD25356@lkcl.net> On Mon, Aug 23, 2004 at 06:50:14PM -0400, Joshua Brindle wrote: > Greg KH wrote: > > >Please fix that patch up to: > > - not have any ifdef in the .c files > > - use the proper coding style > > - use the same convention as the other build flags have. > > > >Actually, what was wrong with the older selinux support in udev that was > >there? Why not just dig that stuff up and see if it works or not (I bet > >it does...) If so, I'll be glad to add it back in, it's just that too > >many people complained about it when it was in there... > > > > > Who complained and why? When selinux support wasn't built in the > functions were just stubs, how could that have possibly had any effect > whatsoever on anyone else? there was a bugreport on debian.org complaining about the d-bus support which took ONE SECOND per inode created (most probably due to poor design of d-bus, e.g. not having a prefork'd server like apache does) due to the multi-exe design of udev (udevd, udev, udevsend) it is quite difficult to maintain persistent network or socket connections such that both d-bus and libselinux1 "cacheing" can be taken advantage of. [libselinux1 does cacheing of file context lookups - this can only be taken advantage of IF you use a single process, of course - and udevsend is only given ONE device name to create, and then it exits] consequently, d-bus support was ripped out and disabled. and it looks like the selinux support, which wasn't very good anyway, was also removed and turned into a script that ran "restorecon" post-inode creation, see /etc/udev.d/default/selinux. > If you could, please paste a patch from the older version so that we can > see here whether it should work right (it's possible that the libselinux > api changed between then and now) udev-0.024 was the last version containing selinux support, i had to track it down. iirc: 1) it used setfilecon() not setfscreatecon(). 2) it ONLY set the permissions on the inode NOT on any symlinks and NOT on any directories or subdirectories created. the patch i created is at least an attempt to GetThingsWorking(tm). if time REALLY IS a major concern: what _should_ be done is that udev (or udevd) should be patched to popen("setfiles -q -s", "w") and then when each device inode is created (and a udevsend is exec'd to do it), the filename of the device inode is ALSO sent down the pipe to setfiles. i say should, what i mean is, this is the most non-nasty solution with the tools and options presently available. if the file_contexts stuff was somehow pre-munged and transferred into kernel, and the regexp matching code (or something similar) was _also_ transferred into the kernel, then this problem would go away. l. -- -- Truth, honesty and respect are rare commodities that all spring from the same well: Love. If you love yourself and everyone and everything around you, funnily and coincidentally enough, life gets a lot better. -- lkcl.net
lkcl at lkcl.net
From lkcl at lkcl.net Tue Aug 24 14:18:28 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 24 Aug 2004 15:18:28 +0100 Subject: Fedora and udev In-Reply-To: <200408242006.41591.russell@coker.com.au> References: <200408222125.38169.russell@coker.com.au> <412A74A6.9070206@tresys.com> <20040824092853.GD25356@lkcl.net> <200408242006.41591.russell@coker.com.au> Message-ID: <20040824141828.GA4698@lkcl.net> On Tue, Aug 24, 2004 at 08:06:41PM +1000, Russell Coker wrote: > On Tue, 24 Aug 2004 19:28, Luke Kenneth Casson Leighton wrote: > > 2) it ONLY set the permissions on the inode NOT on any symlinks and NOT > > on any directories or subdirectories created. > > This part is OK. We have moved to using device_t (the default) as the context > for all directories and sym-links under /dev. great, then the policy modifications i've made will be of some value in pointing you in the right direction, i'll endeavour to clean them up, sort them out [dammit i just did that and ended up accidentally deleting it, i _must_ try to stop the habit of reusing filenames f g h x y and z] i'm attaching also my modified /etc/init.d/udev file. as you can see it calls /sbin/restoredevicefiles (sent earlier) after the make_extra_nodes() call has been made. why? because it is necessary to do a restorecon on every item created in /dev, and this is _before_ udev is running, and it is _to_ get udev running! i mean, sure, it's fine to grant udev permission to do stuff to device_t:file/directory instead (or as well?) such that it can "get started" and then "replace" or "re-restore" permissions on entries listed in /etc/udev/links.conf, that's another approach i imagine could be taken. > > if the file_contexts stuff was somehow pre-munged and > > transferred into kernel, and the regexp matching code (or > > something similar) was _also_ transferred into the kernel, > > then this problem would go away. > > I think it's already been decided not to do that. oh. right. ah well. Next :) From lkcl at lkcl.net Tue Aug 24 16:01:26 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 24 Aug 2004 17:01:26 +0100 Subject: Fedora and udev In-Reply-To: <20040824141828.GA4698@lkcl.net> References: <200408222125.38169.russell@coker.com.au> <412A74A6.9070206@tresys.com> <20040824092853.GD25356@lkcl.net> <200408242006.41591.russell@coker.com.au> <20040824141828.GA4698@lkcl.net> Message-ID: <20040824160126.GA19197@lkcl.net> On Tue, Aug 24, 2004 at 03:18:28PM +0100, Luke Kenneth Casson Leighton wrote: > On Tue, Aug 24, 2004 at 08:06:41PM +1000, Russell Coker wrote: > > On Tue, 24 Aug 2004 19:28, Luke Kenneth Casson Leighton wrote: > > > 2) it ONLY set the permissions on the inode NOT on any symlinks and NOT > > > on any directories or subdirectories created. > > > > This part is OK. We have moved to using device_t (the default) as the context > > for all directories and sym-links under /dev. > > great, then the policy modifications i've made will be of some > value in pointing you in the right direction, i'll endeavour to > clean them up, sort them out [dammit i just did that and ended > up accidentally deleting it, i _must_ try to stop the habit of > reusing filenames f g h x y and z] > > i'm attaching also my modified /etc/init.d/udev file. > > as you can see it calls /sbin/restoredevicefiles (sent earlier) > after the make_extra_nodes() call has been made. well you _could_ if i attached it. okay, also attached the most historically horrible "ItWorksForMe(tm)" udev-device-t-patch for selinux. note that there are some awful hacks in here such as allow hotplug_t device_t:file { ioctl read write }; the reason for this horrible hack is because, i believe, i am running /bin/ls from inside my horrible hack script /sbin/restoredevicefiles. during the setup phase, no program should endeavour to access /dev/null. less obvious ones are: allow init_t device_t:fifo_file { getattr read write }; to access /dev/initctl now, this _could_ be due to a mistake that i made, because strictly speaking, /dev/initctl should be in /dev as in a _real_ /dev on a _real_ ext2 persistent filesystem. stephen's explanation about setfiles not traversing mount points including --rbind moved mountpoints _could_ explain why i was having the above difficulties, namely that if /.dev was not being relabelled, then /.dev/initctl would be as the default device_t type, such that on an initial boot (prior to /dev getting --rbind mount moved to /dev by /etc/init.d/udev) the filecontext was incorrect. but, like i said earlier, i believe that setfiles was _not_ doing a proper job of ignoring --rbind mountpoints, and consequently a make relabel or a setfiles / resulted in /.dev _deliberately_ being set to something it should not have been set to. which reminds me to suggest that for this reason, it might be necessary to add /.dev to the make relabel rule in setfiles. oh, and of course to add in /.?u?dev [or a better regexp] to every single line in the file contexts thing. at this point i have to confess that i am getting a little confused because there is so much that i have just ridden slip-shod over in the past few weeks and approximately 100 reboots in order to get a working system: priority of time and running out of cash. l. -------------- next part -------------- #!/bin/sh -e PATH="/sbin:/bin" UDEVSTART=/sbin/udevstart # default maximum size of the /dev tmpfs tmpfs_size="1M" [ -x $UDEVSTART ] || exit 0 . /etc/udev/udev.conf case "$(uname -r)" in 2.[012345].*) echo "udev requires a 2.6.x kernel, not started." exit 0 ;; esac if ! grep -q '[[:space:]]tmpfs$' /proc/filesystems; then echo "udev requires tmpfs support, not started." exit 0 fi if [ ! -e /proc/sys/kernel/hotplug ]; then echo "udev requires hotplug support, not started." exit 0 fi if [ "$udev_root" != "/dev/" ]; then echo "udev_root != /dev/, not started. Please check /etc/udev/udev.conf." exit 0 fi ############################################################################## # we need to unmount /dev/pts/ and remount it later over the tmpfs unmount_devpts() { if mountpoint -q /dev/pts/; then umount -l /dev/pts/ fi if mountpoint -q /dev/shm/; then umount -l /dev/shm/ fi } # mount a tmpfs over /dev, if somebody did not already do it mount_tmpfs() { if grep -E -q "^[^[:space:]]+ /dev tmpfs" /proc/mounts; then return 0 fi # /.dev is used by /sbin/MAKEDEV to access the real /dev directory. # if you don't like it just remove it. [ -d /.dev ] && mount --bind /dev /.dev echo -n "Mounting a tmpfs over /dev..." mount -n -o fscontext=system_u:object_r:device_t,size=$tmpfs_size,mode=0755 -t tmpfs none /dev echo "done." } # I hate this hack. -- Md make_extra_nodes () { grep '^[^#]' /etc/udev/links.conf | \ while read type name arg1; do [ "$type" -a "$name" -a ! -e "/dev/$name" -a ! -L "/dev/$name" ] ||continue case "$type" in L) ln -s $arg1 /dev/$name ;; D) mkdir -p /dev/$name ;; M) mknod --mode=600 /dev/$name $arg1 ;; *) echo "unparseable line ($type $name $arg1)" ;; esac done } # When modifying this script, do not forget that between the time that # the new /dev has been mounted and udevstart has been run there will be # no /dev/null. This also means that you cannot use the "&" shell command. ############################################################################## case "$1" in start) unmount_devpts mount_tmpfs ACTION=add echo -n "Creating initial device nodes..." $UDEVSTART make_extra_nodes # all extra nodes created we must do the security contexts on them, oh dear. if [ -x /sbin/restoredevicefiles ]; then /sbin/restoredevicefiles fi echo "done." ;; remove) # I'm not sure this is useful ACTION=remove echo -n "Removing device nodes..." old_synthesize_events echo "done." ;; stop) start-stop-daemon --stop --exec /sbin/udevd --oknodo --quiet unmount_devpts echo -n "Unmounting /dev..." # unmounting with -l should never fail if umount -l /dev; then echo "done." umount -l /.dev || true /etc/init.d/mountvirtfs start else echo "failed." fi ;; restart|force-reload) echo -n "Recreating device nodes..." ACTION=add $UDEVSTART make_extra_nodes echo "done." ;; *) echo "Usage: /etc/init.d/udev {start|stop|restart|force-reload}" exit 1 ;; esac exit 0 -------------- next part -------------- diff -Naur --- default.1.14/domains/misc/horrible_hacks.te 1970-01-01 01:00:00.000000000 +0100 +++ current/domains/misc/horrible_hacks.te 2004-08-22 18:15:37.000000000 +0100 @@ -0,0 +1,201 @@ +# this is to deal with restorecon devices being associated with udev's +# mounting of /dev as a fscontext=device_t. help, help, gloop! + +# this is to allow /etc/init.d/udev to do its horrible hacks +# if it wasn't done in /etc/init.d or it wasn't device_t under which +# /dev was mounted (mount ... -o fscontext=....device_t) then this +# would be different or not there: + +allow initrc_t device_t:dir { create setattr }; + #EXE=/bin/mkdir NAME=pts : create + #EXE=/bin/touch NAME=/ : setattr + +allow initrc_t device_t:lnk_file { create }; + #EXE=/bin/ln NAME=fd : create + +allow initrc_t device_t:blk_file { getattr }; + #EXE=/bin/ls PATH=/dev/ram0 : getattr + +allow initrc_t device_t:chr_file { getattr read write }; + #EXE=/bin/bash NAME=tty : read write + #EXE=/bin/ls PATH=/dev/ptmx : getattr + +# not sure about this one + +allow initrc_t fixed_disk_device_t:blk_file { getattr }; + #EXE=/bin/bash PATH=/dev/ram0 : getattr + + +allow init_t device_t:fifo_file { getattr read write }; + #EXE=/sbin/init PATH=/dev/initctl : getattr + #EXE=/sbin/init NAME=initctl : read write + +allow hotplug_t device_t:file { ioctl read write }; + #EXE=/bin/bash NAME=null : read + #EXE=/bin/bash NAME=null : write + #EXE=/bin/bash PATH=/dev/null : ioctl + +allow initrc_t memory_device_t:chr_file { getattr }; + #EXE=/bin/ls PATH=/dev/port : getattr + +allow initrc_t random_device_t:chr_file { getattr }; + #EXE=/bin/ls PATH=/dev/random : getattr + +allow initrc_t romfs_t:dir { search }; + #EXE=/bin/dash : search + +allow initrc_t usbfs_t:dir { getattr read search }; + #EXE=/bin/dash : search + #EXE=/bin/dash PATH=/proc/bus/usb : getattr + #EXE=/bin/ls : read + +allow udev_t device_t:file { getattr unlink }; + #EXE=/sbin/udev PATH=/dev/null : getattr + #EXE=/sbin/udev NAME=null : unlink + +allow udev_t etc_runtime_t:file { relabelfrom relabelto }; + #EXE=/bin/cp NAME=ifstate.hotplug : relabelfrom + #EXE=/bin/cp NAME=ifstate.hotplug : relabelto + +allow udev_t self:file { write }; + #EXE=/sbin/udev NAME=fscreate : write + +allow udev_t self:process { setfscreate }; + #EXE=/sbin/udev : setfscreate + + +allow initrc_t usbfs_t:file { getattr read }; + #EXE=/bin/dash PATH=/proc/bus/usb/devices : getattr + #EXE=/bin/grep NAME=devices : read + +allow insmod_t hotplug_etc_t:dir { getattr search }; + #EXE=/bin/dash PATH=/etc/hotplug : getattr + #EXE=/bin/dash NAME=hotplug : search + +allow device_t device_t:filesystem { associate }; + #EXE=/bin/bash NAME=null : associate + #EXE=/sbin/udev NAME=snd : associate + +allow hotplug_t device_t:dir { add_name write }; + #EXE=/bin/bash : write + #EXE=/bin/bash NAME=null : add_name + +allow hotplug_t device_t:file { create }; + #EXE=/bin/bash NAME=null : create + +allow initctl_t device_t:filesystem { associate }; + #EXE=/sbin/init NAME=initctl : associate + +allow initrc_t root_t:dir { remove_name write }; + #EXE=/bin/rm : write + #EXE=/bin/rm NAME=fastboot : remove_name + +allow initrc_t root_t:file { unlink }; + #EXE=/bin/rm NAME=fastboot : unlink + +allow initrc_t usbfs_t:file { getattr read }; + #EXE=/bin/dash PATH=/proc/bus/usb/devices : getattr + #EXE=/bin/grep NAME=devices : read + +allow initrc_t zero_device_t:chr_file { getattr }; + #EXE=/bin/ls PATH=/dev/zero : getattr + + + + + +allow udev_tbl_t device_t:filesystem { associate }; + #EXE=/sbin/udev NAME=.udev.tdb : associate + + + + + +allow mount_t tmpfs_t:filesystem { relabelfrom }; + #EXE=/bin/mount : relabelfrom + + +allow devlog_t device_t:filesystem { associate }; + #EXE=/sbin/syslogd NAME=log : associate + +allow sshd_t device_t:filesystem { getattr }; + #EXE=/usr/sbin/sshd NAME=/ : getattr + #EXE=/usr/sbin/sshd NAME=/ : getattr + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff -Naur --- default.1.14/domains/program/init.te 2004-08-02 08:28:37.000000000 +0100 +++ current/domains/program/init.te 2004-08-15 15:35:27.000000000 +0100 @@ -131,6 +131,9 @@ allow init_t devtty_t:chr_file { read write }; allow init_t ramfs_t:dir search; ') + r_dir_file(init_t, sysfs_t) +r_dir_file(init_t, tmpfs_t) r_dir_file(init_t, selinux_config_t) + diff -Naur --- default.1.14/domains/program/initrc.te 2004-08-02 08:28:37.000000000 +0100 +++ current/domains/program/initrc.te 2004-08-22 18:09:23.000000000 +0100 @@ -312,3 +312,27 @@ # allow initrc_t security_t:dir { getattr search }; allow initrc_t security_t:file { getattr read }; + +allow initrc_t device_t:filesystem { getattr }; + + + + + + + + + + + + + + + + + + + + + + diff -Naur --- default.1.14/domains/program/mount.te 2004-08-02 08:28:37.000000000 +0100 +++ current/domains/program/mount.te 2004-08-21 19:12:19.000000000 +0100 @@ -16,7 +16,7 @@ role sysadm_r types mount_t; role system_r types mount_t; -allow mount_t { initrc_devpts_t console_device_t }:chr_file { read write }; +allow mount_t { initrc_devpts_t console_device_t tty_device_t }:chr_file { read write }; domain_auto_trans(initrc_t, mount_exec_t, mount_t) allow mount_t init_t:fd use; @@ -49,11 +49,12 @@ allow mount_t usbdevfs_t:dir mounton; allow mount_t sysfs_t:dir { mounton }; allow mount_t nfs_t:dir mounton; +allow mount_t security_t:dir mounton; allow mount_t nfs_t:dir { search }; # nfsv4 has a filesystem to mount for its userspace daemons allow mount_t var_lib_nfs_t:dir { mounton }; -# On some RedHat systems, /boot is a mount point +# On some RedHat and Debian systems, /boot is a mount point allow mount_t boot_t:dir mounton; allow mount_t device_t:dir mounton; # mount binfmt_misc on /proc/sys/fs/binfmt_misc diff -Naur --- default.1.14/domains/program/restorecon.te 2004-08-02 08:28:37.000000000 +0100 +++ current/domains/program/restorecon.te 2004-08-06 15:54:12.000000000 +0100 @@ -59,3 +59,6 @@ r_dir_file(restorecon_t, selinux_config_t) r_dir_file(restorecon_t, file_context_t) +allow restorecon_t udev_tbl_t:file { read write }; + #EXE=/sbin/restorecon PATH=/dev/.udev.tdb : read write + diff -Naur --- default.1.14/domains/program/udev.te 2004-08-02 08:28:37.000000000 +0100 +++ current/domains/program/udev.te 2004-08-06 19:20:29.000000000 +0100 @@ -18,6 +18,7 @@ type udev_helper_exec_t, file_type, sysadmfile, exec_type; r_dir_file(udev_t, udev_helper_exec_t) can_exec(udev_t, udev_helper_exec_t) +#domain_auto_trans(udev_t, udev_helper_exec_t, hotplug_t) # # Rules used for udev @@ -33,6 +34,7 @@ allow udev_t device_t:chr_file create_file_perms; allow udev_t device_t:sock_file create_file_perms; allow udev_t device_t:lnk_file create_file_perms; +allow udev_t device_t:dir create_dir_perms; allow udev_t etc_t:file { getattr read }; allow udev_t { bin_t sbin_t }:dir r_dir_perms; allow udev_t bin_t:lnk_file read; @@ -70,6 +72,8 @@ ifdef(`hotplug.te', ` r_dir_file(udev_t, hotplug_etc_t) +domain_auto_trans(udev_t, hotplug_exec_t, hotplug_t) +can_exec(udev_t, hotplug_exec_t) ') allow udev_t var_log_t:dir { search }; @@ -79,3 +83,15 @@ domain_auto_trans(udev_t, ifconfig_exec_t, ifconfig_t) dontaudit udev_t file_t:dir search; + +# hacked stuff... + +can_ps(udev_t, domain) + +# for /etc/dev.d/net/hotplug.dev + +allow udev_t etc_runtime_t:file { append lock write }; +can_exec(udev_t hotplug_etc_t) + + +r_dir_file(udev_t, selinux_config_t) diff -Naur --- default.1.14/file_contexts/program/udev.fc 2004-08-02 08:28:37.000000000 +0100 +++ current/file_contexts/program/udev.fc 2004-08-06 15:18:35.000000000 +0100 @@ -4,5 +4,8 @@ /sbin/udevd -- system_u:object_r:udev_exec_t /etc/dev.d(/.*)? system_u:object_r:udev_helper_exec_t /etc/hotplug.d/default/udev.* system_u:object_r:udev_helper_exec_t +/etc/udev/cdsymlinks.sh system_u:object_r:udev_helper_exec_t +/etc/udev/ide-devfs.sh system_u:object_r:udev_helper_exec_t +/etc/udev/scsi-devfs.sh system_u:object_r:udev_helper_exec_t /dev/udev.tbl -- system_u:object_r:udev_tbl_t /dev/\.udev\.tdb -- system_u:object_r:udev_tbl_t diff -Naur --- default.1.14/macros/base_user_macros.te 2004-08-02 08:28:37.000000000 +0100 +++ current/macros/base_user_macros.te 2004-08-14 22:59:48.000000000 +0100 @@ -80,6 +80,16 @@ allow $1_t privfd:fd use; allow $1_t $1_tty_device_t:chr_file { setattr rw_file_perms }; + + + +# needed for udev-mounted (/dev) tmpfs +allow $1_tty_device_t device_t:filesystem { associate }; + +# to allow users to run df on udev-mounted (/dev) tmpfs +allow $1_t device_t:filesystem { getattr }; + #EXE=/bin/df NAME=/ : getattr + # Use the type when relabeling terminal devices. type_change $1_t tty_device_t:chr_file $1_tty_device_t; diff -Naur --- default.1.14/types/file.te 2004-08-02 08:28:37.000000000 +0100 +++ current/types/file.te 2004-08-09 19:52:49.000000000 +0100 @@ -259,12 +259,23 @@ # allow { file_type device_type } fs_t:filesystem associate; +# +# Allow device types to be associated with a udev-mounted +# file system where the -o mount option "fscontext=....device_t" +# has been added. if it was fscontext=...something_else_t +# then it would be allow .... something_else_t:filesystem here: +# +allow { device_type } device_t:filesystem associate; + # Allow the pty to be associated with the file system. allow devpts_t devpts_t:filesystem associate; type tmpfs_t, file_type, sysadmfile, fs_type, root_dir_type; allow { tmpfs_t tmp_t } tmpfs_t:filesystem associate; + + + type usbdevfs_t, fs_type, root_dir_type, noexattrfile, sysadmfile; allow usbdevfs_t usbdevfs_t:filesystem associate; From selinux at comcast.net Tue Aug 24 16:01:22 2004 From: selinux at comcast.net (Tom London) Date: Tue, 24 Aug 2004 09:01:22 -0700 Subject: udevsend.... Message-ID: <412B6652.2040606@comcast.net> The newest Rawhide udev seems to add 'udevsend' that seems to want allow udev_t selinux_config_t:dir { search }; allow udev_t selinux_config_t:file { read }; I'm guessing that udevsend replaces the script /etc/dev.d/default/selinux.dev. tom Here are the avcs.... Aug 24 08:45:13 fedora kernel: audit(1093362313.380:0): avc: denied { search } for pid=3905 exe=/sbin/udevsend name=selinux dev=hda2 ino=4509743 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:selinux_config_t tclass=dir Aug 24 08:45:13 fedora kernel: audit(1093362313.380:0): avc: denied { read } for pid=3905 exe=/sbin/udevsend name=config dev=hda2 ino=4509759 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:selinux_config_t tclass=file Aug 24 08:45:13 fedora kernel: audit(1093362313.380:0): avc: denied { getattr } for pid=3905 exe=/sbin/udevsend path=/etc/selinux/config dev=hda2 ino=4509759 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:selinux_config_t tclass=file From selinux at comcast.net Tue Aug 24 16:38:55 2004 From: selinux at comcast.net (Tom London) Date: Tue, 24 Aug 2004 09:38:55 -0700 Subject: udevsend.... In-Reply-To: <412B6652.2040606@comcast.net> References: <412B6652.2040606@comcast.net> Message-ID: <412B6F1F.4050505@comcast.net> Sorry, I sent this off too quickly. Here are additional avc's generated by udev.... Aug 24 09:12:27 fedora kernel: audit(1093338680.407:0): avc: denied { getattr } for pid=315 exe=/sbin/udevsend path=/etc/selinux/config dev=hda2 ino=4509759 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:selinux_config_t tclass=file Aug 24 09:12:31 fedora kernel: audit(1093363902.870:0): avc: denied { search } for pid=1079 exe=/sbin/udev name=contexts dev=hda2 ino=4509745 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:default_context_t tclass=dir Aug 24 09:12:31 fedora kernel: audit(1093363902.877:0): avc: denied { search } for pid=1079 exe=/sbin/udev name=files dev=hda2 ino=4509746 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:file_context_t tclass=dir Aug 24 09:12:31 fedora kernel: audit(1093363902.894:0): avc: denied { read } for pid=1079 exe=/sbin/udev name=file_contexts dev=hda2 ino=4505700 scontext=system_u:system_r:udev_t tcontext=root:object_r:file_context_t tclass=file Aug 24 09:12:31 fedora kernel: audit(1093363902.894:0): avc: denied { getattr } for pid=1079 exe=/sbin/udev path=/etc/selinux/strict/contexts/files/file_contexts dev=hda2 ino=4505700 scontext=system_u:system_r:udev_t tcontext=root:object_r:file_context_t tclass=file Aug 24 09:12:31 fedora kernel: audit(1093363919.802:0): avc: denied { write } for pid=1200 exe=/sbin/udev name=fscreate dev=proc ino=78643222 scontext=system_u:system_r:udev_t tcontext=system_u:system_r:udev_t tclass=file Aug 24 09:12:31 fedora kernel: audit(1093363919.802:0): avc: denied { setfscreate } for pid=1200 exe=/sbin/udev scontext=system_u:system_r:udev_t tcontext=system_u:system_r:udev_t tclass=process Aug 24 09:12:31 fedora kernel: audit(1093363919.941:0): avc: denied { search } for pid=1202 exe=/bin/bash name=console dev=hda2 ino=4456494 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:pam_var_console_t tclass=dir Aug 24 09:12:32 fedora kernel: audit(1093363947.209:0): avc: denied { getattr } for pid=2131 exe=/sbin/udev path=/etc/selinux/config dev=hda2 ino=4509759 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:selinux_config_t tclass=file Seems to want: allow udev_t default_context_t:dir { search }; allow udev_t file_context_t:dir { search }; allow udev_t file_context_t:file { getattr read }; allow udev_t pam_var_console_t:dir { search }; allow udev_t selinux_config_t:file { getattr }; allow udev_t udev_t:file { write }; allow udev_t udev_t:process { setfscreate } Help.... this one is beyond me...... tom Tom London wrote: > The newest Rawhide udev seems to add 'udevsend' that seems to want > allow udev_t selinux_config_t:dir { search }; > allow udev_t selinux_config_t:file { read }; > > I'm guessing that udevsend replaces the script > /etc/dev.d/default/selinux.dev. > > tom > > Here are the avcs.... > > Aug 24 08:45:13 fedora kernel: audit(1093362313.380:0): avc: denied > { search } for pid=3905 exe=/sbin/udevsend name=selinux dev=hda2 > ino=4509743 scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:selinux_config_t tclass=dir > Aug 24 08:45:13 fedora kernel: audit(1093362313.380:0): avc: denied > { read } for pid=3905 exe=/sbin/udevsend name=config dev=hda2 > ino=4509759 scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:selinux_config_t tclass=file > Aug 24 08:45:13 fedora kernel: audit(1093362313.380:0): avc: denied > { getattr > } for pid=3905 exe=/sbin/udevsend path=/etc/selinux/config dev=hda2 > ino=4509759 scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:selinux_config_t tclass=file > > From selinux at comcast.net Tue Aug 24 16:46:11 2004 From: selinux at comcast.net (Tom London) Date: Tue, 24 Aug 2004 09:46:11 -0700 Subject: fstab, mount, minilog ... Message-ID: <412B70D3.4050503@comcast.net> Newest Rawhide: some funny things at boot up: Aug 24 08:43:24 fedora kernel: audit(1093336939.824:0): avc: denied { use } for pid=546 exe=/sbin/minilogd path=/init dev=rootfs ino=14 scontext=system_u:system_r:syslogd_t tcontext=system_u:system_r:kernel_t tclass=fd Aug 24 08:43:24 fedora kernel: audit(1093336939.943:0): avc: denied { read } for pid=551 exe=/bin/mount name=fstab dev=hda2 ino=4654138 scontext=system_u:system_r:mount_t tcontext=system_u:object_r:tmp_t tclass=file Aug 24 08:43:24 fedora kernel: audit(1093336939.943:0): avc: denied { getattr } for pid=551 exe=/bin/mount path=/etc/fstab dev=hda2 ino=4654138 scontext=system_u:system_r:mount_t tcontext=system_u:object_r:tmp_t tclass=file The minilog avc is 'old', but the ones from mount are new. In addition, looks like /etc/fstab is created with the wrong label. Here's the output from 'setfiles' after boot: setfiles: relabeling /etc/fstab from system_u:object_r:tmp_t to system_u:object_r:etc_t For minilog, is this a case of a file descriptor leaking across the exec? tom From lkcl at lkcl.net Tue Aug 24 22:23:04 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 24 Aug 2004 23:23:04 +0100 Subject: Fedora and udev In-Reply-To: <20040824160126.GA19197@lkcl.net> References: <200408222125.38169.russell@coker.com.au> <412A74A6.9070206@tresys.com> <20040824092853.GD25356@lkcl.net> <200408242006.41591.russell@coker.com.au> <20040824141828.GA4698@lkcl.net> <20040824160126.GA19197@lkcl.net> Message-ID: <20040824222304.GE12140@lkcl.net> On Tue, Aug 24, 2004 at 05:01:26PM +0100, Luke Kenneth Casson Leighton wrote: > diff -Naur > --- default.1.14/domains/program/udev.te 2004-08-02 08:28:37.000000000 +0100 > +++ current/domains/program/udev.te 2004-08-06 19:20:29.000000000 +0100 > @@ -79,3 +83,15 @@ > domain_auto_trans(udev_t, ifconfig_exec_t, ifconfig_t) > > dontaudit udev_t file_t:dir search; > + > +# hacked stuff... > + > +can_ps(udev_t, domain) > + > +# for /etc/dev.d/net/hotplug.dev > + > +allow udev_t etc_runtime_t:file { append lock write }; > +can_exec(udev_t hotplug_etc_t) ^^^^^^ yes my policy _does_ really have this (spotted it just now) without the comma. no, the policy compiler _doesn't_ spot it. l. From greg at kroah.com Tue Aug 24 16:30:49 2004 From: greg at kroah.com (Greg KH) Date: Tue, 24 Aug 2004 09:30:49 -0700 Subject: Fedora and udev In-Reply-To: <20040824094157.GF25356@lkcl.net> References: <200408222125.38169.russell@coker.com.au> <4128B637.8040900@tresys.com> <20040822173457.GD13842@lkcl.net> <20040823224444.GI4694@kroah.com> <412A74A6.9070206@tresys.com> <20040824094157.GF25356@lkcl.net> Message-ID: <20040824163048.GA1715@kroah.com> On Tue, Aug 24, 2004 at 10:41:57AM +0100, Luke Kenneth Casson Leighton wrote: > > the debian maintainer for udev is under the impression that udev has > stacks of race conditions: if that isn't actually the case, then great! He is mistaken. greg k-h From russell at coker.com.au Wed Aug 25 08:28:14 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 25 Aug 2004 18:28:14 +1000 Subject: fstab, mount, minilog ... In-Reply-To: <412B70D3.4050503@comcast.net> References: <412B70D3.4050503@comcast.net> Message-ID: <200408251828.14466.russell@coker.com.au> On Wed, 25 Aug 2004 02:46, Tom London wrote: > Newest Rawhide: some funny things at boot up: > > Aug 24 08:43:24 fedora kernel: audit(1093336939.824:0): avc: denied { > use } for pid=546 exe=/sbin/minilogd path=/init dev=rootfs ino=14 > scontext=system_u:system_r:syslogd_t tcontext=system_u:system_r:kernel_t > tclass=fd I'm getting the same, it seemed to have started at kernel 2.6.8-1.525. Kernel 2.6.8-1.524 didn't have that on my targeted test machine. > Aug 24 08:43:24 fedora kernel: audit(1093336939.943:0): avc: denied { > read } for pid=551 exe=/bin/mount name=fstab dev=hda2 ino=4654138 > scontext=system_u:system_r:mount_t tcontext=system_u:object_r:tmp_t > tclass=file That is really broken. There should be no way for the fstab file to get the label tmp_t. In fact no file should have the label tmp_t. How was the fstab file created? > The minilog avc is 'old', but the ones from mount are new. In addition, > looks > like /etc/fstab is created with the wrong label. Here's the output from > 'setfiles' > after boot: > setfiles: relabeling /etc/fstab from system_u:object_r:tmp_t to > system_u:object_r:etc_t > > For minilog, is this a case of a file descriptor leaking across the exec? Looks like it. Kernel bug. -- 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 Wed Aug 25 08:35:59 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 25 Aug 2004 18:35:59 +1000 Subject: glibc post upgrade In-Reply-To: <412A6E4E.5080600@nc.rr.com> References: <200408232344.23345.russell@coker.com.au> <412A3701.2020401@redhat.com> <412A6E4E.5080600@nc.rr.com> Message-ID: <200408251835.59432.russell@coker.com.au> On Tue, 24 Aug 2004 08:23, Jeff Johnson wrote: > On a parallel, multilib install battle front, /usr/bin/{glibc,libgcc} > have also been causing rpm pain. > > The packaging requirements are that these packages must be installable > into an empty > chroot, i.e. no /bin/sh, hence statically linked helpers. > > Unfortunately, the statically linked helpers are installed on the same > path, but are > platform dependent. The statically linked helpers are also quite > mysterious, e.g. > this isn't the first time that the rpm_t vs. rpm_script_t has been raised. > > One approach to a multilib packaging solution is to use embedded lua to > avoid platform > dependent helpers that are on conflicting paths. > > But that then means that embedded lua will be run as "rpm_t", not > "rpm_script_t", > as this is rpm running in a nearly empty chroot. The main use for chroot operation of RPM is for the early stages of the install process. Currently we don't do this in enforcing mode so this doesn't matter. What is a LUA? I suggest using /bin/sh to execute the postinst commands if it exists. If there is no /bin/sh then just execute them directly and don't worry about SE Linux. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From sds at epoch.ncsc.mil Wed Aug 25 11:26:51 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 25 Aug 2004 07:26:51 -0400 Subject: fstab, mount, minilog ... In-Reply-To: <200408251828.14466.russell@coker.com.au> References: <412B70D3.4050503@comcast.net> <200408251828.14466.russell@coker.com.au> Message-ID: <1093433211.6743.2.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-08-25 at 04:28, Russell Coker wrote: > On Wed, 25 Aug 2004 02:46, Tom London wrote: > > Newest Rawhide: some funny things at boot up: > > > > Aug 24 08:43:24 fedora kernel: audit(1093336939.824:0): avc: denied { > > use } for pid=546 exe=/sbin/minilogd path=/init dev=rootfs ino=14 > > scontext=system_u:system_r:syslogd_t tcontext=system_u:system_r:kernel_t > > tclass=fd > > I'm getting the same, it seemed to have started at kernel 2.6.8-1.525. Kernel > 2.6.8-1.524 didn't have that on my targeted test machine. Kernel is leaking descriptors to the rootfs; I reported this a while ago. SELinux should be closing and re-opening them to /dev/null on the denial, so they won't be accessible to userspace. -- Stephen Smalley National Security Agency From pmatilai at welho.com Wed Aug 25 12:48:32 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Wed, 25 Aug 2004 15:48:32 +0300 (EEST) Subject: glibc post upgrade In-Reply-To: <200408251835.59432.russell@coker.com.au> References: <200408232344.23345.russell@coker.com.au> <412A3701.2020401@redhat.com> <412A6E4E.5080600@nc.rr.com> <200408251835.59432.russell@coker.com.au> Message-ID: On Wed, 25 Aug 2004, Russell Coker wrote: > On Tue, 24 Aug 2004 08:23, Jeff Johnson wrote: > > On a parallel, multilib install battle front, /usr/bin/{glibc,libgcc} > > have also been causing rpm pain. > > > > The packaging requirements are that these packages must be installable > > into an empty > > chroot, i.e. no /bin/sh, hence statically linked helpers. > > > > Unfortunately, the statically linked helpers are installed on the same > > path, but are > > platform dependent. The statically linked helpers are also quite > > mysterious, e.g. > > this isn't the first time that the rpm_t vs. rpm_script_t has been raised. > > > > One approach to a multilib packaging solution is to use embedded lua to > > avoid platform > > dependent helpers that are on conflicting paths. > > > > But that then means that embedded lua will be run as "rpm_t", not > > "rpm_script_t", > > as this is rpm running in a nearly empty chroot. > > The main use for chroot operation of RPM is for the early stages of the > install process. Currently we don't do this in enforcing mode so this > doesn't matter. > > What is a LUA? Lua is a programming language, nowadays embedded in rpm. See http://www.lua.org/ for info on Lua itself and here https://moin.conectiva.com.br/GustavoNiemeyer/2004-03-22 for info on how it works from inside rpm. - Panu - From sds at epoch.ncsc.mil Wed Aug 25 13:08:17 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 25 Aug 2004 09:08:17 -0400 Subject: glibc post upgrade In-Reply-To: <412A6E4E.5080600@nc.rr.com> References: <200408232344.23345.russell@coker.com.au> <412A21A6.7040203@nc.rr.com> <1093281676.27211.159.camel@moss-spartans.epoch.ncsc.mil> <412A3701.2020401@redhat.com> <412A6E4E.5080600@nc.rr.com> Message-ID: <1093439297.6743.69.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2004-08-23 at 18:23, Jeff Johnson wrote: > Well, it's not that simple. > > On a parallel, multilib install battle front, /usr/bin/{glibc,libgcc} > have also been causing rpm pain. > > The packaging requirements are that these packages must be installable > into an empty > chroot, i.e. no /bin/sh, hence statically linked helpers. > > Unfortunately, the statically linked helpers are installed on the same > path, but are > platform dependent. The statically linked helpers are also quite > mysterious, e.g. > this isn't the first time that the rpm_t vs. rpm_script_t has been raised. > > One approach to a multilib packaging solution is to use embedded lua to > avoid platform > dependent helpers that are on conflicting paths. > > But that then means that embedded lua will be run as "rpm_t", not > "rpm_script_t", > as this is rpm running in a nearly empty chroot. > > There are no easy answers for conflicting needs. Something has to give, > either selinux > policy or multilib paths. I'm afraid I don't follow this. As long as the helper is run as a separate program (or even the same program re-exec'd), we can transition it to a separate domain via a prior call to setexeccon(). Policy can simply allow entrypoint permission for the domain for any of the possible types for such helpers. -- Stephen Smalley National Security Agency From n3npq at nc.rr.com Wed Aug 25 13:54:17 2004 From: n3npq at nc.rr.com (Jeff Johnson) Date: Wed, 25 Aug 2004 09:54:17 -0400 Subject: glibc post upgrade In-Reply-To: <1093439297.6743.69.camel@moss-spartans.epoch.ncsc.mil> References: <200408232344.23345.russell@coker.com.au> <412A21A6.7040203@nc.rr.com> <1093281676.27211.159.camel@moss-spartans.epoch.ncsc.mil> <412A3701.2020401@redhat.com> <412A6E4E.5080600@nc.rr.com> <1093439297.6743.69.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <412C9A09.700@nc.rr.com> Stephen Smalley wrote: >On Mon, 2004-08-23 at 18:23, Jeff Johnson wrote: > > >>Well, it's not that simple. >> >>On a parallel, multilib install battle front, /usr/bin/{glibc,libgcc} >>have also been causing rpm pain. >> >>The packaging requirements are that these packages must be installable >>into an empty >>chroot, i.e. no /bin/sh, hence statically linked helpers. >> >>Unfortunately, the statically linked helpers are installed on the same >>path, but are >>platform dependent. The statically linked helpers are also quite >>mysterious, e.g. >>this isn't the first time that the rpm_t vs. rpm_script_t has been raised. >> >>One approach to a multilib packaging solution is to use embedded lua to >>avoid platform >>dependent helpers that are on conflicting paths. >> >>But that then means that embedded lua will be run as "rpm_t", not >>"rpm_script_t", >>as this is rpm running in a nearly empty chroot. >> >>There are no easy answers for conflicting needs. Something has to give, >>either selinux >>policy or multilib paths. >> >> > >I'm afraid I don't follow this. As long as the helper is run as a >separate program (or even the same program re-exec'd), we can transition >it to a separate domain via a prior call to setexeccon(). Policy can >simply allow entrypoint permission for the domain for any of the >possible types for such helpers. > > That's the point. Lua is embedded, would be run by rpm, and no re-exec because of internal state. 73 de Jeff From sds at epoch.ncsc.mil Wed Aug 25 14:02:01 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 25 Aug 2004 10:02:01 -0400 Subject: glibc post upgrade In-Reply-To: <412C9A09.700@nc.rr.com> References: <200408232344.23345.russell@coker.com.au> <412A21A6.7040203@nc.rr.com> <1093281676.27211.159.camel@moss-spartans.epoch.ncsc.mil> <412A3701.2020401@redhat.com> <412A6E4E.5080600@nc.rr.com> <1093439297.6743.69.camel@moss-spartans.epoch.ncsc.mil> <412C9A09.700@nc.rr.com> Message-ID: <1093442521.6743.109.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-08-25 at 09:54, Jeff Johnson wrote: > That's the point. Lua is embedded, would be run by rpm, and no re-exec > because of internal state. Ok. And the lua "program" would still be extracted from the (possibly untrustworthy) package contents, as with current helpers like glibc_post_upgrade? So a package can carry arbitrary malicious lua code and get it executed by rpm? -- Stephen Smalley National Security Agency From leonard at den.ottolander.nl Wed Aug 25 16:55:57 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 25 Aug 2004 18:55:57 +0200 Subject: Switching policy, need to relabel files? Message-ID: <1093452957.4788.73.camel@athlon.localdomain> Hi, Just switched SELinux policy from targeted to strict. Rebooting caused a lot of avc denied messages and mDNSresponder asking me whether to enter a role. Should I relabel my file systems or are these errors in the policy? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From walters at redhat.com Wed Aug 25 17:05:18 2004 From: walters at redhat.com (Colin Walters) Date: Wed, 25 Aug 2004 13:05:18 -0400 Subject: Switching policy, need to relabel files? In-Reply-To: <1093452957.4788.73.camel@athlon.localdomain> References: <1093452957.4788.73.camel@athlon.localdomain> Message-ID: <1093453518.5092.81.camel@nexus.verbum.private> On Wed, 2004-08-25 at 18:55 +0200, Leonard den Ottolander wrote: > Hi, > > Just switched SELinux policy from targeted to strict. Rebooting caused a > lot of avc denied messages and mDNSresponder asking me whether to enter > a role. Should I relabel my file systems or are these errors in the > policy? Yes, you currently need to relabel after switching policy. Work is in progress to fix this. -------------- 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 notting at redhat.com Wed Aug 25 17:08:58 2004 From: notting at redhat.com (Bill Nottingham) Date: Wed, 25 Aug 2004 13:08:58 -0400 Subject: Switching policy, need to relabel files? In-Reply-To: <1093453518.5092.81.camel@nexus.verbum.private> References: <1093452957.4788.73.camel@athlon.localdomain> <1093453518.5092.81.camel@nexus.verbum.private> Message-ID: <20040825170857.GB16602@nostromo.devel.redhat.com> Colin Walters (walters at redhat.com) said: > > Just switched SELinux policy from targeted to strict. Rebooting caused a > > lot of avc denied messages and mDNSresponder asking me whether to enter > > a role. Should I relabel my file systems or are these errors in the > > policy? > > Yes, you currently need to relabel after switching policy. Work is in > progress to fix this. Where fix == do the relabel for you. :) Bill From leonard at den.ottolander.nl Wed Aug 25 17:28:04 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 25 Aug 2004 19:28:04 +0200 Subject: Switching policy, need to relabel files? In-Reply-To: <1093453518.5092.81.camel@nexus.verbum.private> References: <1093452957.4788.73.camel@athlon.localdomain> <1093453518.5092.81.camel@nexus.verbum.private> Message-ID: <1093454884.4788.82.camel@athlon.localdomain> Hi Colin, On Wed, 2004-08-25 at 19:05, Colin Walters wrote: > > Just switched SELinux policy from targeted to strict. Rebooting caused a > > lot of avc denied messages and mDNSresponder asking me whether to enter > > a role. Should I relabel my file systems or are these errors in the > > policy? > > Yes, you currently need to relabel after switching policy. Work is in > progress to fix this. Yes but I lost my Grub password and now I don't know how to boot into enforcing=0. What should I do? Just kidding folks ;-) . I searched the faqs and everything will be fine (in an hour or so I guess :) . By the way, fixfiles exits without an error nor a help message when run without an argument. Maybe that should change? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Aug 25 22:51:09 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 26 Aug 2004 00:51:09 +0200 Subject: xfs socket startup fails with strict policy Message-ID: <1093474268.4788.107.camel@athlon.localdomain> Hi, I'm seeing the following at startup. I have to boot to runlevel 3 because X won't start since it "could not open default font 'fixed'". There is no socket for xfs (7100) although service xfs is reported running. Aug 25 23:27:36 k6-joy xfs: xfs startup succeeded Aug 25 23:27:36 k6-joy kernel: audit(1093469256.744:0): avc: denied { getattr } for pid=2171 exe=/usr/X11R6/bin/xfs path=/tmp/.font-unix dev=hda6 ino=425186 scontext=system_u:system_r:xfs_t tcontext=system_u:object_r:initrc_tmp_t tclass=dir Aug 25 23:27:36 k6-joy xfs[2171]: cannot establish any listening sockets Aug 25 23:27:37 k6-joy xfs[2171]: ignoring font path element /usr/X11R6/lib/X11/fonts/Speedo (unreadable) Running a fixfiles relabel did not fix this issue. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Aug 25 23:07:29 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 26 Aug 2004 01:07:29 +0200 Subject: xfs socket startup fails with strict policy In-Reply-To: <1093474268.4788.107.camel@athlon.localdomain> References: <1093474268.4788.107.camel@athlon.localdomain> Message-ID: <1093475249.4788.112.camel@athlon.localdomain> Hi, I wrote: > I'm seeing the following at startup. I have to boot to runlevel 3 > because X won't start since it "could not open default font 'fixed'". > There is no socket for xfs (7100) although service xfs is reported > running. The fact that xfs is not listening on port 7100 is of course expected behaviour. The directory /tmp/.font-unix seems to have the wrong security context though. Did fixfiles miss this temporary directory? > Aug 25 23:27:36 k6-joy xfs: xfs startup succeeded > Aug 25 23:27:36 k6-joy kernel: audit(1093469256.744:0): avc: denied { > getattr } for pid=2171 exe=/usr/X11R6/bin/xfs path=/tmp/.font-unix > dev=hda6 ino=425186 scontext=system_u:system_r:xfs_t > tcontext=system_u:object_r:initrc_tmp_t tclass=dir [root at k6-joy tmp]# ls -aZd .font-unix drwxrwxrwt root root system_u:object_r:initrc_tmp_t .font-unix Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Aug 25 23:15:49 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 26 Aug 2004 01:15:49 +0200 Subject: xfs socket startup fails with strict policy In-Reply-To: <1093475249.4788.112.camel@athlon.localdomain> References: <1093474268.4788.107.camel@athlon.localdomain> <1093475249.4788.112.camel@athlon.localdomain> Message-ID: <1093475749.4788.116.camel@athlon.localdomain> Hi, > The fact that xfs is not listening on port 7100 is of course expected > behaviour. The directory /tmp/.font-unix seems to have the wrong > security context though. Did fixfiles miss this temporary directory? Not necessarily. Removing it by hand and rebooting doesn't fix the situation: root 2372 0.5 0.8 12196 2304 ? Ss 01:11 0:00 /usr/bin/gdm-binary -nodaemon root 2917 0.1 0.4 5312 1120 ? Ss 01:11 0:00 /bin/sh /etc/X11/gdm/XKeepsCrashing root 2934 0.0 0.0 2432 252 ? S 01:11 0:00 /usr/libexec/gdmopen -l /bin/sh -c /etc/X11/gdm/XKeepsCrashing -noopen root 2947 0.3 0.4 5168 1124 tty8 Ss+ 01:11 0:00 /bin/sh /etc/X11/gdm/XKeepsCrashing -noopen root 3007 0.0 0.3 5020 1016 tty8 S+ 01:11 0:00 /usr/bin/dialog --yesno I cannot start the X server (your graphical interface). It is likely that it is not set up correctly. Would you like to view the X server output to diagnose the problem? 10 50 > Leonard. -- mount -t life -o ro /dev/dna /genetic/research From n3npq at nc.rr.com Thu Aug 26 09:37:30 2004 From: n3npq at nc.rr.com (Jeff Johnson) Date: Thu, 26 Aug 2004 05:37:30 -0400 Subject: glibc post upgrade In-Reply-To: <1093442521.6743.109.camel@moss-spartans.epoch.ncsc.mil> References: <200408232344.23345.russell@coker.com.au> <412A21A6.7040203@nc.rr.com> <1093281676.27211.159.camel@moss-spartans.epoch.ncsc.mil> <412A3701.2020401@redhat.com> <412A6E4E.5080600@nc.rr.com> <1093439297.6743.69.camel@moss-spartans.epoch.ncsc.mil> <412C9A09.700@nc.rr.com> <1093442521.6743.109.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <412DAF5A.9030906@nc.rr.com> Stephen Smalley wrote: >On Wed, 2004-08-25 at 09:54, Jeff Johnson wrote: > > >>That's the point. Lua is embedded, would be run by rpm, and no re-exec >>because of internal state. >> >> > >Ok. And the lua "program" would still be extracted from the (possibly >untrustworthy) package contents, as with current helpers like >glibc_post_upgrade? So a package can carry arbitrary malicious lua code >and get it executed by rpm? > > > Exactly the same as current rpm behavior, yes. But thanks for explaining the need for distinguishing rpm_t and rpm_script_t. ;-) I'll have rpm_script_t into fc3 rpm in a day or two, lua ain't going to happen soon, or suddenly, or even only from package tag content, in rpm. Almost certainly lua is going to happen in rpm though, as lua scriptlet support is already in rpm HEAD, and there is a need for embedded scripts in order to accomplish certain tasks in a near empty chroot without encumbering dependency baggage. That is/was the original motivation for /usr/sbin/glibc_post_upgrade, not otherwise. Malicious code from untrusted package problem not going to be solved by rpm_script_t alone afaict either. And the real problem is that glibc_post_upgrade should not be attempting sshd restart always, as the need to insure connectivity when modules change occurs only occaisionally, and could be handled in other ways like, say, documenting an incompatibility or avoiding altogether. 73 de Jeff From sds at epoch.ncsc.mil Thu Aug 26 12:06:58 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 26 Aug 2004 08:06:58 -0400 Subject: xfs socket startup fails with strict policy In-Reply-To: <1093474268.4788.107.camel@athlon.localdomain> References: <1093474268.4788.107.camel@athlon.localdomain> Message-ID: <1093522017.9280.4.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-08-25 at 18:51, Leonard den Ottolander wrote: > Hi, > > I'm seeing the following at startup. I have to boot to runlevel 3 > because X won't start since it "could not open default font 'fixed'". > There is no socket for xfs (7100) although service xfs is reported > running. > > Aug 25 23:27:36 k6-joy xfs: xfs startup succeeded > Aug 25 23:27:36 k6-joy kernel: audit(1093469256.744:0): avc: denied { > getattr } for pid=2171 exe=/usr/X11R6/bin/xfs path=/tmp/.font-unix > dev=hda6 ino=425186 scontext=system_u:system_r:xfs_t > tcontext=system_u:object_r:initrc_tmp_t tclass=dir > Aug 25 23:27:36 k6-joy xfs[2171]: cannot establish any listening sockets > Aug 25 23:27:37 k6-joy xfs[2171]: ignoring font path element > /usr/X11R6/lib/X11/fonts/Speedo (unreadable) > > Running a fixfiles relabel did not fix this issue. Already bugzilla'd, I think. /etc/init.d/xfs needs to restorecon /tmp/.font-unix after re-creating it (previously, it was getting re-created by xfs itself, and the policy automatically put it into the right type using a file_type_auto_trans rule from xfs_t). -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Thu Aug 26 13:44:31 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 26 Aug 2004 09:44:31 -0400 Subject: glibc post upgrade In-Reply-To: <412DAF5A.9030906@nc.rr.com> References: <200408232344.23345.russell@coker.com.au> <412A21A6.7040203@nc.rr.com> <1093281676.27211.159.camel@moss-spartans.epoch.ncsc.mil> <412A3701.2020401@redhat.com> <412A6E4E.5080600@nc.rr.com> <1093439297.6743.69.camel@moss-spartans.epoch.ncsc.mil> <412C9A09.700@nc.rr.com> <1093442521.6743.109.camel@moss-spartans.epoch.ncsc.mil> <412DAF5A.9030906@nc.rr.com> Message-ID: <1093527871.9280.110.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-08-26 at 05:37, Jeff Johnson wrote: > Malicious code from untrusted package problem not going to be solved by > rpm_script_t alone afaict either. Right. We still need a mechanism for distinguishing among packages and running scriptlets in different domains based on either some property of the package (the authority that signed it) or some knowledge of the admin (i.e. he specifies the desired scriptlet domain for all packages obtained from a given repository in his yum.conf or similar). -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Thu Aug 26 13:51:53 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 26 Aug 2004 09:51:53 -0400 Subject: glibc post upgrade In-Reply-To: <1093527871.9280.110.camel@moss-spartans.epoch.ncsc.mil> References: <200408232344.23345.russell@coker.com.au> <412A21A6.7040203@nc.rr.com> <1093281676.27211.159.camel@moss-spartans.epoch.ncsc.mil> <412A3701.2020401@redhat.com> <412A6E4E.5080600@nc.rr.com> <1093439297.6743.69.camel@moss-spartans.epoch.ncsc.mil> <412C9A09.700@nc.rr.com> <1093442521.6743.109.camel@moss-spartans.epoch.ncsc.mil> <412DAF5A.9030906@nc.rr.com> <1093527871.9280.110.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1093528312.9280.112.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-08-26 at 09:44, Stephen Smalley wrote: > On Thu, 2004-08-26 at 05:37, Jeff Johnson wrote: > > Malicious code from untrusted package problem not going to be solved by > > rpm_script_t alone afaict either. > > Right. We still need a mechanism for distinguishing among packages and > running scriptlets in different domains based on either some property of > the package (the authority that signed it) or some knowledge of the > admin (i.e. he specifies the desired scriptlet domain for all packages > obtained from a given repository in his yum.conf or similar). Not to mention needing different domains for rpm itself in such scenarios... -- Stephen Smalley National Security Agency From dwalsh at redhat.com Thu Aug 26 13:57:30 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 26 Aug 2004 09:57:30 -0400 Subject: Fedora and udev In-Reply-To: <20040824163048.GA1715@kroah.com> References: <200408222125.38169.russell@coker.com.au> <4128B637.8040900@tresys.com> <20040822173457.GD13842@lkcl.net> <20040823224444.GI4694@kroah.com> <412A74A6.9070206@tresys.com> <20040824094157.GF25356@lkcl.net> <20040824163048.GA1715@kroah.com> Message-ID: <412DEC4A.6090101@redhat.com> Rewritten patch. Dan -------------- next part -------------- A non-text attachment was scrubbed... Name: udev-030-selinux.patch Type: text/x-patch Size: 5039 bytes Desc: not available URL: From leonard at den.ottolander.nl Thu Aug 26 14:20:59 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 26 Aug 2004 16:20:59 +0200 Subject: xfs socket startup fails with strict policy In-Reply-To: <1093522017.9280.4.camel@moss-spartans.epoch.ncsc.mil> References: <1093474268.4788.107.camel@athlon.localdomain> <1093522017.9280.4.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1093530059.4786.10.camel@athlon.localdomain> On Thu, 2004-08-26 at 14:06, Stephen Smalley wrote: > On Wed, 2004-08-25 at 18:51, Leonard den Ottolander wrote: > > Hi, > > > > I'm seeing the following at startup. I have to boot to runlevel 3 > > because X won't start since it "could not open default font 'fixed'". > > There is no socket for xfs (7100) although service xfs is reported > > running. > > > > Aug 25 23:27:36 k6-joy xfs: xfs startup succeeded > > Aug 25 23:27:36 k6-joy kernel: audit(1093469256.744:0): avc: denied { > > getattr } for pid=2171 exe=/usr/X11R6/bin/xfs path=/tmp/.font-unix > > dev=hda6 ino=425186 scontext=system_u:system_r:xfs_t > > tcontext=system_u:object_r:initrc_tmp_t tclass=dir > > Aug 25 23:27:36 k6-joy xfs[2171]: cannot establish any listening sockets > > Aug 25 23:27:37 k6-joy xfs[2171]: ignoring font path element > > /usr/X11R6/lib/X11/fonts/Speedo (unreadable) > > > > Running a fixfiles relabel did not fix this issue. > > Already bugzilla'd, I think. /etc/init.d/xfs needs to restorecon > /tmp/.font-unix after re-creating it (previously, it was getting > re-created by xfs itself, and the policy automatically put it into the > right type using a file_type_auto_trans rule from xfs_t). -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Thu Aug 26 14:25:44 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 26 Aug 2004 16:25:44 +0200 Subject: xfs socket startup fails with strict policy In-Reply-To: <1093522017.9280.4.camel@moss-spartans.epoch.ncsc.mil> References: <1093474268.4788.107.camel@athlon.localdomain> <1093522017.9280.4.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1093530344.4786.15.camel@athlon.localdomain> Hi Stephen, On Thu, 2004-08-26 at 14:06, Stephen Smalley wrote: > Already bugzilla'd, I think. /etc/init.d/xfs needs to restorecon > /tmp/.font-unix after re-creating it (previously, it was getting > re-created by xfs itself, and the policy automatically put it into the > right type using a file_type_auto_trans rule from xfs_t). Didn't see it filed under selinux-policy-strict. Don't see something similar under selinux-policy-targeted now I look there. I did however bugzilla this myself this morning (http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130969). I'll add your comment to it. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From n3npq at nc.rr.com Thu Aug 26 16:00:04 2004 From: n3npq at nc.rr.com (Jeff Johnson) Date: Thu, 26 Aug 2004 12:00:04 -0400 Subject: glibc post upgrade In-Reply-To: <1093527871.9280.110.camel@moss-spartans.epoch.ncsc.mil> References: <200408232344.23345.russell@coker.com.au> <412A21A6.7040203@nc.rr.com> <1093281676.27211.159.camel@moss-spartans.epoch.ncsc.mil> <412A3701.2020401@redhat.com> <412A6E4E.5080600@nc.rr.com> <1093439297.6743.69.camel@moss-spartans.epoch.ncsc.mil> <412C9A09.700@nc.rr.com> <1093442521.6743.109.camel@moss-spartans.epoch.ncsc.mil> <412DAF5A.9030906@nc.rr.com> <1093527871.9280.110.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <412E0904.4080407@nc.rr.com> Stephen Smalley wrote: >On Thu, 2004-08-26 at 05:37, Jeff Johnson wrote: > > >>Malicious code from untrusted package problem not going to be solved by >>rpm_script_t alone afaict either. >> >> > >Right. We still need a mechanism for distinguishing among packages and >running scriptlets in different domains based on either some property of >the package (the authority that signed it) or some knowledge of the >admin (i.e. he specifies the desired scriptlet domain for all packages >obtained from a given repository in his yum.conf or similar). > > > My current thoughts are to pass to libselinux a) the result (OK/NOKEY/UNTRUSTED/BAD) of the package header signature verify. b) the contained file manifest. and have libselinux return a) the file contexts to be applied. b) the exec context to use for that package's scriptlets. That info permits libselinux to have full control of what rpmlib can/will do to establish policy for packe files and scripts. I can add the signature fingerprint id, but then libselinux and /var/lib/rpm/Pubkeys would have different conceptions of keyring, and (for better or worse) rpmlib is better positioned to decide what input is valid than libselinux is. If necessary, I suppose I can pass signature/pubkey/blob if libselinux wishes to do it's own crypto. I suspect that I could even wire the call to libselinux with a return code so that libselinux could control whether rpm was permitted to read any given header. Say when, not my call. Perhaps a week's work, another week to stabilize on fc3 packaging. Otherwise crypto is hard slow design, known. 73 de Jeff From rhally at mindspring.com Thu Aug 26 16:10:59 2004 From: rhally at mindspring.com (Richard Hally) Date: Thu, 26 Aug 2004 12:10:59 -0400 Subject: xfs socket startup fails with strict policy In-Reply-To: <1093530344.4786.15.camel@athlon.localdomain> References: <1093474268.4788.107.camel@athlon.localdomain> <1093522017.9280.4.camel@moss-spartans.epoch.ncsc.mil> <1093530344.4786.15.camel@athlon.localdomain> Message-ID: <412E0B93.9030207@mindspring.com> Leonard den Ottolander wrote: >Hi Stephen, > >On Thu, 2004-08-26 at 14:06, Stephen Smalley wrote: > > >>Already bugzilla'd, I think. /etc/init.d/xfs needs to restorecon >>/tmp/.font-unix after re-creating it (previously, it was getting >>re-created by xfs itself, and the policy automatically put it into the >>right type using a file_type_auto_trans rule from xfs_t). >> >> > >Didn't see it filed under selinux-policy-strict. Don't see something >similar under selinux-policy-targeted now I look there. I did however >bugzilla this myself this morning >(http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130969). I'll add >your comment to it. > >Leonard. > > > See: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130421 Russell Coker filed this on the 20th. Thanks Russell! Richard Hally From n3npq at nc.rr.com Thu Aug 26 16:12:03 2004 From: n3npq at nc.rr.com (Jeff Johnson) Date: Thu, 26 Aug 2004 12:12:03 -0400 Subject: glibc post upgrade In-Reply-To: <1093528312.9280.112.camel@moss-spartans.epoch.ncsc.mil> References: <200408232344.23345.russell@coker.com.au> <412A21A6.7040203@nc.rr.com> <1093281676.27211.159.camel@moss-spartans.epoch.ncsc.mil> <412A3701.2020401@redhat.com> <412A6E4E.5080600@nc.rr.com> <1093439297.6743.69.camel@moss-spartans.epoch.ncsc.mil> <412C9A09.700@nc.rr.com> <1093442521.6743.109.camel@moss-spartans.epoch.ncsc.mil> <412DAF5A.9030906@nc.rr.com> <1093527871.9280.110.camel@moss-spartans.epoch.ncsc.mil> <1093528312.9280.112.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <412E0BD3.4010806@nc.rr.com> Stephen Smalley wrote: >On Thu, 2004-08-26 at 09:44, Stephen Smalley wrote: > > >>On Thu, 2004-08-26 at 05:37, Jeff Johnson wrote: >> >> >>>Malicious code from untrusted package problem not going to be solved by >>>rpm_script_t alone afaict either. >>> >>> >>Right. We still need a mechanism for distinguishing among packages and >>running scriptlets in different domains based on either some property of >>the package (the authority that signed it) or some knowledge of the >>admin (i.e. he specifies the desired scriptlet domain for all packages >>obtained from a given repository in his yum.conf or similar). >> >> > >Not to mention needing different domains for rpm itself in such >scenarios... > > There are a slew of issues beyond the mechanics of exec'ing a helper to establish a new domain for rpm to run in. The open questions that I have are: a) Can untrusted and trusted data be stored in the same file? b) Can trusted packages depend on untrusted? How? c) How to preserve the existing rpmlib API while re-execing a helper that will require non-trivial amounts of state to be reconstructed? "trust" defined however selinux wishes of course. Probably easier to write an installer from scratch for selinux purposes than it will be to try to adapt the existing rpm code base is my current opinion. 73 de Jeff From dwalsh at redhat.com Thu Aug 26 17:41:03 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 26 Aug 2004 13:41:03 -0400 Subject: Cleaned up udev-selinux patch In-Reply-To: <20040826155716.GA30726@kroah.com> References: <20040223213614.GA12242@devserv.devel.redhat.com> <20040224233859.GA3265@kroah.com> <20040224234652.GA14775@devserv.devel.redhat.com> <403C8AE4.10403@redhat.com> <20040228005300.GA13860@kroah.com> <412DFE7B.6060409@redhat.com> <20040826155716.GA30726@kroah.com> Message-ID: <412E20AF.7000102@redhat.com> Greg KH wrote: >On Thu, Aug 26, 2004 at 11:15:07AM -0400, Daniel J Walsh wrote: > > >>This will create the security contexts on the fly. >> >>Please comment on what would be needed to get this acceptable? >> >> > >Same things I said on the mailing list: > - fix coding style > - no ifdefs in .c files > - make the selinux stuff all be in its own file > - make the build flag look like the other build flags > - not make the makefile changes have silly line continuations > when not needed :) > - post the patch on the mailing list (linux-hotplug-devel) for > others to comment on after fixing the above. > >thanks, > >greg k-h > > Another pass at a cleaned up patch. This time attempting to folow Greg guidelines. Dan -------------- next part -------------- A non-text attachment was scrubbed... Name: udev-030-selinux.patch Type: text/x-patch Size: 4830 bytes Desc: not available URL: From greg at kroah.com Thu Aug 26 17:51:39 2004 From: greg at kroah.com (Greg KH) Date: Thu, 26 Aug 2004 10:51:39 -0700 Subject: Cleaned up udev-selinux patch In-Reply-To: <412E20AF.7000102@redhat.com> References: <20040223213614.GA12242@devserv.devel.redhat.com> <20040224233859.GA3265@kroah.com> <20040224234652.GA14775@devserv.devel.redhat.com> <403C8AE4.10403@redhat.com> <20040228005300.GA13860@kroah.com> <412DFE7B.6060409@redhat.com> <20040826155716.GA30726@kroah.com> <412E20AF.7000102@redhat.com> Message-ID: <20040826175139.GA12225@kroah.com> On Thu, Aug 26, 2004 at 01:41:03PM -0400, Daniel J Walsh wrote: > Greg KH wrote: > > >On Thu, Aug 26, 2004 at 11:15:07AM -0400, Daniel J Walsh wrote: > > > > > >>This will create the security contexts on the fly. > >> > >>Please comment on what would be needed to get this acceptable? > >> > >> > > > >Same things I said on the mailing list: > > - fix coding style > > - no ifdefs in .c files > > - make the selinux stuff all be in its own file > > - make the build flag look like the other build flags > > - not make the makefile changes have silly line continuations > > when not needed :) > > - post the patch on the mailing list (linux-hotplug-devel) for > > others to comment on after fixing the above. > > > >thanks, > > > >greg k-h > > > > > Another pass at a cleaned up patch. This time attempting to folow Greg > guidelines. Looks good. Do you really want it all in a .h file? I don't mind having the selinux functions being in a .c file and building that if USE_SELINUX is enabled. But it's your call, as you are the one going to have to live with the code :) thanks, greg k-h From leonard at den.ottolander.nl Thu Aug 26 19:01:29 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 26 Aug 2004 21:01:29 +0200 Subject: xfs socket startup fails with strict policy In-Reply-To: <412E0B93.9030207@mindspring.com> References: <1093474268.4788.107.camel@athlon.localdomain> <1093522017.9280.4.camel@moss-spartans.epoch.ncsc.mil> <1093530344.4786.15.camel@athlon.localdomain> <412E0B93.9030207@mindspring.com> Message-ID: <1093546889.4786.115.camel@athlon.localdomain> Hi Richard, On Thu, 2004-08-26 at 18:10, Richard Hally wrote: > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130421 > > Russell Coker filed this on the 20th. Thanks Russell! > > Richard Hally Yeah, only not with the correct package. This is not an issue with X. Maybe with selinux-policy-strict, udev, or xfs, bug not X. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From dwalsh at redhat.com Thu Aug 26 19:07:23 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 26 Aug 2004 15:07:23 -0400 Subject: Cleaned up udev-selinux patch In-Reply-To: <20040826175139.GA12225@kroah.com> References: <20040223213614.GA12242@devserv.devel.redhat.com> <20040224233859.GA3265@kroah.com> <20040224234652.GA14775@devserv.devel.redhat.com> <403C8AE4.10403@redhat.com> <20040228005300.GA13860@kroah.com> <412DFE7B.6060409@redhat.com> <20040826155716.GA30726@kroah.com> <412E20AF.7000102@redhat.com> <20040826175139.GA12225@kroah.com> Message-ID: <412E34EB.1030909@redhat.com> Greg KH wrote: >On Thu, Aug 26, 2004 at 01:41:03PM -0400, Daniel J Walsh wrote: > > >>Greg KH wrote: >> >> >> >>>On Thu, Aug 26, 2004 at 11:15:07AM -0400, Daniel J Walsh wrote: >>> >>> >>> >>> >>>>This will create the security contexts on the fly. >>>> >>>>Please comment on what would be needed to get this acceptable? >>>> >>>> >>>> >>>> >>>Same things I said on the mailing list: >>> - fix coding style >>> - no ifdefs in .c files >>> - make the selinux stuff all be in its own file >>> - make the build flag look like the other build flags >>> - not make the makefile changes have silly line continuations >>> when not needed :) >>> - post the patch on the mailing list (linux-hotplug-devel) for >>> others to comment on after fixing the above. >>> >>>thanks, >>> >>>greg k-h >>> >>> >>> >>> >>Another pass at a cleaned up patch. This time attempting to folow Greg >>guidelines. >> >> > >Looks good. Do you really want it all in a .h file? I don't mind >having the selinux functions being in a .c file and building that if >USE_SELINUX is enabled. > >But it's your call, as you are the one going to have to live with the >code :) > >thanks, > >greg k-h > > I copied the way it was being done with logging.h I already have some updates from comments from other people. Dan From leonard at den.ottolander.nl Thu Aug 26 19:15:46 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 26 Aug 2004 21:15:46 +0200 Subject: xfs socket startup fails with strict policy In-Reply-To: <1093546889.4786.115.camel@athlon.localdomain> References: <1093474268.4788.107.camel@athlon.localdomain> <1093522017.9280.4.camel@moss-spartans.epoch.ncsc.mil> <1093530344.4786.15.camel@athlon.localdomain> <412E0B93.9030207@mindspring.com> <1093546889.4786.115.camel@athlon.localdomain> Message-ID: <1093547745.4786.118.camel@athlon.localdomain> Hi, I wrote: > Yeah, only not with the correct package. This is not an issue with X. > Maybe with selinux-policy-strict, udev, or xfs, bug not X. Sorry. Has nothing to do with udev. My mistake. It's just there's a load of udev warnings at the same time. No relation though. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From greg at kroah.com Thu Aug 26 19:14:22 2004 From: greg at kroah.com (Greg KH) Date: Thu, 26 Aug 2004 12:14:22 -0700 Subject: Cleaned up udev-selinux patch In-Reply-To: <412E34EB.1030909@redhat.com> References: <20040223213614.GA12242@devserv.devel.redhat.com> <20040224233859.GA3265@kroah.com> <20040224234652.GA14775@devserv.devel.redhat.com> <403C8AE4.10403@redhat.com> <20040228005300.GA13860@kroah.com> <412DFE7B.6060409@redhat.com> <20040826155716.GA30726@kroah.com> <412E20AF.7000102@redhat.com> <20040826175139.GA12225@kroah.com> <412E34EB.1030909@redhat.com> Message-ID: <20040826191422.GB13310@kroah.com> On Thu, Aug 26, 2004 at 03:07:23PM -0400, Daniel J Walsh wrote: > Greg KH wrote: > > >Looks good. Do you really want it all in a .h file? I don't mind > >having the selinux functions being in a .c file and building that if > >USE_SELINUX is enabled. > > > >But it's your call, as you are the one going to have to live with the > >code :) > > I copied the way it was being done with logging.h Yeah, but logging.h has such tiny functions :) Anyway, it's your decision. > I already have some updates from comments from other people. Ok, feel free to send me a patch when you feel it should be applied. thanks, greg k-h From sds at epoch.ncsc.mil Thu Aug 26 19:37:34 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 26 Aug 2004 15:37:34 -0400 Subject: Caveat: checkpolicy broken with respect to policy Message-ID: <1093549054.9280.234.camel@moss-spartans.epoch.ncsc.mil> Hi, policy 1.17.3 and later are not being handled properly by checkpolicy, because the update that was supposed to go out with checkpolicy-1.16.2 was not built properly due to a packaging mistake. End result: All reserved ports are remapped to reserved_port_t, and most daemons will fail during startup due to a lack of name_bind permission, at least with strict policy. Fixed checkpolicy should be available soon. -- Stephen Smalley National Security Agency From rhally at mindspring.com Thu Aug 26 21:12:49 2004 From: rhally at mindspring.com (Richard Hally) Date: Thu, 26 Aug 2004 17:12:49 -0400 Subject: xfs socket startup fails with strict policy In-Reply-To: <1093546889.4786.115.camel@athlon.localdomain> References: <1093474268.4788.107.camel@athlon.localdomain> <1093522017.9280.4.camel@moss-spartans.epoch.ncsc.mil> <1093530344.4786.15.camel@athlon.localdomain> <412E0B93.9030207@mindspring.com> <1093546889.4786.115.camel@athlon.localdomain> Message-ID: <412E5251.7080101@mindspring.com> Leonard den Ottolander wrote: >Hi Richard, > >On Thu, 2004-08-26 at 18:10, Richard Hally wrote: > > >>http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130421 >> >>Russell Coker filed this on the 20th. Thanks Russell! >> >>Richard Hally >> >> > >Yeah, only not with the correct package. This is not an issue with X. >Maybe with selinux-policy-strict, udev, or xfs, bug not X. > >Leonard. > > > Hi Leonard, Look like the correction needs to be made in the X startup script. At least I run into the problem when trying to start X. But I guess I'm silly to think the bug should be reported against xorg-X11. Isn't xfs part of or used by xorg-X11? Richard Hally From lkcl at lkcl.net Thu Aug 26 22:59:28 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 26 Aug 2004 23:59:28 +0100 Subject: Cleaned up udev-selinux patch In-Reply-To: <412E34EB.1030909@redhat.com> References: <20040223213614.GA12242@devserv.devel.redhat.com> <20040224233859.GA3265@kroah.com> <20040224234652.GA14775@devserv.devel.redhat.com> <403C8AE4.10403@redhat.com> <20040228005300.GA13860@kroah.com> <412DFE7B.6060409@redhat.com> <20040826155716.GA30726@kroah.com> <412E20AF.7000102@redhat.com> <20040826175139.GA12225@kroah.com> <412E34EB.1030909@redhat.com> Message-ID: <20040826225928.GD6058@lkcl.net> perhaps the style should be that the Makefile adds some code add_selinux.c based on a configure-time option, and that some #ifdefs in a header file call a function which is a stub in the header if WITH_SELINUX is not defined. bizarre_but_likely_quite_good_coding_style_never_encountered_before.h: #ifdef WITH_SELINUX int do_add_selinux_stuff(args) { return 0; } #else #define do_add_selinux_stuff the_real_add_selinux_stuff #endif and add_selinux.c contains: int the_real_add_selinux_stuff(args) { .... return err; } On Thu, Aug 26, 2004 at 03:07:23PM -0400, Daniel J Walsh wrote: > Greg KH wrote: > > >On Thu, Aug 26, 2004 at 01:41:03PM -0400, Daniel J Walsh wrote: > > > > > >>Greg KH wrote: > >> > >> > >> > >>>On Thu, Aug 26, 2004 at 11:15:07AM -0400, Daniel J Walsh wrote: > >>> > >>> > >>> > >>> > >>>>This will create the security contexts on the fly. > >>>> > >>>>Please comment on what would be needed to get this acceptable? > >>>> > >>>> > >>>> > >>>> > >>>Same things I said on the mailing list: > >>> - fix coding style > >>> - no ifdefs in .c files > >>> - make the selinux stuff all be in its own file > >>> - make the build flag look like the other build flags > >>> - not make the makefile changes have silly line continuations > >>> when not needed :) > >>> - post the patch on the mailing list (linux-hotplug-devel) for > >>> others to comment on after fixing the above. > >>> > >>>thanks, > >>> > >>>greg k-h > >>> > >>> > >>> > >>> > >>Another pass at a cleaned up patch. This time attempting to folow Greg > >>guidelines. > >> > >> > > > >Looks good. Do you really want it all in a .h file? I don't mind > >having the selinux functions being in a .c file and building that if > >USE_SELINUX is enabled. > > > >But it's your call, as you are the one going to have to live with the > >code :) > > > >thanks, > > > >greg k-h > > > > > I copied the way it was being done with logging.h > > I already have some updates from comments from other people. > > Dan > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to majordomo at tycho.nsa.gov > with > the words "unsubscribe selinux" without quotes as the message. -- -- Truth, honesty and respect are rare commodities that all spring from the same well: Love. If you love yourself and everyone and everything around you, funnily and coincidentally enough, life gets a lot better. -- lkcl.net
lkcl at lkcl.net
From lkcl at lkcl.net Thu Aug 26 23:02:21 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 27 Aug 2004 00:02:21 +0100 Subject: Cleaned up udev-selinux patch In-Reply-To: <412E20AF.7000102@redhat.com> References: <20040223213614.GA12242@devserv.devel.redhat.com> <20040224233859.GA3265@kroah.com> <20040224234652.GA14775@devserv.devel.redhat.com> <403C8AE4.10403@redhat.com> <20040228005300.GA13860@kroah.com> <412DFE7B.6060409@redhat.com> <20040826155716.GA30726@kroah.com> <412E20AF.7000102@redhat.com> Message-ID: <20040826230221.GE6058@lkcl.net> On Thu, Aug 26, 2004 at 01:41:03PM -0400, Daniel J Walsh wrote: like this: --- /dev/null 2004-06-21 15:29:38.000000000 -0400 +++ udev-030/selinux.h 2004-08-26 13:14:05.730808665 -0400 @@ -0,0 +1,87 @@ +#ifndef SELINUX_H +#define SELINUX_H + +#ifndef USE_SELINUX +#define set_selinux_set_context(file, mode) do { } while (0) +#define selinux_setup_context(file, mode) do { } while (0) +#define selinux_init() do { } while (0) +#define selinux_restore() do { } while (0) + +#else + +#define set_selinux_set_context real_set_selinux_context +#define set_selinux_setup_context real_set_setup_context +... --- /dev/null 2004-06-21 15:29:38.000000000 -0400 +++ udev-030/selinux.c 2004-08-26 13:14:05.730808665 -0400 +#include + +static int selinux_enabled=-1; +static security_context_t prev_scontext=NULL; + +#undef is_selinux_running +static inline int is_selinux_running(void) { + if ( selinux_enabled==-1 ) + return selinux_enabled=is_selinux_enabled()>0; + return selinux_enabled; +} +#undef selinux_set_context +void real_selinux_set_context(char *file, unsigned int mode) { ^^^^ From greg at kroah.com Thu Aug 26 22:56:40 2004 From: greg at kroah.com (Greg KH) Date: Thu, 26 Aug 2004 15:56:40 -0700 Subject: Cleaned up udev-selinux patch In-Reply-To: <20040826225928.GD6058@lkcl.net> References: <20040224233859.GA3265@kroah.com> <20040224234652.GA14775@devserv.devel.redhat.com> <403C8AE4.10403@redhat.com> <20040228005300.GA13860@kroah.com> <412DFE7B.6060409@redhat.com> <20040826155716.GA30726@kroah.com> <412E20AF.7000102@redhat.com> <20040826175139.GA12225@kroah.com> <412E34EB.1030909@redhat.com> <20040826225928.GD6058@lkcl.net> Message-ID: <20040826225640.GA13818@kroah.com> On Thu, Aug 26, 2004 at 11:59:28PM +0100, Luke Kenneth Casson Leighton wrote: > perhaps the style should be that the Makefile adds some code > add_selinux.c based on a configure-time option, > > and that some #ifdefs in a header file call a function which > is a stub in the header if WITH_SELINUX is not defined. > > bizarre_but_likely_quite_good_coding_style_never_encountered_before.h: You've never read Linux kernel code, have you :) > #ifdef WITH_SELINUX > int do_add_selinux_stuff(args) { return 0; } Logic is backwards here. > #else > #define do_add_selinux_stuff the_real_add_selinux_stuff This define is unncessary. Just call the function do_add_selinux_stuff(), and protype it. Actually, inline functions that do nothing if selinux is disabled is better to catch compiler errors with types if things change in the future. thanks, greg k-h From leonard at den.ottolander.nl Fri Aug 27 00:15:30 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 27 Aug 2004 02:15:30 +0200 Subject: xfs socket startup fails with strict policy In-Reply-To: <412E5251.7080101@mindspring.com> References: <1093474268.4788.107.camel@athlon.localdomain> <1093522017.9280.4.camel@moss-spartans.epoch.ncsc.mil> <1093530344.4786.15.camel@athlon.localdomain> <412E0B93.9030207@mindspring.com> <1093546889.4786.115.camel@athlon.localdomain> <412E5251.7080101@mindspring.com> Message-ID: <1093565729.4786.142.camel@athlon.localdomain> Hi Richard, On Thu, 2004-08-26 at 23:12, Richard Hally wrote: > Look like the correction needs to be made in the X startup script. By the way, can one work around this by enabling tcp sockets for xfs? Or is there a one line patch that makes the startup script tag that directory correctly? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Fri Aug 27 00:11:43 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 27 Aug 2004 02:11:43 +0200 Subject: xfs socket startup fails with strict policy In-Reply-To: <412E5251.7080101@mindspring.com> References: <1093474268.4788.107.camel@athlon.localdomain> <1093522017.9280.4.camel@moss-spartans.epoch.ncsc.mil> <1093530344.4786.15.camel@athlon.localdomain> <412E0B93.9030207@mindspring.com> <1093546889.4786.115.camel@athlon.localdomain> <412E5251.7080101@mindspring.com> Message-ID: <1093565503.4786.139.camel@athlon.localdomain> Hi Richard, On Thu, 2004-08-26 at 23:12, Richard Hally wrote: > Look like the correction needs to be made in the X startup script. At > least I run into the problem when trying to start X. But I guess I'm > silly to think the bug should be reported against xorg-X11. Isn't xfs > part of or used by xorg-X11? Looks like I'm the silly one ;-\ . I stand corrected. Of course xfs is an integral part of the xorg-x11 source rpm. I believed this to be a policy issue though, so I missed that report. If the mislabeling happens during startup (hadn't thought of it that way, but now you say, fixfiles relabel did ask me to remove /tmp files) this is indeed more of an xfs (xorg) issue than a policy matter. Checking xorg-x11 for entries wouldn't have been a bad idea anyway ;) . Leonard. -- mount -t life -o ro /dev/dna /genetic/research From rhally at mindspring.com Fri Aug 27 05:07:01 2004 From: rhally at mindspring.com (Richard Hally) Date: Fri, 27 Aug 2004 01:07:01 -0400 Subject: xfs socket startup fails with strict policy In-Reply-To: <1093565729.4786.142.camel@athlon.localdomain> References: <1093474268.4788.107.camel@athlon.localdomain> <1093522017.9280.4.camel@moss-spartans.epoch.ncsc.mil> <1093530344.4786.15.camel@athlon.localdomain> <412E0B93.9030207@mindspring.com> <1093546889.4786.115.camel@athlon.localdomain> <412E5251.7080101@mindspring.com> <1093565729.4786.142.camel@athlon.localdomain> Message-ID: <412EC175.6040600@mindspring.com> Leonard den Ottolander wrote: >Hi Richard, > >On Thu, 2004-08-26 at 23:12, Richard Hally wrote: > > >>Look like the correction needs to be made in the X startup script. >> >> > >By the way, can one work around this by enabling tcp sockets for xfs? Or >is there a one line patch that makes the startup script tag that >directory correctly? > >Leonard. > > > Below is part of the previous thread "SELinux stops new X11" (I'd give you a url but the list archive is down att) There may be changes to the strict policy from Russell Coker as well. Richard Hally On Thu, 2004-08-19 at 19:10, Richard Hally wrote: >> The new xorg-X11(6.7.99.902-1) will not start with the current strict >> SELinux policy(1.15.16-1) in enforcing mode. (xorg-x11-*6.7.0-7.2 works >> just fine). I have not tried permissive mode. >> It looks like something has changed in X11 that has to do with the >> fonts and the SE policy has not been updated to handle it but that is >> just speculation. > > I applied the patch below to my /etc/init.d/xfs to fix. This patch restores the type on /tmp/.font-unix when it is re-created by /etc/init.d/xfs. I assume that previously xfs was directly creating the directory itself, so that the file_type_auto_trans rule for xfs_t was sufficient to label it, but since it is now being created by the init script, it is getting a different type. --- /etc/init.d/xfs.old 2004-08-18 14:45:54.000000000 -0400 +++ /etc/init.d/xfs 2004-08-20 07:16:01.539914488 -0400 @@ -78,6 +78,7 @@ mkdir $FONT_UNIX_DIR chown root:root $FONT_UNIX_DIR chmod 1777 $FONT_UNIX_DIR + restorecon $FONT_UNIX_DIR daemon xfs -droppriv -daemon ret=$? -- 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 leonard at den.ottolander.nl Fri Aug 27 08:39:44 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 27 Aug 2004 10:39:44 +0200 Subject: xfs socket startup fails with strict policy In-Reply-To: <412EC175.6040600@mindspring.com> References: <1093474268.4788.107.camel@athlon.localdomain> <1093522017.9280.4.camel@moss-spartans.epoch.ncsc.mil> <1093530344.4786.15.camel@athlon.localdomain> <412E0B93.9030207@mindspring.com> <1093546889.4786.115.camel@athlon.localdomain> <412E5251.7080101@mindspring.com> <1093565729.4786.142.camel@athlon.localdomain> <412EC175.6040600@mindspring.com> Message-ID: <1093595984.4786.6.camel@athlon.localdomain> Hello Richard, On Fri, 2004-08-27 at 07:07, Richard Hally wrote: > Leonard den Ottolander wrote: > >Or is there a one line patch that makes the startup script tag that > >directory correctly? > --- /etc/init.d/xfs.old 2004-08-18 14:45:54.000000000 -0400 > +++ /etc/init.d/xfs 2004-08-20 07:16:01.539914488 -0400 > @@ -78,6 +78,7 @@ > mkdir $FONT_UNIX_DIR > chown root:root $FONT_UNIX_DIR > chmod 1777 $FONT_UNIX_DIR > + restorecon $FONT_UNIX_DIR > > daemon xfs -droppriv -daemon > ret=$? That did the trick. Thanks. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From russell at coker.com.au Fri Aug 27 12:22:42 2004 From: russell at coker.com.au (Russell Coker) Date: Fri, 27 Aug 2004 22:22:42 +1000 Subject: sshd Message-ID: <200408272222.42422.russell@coker.com.au> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131083 The latest sshd in rawhide does not work correctly with SE Linux. It does not label the pseudo-tty and thus all logins will fail in enforcing mode with the strict policy. Above is the URL for the bugzilla entry I created, I have not had time to look at the code yet. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From dwalsh at redhat.com Fri Aug 27 13:32:02 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 27 Aug 2004 09:32:02 -0400 Subject: Cleaned up udev-selinux patch In-Reply-To: <20040826225640.GA13818@kroah.com> References: <20040224233859.GA3265@kroah.com> <20040224234652.GA14775@devserv.devel.redhat.com> <403C8AE4.10403@redhat.com> <20040228005300.GA13860@kroah.com> <412DFE7B.6060409@redhat.com> <20040826155716.GA30726@kroah.com> <412E20AF.7000102@redhat.com> <20040826175139.GA12225@kroah.com> <412E34EB.1030909@redhat.com> <20040826225928.GD6058@lkcl.net> <20040826225640.GA13818@kroah.com> Message-ID: <412F37D2.7070105@redhat.com> Further cleanup and using all static inlines versus defines. Renamed a couple of functions to make them clearer. Dan -------------- next part -------------- A non-text attachment was scrubbed... Name: udev-030-selinux.patch Type: text/x-patch Size: 4498 bytes Desc: not available URL: From lkcl at lkcl.net Fri Aug 27 14:28:55 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 27 Aug 2004 15:28:55 +0100 Subject: Cleaned up udev-selinux patch In-Reply-To: <20040826225640.GA13818@kroah.com> References: <20040224234652.GA14775@devserv.devel.redhat.com> <403C8AE4.10403@redhat.com> <20040228005300.GA13860@kroah.com> <412DFE7B.6060409@redhat.com> <20040826155716.GA30726@kroah.com> <412E20AF.7000102@redhat.com> <20040826175139.GA12225@kroah.com> <412E34EB.1030909@redhat.com> <20040826225928.GD6058@lkcl.net> <20040826225640.GA13818@kroah.com> Message-ID: <20040827142855.GC3850@lkcl.net> On Thu, Aug 26, 2004 at 03:56:40PM -0700, Greg KH wrote: > On Thu, Aug 26, 2004 at 11:59:28PM +0100, Luke Kenneth Casson Leighton wrote: > > perhaps the style should be that the Makefile adds some code > > add_selinux.c based on a configure-time option, > > > > and that some #ifdefs in a header file call a function which > > is a stub in the header if WITH_SELINUX is not defined. > > > > bizarre_but_likely_quite_good_coding_style_never_encountered_before.h: > > You've never read Linux kernel code, have you :) all the tiime :) no, but seriously i have: i spent about three months porting linux to the xda-2 (400mhz intel-arm pxa263) l. From lkcl at lkcl.net Fri Aug 27 15:42:00 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 27 Aug 2004 16:42:00 +0100 Subject: Cleaned up udev-selinux patch In-Reply-To: <412F37D2.7070105@redhat.com> References: <403C8AE4.10403@redhat.com> <20040228005300.GA13860@kroah.com> <412DFE7B.6060409@redhat.com> <20040826155716.GA30726@kroah.com> <412E20AF.7000102@redhat.com> <20040826175139.GA12225@kroah.com> <412E34EB.1030909@redhat.com> <20040826225928.GD6058@lkcl.net> <20040826225640.GA13818@kroah.com> <412F37D2.7070105@redhat.com> Message-ID: <20040827154200.GB4760@lkcl.net> On Fri, Aug 27, 2004 at 09:32:02AM -0400, Daniel J Walsh wrote: > Further cleanup and using all static inlines versus defines. Renamed a > couple of functions to make them clearer. > +} > +static inline void selinux_setfilecon(char *file, unsigned int mode) { > + if (is_selinux_running()) { > + security_context_t scontext=NULL; > + if (matchpathcon(file, mode, &scontext) < 0) { > + dbg("matchpathcon(%s) failed\n", file); > + } else { > + > + if (setfilecon(file, scontext) < 0) > + dbg("setfiles %s failed with error '%s'", > + file, strerror(errno)); > + freecon(scontext); > + } > + } > +} > + > +static inline void selinux_setfscreatecon(char *file, unsigned int mode) { > + int retval = 0; > + security_context_t scontext=NULL; > + > + if (is_selinux_running()) { > + if (matchpathcon(file, S_IFDIR, &scontext) < 0) { ^^^^^^^ this should be matchpathcon(file, mode, &scontext) From jmorris at redhat.com Fri Aug 27 15:36:33 2004 From: jmorris at redhat.com (James Morris) Date: Fri, 27 Aug 2004 11:36:33 -0400 (EDT) Subject: Cleaned up udev-selinux patch In-Reply-To: <412F37D2.7070105@redhat.com> Message-ID: On Fri, 27 Aug 2004, Daniel J Walsh wrote: > Further cleanup and using all static inlines versus defines. Renamed a > couple of functions to make them clearer. I think Luke is right, these functions should be in a .c file. - James -- James Morris From jim-cornette at sbcglobal.net Sat Aug 28 03:51:56 2004 From: jim-cornette at sbcglobal.net (Jim Cornette) Date: Fri, 27 Aug 2004 23:51:56 -0400 Subject: Thanks! - Now able to test SELinux in enforcing. Message-ID: <4130015C.9020805@sbcglobal.net> Earlier on in the list, I mentioned problems getting SELinux to even boot so I could test it out. I'd like to thank those for the guidance on getting the problems straightened out on my end with advice. I can now run SELInux in enforcing mode and using the targeted policy. Thanks! Jim -- What a strange game. The only winning move is not to play. -- WOP, "War Games" From jim-cornette at sbcglobal.net Sat Aug 28 17:36:48 2004 From: jim-cornette at sbcglobal.net (Jim Cornette) Date: Sat, 28 Aug 2004 13:36:48 -0400 Subject: dot directory - .mozilla, .gqview, ETC: Message-ID: <4130C2B0.4090906@sbcglobal.net> After finally getting SELinux working, I had a message related to the .whatever configuration directories in the /home/user directories. The local email to root is attached. The mail in not long and seems to be fairly minor. The other errors are obvious within the attachment. (kernel modules, etc) I don't know if this is helpful or just a "not again", but here it is. Jim -- There's a fine line between courage and foolishness. Too bad it's not a fence. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: invalid-file-contents URL: From jim-cornette at sbcglobal.net Sat Aug 28 17:49:46 2004 From: jim-cornette at sbcglobal.net (Jim Cornette) Date: Sat, 28 Aug 2004 13:49:46 -0400 Subject: dot directory - (exceptions) In-Reply-To: <4130C2B0.4090906@sbcglobal.net> References: <4130C2B0.4090906@sbcglobal.net> Message-ID: <4130C5BA.5070006@sbcglobal.net> Jim Cornette wrote: > After finally getting SELinux working, I had a message related to the > .whatever configuration directories in the /home/user directories. > The local email to root is attached. The mail in not long and seems to > be fairly minor. The other errors are obvious within the attachment. > (kernel modules, etc) > > I don't know if this is helpful or just a "not again", but here it is. > > Jim > The below files were originally root owner and group. I changed these to be owned by jim using the program mc. I didn't chmod user or chgrp user . I don't know if using thealternative method would have kept the relabeling files error free. /home/jim/avc-kernel-reinstall.txt /home/jim/fixfiles-cron /home/jim/relabeled.targeted.permissive.txt Jim From selinux at comcast.net Sat Aug 28 18:29:47 2004 From: selinux at comcast.net (Tom London) Date: Sat, 28 Aug 2004 11:29:47 -0700 Subject: Progress! .532 boots! -- but dbus/hotplug/udev problems remain? Message-ID: <4130CF1B.3090909@comcast.net> Newest Rawhide updates (including udev-030-10, mkinitrd-4.1.8-1, kernel-2.6.8-1.532, and selinux-policy-strict-1.17.5-2) now boots in strict/enforcing. Many AVCs, and there is a problem with runlevel 5 (graphical login, etc.) preventing login, (but text login works). Here are the first, early AVCs: (I'll dig for more later.) Aug 28 10:23:40 fedora kernel: usbcore: registered new driver usblp Aug 28 10:23:40 fedora kernel: drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver Aug 28 10:23:40 fedora acpid: acpid startup succeeded Aug 28 10:23:40 fedora kernel: ACPI: Power Button (FF) [PWRF] Aug 28 10:23:40 fedora kernel: ACPI: Sleep Button (CM) [FUTS] Aug 28 10:23:40 fedora kernel: EXT3 FS on hda2, internal journal Aug 28 10:23:41 fedora kernel: audit(1093713783.757:0): avc: denied { search } for pid=1264 exe=/sbin/udev name=contexts dev=hda2 ino=4509745 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:default_context_t tclass=dir Aug 28 10:23:41 fedora kernel: audit(1093713783.790:0): avc: denied { execute_no_trans } for pid=1271 exe=/sbin/udev path=/etc/udev/scripts/pam_console.dev dev=hda2 ino=574019 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Aug 28 10:23:41 fedora kernel: audit(1093713783.790:0): avc: denied { write } for pid=1264 exe=/sbin/udev name=fscreate dev=proc ino=82837526 scontext=system_u:system_r:udev_t tcontext=system_u:system_r:udev_t tclass=file There repeat many times. When run in permissive mode, this sequence becomes: Aug 28 10:32:25 fedora kernel: EXT3 FS on hda2, internal journal Aug 28 10:32:25 fedora kernel: audit(1093714297.852:0): avc: denied { search } for pid=1283 exe=/sbin/udev name=contexts dev=hda2 ino=4509745 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:default_context_t tclass=dir Aug 28 10:32:25 fedora kernel: audit(1093714297.859:0): avc: denied { search } for pid=1283 exe=/sbin/udev name=files dev=hda2 ino=4509746 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:file_context_t tclass=dir Aug 28 10:32:25 fedora kernel: audit(1093714297.872:0): avc: denied { read } for pid=1283 exe=/sbin/udev name=file_contexts dev=hda2 ino=4505700 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:file_context_t tclass=file Aug 28 10:32:25 fedora kernel: audit(1093714297.872:0): avc: denied { getattr } for pid=1283 exe=/sbin/udev path=/etc/selinux/strict/contexts/files/file_contexts dev=hda2 ino=4505700 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:file_context_t tclass=file Aug 28 10:32:25 fedora kernel: audit(1093714298.077:0): avc: denied { execute_no_trans } for pid=1285 exe=/sbin/udev path=/etc/udev/scripts/pam_console.dev dev=hda2 ino=574019 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Aug 28 10:32:25 fedora kernel: audit(1093714298.109:0): avc: denied { search } for pid=1285 exe=/bin/bash name=console dev=hda2 ino=4456494 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:pam_var_console_t tclass=dir Aug 28 10:32:25 fedora kernel: audit(1093714298.113:0): avc: denied { write } for pid=1283 exe=/sbin/udev name=fscreate dev=proc ino=84082710 scontext=system_u:system_r:udev_t tcontext=system_u:system_r:udev_t tclass=file Aug 28 10:32:25 fedora kernel: audit(1093714298.113:0): avc: denied { setfscreate } for pid=1283 exe=/sbin/udev scontext=system_u:system_r:udev_t tcontext=system_u:system_r:udev_t tclass=process Aug 28 10:32:25 fedora kernel: audit(1093714317.126:0): avc: denied { search } for pid=1671 exe=/sbin/udev name=files dev=hda2 ino=4509746 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:file_context_t tclass=dir Audit2allow on this says: allow : { write }; allow udev_t default_context_t:dir { search }; allow udev_t etc_t:file { execute_no_trans }; allow udev_t file_context_t:dir { search }; allow udev_t file_context_t:file { read }; allow udev_t pam_var_console_t:dir { search }; allow udev_t udev_t:process { setfscreate }; The funny 'allow : { write };' is for the write of 'fscreate' in /proc. After obtaining the graphical login screen, here is the offending AVC: Aug 28 10:24:42 fedora gdm(pam_unix)[3888]: session opened for user tbl by (uid=0) Aug 28 10:24:43 fedora kernel: audit(1093713883.626:0): avc: denied { create } for pid=4042 exe=/usr/bin/dbus-daemon-1 scontext=user_u:user_r:user_t tcontext=user_u:user_r:user_t tclass=netlink_selinux_socket An error window pops up reporting an SELinux/AVC type failure. It then returns to the login screen. Just prior to that, there are many 'denied's from udev and hald. Here are a few: Aug 28 10:24:21 fedora dbus: avc: denied { send_msg } for scontext=system_u:system_r:hald_t tcontext=system_u:system_r:updfstab_t tclass=dbus Aug 28 10:24:21 fedora kernel: audit(1093713853.755:0): avc: denied { execute } for pid=3466 exe=/usr/sbin/hald name=hal-hotplug-map dev=hda2 ino=606213 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:bin_t tclass=file Aug 28 10:24:21 fedora udev[3953]: creating device node '/dev/vcs7' Aug 28 10:24:22 fedora dbus: avc: denied { send_msg } for scontext=system_u:system_r:hald_t tcontext=system_u:system_r:updfstab_t tclass=dbus Aug 28 10:24:22 fedora kernel: audit(1093713853.817:0): avc: denied { search } for pid=3798 exe=/sbin/udev name=contexts dev=hda2 ino=4509745 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:default_context_t tclass=dir Aug 28 10:24:22 fedora dbus: avc: denied { send_msg } for scontext=system_u:system_r:hald_t tcontext=system_u:system_r:updfstab_t tclass=dbus Aug 28 10:24:22 fedora kernel: audit(1093713853.819:0): avc: denied { execute_no_trans } for pid=3846 exe=/sbin/udev path=/etc/udev/scripts/pam_console.dev dev=hda2 ino=574019 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=file Aug 28 10:24:22 fedora dbus: avc: denied { send_msg } for scontext=system_u:system_r:updfstab_t tcontext=system_u:system_r:hald_t tclass=dbus Aug 28 10:24:22 fedora kernel: audit(1093713853.820:0): avc: denied { write } for pid=3798 exe=/sbin/udev name=fscreate dev=proc ino=248905750 scontext=system_u:system_r:udev_t tcontext=system_u:system_r:udev_t tclass=file [BTW: When I reboot, /etc/fstab has been relabeled to type tmp_t. Is the above causing this?] I rebooted strict/permissive, and things appear OK, including loading of sound modules. However, as noted above, something is relabeling /etc/fstab to tmp_t: Aug 28 10:33:21 fedora gdm(pam_unix)[3786]: session opened for user tbl by (uid=0) Aug 28 10:33:21 fedora kernel: audit(1093714401.349:0): avc: denied { read } for pid=3786 exe=/usr/bin/gdm-binary name=fstab dev=hda2 ino=4654141 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:tmp_t tclass=file Aug 28 10:33:21 fedora kernel: audit(1093714401.350:0): avc: denied { getattr } for pid=3786 exe=/usr/bin/gdm-binary path=/etc/fstab dev=hda2 ino=4654141 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:tmp_t tclass=file I believe I'm running a 'stock' Rawhide system. tom From selinux at comcast.net Sat Aug 28 21:15:24 2004 From: selinux at comcast.net (Tom London) Date: Sat, 28 Aug 2004 14:15:24 -0700 Subject: fstab-sync - relabeling /etc/fstab? Message-ID: <4130F5EC.9070603@comcast.net> With latest from Rawhide, running strict/permissive: Each boot, something is relabeling /etc/fstab from etc_t to tmp_t. I suspect fstab-sync, which seems to be run just after hald is started (from hald? /etc/hal/device.d/50-fstab-sync.hal ?) Of course, if you forget to restore it before rebooting in strict/enforcing mode, the boot fails trying to read /etc/fstab, and puts you into 'disk doctor' mode. This doesn't happen if you boot in strict/enforcing mode, since the policy prevents this from running and doing damage. I noticed a bugzilla against hal: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131187 Anyone else seeing this? Does this happen in targeted policy? tom From selinux at comcast.net Sun Aug 29 00:49:19 2004 From: selinux at comcast.net (Tom London) Date: Sat, 28 Aug 2004 17:49:19 -0700 Subject: dbus-daemon-1 running as user_u:user_r:user_t.... that right? Message-ID: <4131280F.3050103@comcast.net> Running Rawhide, strict/permissive, 'ps aZx' yields (some lines snipped): system_u:system_r:saslauthd_t 3438 ? S 0:00 /usr/sbin/saslauthd system_u:system_r:dbusd_t 3455 ? Ss 0:00 dbus-daemon-1 syste system_u:system_r:hald_t 3468 ? Ss 0:00 hald system_u:system_r:mdadm_t 3488 ? Ss 0:00 mdadm --monitor system_u:system_r:xdm_t 3675 ? Ss 0:00 /usr/bin/gdm-binary system_u:system_r:xdm_t 3939 ? S 0:00 /usr/bin/gdm-binary system_u:system_r:xdm_xserver_t 3952 ? S 40:14 /usr/X11R6/bin/X :0 user_u:user_r:user_t 4026 ? Ss 0:01 /usr/bin/gnome-sessio user_u:user_r:user_ssh_agent_t 4076 ? Ss 0:00 /usr/bin/ssh-agent /u user_u:user_r:user_t 4080 ? Ss 0:00 dbus-daemon-1 --fork user_u:user_r:user_t 4084 ? S 0:01 /usr/libexec/gconfd-2 As shown, gnome-session, ssh-agent, dbus-daemon-1 (the second one), and gconfd-2 are running in user_u:user_r:user_t. That right? thanks, tom From walters at redhat.com Sun Aug 29 01:17:16 2004 From: walters at redhat.com (Colin Walters) Date: Sat, 28 Aug 2004 21:17:16 -0400 Subject: dbus-daemon-1 running as user_u:user_r:user_t.... that right? In-Reply-To: <4131280F.3050103@comcast.net> References: <4131280F.3050103@comcast.net> Message-ID: <1093742236.11028.10.camel@nexus.verbum.private> On Sat, 2004-08-28 at 17:49 -0700, Tom London wrote: > Running Rawhide, strict/permissive, 'ps aZx' yields (some lines snipped): > > system_u:system_r:saslauthd_t 3438 ? S 0:00 > /usr/sbin/saslauthd > system_u:system_r:dbusd_t 3455 ? Ss 0:00 dbus-daemon-1 > syste > system_u:system_r:hald_t 3468 ? Ss 0:00 hald > system_u:system_r:mdadm_t 3488 ? Ss 0:00 mdadm --monitor > system_u:system_r:xdm_t 3675 ? Ss 0:00 > /usr/bin/gdm-binary > system_u:system_r:xdm_t 3939 ? S 0:00 > /usr/bin/gdm-binary > system_u:system_r:xdm_xserver_t 3952 ? S 40:14 > /usr/X11R6/bin/X :0 > user_u:user_r:user_t 4026 ? Ss 0:01 > /usr/bin/gnome-sessio > user_u:user_r:user_ssh_agent_t 4076 ? Ss 0:00 > /usr/bin/ssh-agent /u > user_u:user_r:user_t 4080 ? Ss 0:00 dbus-daemon-1 > --fork > user_u:user_r:user_t 4084 ? S 0:01 > /usr/libexec/gconfd-2 > > As shown, gnome-session, ssh-agent, dbus-daemon-1 (the second one), > and gconfd-2 are running in user_u:user_r:user_t. That right? That's right; the second dbus-dameon-1 is the per-user session bus, as opposed to the system bus. -------------- 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 russell at coker.com.au Sun Aug 29 07:05:33 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 29 Aug 2004 17:05:33 +1000 Subject: fstab-sync - relabeling /etc/fstab? In-Reply-To: <4130F5EC.9070603@comcast.net> References: <4130F5EC.9070603@comcast.net> Message-ID: <200408291705.33545.russell@coker.com.au> On Sun, 29 Aug 2004 07:15, Tom London wrote: > Each boot, something is relabeling /etc/fstab from etc_t to tmp_t. Probably it is creating the file in /tmp and then moving it to /etc. Even without SE Linux this is a bug. /tmp may not be on the root file system, in which case moving the file from /tmp to /etc is not atomic and may result in file truncation on an unexpected power failure or system crash. -- 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 Sun Aug 29 07:37:17 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 29 Aug 2004 17:37:17 +1000 Subject: Progress! .532 boots! -- but dbus/hotplug/udev problems remain? In-Reply-To: <4130CF1B.3090909@comcast.net> References: <4130CF1B.3090909@comcast.net> Message-ID: <200408291737.17497.russell@coker.com.au> On Sun, 29 Aug 2004 04:29, Tom London wrote: > Newest Rawhide updates (including udev-030-10, mkinitrd-4.1.8-1, > kernel-2.6.8-1.532, and selinux-policy-strict-1.17.5-2) > now boots in strict/enforcing. I've attached a diff against the CVS policy as well as the .te and .fc files for udev changes which fix this and address some other issues as well. Please try it out and let me know how it goes. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -------------- next part -------------- A non-text attachment was scrubbed... Name: udev.diff Type: text/x-diff Size: 3514 bytes Desc: not available URL: -------------- next part -------------- #DESC udev - Linux configurable dynamic device naming support # # Author: Dan Walsh dwalsh at redhat.com # ################################# # # Rules for the udev_t domain. # # udev_exec_t is the type of the udev executable. # daemon_domain(udev, `, privmodule, privmem, fs_domain, privfd, dbus_client_domain') general_domain_access(udev_t) etc_domain(udev) typealias udev_etc_t alias etc_udev_t; type udev_helper_exec_t, file_type, sysadmfile, exec_type; can_exec(udev_t, udev_helper_exec_t) # # Rules used for udev # type udev_tbl_t, file_type, sysadmfile; file_type_auto_trans(udev_t, device_t, udev_tbl_t, file) allow udev_t self:capability { chown dac_override dac_read_search fowner fsetid sys_admin mknod }; allow udev_t self:file { getattr read }; allow udev_t self:unix_stream_socket {connectto create_stream_socket_perms}; allow udev_t self:unix_dgram_socket create_socket_perms; allow udev_t self:fifo_file rw_file_perms; allow udev_t device_t:blk_file create_file_perms; allow udev_t device_t:chr_file create_file_perms; allow udev_t device_t:sock_file create_file_perms; allow udev_t device_t:lnk_file create_lnk_perms; allow udev_t etc_t:file { getattr read }; allow udev_t { bin_t sbin_t }:dir r_dir_perms; allow udev_t { sbin_t bin_t }:lnk_file read; allow udev_t bin_t:lnk_file read; can_exec(udev_t, { shell_exec_t bin_t sbin_t etc_t } ) can_exec(udev_t, udev_exec_t) r_dir_file(udev_t, sysfs_t) allow udev_t sysadm_tty_device_t:chr_file { read write }; allow udev_t { device_t device_type }:{chr_file blk_file} { relabelfrom relabelto create_file_perms }; # to read the file_contexts file allow udev_t { selinux_config_t default_context_t }:dir search; allow udev_t default_context_t:file { getattr read }; allow udev_t policy_config_t:dir { search }; allow udev_t proc_t:file { read }; # Get security policy decisions. can_getsecurity(udev_t) # set file system create context can_setfscreate(udev_t) allow udev_t kernel_t:fd { use }; allow udev_t kernel_t:unix_dgram_socket { sendto ioctl read write }; allow udev_t initrc_var_run_t:file r_file_perms; dontaudit udev_t initrc_var_run_t:file write; domain_auto_trans(initrc_t, udev_exec_t, udev_t) domain_auto_trans(kernel_t, udev_exec_t, udev_t) domain_auto_trans(udev_t, restorecon_exec_t, restorecon_t) ifdef(`hide_broken_symptoms', ` dontaudit restorecon_t udev_t:unix_dgram_socket { read write }; ') allow udev_t devpts_t:dir { search }; allow udev_t etc_runtime_t:file { getattr read }; allow udev_t etc_t:file { ioctl }; allow udev_t proc_t:file { getattr }; ifdef(`xdm.te', ` allow udev_t xdm_var_run_t:file { getattr read }; ') ifdef(`hotplug.te', ` r_dir_file(udev_t, hotplug_etc_t) ') allow udev_t var_log_t:dir { search }; ifdef(`consoletype.te', ` can_exec(udev_t, consoletype_exec_t) ') domain_auto_trans(udev_t, ifconfig_exec_t, ifconfig_t) ifdef(`hide_broken_symptoms', ` dontaudit ifconfig_t udev_t:unix_dgram_socket { read write }; ') dontaudit udev_t file_t:dir search; ifdef(`dhcpc.te', ` domain_auto_trans(udev_t, dhcpc_exec_t, dhcpc_t) ') -------------- next part -------------- # udev /sbin/udevsend -- system_u:object_r:udev_exec_t /sbin/udev -- system_u:object_r:udev_exec_t /sbin/udevd -- system_u:object_r:udev_exec_t /usr/bin/udevinfo -- system_u:object_r:udev_exec_t /etc/dev\.d/.+ -- system_u:object_r:udev_helper_exec_t /etc/udev/scripts/.+ -- system_u:object_r:udev_helper_exec_t /etc/hotplug.d/default/udev.* -- system_u:object_r:udev_helper_exec_t /dev/udev\.tbl -- system_u:object_r:udev_tbl_t /dev/\.udev\.tdb -- system_u:object_r:udev_tbl_t From russell at coker.com.au Sun Aug 29 07:47:47 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 29 Aug 2004 17:47:47 +1000 Subject: rpc.mountd failure... In-Reply-To: <412A0E73.5020001@comcast.net> References: <412A0E73.5020001@comcast.net> Message-ID: <200408291747.47554.russell@coker.com.au> On Tue, 24 Aug 2004 01:34, Tom London wrote: > Noticed the following, running .524 kernel and latest policy from Rawhide. > > > Aug 23 08:20:18 fedora nfs: Starting NFS services: succeeded > > Aug 23 08:20:18 fedora nfs: rpc.rquotad startup succeeded > > Aug 23 08:20:18 fedora nfs: rpc.nfsd startup succeeded > > Aug 23 08:20:18 fedora kernel: audit(1093274418.647:0): avc: denied > > { name_bind } for pid=2564 exe=/usr/sbin/rpc.mountd > > scontext=system_u:system_r:nfsd_t > > tcontext=system_u:object_r:ipp_port_t tclass=udp_socket > > Aug 23 08:20:18 fedora portmap[2565]: connect from 127.0.0.1 to > > set(mountd): request from unprivileged port > > Aug 23 08:20:18 fedora rpc.mountd: unable to register (mountd, 3, udp). > > Aug 23 08:20:18 fedora nfs: rpc.mountd startup failed > > Aug 23 08:20:18 fedora rpcidmapd: rpc.idmapd -SIGHUP succeeded I think that this is a lack in the kernel code. We have to prevent such access because otherwise if the NFS server is started or re-started when cups is not running then cups will be prevented from working at all. Also in some situations you might have a running NFS server with no cups installed and want to install it without rebooting. When the kernel code selects an arbitary port to bind to it should only select from the set of ports that the application in question is permitted to bind to. This would also permit us to restrict an application to two ports (I believe that restricting to only one port would not work well for a restart) via the SE Linux policy and then use firewall rules controlling access to those two ports (currently trying to control access to an RPC service via iptables is really difficult). -- 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 lkcl at lkcl.net Sun Aug 29 09:54:58 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 29 Aug 2004 10:54:58 +0100 Subject: rpc.mountd failure... In-Reply-To: <200408291747.47554.russell@coker.com.au> References: <412A0E73.5020001@comcast.net> <200408291747.47554.russell@coker.com.au> Message-ID: <20040829095458.GF7610@lkcl.net> On Sun, Aug 29, 2004 at 05:47:47PM +1000, Russell Coker wrote: > On Tue, 24 Aug 2004 01:34, Tom London wrote: > When the kernel code selects an arbitary port to bind to it should only select > from the set of ports that the application in question is permitted to bind > to. oo. that'd be _great_ because i could restrict skype to a range of ports in the firewall rules. and giftd (file sharing server). From lkcl at lkcl.net Sun Aug 29 10:06:42 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 29 Aug 2004 11:06:42 +0100 Subject: Progress! .532 boots! -- but dbus/hotplug/udev problems remain? In-Reply-To: <200408291737.17497.russell@coker.com.au> References: <4130CF1B.3090909@comcast.net> <200408291737.17497.russell@coker.com.au> Message-ID: <20040829100641.GG7610@lkcl.net> btw i didn't see an acknowledgement from the person who sent the last udev patch (dan was it you?) the use of the "mode" argument it is clear has not been used, to call i think it was matchpathcon. instead, because i had three near-identical code portions all of which had different S_IFXXX thingies, dan-i-think-it-was moved the near-identical code into a function with a "mode" argument... ... and forgot to use the "mode" argument such that matchpathcon is called with S_IFDIR. given that i haven't seen an acknowledgement of this issue either in my inbox or on the mailing lists (which i am checking manually) i thought it best to hassle people until i know it's been spotted. this is IMPORTANT because it will impact the contexts on inodes and stuff created in /dev: the "optimising" argument "mode" passed to matchpathcon and setfscreatecon, if wrong, results in relevant (and correct!) file_context entries being skipped! l. On Sun, Aug 29, 2004 at 05:37:17PM +1000, Russell Coker wrote: > On Sun, 29 Aug 2004 04:29, Tom London wrote: > > Newest Rawhide updates (including udev-030-10, mkinitrd-4.1.8-1, > > kernel-2.6.8-1.532, and selinux-policy-strict-1.17.5-2) > > now boots in strict/enforcing. > > I've attached a diff against the CVS policy as well as the .te and .fc files > for udev changes which fix this and address some other issues as well. From parklee_sel at yahoo.com Sun Aug 29 10:33:02 2004 From: parklee_sel at yahoo.com (Park Lee) Date: Sun, 29 Aug 2004 03:33:02 -0700 (PDT) Subject: Disable SELinux question Message-ID: <20040829103302.65147.qmail@web51506.mail.yahoo.com> Hi, In Fedora Core 2, if we add selinux=0 to the kernel boot line, SELinux will be disabled completely. By adding SELINUX=disabled into /etc/sysconfig/selinux. We can "disable" the SELinux kernel. Surely disabled in here doesn't fully disable the SELinux kernel but simply boots into permissive mode and skips loading the policy. Then, If we do this(i.e. adding SELINUX=disabled into /etc/sysconfig/selinux), Will new files be created without security context information? Need we relabel the entire filesystem again? Thanks, -- Best Regards, Park Lee --------------------------------- Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From walters at redhat.com Sun Aug 29 13:04:21 2004 From: walters at redhat.com (Colin Walters) Date: Sun, 29 Aug 2004 09:04:21 -0400 Subject: Disable SELinux question In-Reply-To: <20040829103302.65147.qmail@web51506.mail.yahoo.com> References: <20040829103302.65147.qmail@web51506.mail.yahoo.com> Message-ID: <1093784661.12727.4.camel@nexus.verbum.private> On Sun, 2004-08-29 at 03:33 -0700, Park Lee wrote: > Then, If we do this(i.e. adding SELINUX=disabled > into /etc/sysconfig/selinux), Will new files be created without > security context information? Need we relabel the entire filesystem > again? Yes. -------------- 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 selinux at comcast.net Sun Aug 29 19:32:46 2004 From: selinux at comcast.net (Tom London) Date: Sun, 29 Aug 2004 12:32:46 -0700 Subject: Progress! .532 boots! -- but dbus/hotplug/udev problems remain? In-Reply-To: <200408291737.17497.russell@coker.com.au> References: <4130CF1B.3090909@comcast.net> <200408291737.17497.russell@coker.com.au> Message-ID: <41322F5E.90409@comcast.net> Russell, Thanks, but it didn't quite work. The following change to dbusd.te seems to make graphical login work under strict/enforcing. Please correct/improve... :) tom --- /root/src.package/policy/domains/program/dbusd.te 2004-08-29 11:38:27.000000000 -0700 +++ dbusd.te 2004-08-29 12:19:25.000000000 -0700 @@ -32,3 +32,7 @@ # SE-DBus specific permissions allow { dbus_client_domain userdomain } { dbusd_t self }:dbus { send_msg }; + +allow user_t etc_dbusd_t:dir { search }; +allow user_t etc_dbusd_t:file { getattr read }; +allow user_t user_t:netlink_selinux_socket { bind create }; Russell Coker wrote: >On Sun, 29 Aug 2004 04:29, Tom London wrote: > > >>Newest Rawhide updates (including udev-030-10, mkinitrd-4.1.8-1, >>kernel-2.6.8-1.532, and selinux-policy-strict-1.17.5-2) >>now boots in strict/enforcing. >> >> > >I've attached a diff against the CVS policy as well as the .te and .fc files >for udev changes which fix this and address some other issues as well. > >Please try it out and let me know how it goes. > > > From selinux at comcast.net Sun Aug 29 19:53:05 2004 From: selinux at comcast.net (Tom London) Date: Sun, 29 Aug 2004 12:53:05 -0700 Subject: Progress! .532 boots! -- but dbus/hotplug/udev problems remain? In-Reply-To: <200408291737.17497.russell@coker.com.au> References: <4130CF1B.3090909@comcast.net> <200408291737.17497.russell@coker.com.au> Message-ID: <41323421.7050904@comcast.net> Russell, The following changes to udev.te seem needed.... (If udev shouldn't be reading file_contexts, then dontaudit?) Please correct/improve, tom --- /tmp/patches/udev.te 2004-08-29 11:35:48.000000000 -0700 +++ udev.te 2004-08-29 12:40:58.000000000 -0700 @@ -44,7 +44,9 @@ # to read the file_contexts file allow udev_t { selinux_config_t default_context_t }:dir search; -allow udev_t default_context_t:file { getattr read }; +allow udev_t { selinux_config_t default_context_t }:file { getattr read }; +allow udev_t file_context_t:dir { search }; +allow udev_t file_context_t:file { getattr read }; allow udev_t policy_config_t:dir { search }; allow udev_t proc_t:file { read }; Russell Coker wrote: >On Sun, 29 Aug 2004 04:29, Tom London wrote: > > >>Newest Rawhide updates (including udev-030-10, mkinitrd-4.1.8-1, >>kernel-2.6.8-1.532, and selinux-policy-strict-1.17.5-2) >>now boots in strict/enforcing. >> >> > >I've attached a diff against the CVS policy as well as the .te and .fc files >for udev changes which fix this and address some other issues as well. > >Please try it out and let me know how it goes. > From selinux at comcast.net Sun Aug 29 20:41:15 2004 From: selinux at comcast.net (Tom London) Date: Sun, 29 Aug 2004 13:41:15 -0700 Subject: hald/hal-hotplug-map Message-ID: <41323F6B.4020701@comcast.net> hald seems to need to execute /usr/libexec/hal-hotplug-map: Aug 29 12:45:46 fedora kernel: audit(1093808744.270:0): avc: denied { execute } for pid=3436 exe=/usr/sbin/hald name=hal-hotplug-map dev=hda2 ino=4123436 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:bin_t tclass=file Aug 29 12:45:46 fedora kernel: audit(1093808744.284:0): avc: denied { execute } for pid=3436 exe=/usr/sbin/hald name=hal-hotplug-map dev=hda2 ino=4123436 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:bin_t tclass=file Does it make sense to label /usr/libexec/hal* as hald_exec_t and add 'canexec(hald_t, hald_exec_t)' to hald.te ? Also, seems that hald and updfstab need to do their dbus thing, and hald wants to access printer_device_t. Suggested patches to hald.te and hald.fc --- hald.te 2004-08-27 14:37:17.000000000 -0700 +++ /etc/selinux/strict/src.old/policy/domains/program/hald.te 2004-08-28 13:40:57.000000000 -0700 @@ -37,7 +37,12 @@ ifdef(`udev.te', ` domain_auto_trans(hald_t, udev_exec_t, udev_t) allow udev_t hald_t:unix_dgram_socket sendto; +allow hald_t updfstab_t:dbus { send_msg }; +allow updfstab_t hald_t:dbus { send_msg }; ') allow hald_t usbdevfs_t:dir search; allow hald_t usbdevfs_t:file { getattr read }; + +allow hald_t printer_device_t:chr_file { read write }; +can_exec(hald_t, hald_exec_t) --- /etc/selinux/strict/src.old/policy/domains/program/../../file_contexts/program/hald.fc 2004-08-27 14:37:17.000000000 -0700 +++ hald.fc 2004-08-29 13:36:44.147534409 -0700 @@ -1,2 +1,3 @@ # hald - hardware informationd daemon /usr/sbin/hald -- system_u:object_r:hald_exec_t +/usr/libexec/hal-.* -- system_u:object_r:hald_exec_t Please correct/improve, tom tom From selinux at comcast.net Sun Aug 29 20:48:15 2004 From: selinux at comcast.net (Tom London) Date: Sun, 29 Aug 2004 13:48:15 -0700 Subject: more on udev.te Message-ID: <4132410F.302@comcast.net> Russell, Get many avc's like: Aug 29 12:45:06 fedora kernel: audit(1093808656.624:0): avc: denied { search } for pid=1354 exe=/bin/bash name=console dev=hda2 ino=4456494 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:pam_var_console_t tclass=dir Aug 29 12:45:06 fedora kernel: audit(1093808656.757:0): avc: denied { search } for pid=1357 exe=/bin/bash name=console dev=hda2 ino=4456494 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:pam_var_console_t tclass=dir indicating that udev.te needs either allow udev_t pam_var_console_t:dir { search }; or dontaudit udev_t pam_var_console_t:dir { search }; Either of those correct? tom From walters at redhat.com Sun Aug 29 20:59:44 2004 From: walters at redhat.com (Colin Walters) Date: Sun, 29 Aug 2004 16:59:44 -0400 Subject: Progress! .532 boots! -- but dbus/hotplug/udev problems remain? In-Reply-To: <41322F5E.90409@comcast.net> References: <4130CF1B.3090909@comcast.net> <200408291737.17497.russell@coker.com.au> <41322F5E.90409@comcast.net> Message-ID: <1093813184.12727.25.camel@nexus.verbum.private> On Sun, 2004-08-29 at 12:32 -0700, Tom London wrote: > Russell, > > Thanks, but it didn't quite work. The following change to dbusd.te seems > to make graphical login work under strict/enforcing. I think we need to rework the dbusd.te to break it into dbusd_system_t and dbusd_{user,staff}_t. -------------- 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 selinux at comcast.net Sun Aug 29 21:10:52 2004 From: selinux at comcast.net (Tom London) Date: Sun, 29 Aug 2004 14:10:52 -0700 Subject: hald/hal-hotplug-map In-Reply-To: <41323F6B.4020701@comcast.net> References: <41323F6B.4020701@comcast.net> Message-ID: <4132465C.6080806@comcast.net> Oops.... hald.fc should be # hald - hardware informationd daemon /usr/sbin/hald -- system_u:object_r:hald_exec_t /usr/libexec/hal-hotplug-map -- system_u:object_r:hald_exec_t Otherwise hal.dev and hal.hotplug get erroneously relabeled. Sorry, tom Tom London wrote: > --- > /etc/selinux/strict/src.old/policy/domains/program/../../file_contexts/program/hald.fc > 2004-08-27 14:37:17.000000000 -0700 > +++ hald.fc 2004-08-29 13:36:44.147534409 -0700 > @@ -1,2 +1,3 @@ > # hald - hardware informationd daemon > /usr/sbin/hald -- system_u:object_r:hald_exec_t > +/usr/libexec/hal-.* -- system_u:object_r:hald_exec_t > > > Please correct/improve, > tom > tom > From selinux at comcast.net Mon Aug 30 15:21:27 2004 From: selinux at comcast.net (Tom London) Date: Mon, 30 Aug 2004 08:21:27 -0700 Subject: xdm.te - patch to allow 'graphical shutdown/reboot' Message-ID: <413345F7.20100@comcast.net> Clicking on 'shutdown' on the login screen doesn't 'work'. /sbin/shutdown (running in xdm_t) wants to execute init (init_exec_t). Here's a patch that fixes.... Not sure about the 'allow xdm_t devpts_t:dir { search };'. dontaudit? Please correct/improve/... tom --- /root/src.package/policy/domains/program/xdm.te 2004-08-29 11:38:27.000000000 -0700 +++ ./xdm.te 2004-08-30 07:13:32.000000000 -0700 @@ -331,3 +331,7 @@ allow xdm_t crack_db_t:file r_file_perms; ') r_dir_file(xdm_t, selinux_config_t) + +# let xdm do shutdown +allow xdm_t devpts_t:dir { search }; +can_exec(xdm_t, init_exec_t) From lkcl at lkcl.net Mon Aug 30 17:07:11 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 30 Aug 2004 18:07:11 +0100 Subject: bug in presently-developed selinux patch to udev: no acknowledgement received Message-ID: <20040830170711.GB8382@lkcl.net> i noticed a bug in the last udev-selinux patch that went past [these?] lists last week. i sent a request for acknowldgement, and unfortunately i am very sorry to say that i have not received an acknowledgement, and so unfortunately i will continue to request an acknowledgement from the people doing the redhat-based development until i receive one. if it wasn't important - namely that the bug in the patch will result in incorrect policy file development for udev.te - i wouldn't bother. the bug is that the patch merged three near-identical sections of code that use matchpathcon(..., mode) into a function, where mode was S_IFDIR, SF_IFLNK and S_IFsomething ... ... and the person who reworked the patch forgot to pass the mode argument down to matchpathcon. result: on all three instances of calling matchpathcon, the file_contexts for DIRECTORIES will be looked up. it was either dan or colin, and i can't remember who. anyone who is doing udev selinux development who is NOT using my original patch, non-optimised as it is, please be advised. l. -- -- Truth, honesty and respect are rare commodities that all spring from the same well: Love. If you love yourself and everyone and everything around you, funnily and coincidentally enough, life gets a lot better. -- lkcl.net
lkcl at lkcl.net
From concert at europe.com Mon Aug 30 17:24:52 2004 From: concert at europe.com (t l) Date: Mon, 30 Aug 2004 09:24:52 -0800 Subject: ssh.te - more needed? Message-ID: <20040830172452.7C68C1F50B1@ws1-2.us4.outblaze.com> After augmenting ssh.te with can_exec(sshd_t, sshd_exec_t) as suggested by Stephen S., inbound ssh to strict/enforcing system still fails. Here are avc's (running permissive): Aug 30 09:49:44 fedora kernel: audit(1093884584.213:0): avc: denied { ioctl } for pid=4998 exe=/bin/su path=/dev/pts/4 dev=devpts ino=6 scontext=user_u:user_r:user_su_t tcontext=system_u:object_r:sshd_devpts_t tclass=chr_file Aug 30 09:49:46 fedora kernel: audit(1093884586.516:0): avc: denied { getattr } for pid=4998 exe=/bin/su name=4 dev=devpts ino=6 scontext=user_u:user_r:user_su_t tcontext=system_u:object_r:sshd_devpts_t tclass=chr_file Aug 30 09:49:46 fedora kernel: audit(1093884586.542:0): avc: denied { read write } for pid=5013 exe=/bin/hostname name=4 dev=devpts ino=6 scontext=root:sysadm_r:hostname_t tcontext=root:object_r:sshd_devpts_t tclass=chr_file audit2allow says: allow hostname_t sshd_devpts_t:chr_file { read write }; allow user_su_t sshd_devpts_t:chr_file { getattr ioctl }; tom -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From dwalsh at redhat.com Mon Aug 30 18:17:30 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 30 Aug 2004 14:17:30 -0400 Subject: Progress! .532 boots! -- but dbus/hotplug/udev problems remain? In-Reply-To: <20040829100641.GG7610@lkcl.net> References: <4130CF1B.3090909@comcast.net> <200408291737.17497.russell@coker.com.au> <20040829100641.GG7610@lkcl.net> Message-ID: <41336F3A.9030002@redhat.com> Luke Kenneth Casson Leighton wrote: >btw i didn't see an acknowledgement from the person who sent the >last udev patch (dan was it you?) > >the use of the "mode" argument it is clear has not been used, >to call i think it was matchpathcon. > >instead, because i had three near-identical code portions all >of which had different S_IFXXX thingies, dan-i-think-it-was >moved the near-identical code into a function with a "mode" >argument... > >... and forgot to use the "mode" argument such that matchpathcon >is called with S_IFDIR. > >given that i haven't seen an acknowledgement of this issue >either in my inbox or on the mailing lists (which i am checking >manually) i thought it best to hassle people until i know it's >been spotted. > >this is IMPORTANT because it will impact the contexts on >inodes and stuff created in /dev: the "optimising" argument >"mode" passed to matchpathcon and setfscreatecon, if wrong, >results in relevant (and correct!) file_context entries being >skipped! > >l. > >On Sun, Aug 29, 2004 at 05:37:17PM +1000, Russell Coker wrote: > > > >>On Sun, 29 Aug 2004 04:29, Tom London wrote: >> >> >>>Newest Rawhide updates (including udev-030-10, mkinitrd-4.1.8-1, >>>kernel-2.6.8-1.532, and selinux-policy-strict-1.17.5-2) >>>now boots in strict/enforcing. >>> >>> >>I've attached a diff against the CVS policy as well as the .te and .fc files >>for udev changes which fix this and address some other issues as well. >> >> >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Yes it was me and I modified out udev rpm, but I guess I never responded. Sorry about that. Luke thanks for the fix. Dan -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: udev-030-selinux.patch URL: From dwalsh at redhat.com Mon Aug 30 18:20:32 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 30 Aug 2004 14:20:32 -0400 Subject: Progress! .532 boots! -- but dbus/hotplug/udev problems remain? In-Reply-To: <41323421.7050904@comcast.net> References: <4130CF1B.3090909@comcast.net> <200408291737.17497.russell@coker.com.au> <41323421.7050904@comcast.net> Message-ID: <41336FF0.2060701@redhat.com> Tom London wrote: > Russell, > > The following changes to udev.te seem needed.... > (If udev shouldn't be reading file_contexts, then dontaudit?) > udev needs to read file_contexts. It is doing a matchpathcon in order to setup the devices with the correct context. > Please correct/improve, > tom > > --- /tmp/patches/udev.te 2004-08-29 11:35:48.000000000 -0700 > +++ udev.te 2004-08-29 12:40:58.000000000 -0700 > @@ -44,7 +44,9 @@ > > # to read the file_contexts file > allow udev_t { selinux_config_t default_context_t }:dir search; > -allow udev_t default_context_t:file { getattr read }; > +allow udev_t { selinux_config_t default_context_t }:file { getattr > read }; > +allow udev_t file_context_t:dir { search }; > +allow udev_t file_context_t:file { getattr read }; > > allow udev_t policy_config_t:dir { search }; > allow udev_t proc_t:file { read }; > > > Russell Coker wrote: > >> On Sun, 29 Aug 2004 04:29, Tom London wrote: >> >> >>> Newest Rawhide updates (including udev-030-10, mkinitrd-4.1.8-1, >>> kernel-2.6.8-1.532, and selinux-policy-strict-1.17.5-2) >>> now boots in strict/enforcing. >>> >> >> >> I've attached a diff against the CVS policy as well as the .te and >> .fc files for udev changes which fix this and address some other >> issues as well. >> >> Please try it out and let me know how it goes. >> > -- > 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 Aug 30 18:22:07 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 30 Aug 2004 14:22:07 -0400 Subject: hald/hal-hotplug-map In-Reply-To: <41323F6B.4020701@comcast.net> References: <41323F6B.4020701@comcast.net> Message-ID: <4133704F.9050605@redhat.com> Tom London wrote: > hald seems to need to execute /usr/libexec/hal-hotplug-map: > > Aug 29 12:45:46 fedora kernel: audit(1093808744.270:0): avc: denied > { execute > } for pid=3436 exe=/usr/sbin/hald name=hal-hotplug-map dev=hda2 > ino=4123436 scontext=system_u:system_r:hald_t > tcontext=system_u:object_r:bin_t tclass=file > Aug 29 12:45:46 fedora kernel: audit(1093808744.284:0): avc: denied > { execute > } for pid=3436 exe=/usr/sbin/hald name=hal-hotplug-map dev=hda2 > ino=4123436 scontext=system_u:system_r:hald_t > tcontext=system_u:object_r:bin_t tclass=file > > Does it make sense to label /usr/libexec/hal* as hald_exec_t and add > 'canexec(hald_t, hald_exec_t)' to hald.te ? > Or just add can_exec(hald_t, bin_t) > Also, seems that hald and updfstab need to do their dbus thing, > and hald wants to access printer_device_t. > > Suggested patches to hald.te and hald.fc > > --- hald.te 2004-08-27 14:37:17.000000000 -0700 > +++ /etc/selinux/strict/src.old/policy/domains/program/hald.te > 2004-08-28 13:40:57.000000000 -0700 > @@ -37,7 +37,12 @@ > ifdef(`udev.te', ` > domain_auto_trans(hald_t, udev_exec_t, udev_t) > allow udev_t hald_t:unix_dgram_socket sendto; > +allow hald_t updfstab_t:dbus { send_msg }; > +allow updfstab_t hald_t:dbus { send_msg }; > ') > > allow hald_t usbdevfs_t:dir search; > allow hald_t usbdevfs_t:file { getattr read }; > + > +allow hald_t printer_device_t:chr_file { read write }; > +can_exec(hald_t, hald_exec_t) > --- > /etc/selinux/strict/src.old/policy/domains/program/../../file_contexts/program/hald.fc > 2004-08-27 14:37:17.000000000 -0700 > +++ hald.fc 2004-08-29 13:36:44.147534409 -0700 > @@ -1,2 +1,3 @@ > # hald - hardware informationd daemon > /usr/sbin/hald -- system_u:object_r:hald_exec_t > +/usr/libexec/hal-.* -- system_u:object_r:hald_exec_t > > > Please correct/improve, > tom > tom > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From lkcl at lkcl.net Mon Aug 30 18:52:44 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 30 Aug 2004 19:52:44 +0100 Subject: Cleaned up udev-selinux patch In-Reply-To: <412F37D2.7070105@redhat.com> References: <403C8AE4.10403@redhat.com> <20040228005300.GA13860@kroah.com> <412DFE7B.6060409@redhat.com> <20040826155716.GA30726@kroah.com> <412E20AF.7000102@redhat.com> <20040826175139.GA12225@kroah.com> <412E34EB.1030909@redhat.com> <20040826225928.GD6058@lkcl.net> <20040826225640.GA13818@kroah.com> <412F37D2.7070105@redhat.com> Message-ID: <20040830185244.GC25229@lkcl.net> found the original message. not sure if post ever made it to lists. bug highlighted with ^^^^ please acknowledge receipt of message, confirming awareness of bug in patch. thanks. l. On Fri, Aug 27, 2004 at 09:32:02AM -0400, Daniel J Walsh wrote: > Further cleanup and using all static inlines versus defines. Renamed a > couple of functions to make them clearer. > > Dan > --- /dev/null 2004-06-21 15:29:38.000000000 -0400 > +++ udev-030/selinux.h 2004-08-27 09:26:40.160862612 -0400 > +static inline void selinux_setfscreatecon(char *file, unsigned int mode) { > + int retval = 0; > + security_context_t scontext=NULL; > + > + if (is_selinux_running()) { > + if (matchpathcon(file, S_IFDIR, &scontext) < 0) { ^^^^^^^ this should be matchpatchon(file, mode, &scontext) > + dbg("matchpathcon(%s) failed\n", file); > + } else { > + retval=setfscreatecon(scontext); > + if (retval < 0) > + dbg("setfiles %s failed with error '%s'", > + file, strerror(errno)); > + freecon(scontext); > + } From nkukard at lbsd.net Mon Aug 30 17:37:44 2004 From: nkukard at lbsd.net (Nigel Kukard) Date: Mon, 30 Aug 2004 19:37:44 +0200 Subject: [idea] udev + selinux Message-ID: <20040830173744.GD10151@lbsd.net> Just an idea, but why not have udev set the context on its root path? I have a simplistic patch for this if its a good idea. Regards Nigel Kukard -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sds at epoch.ncsc.mil Mon Aug 30 19:12:12 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 30 Aug 2004 15:12:12 -0400 Subject: ssh.te - more needed? In-Reply-To: <20040830172452.7C68C1F50B1@ws1-2.us4.outblaze.com> References: <20040830172452.7C68C1F50B1@ws1-2.us4.outblaze.com> Message-ID: <1093893132.6782.4.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2004-08-30 at 13:24, t l wrote: > After augmenting ssh.te with > can_exec(sshd_t, sshd_exec_t) > as suggested by Stephen S., inbound > ssh to strict/enforcing system still fails. > > Here are avc's (running permissive): > > Aug 30 09:49:44 fedora kernel: audit(1093884584.213:0): avc: denied { ioctl } for pid=4998 exe=/bin/su path=/dev/pts/4 dev=devpts ino=6 scontext=user_u:user_r:user_su_t tcontext=system_u:object_r:sshd_devpts_t tclass=chr_file > Aug 30 09:49:46 fedora kernel: audit(1093884586.516:0): avc: denied { getattr } for pid=4998 exe=/bin/su name=4 dev=devpts ino=6 scontext=user_u:user_r:user_su_t tcontext=system_u:object_r:sshd_devpts_t tclass=chr_file > Aug 30 09:49:46 fedora kernel: audit(1093884586.542:0): avc: denied { read write } for pid=5013 exe=/bin/hostname name=4 dev=devpts ino=6 scontext=root:sysadm_r:hostname_t tcontext=root:object_r:sshd_devpts_t tclass=chr_file > > audit2allow says: > allow hostname_t sshd_devpts_t:chr_file { read write }; > allow user_su_t sshd_devpts_t:chr_file { getattr ioctl }; That isn't a policy issue; it is a bug in the SELinux patch for openssh 3.9p1, already bugzilla'd. -- Stephen Smalley National Security Agency From lkcl at lkcl.net Mon Aug 30 20:31:40 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 30 Aug 2004 21:31:40 +0100 Subject: [idea] udev + selinux In-Reply-To: <20040830173744.GD10151@lbsd.net> References: <20040830173744.GD10151@lbsd.net> Message-ID: <20040830203140.GB31497@lkcl.net> On Mon, Aug 30, 2004 at 07:37:44PM +0200, Nigel Kukard wrote: > Just an idea, but why not have udev set the context on its root path? you mean on /dev, i presume? well i had to patch selinux/hooks.c to allow this [on a tmpfs] by relaxing the criteria of the "fscontext=" option for mount. otherwise it's not _possible_ t set the context on /dev as it is mounted [on a tmpfs]. [if /dev was a persistent filesystem everything would be hunky-dory and this wouldn't be an issue]. with that in mind, it's more that because you're putting device inodes into a non-persistent filesystem, you end up getting the "default" rules and so you must "restore" the contexts, or you must patch udev to "understand" the contents of /etc/selinux/src/file_contexts/file_contexts (using matchpathcon() and setfscreatecon() from libselinux) such that it will create inodes with the right file context. like i said, if /dev was a persistent filesystem, and if device inodes never disappeared, this wouldn't be a problem: you could run setfiles /etc/selinux/src/file_contexts/file_contexts /dev and be done with it... ... but that's not how udev works: it deletes and creates inodes on demand; nothing exists at boot-time, it's all created on-demand. so, not only must udev be patched to restore contexts but also the policies and various hacks added to "cope" with /dev being incredibly basic at startup - prior to udev running. _including_ dealing with getting the contexts correct on entries in /.dev [the old /dev remounted with mount --rbind] l. -- -- Truth, honesty and respect are rare commodities that all spring from the same well: Love. If you love yourself and everyone and everything around you, funnily and coincidentally enough, life gets a lot better. -- lkcl.net
lkcl at lkcl.net
From lkcl at lkcl.net Mon Aug 30 20:33:17 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 30 Aug 2004 21:33:17 +0100 Subject: Progress! .532 boots! -- but dbus/hotplug/udev problems remain? In-Reply-To: <41336FF0.2060701@redhat.com> References: <4130CF1B.3090909@comcast.net> <200408291737.17497.russell@coker.com.au> <41323421.7050904@comcast.net> <41336FF0.2060701@redhat.com> Message-ID: <20040830203316.GC31497@lkcl.net> On Mon, Aug 30, 2004 at 02:20:32PM -0400, Daniel J Walsh wrote: > Tom London wrote: > > >Russell, > > > >The following changes to udev.te seem needed.... > >(If udev shouldn't be reading file_contexts, then dontaudit?) > > > udev needs to read file_contexts. It is doing a matchpathcon in order > to setup the devices with the correct context. dan, dan, you MUST fix the bug in that patch before making changes to the selinux policy files for udev!!! matchpathcon() is being called with S_IFDIR not with the mode argument! l. From jwcart2 at epoch.ncsc.mil Mon Aug 30 20:42:13 2004 From: jwcart2 at epoch.ncsc.mil (James Carter) Date: Mon, 30 Aug 2004 16:42:13 -0400 Subject: Progress! .532 boots! -- but dbus/hotplug/udev problems remain? In-Reply-To: <41323421.7050904@comcast.net> References: <4130CF1B.3090909@comcast.net> <200408291737.17497.russell@coker.com.au> <41323421.7050904@comcast.net> Message-ID: <1093898533.3227.28.camel@moss-lions.epoch.ncsc.mil> Thanks Russell and Tom. Merged into sourceforge policy using r_dir_file() for selinux_config_t, file_context_t, and default_context_t. Showing only the part changed from Russell's patch: --- domains/program/unused/udev.te 27 Aug 2004 13:14:05 -0000 1.17 +++ domains/program/unused/udev.te 30 Aug 2004 19:36:44 -0000 @@ -32,19 +31,19 @@ allow udev_t device_t:blk_file create_file_perms; allow udev_t device_t:chr_file create_file_perms; allow udev_t device_t:sock_file create_file_perms; -allow udev_t etc_t:file { getattr read execute }; +allow udev_t device_t:lnk_file create_lnk_perms; +allow udev_t etc_t:file { getattr read }; allow udev_t { bin_t sbin_t }:dir r_dir_perms; allow udev_t { sbin_t bin_t }:lnk_file read; -can_exec(udev_t, { shell_exec_t bin_t sbin_t } ) +allow udev_t bin_t:lnk_file read; +can_exec(udev_t, { shell_exec_t bin_t sbin_t etc_t } ) can_exec(udev_t, udev_exec_t) -can_exec(udev_t, hostname_exec_t) -can_exec(udev_t, iptables_exec_t) r_dir_file(udev_t, sysfs_t) allow udev_t sysadm_tty_device_t:chr_file { read write }; allow udev_t { device_t device_type }:{chr_file blk_file} { relabelfrom relabelto create_file_perms }; -# to read the file_contexts file? -r_dir_file(udev_t, policy_config_t) +# to read the file_contexts file +r_dir_file(udev_t, { selinux_config_t file_context_t default_context_t } ) allow udev_t policy_config_t:dir { search }; allow udev_t proc_t:file { read }; On Sun, 2004-08-29 at 15:53, Tom London wrote: > Russell, > > The following changes to udev.te seem needed.... > (If udev shouldn't be reading file_contexts, then dontaudit?) > > Please correct/improve, > tom > > --- /tmp/patches/udev.te 2004-08-29 11:35:48.000000000 -0700 > +++ udev.te 2004-08-29 12:40:58.000000000 -0700 > @@ -44,7 +44,9 @@ > > # to read the file_contexts file > allow udev_t { selinux_config_t default_context_t }:dir search; > -allow udev_t default_context_t:file { getattr read }; > +allow udev_t { selinux_config_t default_context_t }:file { getattr read }; > +allow udev_t file_context_t:dir { search }; > +allow udev_t file_context_t:file { getattr read }; > > allow udev_t policy_config_t:dir { search }; > allow udev_t proc_t:file { read }; > > > Russell Coker wrote: > > >On Sun, 29 Aug 2004 04:29, Tom London wrote: > > > > > >>Newest Rawhide updates (including udev-030-10, mkinitrd-4.1.8-1, > >>kernel-2.6.8-1.532, and selinux-policy-strict-1.17.5-2) > >>now boots in strict/enforcing. > >> > >> > > > >I've attached a diff against the CVS policy as well as the .te and .fc files > >for udev changes which fix this and address some other issues as well. > > > >Please try it out and let me know how it goes. > > > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to majordomo at tycho.nsa.gov with > the words "unsubscribe selinux" without quotes as the message. -- James Carter National Security Agency From lkcl at lkcl.net Mon Aug 30 21:16:52 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 30 Aug 2004 22:16:52 +0100 Subject: Progress! .532 boots! -- but dbus/hotplug/udev problems remain? In-Reply-To: <41336F3A.9030002@redhat.com> References: <4130CF1B.3090909@comcast.net> <200408291737.17497.russell@coker.com.au> <20040829100641.GG7610@lkcl.net> <41336F3A.9030002@redhat.com> Message-ID: <20040830211652.GF31497@lkcl.net> On Mon, Aug 30, 2004 at 02:17:30PM -0400, Daniel J Walsh wrote: > Luke Kenneth Casson Leighton wrote: > > >btw i didn't see an acknowledgement from the person who sent the > >last udev patch (dan was it you?) > > > >the use of the "mode" argument it is clear has not been used, > >to call i think it was matchpathcon. > > > >instead, because i had three near-identical code portions all > >of which had different S_IFXXX thingies, dan-i-think-it-was > >moved the near-identical code into a function with a "mode" > >argument... > > > >... and forgot to use the "mode" argument such that matchpathcon > >is called with S_IFDIR. > > > >given that i haven't seen an acknowledgement of this issue > >either in my inbox or on the mailing lists (which i am checking > >manually) i thought it best to hassle people until i know it's > >been spotted. > > > >this is IMPORTANT because it will impact the contexts on > >inodes and stuff created in /dev: the "optimising" argument > >"mode" passed to matchpathcon and setfscreatecon, if wrong, > >results in relevant (and correct!) file_context entries being > >skipped! > > > >l. > > > >On Sun, Aug 29, 2004 at 05:37:17PM +1000, Russell Coker wrote: > > > > > > > >>On Sun, 29 Aug 2004 04:29, Tom London wrote: > >> > >> > >>>Newest Rawhide updates (including udev-030-10, mkinitrd-4.1.8-1, > >>>kernel-2.6.8-1.532, and selinux-policy-strict-1.17.5-2) > >>>now boots in strict/enforcing. > >>> > >>> > >>I've attached a diff against the CVS policy as well as the .te and .fc > >>files for udev changes which fix this and address some other issues as > >>well. > >> > >> > >-- > >fedora-selinux-list mailing list > >fedora-selinux-list at redhat.com > >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > Yes it was me and I modified out udev rpm, but I guess I never > responded. Sorry about that. not a problem, just making sure. i have to manually check the fedora-selinux list: if you did i must have missed it. *whew*. l. From jim-cornette at sbcglobal.net Tue Aug 31 03:17:10 2004 From: jim-cornette at sbcglobal.net (Jim Cornette) Date: Mon, 30 Aug 2004 23:17:10 -0400 Subject: SELinux stops new X11? In-Reply-To: <1093000842.16585.3.camel@moss-spartans.epoch.ncsc.mil> References: <41253351.7030807@mindspring.com> <1093000842.16585.3.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4133EDB6.9060809@sbcglobal.net> Stephen Smalley wrote: >On Thu, 2004-08-19 at 19:10, Richard Hally wrote: > > >>The new xorg-X11(6.7.99.902-1) will not start with the current strict >>SELinux policy(1.15.16-1) in enforcing mode. (xorg-x11-*6.7.0-7.2 works >>just fine). I have not tried permissive mode. >> It looks like something has changed in X11 that has to do with the >>fonts and the SE policy has not been updated to handle it but that is >>just speculation. >> >> > >I applied the patch below to my /etc/init.d/xfs to fix. This patch >restores the type on /tmp/.font-unix when it is re-created by >/etc/init.d/xfs. I assume that previously xfs was directly creating the >directory itself, so that the file_type_auto_trans rule for xfs_t was >sufficient to label it, but since it is now being created by the init >script, it is getting a different type. > >--- /etc/init.d/xfs.old 2004-08-18 14:45:54.000000000 -0400 >+++ /etc/init.d/xfs 2004-08-20 07:16:01.539914488 -0400 >@@ -78,6 +78,7 @@ > mkdir $FONT_UNIX_DIR > chown root:root $FONT_UNIX_DIR > chmod 1777 $FONT_UNIX_DIR >+ restorecon $FONT_UNIX_DIR > > daemon xfs -droppriv -daemon > ret=$? > > > with 903-1, I was getting the below errors and am running targeted and enforcing. I noted these in /var/log/messages when trying to track down another problem. I don't know if this is applicable or not to the problem described. Jim /var/log/messages displays the below xfs errors regarding the speedo font. Aug 29 13:34:22 localhost xfs[3371]: ignoring font path element /usr/X11R6/lib/X11/fonts/Speedo (unreadable) Aug 29 14:27:32 localhost xfs[3371]: ignoring font path element /usr/X11R6/lib/X11/fonts/Speedo (unreadable) Aug 29 16:00:00 localhost xfs[3595]: ignoring font path element /usr/X11R6/lib/X11/fonts/Speedo (unreadable) Aug 29 16:14:59 localhost xfs[3154]: ignoring font path element /usr/X11R6/lib/X11/fonts/Speedo (unreadable) -- Old age is too high a price to pay for maturity. From lkcl at lkcl.net Tue Aug 31 09:49:08 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 31 Aug 2004 10:49:08 +0100 Subject: [idea] udev + selinux In-Reply-To: <20040831050252.GF10151@lbsd.net> References: <20040830173744.GD10151@lbsd.net> <20040830203140.GB31497@lkcl.net> <20040831050252.GF10151@lbsd.net> Message-ID: <20040831094908.GA2098@lkcl.net> On Tue, Aug 31, 2004 at 07:02:52AM +0200, Nigel Kukard wrote: > > you mean on /dev, i presume? > > yep, or /udev (configured in the udev config file) oh. yes. redhat :) > > > > well i had to patch selinux/hooks.c to allow this [on a tmpfs] > > by relaxing the criteria of the "fscontext=" option for mount. > > > > if its tmpfs, this would void the requirement of passing a mount option > fscontext, udev would set the correct context when started up (a check > could also be added to do this only if the mount point is /dev and its > tmpfs... *shrug*) > > > otherwise it's not _possible_ t set the context on /dev as it is > > mounted [on a tmpfs]. > > > > [if /dev was a persistent filesystem everything would be hunky-dory > > and this wouldn't be an issue]. > > > > *nod* > > > > > with that in mind, it's more that because you're putting device > > inodes into a non-persistent filesystem, you end up getting the > > "default" rules and so you must "restore" the contexts, or > > you must patch udev to "understand" the contents of > > /etc/selinux/src/file_contexts/file_contexts (using matchpathcon() > > and setfscreatecon() from libselinux) such that it will create > > inodes with the right file context. > > > > I applied the patch to tmpfs to make it store xattr attributes which i > found on the mailing list, seems your patch forgets xattr.h? ?? oops. okay, i had put it at http://www.hands.com/~lkcl/selinux/2.6.6/ and when i posted copies to the list i must have missed it out. if you _do_ know how to properly create patches that other people can apply simply, that'd be great. > I also applied the patch which adds "matchpathcon()" & > "setfscreatecon()" support, dan is working on a new version of that, for udev-0.030-10. > and modified udev to set the correct > context of its root_path on startup. mount -o fscontext=system_u:object_r:device_t yes? did you patch selinux/hooks.c to relax the constraints on the fscontext= parameter to allow the correct context to be correctly applied? :) > > ... but that's not how udev works: it deletes and creates inodes > > on demand; nothing exists at boot-time, it's all created on-demand. > > at boot time i have about 5 devices in /dev with correct contexts set, > udev them mounts tmpfs over this, WorksForMe(tm) > > so in actual fact we do need matchpathcon() & setfscreatecon(), if its a > persistent or non-persistent filesystem yep. > > > > so, not only must udev be patched to restore contexts but also > > the policies and various hacks added to "cope" with /dev being > > incredibly basic at startup - prior to udev running. > > i have a simple persistent /dev which is used before udev runs, udev is > then initialized, mounts a tmpfs over /dev (and restores its context) oh. ah.... you _restore_ its context (i.e. run restorecon /dev), you don't mount it with the modified mount -o fscontext= parameter? > just > after sysctl -p is run in my initscripts so its basically one of the > first things to run. yep. > Seeing as my initial /dev is on a persistent > filesystem i don't have a problem with pre-udev stuff running. well.... you shouldn't... until you reinitialise or somehow delete, upgrade or otherwise modify the "old" /dev [which you will find is remounted --rbind to /.dev]. try it: do setfiles /etc/selinux/src/file_contexts/file_contexts /.dev and then reboot [in permissive mode!!!] due to the present files/types.fc, you will find that the entire /.dev gets relabelled to something completely useless: root_t or default_t. i think it's default_t. consequently your next reboot in enforcing mode will fail because /sbin/init tries to access /dev/null and /dev/initctl etc. as default_t ... and it can't. should you choose to deal with this, replace /u?dev with /[\.u]dev or some suitable regexp that i haven't a clue how to write so i just did /.?u?dev and that did the trick. the only _other_ thing you might find is that things like dialup don't or won't have been loaded. so i had to add in a _second_ version of /etc/init.d/modutils which does exactly the same as /etc/init.d/modutils ... but with a different list of modules, and AFTER udev has been run, not before. the list i have so far in /etc/modules.postudev contains (for my purposes): ppp_generic nvidia sg ppp_generic is there because "pon provider" bitches about /dev/ppp not existing sg is there because of usb-mount using sg_mod: if the module is pre-loaded, then /dev/sg0 gets created by udev. i don't believe that these modules should be loaded prior to udev being run: maybe they can, maybe they can't, maybe the nodes being loaded prior will result in a pending hotplug event such that when udev is run, the node gets created. ... but certainly, _some_ modules haven't been modified to conform to the new /sys thing. the "trick" of a node in /dev existing, and its first access automatically triggering a modprobe... well that only works if the node is there, and of course with udev, it isn't. perhaps there should be a "hook" into tmpfs to be able to pass filenames accessed in /dev on to udev, such that udev can go "oo, they tried to access /dev/ppp, let's kick off that module, then". l. From lkcl at lkcl.net Tue Aug 31 11:26:44 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 31 Aug 2004 12:26:44 +0100 Subject: [idea] udev + selinux In-Reply-To: <20040831094908.GA2098@lkcl.net> References: <20040830173744.GD10151@lbsd.net> <20040830203140.GB31497@lkcl.net> <20040831050252.GF10151@lbsd.net> <20040831094908.GA2098@lkcl.net> Message-ID: <20040831112644.GB11456@lkcl.net> On Tue, Aug 31, 2004 at 10:49:08AM +0100, Luke Kenneth Casson Leighton wrote: > > Seeing as my initial /dev is on a persistent > > filesystem i don't have a problem with pre-udev stuff running. > > well.... you shouldn't... until you reinitialise or somehow delete, > upgrade or otherwise modify the "old" /dev [which you will find is > remounted --rbind to /.dev]. > > try it: do setfiles /etc/selinux/src/file_contexts/file_contexts /.dev > and then reboot [in permissive mode!!!] > > due to the present files/types.fc, you will find that the entire > /.dev gets relabelled to something completely useless: root_t > or default_t. i think it's default_t. > > consequently your next reboot in enforcing mode will fail because > /sbin/init tries to access /dev/null and /dev/initctl etc. as > default_t ... and it can't. > > should you choose to deal with this, replace /u?dev with /[\.u]dev or > some suitable regexp that i haven't a clue how to write so i just > did /.?u?dev and that did the trick. it's insufficient to add /.?u?dev to just file_contexts/types.fc you also have to search in file_contexts/program/* for /dev and set the right context there, too. there is i believe a bug at present in e.g. file_contexts/program/init.fc because it only covers /dev/initctl not /udev/initctl and not /.dev/initctl. i think this one is the only one that's really really critical [except on redhat of course where they all should be /u?dev] because if /.dev/initctl gets set to default_t, you're stuffed at next boot. l. From lkcl at lkcl.net Tue Aug 31 12:46:13 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 31 Aug 2004 13:46:13 +0100 Subject: [idea] udev + selinux In-Reply-To: <20040831102715.GJ10151@lbsd.net> References: <20040830173744.GD10151@lbsd.net> <20040830203140.GB31497@lkcl.net> <20040831050252.GF10151@lbsd.net> <20040831094908.GA2098@lkcl.net> <20040831102715.GJ10151@lbsd.net> Message-ID: <20040831124613.GF11456@lkcl.net> On Tue, Aug 31, 2004 at 12:27:15PM +0200, Nigel Kukard wrote: > > > and modified udev to set the correct > > > context of its root_path on startup. > > > > mount -o fscontext=system_u:object_r:device_t yes? > > > > nope.... mount -t ramfs none /dev > > then run udevstart (udevstart does the C call to restorecon on > root_path, so it ends up being labeled with whatever is configured) oh, does it? oh! > > did you patch selinux/hooks.c to relax the constraints on > > the fscontext= parameter to allow the correct context to be > > correctly applied? :) > > > > correct, not sure if this is the 100% right way to do it though, I think > it would be better for the capabilities of the fs to be set properly > instead of commenting out code, this will have better chance being > included mainstream. > well if someone wants to write a new patch to hooks.c and invent a new mount -o option oh i dunno overridecontext=.... then sure. it's all the same to me. > > > > > > > > so, not only must udev be patched to restore contexts but also > > > > the policies and various hacks added to "cope" with /dev being > > > > incredibly basic at startup - prior to udev running. > > > > > > i have a simple persistent /dev which is used before udev runs, udev is > > > then initialized, mounts a tmpfs over /dev (and restores its context) > > > > oh. ah.... you _restore_ its context (i.e. run restorecon > > /dev), you don't mount it with the modified mount -o fscontext= > > parameter? > > correct!, it does the restore in udevstart ok. my question is: is this desirable behaviour? > > > Seeing as my initial /dev is on a persistent > > > filesystem i don't have a problem with pre-udev stuff running. > > > > well.... you shouldn't... until you reinitialise or somehow delete, > > upgrade or otherwise modify the "old" /dev [which you will find is > > remounted --rbind to /.dev]. > > got no reason to add other entries to the pre-udev /dev, so as I said > ItWorksForMe(tm). > > > > > try it: do setfiles /etc/selinux/src/file_contexts/file_contexts /.dev > > and then reboot [in permissive mode!!!] > > > > due to the present files/types.fc, you will find that the entire > > /.dev gets relabelled to something completely useless: root_t > > or default_t. i think it's default_t. > > yep, i'm 100% aware of this... i don't need /.dev, nor do I have it, nor > do I want it ... heh, on installation of our distribution the pre-udev > /dev is created and labeled correctly. ... how? and can you guarantee that it will _stay_ labelled correctly? > > > > consequently your next reboot in enforcing mode will fail because > > /sbin/init tries to access /dev/null and /dev/initctl etc. as > > default_t ... and it can't. > > > > yep, but as I said... i don't label pre-udev /dev when udev is running, > before I added it to our distro installer I mounted /dev/hda1 (root) as > /mnt/hda1, chroot'd onto it and re-labeled the files there (basically > the same thing our installer does) that's cheating :) > > the list i have so far in /etc/modules.postudev contains (for my purposes): > > > > ppp_generic > > nvidia > > sg > > > > no probs with any of these either (and yes we do use them), the pc i'm > on runs dual-head nvidia ;-) bizarre. how do you deal with that? perhaps an answer would be best off-selinux list because it's not entirely relevant to selinux, more the use of it. > every distro is different, so i would expect some to gulp bubbles and > some not to... *shrug* > > > i don't believe that these modules should be loaded prior to udev > > being run: maybe they can, maybe they can't, maybe the nodes being > > loaded prior will result in a pending hotplug event such that when > > udev is run, the node gets created. > > we load them after udev, and everything ends up labeled correctly... > > for instance... > > ot at localhost.localdomain policy]# ls -Z /dev/ppp > ls: /dev/ppp: No such file or directory > [root at localhost.localdomain policy]# modprobe ppp_generic ^^^^^^^^^^^^^^^^^^^^ this is the bit that my /etc/init.d/modutils.postudev initscript does for me: i'd be interested to know if you do something similar. i can't be telling users to do _that_ they're unlikely even know what a ppp is, that a modprobe is something to do with police investigations in the 70s into the sex pistols, and if you mentioned xterm they'd call rentakill. > [root at localhost.localdomain policy]# ls -Z /dev/ppp > crw------- root root system_u:object_r:ppp_device_t /dev/ppp > [root at localhost.localdomain policy]# yes, this i'd expect to happen... _if_ the modprobe ppp_generic command is ever issued [and users shouldn't be expected to do it!] > > perhaps there should be a "hook" into tmpfs to be able to pass > > filenames accessed in /dev on to udev, such that udev can go > > "oo, they tried to access /dev/ppp, let's kick off that module, > > then". > > if you need any of my initscripts or anything, give me a shout, i've > nearly got a 100% functional selinux enabled server! ;-) if you could place them on a convenient http-accessible server somewhere near you, that'd be great. l. From nkukard at lbsd.net Tue Aug 31 05:02:52 2004 From: nkukard at lbsd.net (Nigel Kukard) Date: Tue, 31 Aug 2004 07:02:52 +0200 Subject: [idea] udev + selinux In-Reply-To: <20040830203140.GB31497@lkcl.net> References: <20040830173744.GD10151@lbsd.net> <20040830203140.GB31497@lkcl.net> Message-ID: <20040831050252.GF10151@lbsd.net> > you mean on /dev, i presume? yep, or /udev (configured in the udev config file) > > well i had to patch selinux/hooks.c to allow this [on a tmpfs] > by relaxing the criteria of the "fscontext=" option for mount. > if its tmpfs, this would void the requirement of passing a mount option fscontext, udev would set the correct context when started up (a check could also be added to do this only if the mount point is /dev and its tmpfs... *shrug*) > otherwise it's not _possible_ t set the context on /dev as it is > mounted [on a tmpfs]. > > [if /dev was a persistent filesystem everything would be hunky-dory > and this wouldn't be an issue]. > *nod* > > with that in mind, it's more that because you're putting device > inodes into a non-persistent filesystem, you end up getting the > "default" rules and so you must "restore" the contexts, or > you must patch udev to "understand" the contents of > /etc/selinux/src/file_contexts/file_contexts (using matchpathcon() > and setfscreatecon() from libselinux) such that it will create > inodes with the right file context. > I applied the patch to tmpfs to make it store xattr attributes which i found on the mailing list, seems your patch forgets xattr.h? I also applied the patch which adds "matchpathcon()" & "setfscreatecon()" support, and modified udev to set the correct context of its root_path on startup. > ... but that's not how udev works: it deletes and creates inodes > on demand; nothing exists at boot-time, it's all created on-demand. at boot time i have about 5 devices in /dev with correct contexts set, udev them mounts tmpfs over this, WorksForMe(tm) so in actual fact we do need matchpathcon() & setfscreatecon(), if its a persistent or non-persistent filesystem > > so, not only must udev be patched to restore contexts but also > the policies and various hacks added to "cope" with /dev being > incredibly basic at startup - prior to udev running. i have a simple persistent /dev which is used before udev runs, udev is then initialized, mounts a tmpfs over /dev (and restores its context) just after sysctl -p is run in my initscripts so its basically one of the first things to run. Seeing as my initial /dev is on a persistent filesystem i don't have a problem with pre-udev stuff running. > > _including_ dealing with getting the contexts correct on entries > in /.dev [the old /dev remounted with mount --rbind] > > l. > > -- Nigel Kukard, PhD CompSc (Chief Executive Officer) Linux Based Systems Design (Non-Profit) Web: www.lbsd.net Email: nkukard at lbsd.net Tel: (+27) 023 349 8000 Cell: (+27) 082 333 3723 Fax: (+27) 023 349 1395 Support: 086 747 7600 Address: LIGT House, 2 Klipdrift Rd, Rawsonville Linux Systems Design & Technology Solutions The best language to use is the language that was designed for what you want to use it for. ===================================================================== Disclaimer ---------- The contents of this message and any attachments are intended solely for the addressee's use and may be legally privileged and/or confidential information. This message may not be retained, distributed, copied or used if you are not he addressee of this message. If this message was sent to you in error, please notify the sender immediately by reply e-mail and then destroy the message and any copies thereof. Opinions, conclusions and other information in this message may be personal to the sender and is not that of Linux Based Systems Design, LinuxRulz or any of it's subsideries, associated companies or principals and is therefore not endorsed by Linux Based Systems Design or LinuxRulz. Due to e-maill communication being insecure, Linux Based Systems Design and LinuxRulz do not guarantee confidentiality, security, accuracy or performance of the e-mail. Any liability for viruses is excluded to the fullest extent. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nkukard at lbsd.net Tue Aug 31 10:27:15 2004 From: nkukard at lbsd.net (Nigel Kukard) Date: Tue, 31 Aug 2004 12:27:15 +0200 Subject: [idea] udev + selinux In-Reply-To: <20040831094908.GA2098@lkcl.net> References: <20040830173744.GD10151@lbsd.net> <20040830203140.GB31497@lkcl.net> <20040831050252.GF10151@lbsd.net> <20040831094908.GA2098@lkcl.net> Message-ID: <20040831102715.GJ10151@lbsd.net> On Tue, Aug 31, 2004 at 10:49:08AM +0100, Luke Kenneth Casson Leighton wrote: > > yep, or /udev (configured in the udev config file) > > oh. > > yes. > > redhat :) no... it just depends how you want it configured ;-) > > I applied the patch to tmpfs to make it store xattr attributes which i > > found on the mailing list, seems your patch forgets xattr.h? > > ?? oops. > > okay, i had put it at http://www.hands.com/~lkcl/selinux/2.6.6/ > and when i posted copies to the list i must have missed it out. > > if you _do_ know how to properly create patches that other people > can apply simply, that'd be great. > *nod*, i'm pondering creating the patches... let me see what i can do > > I also applied the patch which adds "matchpathcon()" & > > "setfscreatecon()" support, > > dan is working on a new version of that, for udev-0.030-10. > cool, that will at least remove 1 patch out my build tree > > > and modified udev to set the correct > > context of its root_path on startup. > > mount -o fscontext=system_u:object_r:device_t yes? > nope.... mount -t ramfs none /dev then run udevstart (udevstart does the C call to restorecon on root_path, so it ends up being labeled with whatever is configured) > did you patch selinux/hooks.c to relax the constraints on > the fscontext= parameter to allow the correct context to be > correctly applied? :) > correct, not sure if this is the 100% right way to do it though, I think it would be better for the capabilities of the fs to be set properly instead of commenting out code, this will have better chance being included mainstream. > > > > > > so, not only must udev be patched to restore contexts but also > > > the policies and various hacks added to "cope" with /dev being > > > incredibly basic at startup - prior to udev running. > > > > i have a simple persistent /dev which is used before udev runs, udev is > > then initialized, mounts a tmpfs over /dev (and restores its context) > > oh. ah.... you _restore_ its context (i.e. run restorecon > /dev), you don't mount it with the modified mount -o fscontext= > parameter? correct!, it does the restore in udevstart > > Seeing as my initial /dev is on a persistent > > filesystem i don't have a problem with pre-udev stuff running. > > well.... you shouldn't... until you reinitialise or somehow delete, > upgrade or otherwise modify the "old" /dev [which you will find is > remounted --rbind to /.dev]. got no reason to add other entries to the pre-udev /dev, so as I said ItWorksForMe(tm). > > try it: do setfiles /etc/selinux/src/file_contexts/file_contexts /.dev > and then reboot [in permissive mode!!!] > > due to the present files/types.fc, you will find that the entire > /.dev gets relabelled to something completely useless: root_t > or default_t. i think it's default_t. yep, i'm 100% aware of this... i don't need /.dev, nor do I have it, nor do I want it ... heh, on installation of our distribution the pre-udev /dev is created and labeled correctly. > > consequently your next reboot in enforcing mode will fail because > /sbin/init tries to access /dev/null and /dev/initctl etc. as > default_t ... and it can't. > yep, but as I said... i don't label pre-udev /dev when udev is running, before I added it to our distro installer I mounted /dev/hda1 (root) as /mnt/hda1, chroot'd onto it and re-labeled the files there (basically the same thing our installer does) > should you choose to deal with this, replace /u?dev with /[\.u]dev or > some suitable regexp that i haven't a clue how to write so i just > did /.?u?dev and that did the trick. > thats a good idea ;-), although in "my" case didn't need it. > > the only _other_ thing you might find is that things like dialup > don't or won't have been loaded. > i don't have any problems with this ;-) > so i had to add in a _second_ version of /etc/init.d/modutils which > does exactly the same as /etc/init.d/modutils ... but with a different > list of modules, and AFTER udev has been run, not before. > > the list i have so far in /etc/modules.postudev contains (for my purposes): > > ppp_generic > nvidia > sg > no probs with any of these either (and yes we do use them), the pc i'm on runs dual-head nvidia ;-) every distro is different, so i would expect some to gulp bubbles and some not to... *shrug* > i don't believe that these modules should be loaded prior to udev > being run: maybe they can, maybe they can't, maybe the nodes being > loaded prior will result in a pending hotplug event such that when > udev is run, the node gets created. we load them after udev, and everything ends up labeled correctly... for instance... ot at localhost.localdomain policy]# ls -Z /dev/ppp ls: /dev/ppp: No such file or directory [root at localhost.localdomain policy]# modprobe ppp_generic [root at localhost.localdomain policy]# ls -Z /dev/ppp crw------- root root system_u:object_r:ppp_device_t /dev/ppp [root at localhost.localdomain policy]# > perhaps there should be a "hook" into tmpfs to be able to pass > filenames accessed in /dev on to udev, such that udev can go > "oo, they tried to access /dev/ppp, let's kick off that module, > then". if you need any of my initscripts or anything, give me a shout, i've nearly got a 100% functional selinux enabled server! ;-) just writing a few security policies -- Nigel Kukard, PhD CompSc (Chief Executive Officer) Linux Based Systems Design (Non-Profit) Web: www.lbsd.net Email: nkukard at lbsd.net Tel: (+27) 023 349 8000 Cell: (+27) 082 333 3723 Fax: (+27) 023 349 1395 Support: 086 747 7600 Address: LIGT House, 2 Klipdrift Rd, Rawsonville Linux Systems Design & Technology Solutions The best language to use is the language that was designed for what you want to use it for. ===================================================================== Disclaimer ---------- The contents of this message and any attachments are intended solely for the addressee's use and may be legally privileged and/or confidential information. This message may not be retained, distributed, copied or used if you are not he addressee of this message. If this message was sent to you in error, please notify the sender immediately by reply e-mail and then destroy the message and any copies thereof. Opinions, conclusions and other information in this message may be personal to the sender and is not that of Linux Based Systems Design, LinuxRulz or any of it's subsideries, associated companies or principals and is therefore not endorsed by Linux Based Systems Design or LinuxRulz. Due to e-maill communication being insecure, Linux Based Systems Design and LinuxRulz do not guarantee confidentiality, security, accuracy or performance of the e-mail. Any liability for viruses is excluded to the fullest extent. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lkcl at lkcl.net Tue Aug 31 16:07:50 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 31 Aug 2004 17:07:50 +0100 Subject: [idea] udev + selinux In-Reply-To: <20040830173744.GD10151@lbsd.net> References: <20040830173744.GD10151@lbsd.net> Message-ID: <20040831160750.GM11456@lkcl.net> On Mon, Aug 30, 2004 at 07:37:44PM +0200, Nigel Kukard wrote: > Just an idea, but why not have udev set the context on its root path? > > I have a simplistic patch for this if its a good idea. ah ha. very funny. now i have re-read what you've said, now that i have enough background based on your further explanations in this thread, _now_ i have enough context to understand your question. okay. let me reiterate what i believe you have said. you have patched the program udev (0.030-10?) [and yes, i would highly recommend sending it to the list(s) to make it clear what you mean]. this patch will run, when it starts up, a call to setfilecon() on /dev (or /udev, or whatever the mount point of the devfs is). and _just_ on "/dev". yes? and it's done BEFORE any inodes are EVER created in the new /dev, yes? assuming yes, then it kinda-solves the need for doing that hacked-up relaxed-constraints-patch-to-hooks.c fscontext= option. why? because you can mount -t tmpfs /dev blah blah and you don't care what the context is because udev will set the correct one when it runs. that is - of course - assuming that file_contexts/file_contexts _contains_ the correct file context for /dev. it might make (i dunno) for a simpler policy. what i mean is, have you had to add in the modifications to the selinux policy that i sent to the lists last week? e.g. these: allow udev_tbl_t device_t:filesystem { associate }; allow initctl_t device_t:filesystem { associate }; and these: +# needed for udev-mounted (/dev) tmpfs +allow $1_tty_device_t device_t:filesystem { associate }; + +# to allow users to run df on udev-mounted (/dev) tmpfs +allow $1_t device_t:filesystem { getattr }; + #EXE=/bin/df NAME=/ : getattr + these are all there for reasons i cannot entirely fathom but it starts, in types/file.te, with this: allow { device_type } device_t:filesystem associate; which is all because of this: mount tmpfs -o fscontext=system_u:object_r:device_t /dev anyway what i am saying is that if you HAVE NOT got all these patches in your selinux policy files, then your approach has distinct advantages: less mods to the policy files and less differences between a persistent and non-persistent udev filesystem. other than that, my intuition is saying "i don't like it" and what that means is that in about two or three weeks i will be able to articulate clearly and precisely why i don't think it's a good idea. it'll likely be something to do with your solution being a two-step operation whereas the hacked-up-relaxed-fscontext-hooks.c things is a one-step (atomic?) operation. l. From lkcl at lkcl.net Tue Aug 31 19:18:10 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 31 Aug 2004 20:18:10 +0100 Subject: [idea] udev + selinux In-Reply-To: <20040831164635.GK10151@lbsd.net> References: <20040830173744.GD10151@lbsd.net> <20040831160750.GM11456@lkcl.net> <20040831164635.GK10151@lbsd.net> Message-ID: <20040831191809.GC4375@lkcl.net> On Tue, Aug 31, 2004 at 06:46:35PM +0200, Nigel Kukard wrote: > > assuming yes, then it kinda-solves the need for doing that hacked-up > > relaxed-constraints-patch-to-hooks.c fscontext= option. > > > > aha, u correct!!!! > > > why? because you can mount -t tmpfs /dev blah blah and you don't > > care what the context is because udev will set the correct one > > when it runs. > > > > > > perfect!!!!, so that solves the need for the hooks patch, which is in > actual fact wrong. oh, is it? uhm, why? > > that is - of course - assuming that file_contexts/file_contexts > > _contains_ the correct file context for /dev. > > > > > > *nod* > > > it might make (i dunno) for a simpler policy. > > > > yep i _say_ might ... but then you mention that you've done exactly the same policy mods that i had to... > > what i mean is, have you had to add in the modifications to the > > selinux policy that i sent to the lists last week? > > > > e.g. these: > > > > allow udev_tbl_t device_t:filesystem { associate }; > > allow initctl_t device_t:filesystem { associate }; > > > > and these: > > > > +# needed for udev-mounted (/dev) tmpfs > > +allow $1_tty_device_t device_t:filesystem { associate }; > > + > > +# to allow users to run df on udev-mounted (/dev) tmpfs > > +allow $1_t device_t:filesystem { getattr }; > > + #EXE=/bin/df NAME=/ : getattr > > + > > > > had to add quite a couple more, but i'm still working on that to make it > "correct" i think we need the input of more experienced people than us to say why these associate things are needed. > > these are all there for reasons i cannot entirely fathom but > > it starts, in types/file.te, with this: > > > > allow { device_type } device_t:filesystem associate; > > > > i need this aswell.... which is very interesting, so my "way of doing > it" doesn't solve this problem. i'll keep looking for the solution > > > which is all because of this: > > > > mount tmpfs -o fscontext=system_u:object_r:device_t /dev > > > > this doesn't cause the problem, its something else > > > > > anyway what i am saying is that if you HAVE NOT got all these patches > > in your selinux policy files, then your approach has distinct > > advantages: less mods to the policy files and less differences between > > a persistent and non-persistent udev filesystem. > > > > correct, i'm still working on it though and it HAS TO BE COMPLETED > SOON!!!! ah, the joys of the "ItWorksForMe(tm)" approach... > > > > other than that, my intuition is saying "i don't like it" and what that > > means is that in about two or three weeks i will be able to articulate > > clearly and precisely why i don't think it's a good idea. > > > > *shrug*, just a different outlook, patching userspace instead of kernel > space > > > it'll likely be something to do with your solution being a two-step > > operation whereas the hacked-up-relaxed-fscontext-hooks.c things is > > a one-step (atomic?) operation. > > > > kernel developers will very much not like to get patches unless for a > very good reason... a correct implementation of the hacked-together-relaxed-fscontext-hooks.c-patch results in an atomic operation (mount with a new context which would otherwise need to be achieved with two commands: mount followed by restorecon) in my books, that's a good reason! > *shrug*... guess i have the totally oposite outlook > than you, i've had quite a number of my patches go mainstream though dude, the entire selinux thing is disliked by stacks of debian maintainers because of the knock-on implications it has. imagine what chaos would ensue if up until now, linux only had a FAT filesystem and someone said "hey, there's this _great_ concept it's called file ownership and file permissions, i've invented something called an ext2 filesystem". l. -- -- Truth, honesty and respect are rare commodities that all spring from the same well: Love. If you love yourself and everyone and everything around you, funnily and coincidentally enough, life gets a lot better. -- lkcl.net
lkcl at lkcl.net
From sds at epoch.ncsc.mil Tue Aug 31 19:26:43 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Tue, 31 Aug 2004 15:26:43 -0400 Subject: [idea] udev + selinux In-Reply-To: <20040831191809.GC4375@lkcl.net> References: <20040830173744.GD10151@lbsd.net> <20040831160750.GM11456@lkcl.net> <20040831164635.GK10151@lbsd.net> <20040831191809.GC4375@lkcl.net> Message-ID: <1093980403.8517.239.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2004-08-31 at 15:18, Luke Kenneth Casson Leighton wrote: > i think we need the input of more experienced people than us to > say why these associate things are needed. It provides control over the set of files that can live in a given filesystem, based on their security types (equivalence classes). As you are now creating device types in a different filesystem type, further allow rules are needed to allow that association. > a correct implementation of the > hacked-together-relaxed-fscontext-hooks.c-patch results in an atomic > operation (mount with a new context which would otherwise need to be > achieved with two commands: mount followed by restorecon) The more important issue is that fscontext= lets you set the superblock security context, not just the root directory context. restorecon can't do that. -- Stephen Smalley National Security Agency From lkcl at lkcl.net Tue Aug 31 20:02:10 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 31 Aug 2004 21:02:10 +0100 Subject: [idea] udev + selinux In-Reply-To: <1093980403.8517.239.camel@moss-spartans.epoch.ncsc.mil> References: <20040830173744.GD10151@lbsd.net> <20040831160750.GM11456@lkcl.net> <20040831164635.GK10151@lbsd.net> <20040831191809.GC4375@lkcl.net> <1093980403.8517.239.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20040831200210.GH4375@lkcl.net> On Tue, Aug 31, 2004 at 03:26:43PM -0400, Stephen Smalley wrote: > On Tue, 2004-08-31 at 15:18, Luke Kenneth Casson Leighton wrote: > > i think we need the input of more experienced people than us to > > say why these associate things are needed. > > It provides control over the set of files that can live in a given > filesystem, based on their security types (equivalence classes). As you > are now creating device types in a different filesystem type, further > allow rules are needed to allow that association. > > > a correct implementation of the > > hacked-together-relaxed-fscontext-hooks.c-patch results in an atomic > > operation (mount with a new context which would otherwise need to be > > achieved with two commands: mount followed by restorecon) > > The more important issue is that fscontext= lets you set the superblock > security context, not just the root directory context. restorecon can't > do that. ah. thanks for clarifying, steven. l. From lkcl at lkcl.net Tue Aug 31 23:26:16 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 1 Sep 2004 00:26:16 +0100 Subject: [idea] udev + selinux In-Reply-To: References: <20040830173744.GD10151@lbsd.net> <20040831160750.GM11456@lkcl.net> <20040831164635.GK10151@lbsd.net> <20040831191809.GC4375@lkcl.net> <1093980403.8517.239.camel@moss-spartans.epoch.ncsc.mil> <20040831200210.GH4375@lkcl.net> Message-ID: <20040831232616.GX4375@lkcl.net> well, the patch is at um.. oh no it's not... um, hang on... yep, it's _now_ at http://hands.com/~lkcl/selinux/selinux-hooks.patch On Tue, Aug 31, 2004 at 05:18:05PM -0400, Jim McCullough wrote: > This should be of great assistance with two home projects currently > and 1 work project due to the filesystem types. I am still working > through size issues and further locking down the images. > > Project 1 = SE Linux image for Netgear MR314 Wireless Lan Router > Project 2 = SE Linux image for Cisco 2501 Router > Project 3 = Debian Sarge Server build on SGI Octane with reiserfs ( > Work for Network Management Server ) > > > The more important issue is that fscontext= lets you set the superblock > > > security context, not just the root directory context. restorecon can't > > > do that. From nkukard at lbsd.net Tue Aug 31 16:46:35 2004 From: nkukard at lbsd.net (Nigel Kukard) Date: Tue, 31 Aug 2004 18:46:35 +0200 Subject: [idea] udev + selinux In-Reply-To: <20040831160750.GM11456@lkcl.net> References: <20040830173744.GD10151@lbsd.net> <20040831160750.GM11456@lkcl.net> Message-ID: <20040831164635.GK10151@lbsd.net> > you have patched the program udev (0.030-10?) > > [and yes, i would highly recommend sending it to the list(s) > to make it clear what you mean]. > > this patch will run, when it starts up, a call to setfilecon() > on /dev (or /udev, or whatever the mount point of the devfs is). > > and _just_ on "/dev". > > yes? correct > > and it's done BEFORE any inodes are EVER created in the new > /dev, yes? > correct > > assuming yes, then it kinda-solves the need for doing that hacked-up > relaxed-constraints-patch-to-hooks.c fscontext= option. > aha, u correct!!!! > why? because you can mount -t tmpfs /dev blah blah and you don't > care what the context is because udev will set the correct one > when it runs. > > perfect!!!!, so that solves the need for the hooks patch, which is in actual fact wrong. > that is - of course - assuming that file_contexts/file_contexts > _contains_ the correct file context for /dev. > > *nod* > it might make (i dunno) for a simpler policy. > yep > what i mean is, have you had to add in the modifications to the > selinux policy that i sent to the lists last week? > > e.g. these: > > allow udev_tbl_t device_t:filesystem { associate }; > allow initctl_t device_t:filesystem { associate }; > > and these: > > +# needed for udev-mounted (/dev) tmpfs > +allow $1_tty_device_t device_t:filesystem { associate }; > + > +# to allow users to run df on udev-mounted (/dev) tmpfs > +allow $1_t device_t:filesystem { getattr }; > + #EXE=/bin/df NAME=/ : getattr > + > had to add quite a couple more, but i'm still working on that to make it "correct" > these are all there for reasons i cannot entirely fathom but > it starts, in types/file.te, with this: > > allow { device_type } device_t:filesystem associate; > i need this aswell.... which is very interesting, so my "way of doing it" doesn't solve this problem. i'll keep looking for the solution > which is all because of this: > > mount tmpfs -o fscontext=system_u:object_r:device_t /dev > this doesn't cause the problem, its something else > > anyway what i am saying is that if you HAVE NOT got all these patches > in your selinux policy files, then your approach has distinct > advantages: less mods to the policy files and less differences between > a persistent and non-persistent udev filesystem. > correct, i'm still working on it though and it HAS TO BE COMPLETED SOON!!!! > > other than that, my intuition is saying "i don't like it" and what that > means is that in about two or three weeks i will be able to articulate > clearly and precisely why i don't think it's a good idea. > *shrug*, just a different outlook, patching userspace instead of kernel space > it'll likely be something to do with your solution being a two-step > operation whereas the hacked-up-relaxed-fscontext-hooks.c things is > a one-step (atomic?) operation. > kernel developers will very much not like to get patches unless for a very good reason... *shrug*... guess i have the totally oposite outlook than you, i've had quite a number of my patches go mainstream though > l. -Nigel -- Nigel Kukard, PhD CompSc (Chief Executive Officer) Linux Based Systems Design (Non-Profit) Web: www.lbsd.net Email: nkukard at lbsd.net Tel: (+27) 023 349 8000 Cell: (+27) 082 333 3723 Fax: (+27) 023 349 1395 Support: 086 747 7600 Address: LIGT House, 2 Klipdrift Rd, Rawsonville Linux Systems Design & Technology Solutions The best language to use is the language that was designed for what you want to use it for. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jim.mccullough at gmail.com Tue Aug 31 21:18:05 2004 From: jim.mccullough at gmail.com (Jim McCullough) Date: Tue, 31 Aug 2004 17:18:05 -0400 Subject: [idea] udev + selinux In-Reply-To: <20040831200210.GH4375@lkcl.net> References: <20040830173744.GD10151@lbsd.net> <20040831160750.GM11456@lkcl.net> <20040831164635.GK10151@lbsd.net> <20040831191809.GC4375@lkcl.net> <1093980403.8517.239.camel@moss-spartans.epoch.ncsc.mil> <20040831200210.GH4375@lkcl.net> Message-ID: This should be of great assistance with two home projects currently and 1 work project due to the filesystem types. I am still working through size issues and further locking down the images. Project 1 = SE Linux image for Netgear MR314 Wireless Lan Router Project 2 = SE Linux image for Cisco 2501 Router Project 3 = Debian Sarge Server build on SGI Octane with reiserfs ( Work for Network Management Server ) Thanks, Jim McCullough On Tue, 31 Aug 2004 21:02:10 +0100, Luke Kenneth Casson Leighton wrote: > On Tue, Aug 31, 2004 at 03:26:43PM -0400, Stephen Smalley wrote: > > On Tue, 2004-08-31 at 15:18, Luke Kenneth Casson Leighton wrote: > > > i think we need the input of more experienced people than us to > > > say why these associate things are needed. > > > > It provides control over the set of files that can live in a given > > filesystem, based on their security types (equivalence classes). As you > > are now creating device types in a different filesystem type, further > > allow rules are needed to allow that association. > > > > > a correct implementation of the > > > hacked-together-relaxed-fscontext-hooks.c-patch results in an atomic > > > operation (mount with a new context which would otherwise need to be > > > achieved with two commands: mount followed by restorecon) > > > > The more important issue is that fscontext= lets you set the superblock > > security context, not just the root directory context. restorecon can't > > do that. > > ah. > > thanks for clarifying, steven. > > l. > > > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to majordomo at tycho.nsa.gov with > the words "unsubscribe selinux" without quotes as the message. > -- Jim McCullough From linas at austin.ibm.com Tue Aug 31 22:44:47 2004 From: linas at austin.ibm.com (Linas Vepstas) Date: Tue, 31 Aug 2004 17:44:47 -0500 Subject: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux] In-Reply-To: <20040831191809.GC4375@lkcl.net> References: <20040830173744.GD10151@lbsd.net> <20040831160750.GM11456@lkcl.net> <20040831164635.GK10151@lbsd.net> <20040831191809.GC4375@lkcl.net> Message-ID: <20040831224447.GA4964@austin.ibm.com> On Tue, Aug 31, 2004 at 08:18:10PM +0100, Luke Kenneth Casson Leighton was heard to remark: > dude, the entire selinux thing is disliked by stacks of debian > maintainers because of the knock-on implications it has. Totally off-topic remark, unrelated to anything, but I'm waiting for somethig to compile :) Every now and then, I look at SELinux, and I get scared away by its complexity. This complexity makes it very hard to audit, and assure oneself that its actually providing any real security, as opposed to the illusion of security. During this email thread, there are references to mysterious rules that neither party in the conversation fully understands; this scares me. Compare this to less complex security provided by e.g. the Linux VServer project. VServer is intended to allow an ISP to pretend they have a rack of 100 cpu's all running linux, when in fact they have just one. The fact that it provides security is a side-effect; but its far simpler, far easier to audit, and allows me to sleep at night. Another example: Way back in the kernel-2.2 timeframe, I hacked on something neat: 'LOMAC': if you came in from a network connection, you lost permission to do almost anything, other than to e.g. webserve. The system was simple, worked well, the kernel patches were easy to audit, you could go home without worrying about priveledge escalation. Compare that to this thread, where we are talking about atomic vs. non-atomic restoration of context for udev-mounted temp file systems. Shudder. This seems to be begging for an exploit to be discovered. Are we sure that SELinux is really on the right track here? --linas