Subject: Re: setuid ssh
To: NetBSD Security Technical Discussion List <tech-security@netbsd.org>
From: Andrew Brown <atatat@atatdot.net>
List: tech-security
Date: 10/20/2000 23:54:26
  by mail.netbsd.org with SMTP; 21 Oct 2000 03:54:28 -0000
	by noc.untraceable.net (8.11.1/8.11.1/bonk!) id e9L3sQA09182
	for tech-security@netbsd.org; Fri, 20 Oct 2000 23:54:26 -0400 (EDT)
Date: Fri, 20 Oct 2000 23:54:26 -0400
From: Andrew Brown <atatat@atatdot.net>
To: NetBSD Security Technical Discussion List <tech-security@netbsd.org>
Subject: Re: setuid ssh
Message-ID: <20001020235426.A9139@noc.untraceable.net>
Reply-To: Andrew Brown <atatat@atatdot.net>
References: <20001018135225.A7705@antioche.lip6.fr> <Pine.NEB.4.21.0010181440492.6544-100000@agnostic.union.cynic.net> <20001020182702.E976D4@proven.weird.com> <20001020143456.A4739@noc.untraceable.net> <20001020191842.BE4324@proven.weird.com> <20001020163146.A5721@noc.untraceable.net> <20001021033956.B6EB94@proven.weird.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20001021033956.B6EB94@proven.weird.com>; from woods@weird.com on Fri, Oct 20, 2000 at 11:39:56PM -0400
Return-Receipt-To: receipts@daemon.org

>> then what's wrong with doing *all* things things (yes, both of them)
>> right at the beginning of main, before *anything else*
>> 
>> 	if (geteuid() != getuid() || getegid() != getgid()) {
>> 		do_root_stuff_now();
>> 		setuid(getuid());
>> 		setgid(getgid());
>> 	}
>> 
>> no?  then you *have* the port if you need it, and you *have* the host
>> key if you need it.  of course, they'd both get thrown away as soon as
>> it was known that they weren't needed.
>
>Well, assuming you're careful with what you do with the private host key
>once you're read it in and you're damn sure it can't be revealed through
>any nefarious means (eg. can I attach a debugger to the process once it
>has dropped privileges and then extract the private host key?); and

i dunno...can you?  i don't pretend to know everything about the way
these things work.  can you attach a debugger to a process that was
*at one point* running setuid/setgid?  does the process get (properly)
forever tainted by that?

>provided that you can safely bind to the low-port socket so early on;
>then yes that might be OK.  However there are many things to consider in
>any endeavour concerning setuid programming -- make sure you know all of
>the consequences of all such actions before you go ahead and change
>anything or invent anything new along these lines.

i can only use my imagination.

>I personally worry more about programmers relaxing their scrutiny and
>attention to detail at the same time they relax the privileges on their
>code and as such I would personally be more comfortable if a setuid
>process kept its privileges throughout its execution -- at least this
>way everyone knows to be paranoid all of the time.  This goes double for
>setuid-root code, especially on systems which support the very dangerous
>feature of allowing a setuid-root process to toggle from and then back
>to superuser status.

netbsd doesn't support the feature you speak of.  at least...not out
of the box.  i'm sure it could be made to very easily.

as for processes keeping setuid privileges throughout their entire
execution...i'm not convinced that's a good idea.  it also exposes
them to bugs in libraries they use at that point, making the amount of
code you possibly have to audit that much bigger.  not very helpful.
i'd rather say to myself "i've done that, and no i'm going 'cold'".

>> i'm not talking about modifying anything -- i'm talking about doing it
>> right.
>
>You *were* talking about existing clients, and this part of this thread
>has been explicitly about the OpenSSH variant currently imported into
>the NetBSD tree, and like I said any change along these lines in
>existing code will need to be very carefully audited throughout the
>entire codebase to ensure it doesn't upset any existing assumptions.

i'm talking about ssh clients *in general* and, now, setuid
programming *in general*.  i'm not talking about the way things were
done wrong...i'm talking about the way to do things right.

it's very simple.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."