Re: Signal security

Pavel Machek (
Wed, 20 May 1998 11:36:03 +0200


> > Consider user running passwd, waiting to just right moment, and then
> > killing passwd with SIGKILL (which it can not block). There even was
> That is harmless. passwd uses rename() as it must be atomic. The off switch
> and sigkill are not dissimilar issues.

They are: I can produce 1000 sigkills per second (probably) to exploit
race condition without anyone noticing. Turning machine off and on
1000 times would take pretty long time to do. Also, you can remove
stale locks at bootup. If I kill someone with sigkill, lock will be
there for sure, and unless they play PID tricks, they will not notice.

> > BSD solved by only allowing you to send certain signals (that
> > generated from keyboard) to programs with different euid but same real
> > uid.
> It doesnt work. I can still generate SIGIO arbitarily for one. Work out what
> you are trying to achieve first of all. If it is to provide totally safe
> areas of code then you are probably doing the wrong thing, hardware and
> off switches must be allowed for.

SIGKILL is really something different from power-off. Consider X
server: turning off while X server is running is harmless as machine
has to restart, anyway. Killing X server with SIGKILL is not harmless:
you make console unusable and you force root to reboot sometimes.

> Various people have bounced around some ideas. There is certainly a possible
> case for a sigblockmask for signals from setuid tasks. However it is nothing
> like as trivial an argument as it may appear from random bits of bugtraq.

Ok: is there some problem with disallowing just SIGKILL for suid case?


The best software in life is free (not shareware)!		Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to