From owner-freebsd-hackers Mon Feb 24 20:28:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA20252 for hackers-outgoing; Mon, 24 Feb 1997 20:28:10 -0800 (PST) Received: from spinner.DIALix.COM (spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA19938; Mon, 24 Feb 1997 20:21:59 -0800 (PST) Received: from spinner.DIALix.COM (localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.5/8.8.5) with ESMTP id MAA23422; Tue, 25 Feb 1997 12:15:43 +0800 (WST) Message-Id: <199702250415.MAA23422@spinner.DIALix.COM> X-Mailer: exmh version 2.0gamma 1/27/96 To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: jehamby@lightside.com (Jake Hamby), abelits@phobos.illtel.denver.co.us, angio@aros.net, hackers@freebsd.org, auditors@freebsd.org Subject: Re: disallow setuid root shells? In-reply-to: Your message of "Tue, 25 Feb 1997 00:51:45 +0100." Date: Tue, 25 Feb 1997 12:15:42 +0800 From: Peter Wemm Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk J Wunsch wrote: > As Jake Hamby wrote: > > > My sentiments exactly! I would think that if there was a valid > > reason for setuid root shells, then a commercial OS like Solaris > > would probably allow them (since paying customers often would rather > > have functionality than security!). > > You think that's the reason why Solaris indeed allows it? :-) They are reasonably secure on solaris when the script writer knows what they are doing. Solaris uses /dev/fd/xxx when running setuid interpreted scripts, so it's not vulnerable to symlink races etc. The -p on /bin/sh is to use /etc/suid_profile rather than ~/.profile and to allow suid execution to continue. ksh doesn't require -p to be specified, it detects uid != euid and turns it on automatically. It has the same effect as -p in /bin/sh. In ksh however, you can turn off the 'p' option and ksh will revoke it's setuid right then. The way secure execution works is that the kernel opens the file in the process's context, so it's available on (eg) /dev/fd/3. It then checks the suid/etc stuff. If all is ok, it runs "/bin/sh /dev/fd/3 ". The race is solved, but $0 looks a bit strange to the script because the shell doesn't know the real name of the script. All that's required then for a reasonably secure script is explicitly setting IFS on the first line of the script, and extreme caution. > -- > cheers, J"org > > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE > Never trust an operating system you don't have sources for. ;-) Cheers, -Peter