Re: pid file security
apologies for butting-in without being able to continue the thread,
but i've just seen this:
http://advogato.org/person/etbe/diary/779.html
which links to this:
http://lists.debian.org/debian-devel/2010/05/msg00067.html
can i please gently remind people that depinit solved the security and
fork-bombing issues years ago. i do keep mentioning depinit, on
debian lists, but there is typically absolutely zero response, which i
do not understand. nevertheless, as a debian and free software
advocate i feel compelled to keep pointing people at solutions: it's
up to you to investigate them.
depinit solved the fork-bombing issue because richard lightman was
concerned about attacks on his internet-facing system. richard added
code which actively tracks child signals (depinit is highly unusual
and innovative in that it catches ALL signals, and can therefore react
_to_ any signal) and analyses the timing etc. and provides a means to
trigger arbitrary "scripts" based on the signal type.
i recall a discussion with richard back in 2004/5 where he said that
when depinit is asked to stop a dependency/service, it does so by
first sending "graceful" signals, then goes on to take increasingly
aggressive action, including deciding, based on child-fork-bombing,
that a service has been corrupted and thus needs to be terminated with
extreme prejudice.
richard also solved the security PID problem ... by doing away with
the need for the PID file. in other words, a service is _always_ run
in "foreground" mode. if it dies (i.e. a segfault signal is caught),
the service is restarted automatically - by depinit (based on the
signal alone). thus, the need for safe_mysql goes away entirely; the
need for "apache2ctl start" goes away (i.e. you use apache2 -c
FOREGROUND=True or whatever it is) and so on. in this way, there
simply _is_ no need for a PID file, period. the relevant state
information is contained within depinit itself, and you can guarantee
that depinit will catch the signal.
one additional incredibly useful action of this "foregrounding"
approach to services was that he added the means to connect dependent
services via pipes, between their stdin and stdout.
the advantage of the entire services approach that richard took in
depinit is phenomenal: richard created dependent services where in
real-time you could script sshd's stdout (logging output) into
_another_ service, which was a shell-script that analysed the contents
and looked for "unauthorised login" attempts. more than three of
those occurring within a specified time, and iptables would be called
to block that user's IP address. voila: no delays due to syslog
polling: instant and real-time attacker blocking, all using simple
shell scripts. [the alternative - continuous polling and reading of
syslog entries - is just utterly messy, results in potential delays,
and requires that each and every "polling" program written for a
particular service understand the concept of syslog, how to read it,
how to read the last entries etc. etc. just... messy.]
so i feel compelled to point these things out, along with the other
incredible benefits that depinit brings including _massive_ reductions
in startup time (25 seconds on a 1.5ghz Pentium 4 when debian was
doing about 90 at the time), and phenomenal near-unbelievable
improvements in shutdown time (2 seconds on a 1.5ghz Pentium 4 when
debian was doing about 60 at the time), as it pains me to see depinit
being totally ignored and these security and painful issues being
discussed _years_ after a solution has already been done, and proven
to be effective.
you are welcome to contact me and discuss this further, if i can
remember any of the details i will be glad to describe them, and if
necessary go dig out the depinit scripts that i created for a KDE
debian desktop system, 4 years ago. which included solving the
udevsettle massive delay problems, by parallelising them and working
out the dependencies for critical startup services.
l.
Reply to: