Re: pid file security
On Sat, 5 Jun 2010, Luke Kenneth Casson Leighton <firstname.lastname@example.org>
> apologies for butting-in without being able to continue the thread,
> but i've just seen this:
> which links to this:
You're quick. I had planned to announce my blog post on this list but forgot
before I went to bed last night. For reference the above URL is the best one
for my blog post as it allows you to enter comments.
> 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.
The above URL is one place to download depinit. It's an init replacement that
uses configuration files to give the details of services to start.
> 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.
How does it do that? Does it ptrace them?
> 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.
How does it prevent processes escaping? Does it use cgroups as systemd does?
See the above URL for some of my thoughts about systemd.
> richard also solved the security PID problem ... by doing away with
> the need for the PID file.
That doesn't do away with the need for arbitrary programs to kill other
arbitrary programs and not make a mistake about which program they are
> 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.
systemd does all that.
> 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
Does a program that uses inotify to wait for log file changes on disk
experience any delay of note?
> 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.
The systemd option of creating sockets before executing services that listen
to them seems to offer the potential of more significant boot performance
benefits than just starting things in parallel.
http://etbe.coker.com.au/ My Main Blog
http://doc.coker.com.au/ My Documents Blog