Re: pid file security
On Sat, Jun 5, 2010 at 2:26 AM, Russell Coker <russell@coker.com.au> wrote:
> On Sat, 5 Jun 2010, Luke Kenneth Casson Leighton <luke.leighton@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 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.
not sure about using depinit as an inetd replacement: i never got
round to asking richard about that, as i never did need to run any
services from it.
l.
Reply to: