Re: [idea] udev + selinux

[Luke Kenneth Casson Leighton <lkcl@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.




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel