CIFS Unix Extensions UIDs and client permission checking

[Andrew Bartlett]

On Sun, 2004-07-18 at 08:37, Simo Sorce wrote:
> On Sat, 2004-07-17 at 18:40, Steve French wrote:
> 
> > Does this logic seem correct?  Obviously this could be improved somewhat 
> > if the CIFS Unix/Linux extensions are extended - e.g. we optionally 
> > could pass the client process's effective uid/gid to the server (so the 
> > server had all of the info it needed to do the real permission check) 
> > and if the server trusted the client and if signing were enabled (so the 
> > uid/gid could not be changed on the wire by a man in the middle).
> 
> I would object this behavior as default.
> One of the biggest problems with NFS is the trust you need between
> server and client. Trusting the client put all your network at the same
> security level. Compromising a single client will potentially allow you
> to access any file on the server just by providing 0/0 as uid/gid (No,
> denying the 0/0 access is not enough other uids/gids may have access to
> sensible data anyway).
> 
> We could think of permitting such a behavior optionally but the best
> thing would be to do a new Session Setup for each user accessing the
> system.
> 
> Providing means to signal user space from the kernel so that when a new
> user access a file system mounted by another would be a very nice
> addition. That way a helper would be able to be called and the user
> prompted for a username/password pair.

I strongly agree with simo.  I don't think that we should compromise the
user-level security of CIFS in this case.

I think that by default, the permissions on the client should *appear*
to be those reported on the server, but that only the UID that mounted
the FS should have access, by default.

Access for alternate uids may either be specified on the command line (a
public' parameter), or they may make a suitable call into the kernel, to
supply a username/password for that uid.  This would perform a session
setup, and start the use of a new vuid on the connection.

We should look carefully at how things like AFS work - they have looked
at this problem for much longer than we have :-)

Andrew Bartlett
-------------- 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 : http://lists.samba.org/archive/samba-technical/attachments/20040718/d39c8e12/attachment.bin