On Sat, 5 Jun 2010, Luke Kenneth Casson Leighton <luke.leigh...@gmail.com> wrote: > 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
http://etbe.coker.com.au/2010/06/04/securely-killing-processes/ 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. http://sourceforge.net/projects/depinit/ 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. http://etbe.coker.com.au/2010/05/16/systemd-init/ 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 killing. > 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. -- russ...@coker.com.au http://etbe.coker.com.au/ My Main Blog http://doc.coker.com.au/ My Documents Blog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201006051226.24353.russ...@coker.com.au