Date: Mon, 24 Feb 1997 14:20:08 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: espel@llaic.univ-bpclermont.fr (Roger Espel Llima) Cc: hackers@freefall.freebsd.org Subject: Re: disabling setuid sh/csh Message-ID: <199702242120.OAA25018@phaeton.artisoft.com> In-Reply-To: <199702242002.MAA12861@freefall.freebsd.org> from "Roger Espel Llima" at Feb 24, 97 09:02:08 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Real security problems should be fixed; things that make it "a little > harder" (read, take 10 seconds more) to break security, without changing > at all whether it's possible or not, should stay on the lax side. I agree. SUID programs, even shells, are easy to catch with an audit. What's harder is hacked /usr/bin/passwd, /usr/bin/login, /sbin/init, /usr/libexec/telnetd, /usr/libexec/rlogind, etc. with the date set back. I personally built an assimilation bacterium: it hooked its code in place of an executable, and put the executable in data, then tried to "infect" other writeable executables as a background task to extracting the data and running the requested executable. When it got a priviledged account, it hooked passwd, and then started removing itself each time it was run after it saw itself on passwd. Eventually, you have the same system with passwd hacked. The intent of the particular bacterium was to compress executables, but the assimilation mechaism could easily be used for breaching a system. If you were serious, you'd set all suid files to be immutable except in single user mode, and all non-suid executables that run as root from inetd or cron or whatever, etc.. You might even want to attribute files so that the only files that had the "can execute" attribute bit are those which were set that way after close by the linker (which would have to be suid to do the job). If you were paranoid, any command that could ever be even potentially run by root would need to be immutable as well, since it could write a password entry or startup yp to allow remote password exposure... etc.. Better to just burn your whole system onto ROM, I suppose... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702242120.OAA25018>