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'?
I surveyed 20-odd daemons, and found 5 with this problem. This is
a pity, because start-stop-daemon has been able to guard against this
problem since its inception, by using the --exec or --name switches to
ensure that the process it stops is actually the daemon in question.
Of the scripts surveyed, one used start-stop-daemon without either
switch; others used things like pidofproc from the LSB init functions,
which does not do such checks, or asked the daemon to kill itself, and
it didn't check.
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.
There is room for improvement here; perhaps the developer's reference
should document best practices of using start-stop-daemon --stop --exec
see shy jo, who has the feeling he wrote something similar a decade ago, *sigh*
05-04-2010, 07:39 AM
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.