Fedora and udev

[Russell Coker]

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

[Alexandre Oliva]

On Aug 22, 2004, Russell Coker <russell(a)coker.com.au&gt; 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(a){redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva(a){lsd.ic.unicamp.br, gnu.org}

[Luke Kenneth Casson Leighton]

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.

[Dennis Gilmore]

Once upon a time Sunday 22 August 2004 9:00 am, Alexandre Oliva wrote:
>  On Aug 22, 2004, Russell Coker <russell(a)coker.com.au&gt; 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

[Joshua Brindle]

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?
>
>   
>

[Joshua Brindle]

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 <file:Documentation/filesystems/tmpfs.txt> 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
> +	  <http://acl.bestbits.at/> 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 <linux/string.h>
>  #include <linux/smp_lock.h>
>  #include <linux/backing-dev.h>
> +#include "xattr.h"
>  
>  #include <asm/uaccess.h>
>  
> @@ -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 <asm/div64.h>
>  #include <asm/pgtable.h>
>  
> +#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 <linux/init.h>
> #include <linux/fs.h>
> #include <linux/slab.h>
> #include <linux/string.h>
> #include <asm/semaphore.h>
> #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<RAMFS_XATTR_INDEX_MAX; 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<RAMFS_XATTR_INDEX_MAX; 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<RAMFS_XATTR_INDEX_MAX; 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 <linux/module.h>
> #include <linux/string.h>
> #include <linux/fs.h>
> #include <linux/security.h>
> #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 <selinux/selinux.h>
> +#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 ; \
>   
>

[Luke Kenneth Casson Leighton]

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?
>  >>   
>  >>

[Luke Kenneth Casson Leighton]

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.

[Russell Coker]

On Mon, 23 Aug 2004 00:00, Alexandre Oliva <aoliva(a)redhat.com&gt; wrote:
>  On Aug 22, 2004, Russell Coker <russell(a)coker.com.au&gt; 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

[James Morris]

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
<jmorris(a)redhat.com&gt;

[W. Michael Petullo]

> > 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

[James Morris]

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
<jmorris(a)redhat.com&gt;

[Luke Kenneth Casson Leighton]

On Mon, Aug 23, 2004 at 12:09:01PM +1000, Russell Coker wrote:
>  On Mon, 23 Aug 2004 00:00, Alexandre Oliva <aoliva(a)redhat.com&gt;
> wrote:
>  > On Aug 22, 2004, Russell Coker <russell(a)coker.com.au&gt; 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.

[Luke Kenneth Casson Leighton]

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.

[Stephen Smalley]

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 <sds(a)epoch.ncsc.mil&gt;
National Security Agency

[Jeremy Katz]

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

[Brian May]

> >>>> "Luke" == Luke Kenneth Casson Leighton
> <lkcl(a)lkcl.net&gt; 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 <bam(a)snoopy.apana.org.au&gt;

[Greg KH]

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

[Joshua Brindle]

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

[Greg KH]

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

[Russell Coker]

On Tue, 24 Aug 2004 04:49, Jeremy Katz <katzj(a)redhat.com&gt; 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

[Florian La Roche]

On Tue, Aug 24, 2004 at 05:25:07PM +1000, Russell Coker wrote:
>  On Tue, 24 Aug 2004 04:49, Jeremy Katz <katzj(a)redhat.com&gt;
> 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

[Luke Kenneth Casson Leighton]

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.
--
<a href="http://lkcl.net">      lkcl.net      </a> <br />
<a href="mailto:[e-mail]"> lkcl(a)lkcl.net </a> <br />

[Luke Kenneth Casson Leighton]

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.
--
<a href="http://lkcl.net">      lkcl.net      </a> <br />
<a href="mailto:[e-mail]"> lkcl(a)lkcl.net </a> <br />

[Luke Kenneth Casson Leighton]

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.

[Russell Coker]

On Tue, 24 Aug 2004 19:28, Luke Kenneth Casson Leighton <lkcl(a)lkcl.net&gt; 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

[Stephen Smalley]

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 <sds(a)epoch.ncsc.mil&gt;
National Security Agency

[Luke Kenneth Casson Leighton]

On Tue, Aug 24, 2004 at 08:06:41PM +1000, Russell Coker wrote:
>  On Tue, 24 Aug 2004 19:28, Luke Kenneth Casson Leighton
> <lkcl(a)lkcl.net&gt; 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 :)

[Luke Kenneth Casson Leighton]

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 <lkcl(a)lkcl.net&gt;
> 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.

[Greg KH]

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

[Luke Kenneth Casson Leighton]

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.

[Daniel J Walsh]

Rewritten patch.

Dan