Messages in this thread | | | Date | Wed, 20 May 1998 11:36:03 +0200 | From | Pavel Machek <> | Subject | Re: Signal security |
| |
Hi!
> > 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?
Pavel
-- 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 majordomo@vger.rutgers.edu
| |