On Thu Aug 01, 2002 at 09:04:33PM +0200, Han wrote:

> > > that means that sshd in  default  installation  has  large  bug.  If
> > > privsep results in complete user lockout, then _PLEASE_  disable  it
> > > by default.
> >
> > There are some little quirks with privsep and pam due to  how  privsep
> > tries to do the authentication as a non-root user. As soon  as  a  new
> > openssh comes out that fixes this, it will go into  updates  all  over
> > the place.
> 
> The OpenSSH team stated in a message  that  they  were  having  lots  of
> problems with all the different versions of pam. I  think  it  would  be
> wise to to provide a pam-version that gives the OpenSSH team  the  least
> headaches. Or rather to take that also in account when working on pam.

Right.  But which pam version do we use as a basis?  openssh has a
responsibility to make it work with every pam out there, whether it be
for Linux, Solaris, or whatever.  That's the whole point of "portable"
openssh.

I wouldn't say they had this responsibility if they hadn't forced
privsep on everyone.  For them to do so without proper compatability
is irresponsible.  They more or less forced all vendors to upgrade to
their privsep-enabled/pam-broken openssh because of a bug that could
be circumvented quite easily (ie. disabling a few things, no
problems).  Instead, they introduced something that isn't 100% and is
causing problems for more people than just those using Mandrake.

> > I'm not comfortable with disabling privsep for a few reasons. For one,
> > it is extremely valuable... it's (to me) an essential feature. And not
> > everyone does password aging (which is the problem here).
> 
> I am sure privsep has much more impact than you can achieve by enforcing
> password aging.

Oh, I'm sure there is.  privsep has not had enough testing to be 100%
yet... pam is just the most obvious.  I'm sure there are others (IIRC,
reverse-resolution DNS lookups is also a problem).  I read the openssh
list and there are a *lot* of problems with 3.4p1; not all of them are
privsep related, but there are a lot of problems.

> > [snip]
> >
> > As well, considering how badly the openbsd/openssh teams  are  fscking
> > things  up  these  days,  I  think  having  privsep  there  is  almost
> > essential.
> 
> Not refering to: 
> 
>   http://slashdot.org/articles/02/08/01/129228.shtml?tid=172

Why not refer to this?  Is not the openbsd FTP site running on
openbsd?  I'm sure I'm not the only person who assumed that openbsd
was supposed to be secure.  Hell, I feel sorry for those people who
chose to use openbsd because if it's apparently much-more-secure base
system.  In the last few months there has been ongoing proof that
openbsd is not as secure as it claims.  I think a well-secured Linux
system can be just as secure as openbsd, considering a remote hole in
openssh (installed default), and now their FTP site being penetrated
for a trojan.  What more evidence do you want that openbsd is not the
be-all and end-all of OS security?

But this doesn't have much to do with openssh other than to prove a
point:  mistakes have been made, and increasingly so with the
open{bsd,ssh} teams lately.

> But for the rest the OpenSSH team are finding  bugs.  They  were  always
> there and they remove  them  and  tell  everybody  that  they  did  find
> something. Anyway you don't sound like someone who knows all the  facts,
> more like someone who has heard something.

Right.  You tell me I don't know all the facts yet you don't provide
any illustration that what I've said is not factual.

Is openbsd not as secure as has been previously reported?  No it's
not.  Fact.

Does openssh not play well with PAM?  No, it does not.  Fact.

Did the openssh team force an upgrade path to a version that was known
not to work in the same way as previous versions because of an
undisclosed remote root vulnerability that could have been avoided by
changing a few options in the configuration?  Yes, they did.  Fact.

What more do you want?

-- 
MandrakeSoft Security; http://www.mandrakesecure.net/
"lynx -source http://www.freezer-burn.org/bios/vdanen.gpg | gpg --import"
{GnuPG: 1024D/FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7  66F9 2043 D0E5 FE6F 2AFD}

Attachment: msg69756/pgp00000.pgp
Description: PGP signature

Reply via email to