On Monday 10 October 2005 01:11, "Marco d'Itri" <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
