Re: pid file security
]] Russell Coker | 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. More importantly: systemd _allows_ them to do that, it doesn't require them. From the description of depinit, it sounds like it requires all daemons to be modified. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87ocfqhuiw@qurzaw.linpro.no
Re: pid file security
On Sat, Jun 5, 2010 at 2:26 AM, Russell Coker russ...@coker.com.au wrote: 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. :) it was pure chance: i saw it in advogato recentlog, which flashes by in a blur. 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. yes. it's worth explicitly mentioning that it's a parallel-capable replacement for sysv init, and a bit more besides. it doesn't use inittab, for example. in another project that he did, richard i think even wrote his own /bin/login replacement because he didn't like the ones that were on offer _either_ :) which he then fired off from depinit, via a signal that is i believe generated for extraneous key-presses such as ctrl-alt-delete or alt-left or alt-right; in this way, pressing alt-right fired up another login console. 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 don't honestly know. richard was the complete frigging introverted genius, here, not me :) http://etbe.coker.com.au/2010/05/16/systemd-init/ How does [depinit] prevent processes escaping? reaally don't know. apologies. 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. yes. correct. i believe that depinit can manage / knows about only the services which it initiates, and are under its immediate control, by capturing all (16?) signals of its immediate child processes. 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. excellent. 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? ... no - you're right: it wouldn't. so that would be a solution but again, it would require an application that had that capability [to use notify] - times however many services you wanted to react to, in real-time. so, an sshd-monitoring application would need to be written (in c?) to wait for inotify; an apache2-monitoring application would... etc. etc. however if that functionality was built-in to systemd, just as it is already built-in to depinit, i.e. if the services which were fired off foreground-style by systemd could have their stdin, stdout and stderr redirected to applications/scripts, as specified by command-line options to systemd... 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. that's got my eyebrows raised - how the heck does _that_ work? i'm both surprised and intrigued. ok, darn it - systemd seems to be a really bad name choice: google search comes up with Systeme D, and also systemd on windows?? ok, let's read this: http://etbe.coker.com.au/2010/05/16/systemd-init/ okaaay, riight. so. ah ha. it makes things quicker... by avoiding starting the services _entirely_ :) ok, so systemd is a merging of the functionality of sysv init and also inetd. right. let me think. insights. ok. inetd. usually inetd (and presumably systemd) services have their stdin and stdout redirected to the TCP/UDP ports, and you pass a specific option to the service to tell it that you want that to happen. that leaves stderr available for error/info logging... so yes, systemd could in fact be enhanced to do the same job as depinit [wrt the real-time reacting _without_ having to use polling or inotify]. second: assuming that systemd is _only_ capable of starting up services [as an inetd replacement] via redirecting
Re: pid file security
]] Luke Kenneth Casson Leighton | Does a program that uses inotify to wait for log file changes on disk | experience any delay of note? | | ... no - you're right: it wouldn't. so that would be a solution | but again, it would require an application that had that capability | [to use notify] - times however many services you wanted to react to, | in real-time. so, an sshd-monitoring application would need to be | written (in c?) to wait for inotify; an apache2-monitoring application | would... etc. etc. Like tail(1) which is part of coreutils? | however if that functionality was built-in to systemd, just as it is | already built-in to depinit, i.e. if the services which were fired off | foreground-style by systemd could have their stdin, stdout and stderr | redirected to applications/scripts, as specified by command-line | options to systemd... command line options to systemd doesn't make any sense, it's an init replacement, not a wrapper around single daemons. | 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. | | that's got my eyebrows raised - how the heck does _that_ work? i'm | both surprised and intrigued. | | ok, darn it - systemd seems to be a really bad name choice: google | search comes up with Systeme D, and also systemd on windows?? http://www.freedesktop.org/wiki/Software/systemd is hit number four or five for it on google. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87wrudbti5@qurzaw.linpro.no
Re: pid file security
On Sat, Jun 5, 2010 at 7:59 AM, Luke Kenneth Casson Leighton luke.leigh...@gmail.com wrote: okaaay, riight. so. ah ha. it makes things quicker... by avoiding starting the services _entirely_ :) It goes beyond that. Instead of program A depending on B being done initializing so that it can connect to B's socket, for example, A can be initialized right away and it'll block when it needs to use B's socket until B is done initializing. This is faster because A and B can be started at the same time even though A depends on something provided by B. second: assuming that systemd is _only_ capable of starting up services [as an inetd replacement] via redirecting stdin/stdout to TCP/UDP/other sockets, that still places depinit as being more capable than systemd because you have the option, in depinit, of: * running a service unmonitored i.e. a la sysv init * running a services foreground-connected i.e. auto-restarted etc. Well, systemd does have sysv-like compatibility (in fact it even parses LSB headers and starts sysv scripts in parallel, unlike upstart). I believe that in that mode it does not monitor the processes, but I'm not sure. Now regarding auto-restarting services as they fail, I believe that's at least planned. Since systemd can monitor services with ease, my guess is that auto-restarting shouldn't be a big deal. I'm quite excited about systemd, I think the potential is there. Most mainstream distros have already commited to upstart though, so I can see why it could fail despite looking like a great alternative. Another major issue is lack of cross-platform support, as it depends on Linux specifics such as cgroups, and this is a big drawback for Debian as we have Hurd and kFreeBSD... More info on systemd in this lengthy blog post: http://0pointer.de/blog/projects/systemd.html -- 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/aanlktim-lsngdcjqj8tqulxz7rd4dlu66dvq6kcyg...@mail.gmail.com
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. -- 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/aanlktimphzloqs1kfvzin2_er_z2qffhihhvnpq36...@mail.gmail.com
Re: pid file security
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
Re: pid file security
Stéphane Glondu glo...@debian.org writes: Yves-Alexis Perez a écrit : And you usually need root access for invoke-rc.d or /etc/init.d scripts (unless you have some kind of specific sudo permissions for that). So you might be able to kill other process as well. I guess one (be it a human operator or a monit-like daemon) can be easily fooled into restarting a service without checking. Cheers, If monit, runit, upstart, heartbeat or whatever is used to monitor daemons does call stop+start then it is trivial. You are already the user the daemon runs under (or you wouldn't have write permissions to the pidfile) so just kill it. The next monitor run will then stop the pid you wrote and restart the normal daemon wiping any trace of what you did. MfG Goswin -- 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/87vdb2bw4w@frosties.localdomain
Re: pid file security
On mar., 2010-05-04 at 02:25 -0400, Joey Hess wrote: As security problems go, being able to DOS a system by killing targeted processes, slowly, is not very bad. After all, it could be fork bombed or OOMed just as effectively. Security aside, there's an overall correctness issue: There's the chance that a daemon will unexpectly die, and its PID be reused by an unrelated process, which is later incorrectly stopped. And you usually need root access for invoke-rc.d or /etc/init.d scripts (unless you have some kind of specific sudo permissions for that). So you might be able to kill other process as well. (it's still safer to test though) Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: pid file security
Yves-Alexis Perez a écrit : And you usually need root access for invoke-rc.d or /etc/init.d scripts (unless you have some kind of specific sudo permissions for that). So you might be able to kill other process as well. I guess one (be it a human operator or a monit-like daemon) can be easily fooled into restarting a service without checking. Cheers, -- Stéphane -- 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/4bdfc2ff.5080...@debian.org
Re: pid file security
On Tuesday 04 May 2010 08:25:25 Joey Hess wrote: Take a look in /var/run. Find a pid file that is owned by a non-root user. Now, look at the corresponding init script. What does it stop if that non-root user edited the pid file to contain '1'? The fact that they are not owned by root doesn't mean you can edit them, they would probably be owned by a specific user for that daemon and will not have write access for others. Have you found some with write permissions set to all? Bye -- Salvo Tomaselli -- 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/201005041000.13181.tipos...@tiscali.it
Re: pid file security
On 2010-05-04, Salvo Tomaselli tipos...@tiscali.it wrote: On Tuesday 04 May 2010 08:25:25 Joey Hess wrote: Take a look in /var/run. Find a pid file that is owned by a non-root user. Now, look at the corresponding init script. What does it stop if that non-root user edited the pid file to contain '1'? The fact that they are not owned by root doesn't mean you can edit them, they would probably be owned by a specific user for that daemon and will not have write access for others. So if I trick the daemon to write 1 to that file it's ok? Sure, tricking a program into doing something the admin didn't intend is a bug in itself, still we shouldn't leave that hole open. (Putting the PID file a-w might help with that, though, no?) Kind regards, Philipp Kern -- 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/slrnhtvr9r.m67.tr...@kelgar.0x539.de
Re: pid file security
On Tue, May 04, 2010 at 02:25:25AM -0400, Joey Hess wrote: Take a look in /var/run. Find a pid file that is owned by a non-root user. Now, look at the corresponding init script. What does it stop if that non-root user edited the pid file to contain '1'? On Linux, nothing. From kill(2): The only signals that can be sent to process ID 1, the init process, are those for which init has explicitly installed signal handlers. This is done to assure the system is not brought down accidentally. Nevertheless, this could be a problem with other pids or on kfreebsd, where the kernel will happily kill init and cause a panic. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: pid file security
On Tuesday 04 May 2010 18:14:07 brian m. carlson wrote: Nevertheless, this could be a problem with other pids or on kfreebsd, where the kernel will happily kill init and cause a panic. And the pid could still be set to something else than 1 and bring down something important. -- Salvo Tomaselli -- 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/201005041902.23653.tipos...@tiscali.it
Re: pid file security
On Tue, May 04, 2010 at 07:02:23PM +0200, Salvo Tomaselli wrote: On Tuesday 04 May 2010 18:14:07 brian m. carlson wrote: Nevertheless, this could be a problem with other pids or on kfreebsd, where the kernel will happily kill init and cause a panic. And the pid could still be set to something else than 1 and bring down something important. Which is exactly what I said: this could be a problem with other pids. I understand the implications that Joey was talking about, but I was just pointing out that the particular example he gave was not the best for his argument. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
