On Monday 10 October 2005 01:11, "Marco d'Itri" <email@example.com> 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
- From: Russell Coker <firstname.lastname@example.org>
- Re: udev
- From: md@Linux.IT (Marco d'Itri)