SYSKEY2. Request For Comments

[Luke Kenneth Casson Leighton]

On Tue, 8 Feb 2000, Phil Mayers wrote:

> Hmm. Interesting point which I hadn't considered. For LDAP I would say
> that the entry really ought to be ACL'd anyhow (they are here at my
> site) which is similar to having a seperate password-protected database
> file. Hmm. NIS and SQL I don't know about though.

and if you don't _have_ acls in your ldap implementation?  or if you don't
_realiase_ that ldap doesn't have any security?

i don't want administrators bitching that their passwords were sent
in-the-clear, and thinking it's our fault.

i don't want a security report on bugtraq, either, bitching that we didn't
document that passwords are sent in-the-clear for ldap / samba

or mysql / samba.



 
> Cheers,
> Phil
> 
> Luke Kenneth Casson Leighton wrote:
> > 
> > On Mon, 7 Feb 2000 jeremy at valinux.com wrote:
> > 
> > > >
> > > > phil, this isn't about root being trusted or untrusted.  it's about making
> > > > sure that only root can decode a password stored in a location in a
> > > > publicly accessible file.
> > > >
> > > >
> > > > On Sat, 5 Feb 2000, Phil Mayers wrote:
> > > >
> > > > > I'm afraid I agree. If you don't trust root, then you're screwed. If
> > > > > someones get a root shell on the machine, you're deader than courdroy.
> > > > > They can essentially do anything, hence it adds no real security, just
> > > > > puts another step in the way.
> > >
> > > But passwords should *never* be stored in a publicly accessible
> > > file - not even obfuscated !
> > 
> > for, say, ldap, which is publicly accessible, we don't have any choice.
> > 
> > > Luke - just because NT does it doesn't mean it is a good
> > > idea. Don't code this up. If you do it'll be a waste of
> > > your efforts as it will not go into a stable release.
> > 
> > jeremy, that's silly.
> > 
> > if this was only a matter of local-filesystem-based password storage, i
> > wouldn't bother, or i would be pushing the off-line storage of syskey
> > more.
> > 
> > but it's not.  think.  ldap.  sql.  nis+.  we can't trust them, and
> > they're all publicly accessible network protocols.
> > 
> > 
> > > If the key is stored off machine in some way then that's a
> > > different matter, as that actually does add some security.
> > 
> > that is one option.
> > 
> > > It would, however, mean that human intervention is needed
> > > to restart Samba on a machine. Every time (no unattended boots).
> > 
> > yes. for those people prepared to pay that price, fine.
> 

<a href="mailto:lkcl at samba.org"   > Luke Kenneth Casson Leighton    </a>
<a href="http://www.cb1.com/~lkcl"> Samba and Network Development   </a>
<a href="http://samba.org"        > Samba Web site                  </a>
<a href="http://www.iss.net"      > Internet Security Systems, Inc. </a>
<a href="http://mcp.com"          > Macmillan Technical Publishing  </a>

 ISBN1578701503 DCE/RPC over SMB: Samba and Windows NT Domain Internals