cifs multiuser mode and per session treatment

cifs multiuser mode and per session treatment

[Björn JACKE]

Hi,

I'm trying to use cifs vfs with multiuser mode in a way, that it's not possible
for people with root privileges to hijack other users' SMB sessions of a
multiuser mount.

For authentication I use krb5. The first problem to solve is that root users
can access the ccache files of any user who is authenticated and has a
/tmp/krb5cc_%{uid} file. This problem can be solved with a ccache type of
session keyring (default_ccache_name = KEYRING:session:%{uid} in krb5.conf).
This is doing exactly what I expect, you can get a ticket but if you log in to
the server once more you will not have that ccache and thus also other users
logging in and trying to "su" to a different user will not have access to the
keyring of the user.

cifs.upcall might need some tuning to make use of a session keyring but even if
that would be done, there is still one important limitation left to solve: cifs
multiuser SMB connections should also be initiated per session, same like the
keyring. Currently the cifs SMB connections are accessible also from other all
sessions.

For example if I kinit a ticket, access a multiuser cifs mount successfully (so
that the smb session is initiated), then kdestroy my ticket, log in to the
machine again to open a new session, and then access the multiuser cifs mount
from there, this is currently successful. For a cifs multiuser mount with per
session limitation, this access should be denied accordingly.

What do you cifs vfs experts think about adding such a "per session" mode for
the multiuser mode?

Thanks
Björn

Re: cifs multiuser mode and per session treatment

[Aurélien Aptel]

Hi Björn,

Björn JACKE <bj@SerNet.DE> writes:
> cifs.upcall might need some tuning to make use of a session keyring but even if
> that would be done, there is still one important limitation left to solve: cifs

IIRC cifs.upcall uses the session keyring already. 

> multiuser SMB connections should also be initiated per session, same like the
> keyring. Currently the cifs SMB connections are accessible also from other all
> sessions.

That needs to be implemented indeed.

> For example if I kinit a ticket, access a multiuser cifs mount successfully (so
> that the smb session is initiated), then kdestroy my ticket, log in to the
> machine again to open a new session, and then access the multiuser cifs mount
> from there, this is currently successful. For a cifs multiuser mount with per
> session limitation, this access should be denied accordingly.

I think I understood.

In terms of implementation each cifs mount stores a dictionnary mapping
uid to TreeCon (it's the tlink rb-tree, see cifs_sb_tlink(),
tlink_rb_search(), etc).

I think it should just be a matter of storing the session id as the key
in the tlink rb-tree instead of uid (we use fsuid actually). This way
when a new session does a syscall on the mount, the lookup will fail, it
will try to create a new tlink, and fail unless there is the krb stuff
in the keyring.

But are you sure root cannot "enter" an existing user session? I think
I've done it for screen sessions in the past... If yes, would this make
this per-session smb session pointless or is there still some value? 

Cheers,
-- 
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)

Re: cifs multiuser mode and per session treatment

[Björn JACKE]

On 2019-12-16 at 12:38 +0100 Aurélien Aptel sent off:
> In terms of implementation each cifs mount stores a dictionnary mapping
> uid to TreeCon (it's the tlink rb-tree, see cifs_sb_tlink(),
> tlink_rb_search(), etc).
> 
> I think it should just be a matter of storing the session id as the key
> in the tlink rb-tree instead of uid (we use fsuid actually). This way
> when a new session does a syscall on the mount, the lookup will fail, it
> will try to create a new tlink, and fail unless there is the krb stuff
> in the keyring.

Awewone, looks like you have a plan already.


> But are you sure root cannot "enter" an existing user session? I think
> I've done it for screen sessions in the past...

screen sessions are only local sockets without access protection from the
kernel. I can't say for sure if there is a way for root to access users'
session keyrings (I didn't find any) but it was one of the goals of the session
keyring implementation that not even root can access the user keys in there.

Cheers
Björn