On Wed, 7 Apr 2004 04:17, Gene Czarcinski <gene@xxxxxxxxx> 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
