Fedora and udev

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