On Sun, 25 Jul 1999, Pete wrote: > But as for your statement I would prefer a setuid/gid man (to a dedicated > uid and gid) thus *when* your troff is compromised. It will not have the > authority to compromise your system. I agreed entirely with your rant until this point. Making your man programs setuid man does not improve security, only performance due to the caching effect. Let me give an example: because man is setuid to the man uid, the binary must be owned by uid man. As a result, unless the file system is read-only or the immutable bit is used on supporting operating systems, it is writable by the man uid. When you have a trojan man page, the trojaned code runs as uid man, and as such may now modify the man program, etc. If root runs man, it will run the modified man program, and if the man uid is careful to remove the setuid bit from the executable (something it may do as it owns the file) then this new code now runs as root the next time a trojaned man page is executed. All setuid man does is allow a shared cache on man pages, it does not isolate security problems assocated with the man system--any user who runs the man command gives up control of their credentials to any user who can modify the man binary, or trojan a man page. Robert N M Watson robertat_private http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Computing Laboratory at Cambridge University Safeport Network Services
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:53:52 PDT