[RFC/PATCH] cifs.upcall: use kernel.provided principal name if available
jlayton at samba.org
Wed Sep 7 07:03:21 MDT 2011
On Wed, 07 Sep 2011 11:46:23 +0200
Martin Wilck <martin.wilck at ts.fujitsu.com> wrote:
> Hi Jeff,
> thanks for reviewing this.
> > I'm not opposed to adding this with appropriate warnings about the
> > danger involved.
> > Trusting the SPN provided in the NEGOTIATE response waters down much of
> > the security that Kerberos provides. Granted, cifs doesn't currently do
> > mutual auth, but if it did, using this would make it pretty useless.
> Please help me understand - is this functionality any different from
> smbclient's? If yes, what do I need to change? If no, smbclient users
> will suffer from the same security risk (I see that a mounted file
> system is a higher risk than a process like smbclient).
> Is there any way to do this more securely?
> > It would probably be a good idea to clearly warn that an attacker can
> > use this in order to trick the client into mounting a server of his
> > choosing (providing he can redirect the traffic to that server too).
> I'm will happily add a warning if you tell me where you'd like to have
> it - in the man page, or in the kernel logs, or in the cifs.upcall log?
(re-cc'ing linux-cifs and cc'ing samba-technical)
We've discussed this on the list many times before, but the most
comprehensive discussion is here. I recommend reading over that as it
explains the problems in detail:
Really, the best answer is not to rely on this. Windows clients never
have, and recent windows servers don't even populate the field.
smbclient does, but support for that was added long ago. It should
probably be removed as Andrew suggested in the above thread, or
perhaps made conditional on a new smb.conf option that defaults to
Jeff Layton <jlayton at samba.org>
More information about the samba-technical