/sbin/service and /usr/sbin/run_init

[Russell Coker]

On Wed, 7 Apr 2004 04:17, Gene Czarcinski <gene at czarc.net> wrote:
> On Tuesday 06 April 2004 14:07, Daniel J Walsh wrote:
> > No we found that using run_init was far too confusing, so we added auto
> > transition rules
> > so sysadm, or rpm  are allowed to transition initrc programs to their
> > proper state.
> >
> > There is a tunable to turn this off if you want to go back to using
> > run_init, I believe.
>
> No, no!  In fact, do you need run_init at all?

That depends on what your aims are.

Some daemons require write access to a terminal to allow them to start 
correctly, other daemons will start without terminal access but display 
useful error messages to stdout if it's available.

It's generally not desirable to permit all daemons to access the administrator 
tty all the time (if a daemon has { read write ioctl } access to an admin tty 
then it shouldn't be difficult for an attacker who takes over the daemon to 
then take over the entire system).

In Debian I made run_init open a new pty for the daemon start process so that 
the daemon could be permitted to write startup messages and afterwards the 
master end of the pty would be closed denying the daemon any access to do bad 
things.  I have concluded that this isn't the ideal way of doing it as there 
are some problems with signals in the case where the parent exits before the 
child (the actual daemon process) closes it's tty.

I think that the best way of doing this for strong security is to have 
run_init relabel it's controlling tty before spawning the daemon, and then 
label it back after the child exits.

Something like this will probably end up in RHEL, although it will be 
optional.

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