> The key word is "should" draw attention. Unless there is an > application (or the system itself) that periodically checks for any > change in status of a system daemon (like the change of a PID), I > suspect that most sysadmins will not even notice that a system daemon > has died and restarted. To help plug this vulnerability one of the > following options might be desirable, Many sysadmins in control of operating systems which have the immutable/no-unlink flags don't use those flags at all. > following options might be desirable, > > 1. Disallow sending signals to processes started from immutable > binaries, > except from init, e.g. during shutdown. > Advantage: Improved security. > Disadvantages: Administration may be virtually impossible and may > break > existing applicaitons. While I agree that the signal issue is very messy, I don't think this is a good idea. The obvious reasons include being able to keep a handle on an out-of-control process. This would also be a great help to an intruder who doesn't like his/her processes being killed. > 1a. A variation of #1 except using a new "unkillable" flag which denotes > immutable binaries that cannot be sent signals. Same problems. [...] > 3. Replicate the immutable flag when a file is copied. > Advantage: Some improved security. > Disadvantage: Intruder can FTP a rogue daemon and run it instead. Reliably implementing this would be impossible. The system has no real way of knowing whether or not a file is being opened for the purpose of its duplication, and making guesses at that could just lead to big problems. -- cstone <cstoneat_private> <abcat_private>
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:57:53 PDT