Best choice for ntlm_auth's access to winbindd_privileged directory

Andrew Bartlett abartlet at
Thu Sep 14 22:27:33 GMT 2006

On Fri, 2006-09-15 at 00:21 +0200, Henrik Nordstrom wrote:
> fre 2006-09-15 klockan 07:46 +1000 skrev Andrew Bartlett:
> > No, it is not.  The binary does not enforce any more security control
> > over the critical point (being able to specify the challenge) than the
> > raw socket does.
> Perhaps it should?
> What do you think about refusing those explicitly keyed operations when
> sgid (egid != gid), allowing for ntlm_auth setgid to kind of publish the
> challenge/response authentication mechanisms in a reasonable manner to
> the whole system without having to move the challenge generation to
> winbind?
> Is there any other more serious rights the privileged pipe to winbind
> gives? Just trying to assess what the risk may be in opening for
> possible privilege escalation bugs in ntlm_auth by having it setgid for
> everyone.. but I have a feeling it will generally be less than todays
> setup to be honest..  (privilege escalation into service accounts often
> isn't that hard..)

Yeah, we could have another binary, restricted to just the server-side
NTLMSSP protocols, but not returning the keys.  

However, this would not help the SASL case much, as there we actually
want to do signing and sealing (I'm trying to convince kblin to do that
with his NTLMSSP code).

Andrew Bartlett

Andrew Bartlett                      
Authentication Developer, Samba Team 
Samba Developer, Red Hat Inc.        
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url :

More information about the samba-technical mailing list