by mail.netbsd.org with SMTP; 20 Oct 2000 16:56:14 -0000
	by wombat.cs.rmit.edu.au (8.9.3/8.9.3/cshub) id DAA10418
	for tech-security@netbsd.org; Sat, 21 Oct 2000 03:56:10 +1100 (EST)
Approved: eat-raw-chocolate
  by mail.netbsd.org with SMTP; 19 Oct 2000 12:40:52 -0000
	by platonic.cynic.net (Postfix) with ESMTP
	id 50A315D13; Thu, 19 Oct 2000 08:40:48 -0400 (EDT)
Date: Thu, 19 Oct 2000 08:40:47 -0400 (EDT)
From: Curt Sampson <cjs@cynic.net>
To: tech-security@netbsd.org
Cc: Hubert Feyrer <hubert.feyrer@informatik.fh-regensburg.de>,
        Manuel Bouyer <bouyer@antioche.lip6.fr>,
        Andrew Brown <atatat@atatdot.net>, Jason R Thorpe <thorpej@zembu.com>
Subject: Re: setuid ssh
In-Reply-To: <20001018135225.A7705@antioche.lip6.fr>
Message-ID: <Pine.NEB.4.21.0010181440492.6544-100000@agnostic.union.cynic.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Jason Thorpe wrote:

> Yes, and I'm particularly annoyed that the change to de-setuid ssh
> was made without any discussion.

It was discussed a with a couple of developers in person, and with
more on ICB, and there seemed to be a strong agreement that this
should be done. It wasn't a completely random out of the blue thing.

And certainly if my little poll was wrong, we can back out the
change; it's not the end of the world. But I seem to be seeing
support for this change here, as well.

Jason Thorpe wrote:

> PLEASE back out the change that de-setuid's ssh -- some people really
> do use rhosts/rsa authentication legitimately.

Manuel Bouyer wrote:

> And then ? This can be disabled in the config file.
> I do use rhosts with ssh

I know that people use rhosts with ssh. If you do this, you can
turn on the setuid bit just as easily as I could change the config
file. But the standard practice for NetBSD appears to me to be to
ship in a more secure configuration by default. If we're going to
go the other way, you could argue that people do legitimately use
rsh and thus we should leave shell and login services enabled by
default in inetd.conf.

Andrew Brown writes:

> >for backups, you can create a passphraseless trusted key in
> >~backup/.ssh and get roughly the same security properties without
> >requiring the ssh client to be setuid.
> 
> as long as you don't copy that key anywhere.  sure, that key can
> *only* be used to log into the backup server, but from *anywhere*.

If you don't like that property, than don't allow that key to be
used from anywhere. You just need to put `from="foo.bar.com"' in
front of the key in authorized_hosts. I have scripts that allow a
fairly secure backup to be done to a remote host that trusts the
one sending the backup only to write a new file (not overwrite
current files) in a certain directory; e-mail me if you want details
on this. As far as I can tell, the worst attack that it's open to
is a DOS attack that fills up that partition.

And finally, Jason writes again:

> Fine, you can maintain a local hack to support your broken setup,
> but for goodness sake, don't commit such nonsense to the master
> sources....

Jason, this is nonsense only to those who is are completely fucking
cluless about networking security and shouldn't be allowed to plug in
a 10base-T cable, much less operate a computer.

Now, can we stop with the ad-hominem attacks and stick to discussing
the merits of the idea?

cjs
-- 
Curt Sampson  <cjs@cynic.net>  917 532 4208   de gustibus, aut bene aut nihil

She saw that he had singled her out from the three...for no reasoned purpose
of further acquaintance, but in commonplace obedience to conjunctive orders
from headquarters, unconsciously received by unfortunate men when the last
intention of their lives is to be occupied with the feminine.