Re: udev

[Russell Coker <russell@coker.com.au>]

On Monday 10 October 2005 01:11, "Marco d'Itri" <md@linux.it> wrote:
> > Also the udev script is rather complex.  It seems to me that a better
> > option might be to have the /etc/init.d/udev script call a udev setup
> > script (maybe named /sbin/setup_udev) and then start the udevd.
>
> I tought about this, but I think it's still premature because the udev
> init script may still be changed a lot in the close future and I am not
> sure that udevd and /dev management can be cleanly separated anyway.

The method I described is working well in Fedora and has been for a couple of 
releases, as well as Red Hat Enterprise Linux.  I am not suggesting that 
things should be done the "Red Hat way" (if there is such a thing), merely 
pointing out that it's been working well for a while on a large number of 
systems and can be expected to work reasonably well in Debian too.

One thing I didn't mention in my previous message is that splitting the init 
script in the manner I described makes it a little easier to write clear SE 
Linux policy.  I can write policy to match whatever design is devised, but 
how nice the policy is will depend greatly on the design of the code.

> Would it be acceptable for you to discuss this again when we will be
> closer to the release?

Sure.  But I am back-logged on my email, and responses may be delayed - 
particularly if you don't CC me.

> > One of the reasons for not wanting complex init.d scripts is that for SE
> > Linux we don't want to give ultimate access to such scripts.  The udev
> > script does many things such as creating directories and device nodes
> > under /dev which we normally want to restrict as much as possible.
>
> Can you explain better which threat model you are considering?

In this case the aim is to just use minimum privileges for all applications.  
Of course we can just grant the init scripts significant privs on the 
assumption that a process that can exploit such scripts can exploit any 
domain which can be entered from initrc_t via a script (a correct assumption 
although it is a little fiddly and inconvenient to do).  But restricting the 
access of the init scripts makes exploiting such scripts a little more 
difficult (NB such scripts often use data created by untrusted sources) and 
also encourages a good design of such scripts.

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