Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On Aug 11, 2017, at 3:17 AM, NeilBrown <neilb@xxxxxxxx> wrote:
> 
> On Wed, Aug 09 2017, Jeff Layton wrote:
> ....
>> 
>> Thanks, that helps a bit. I'm less clear on what the higher-level
>> vision is here though:
>> 
>> Are we all going to be running scripts on logout that scrape
>> /proc/mounts and run fslogout on each? Will this be added to kdestroy?
>> 
>> Or are you aiming to have KCM do this on some trigger? (see:
>> https://fedoraproject.org/wiki/Changes/KerberosKCMCache)
>> 
>> Also, doing this per-mount seems wrong to me. Shouldn't this be done on
>> a per-net-namespace basis or maybe even globally?
> 
> Having looked at the code, I think this is invalidating cached
> credentials globally -- or at least, globally for all filesystems that
> use sunrpc.

Yes all filesystems that use sunrpc could benefit from by calling the 
same routine that NFS calls. It only does it per “auth” flavor. If you 
have multiple flavor mounts, only specified one is effected.

> I actually question the premise for wanting to do this.  Tickets have a
> timeout and will expire.  Any code that is allowed to get a ticket, can
> hold on to it as long as it likes - but it will cease to work after the
> expiry time.

However, when kdestroy is called, then any code that tries to use it
will yet. User land is unaware that the kernel has cached his 
credentials.

>  Hunting out all the places that a key might be cached, and
> invalidating them, seems to deviate from the model.  

No caching should be valid after credentials were explicitly removed. 

> If you are concerned
> about leaving credentials around where they can theoretically be
> misused, then set a smaller expiry time.

That’s correct. The only means that people who have complained 
about is left with is using short credentials. But security context 
establishment is not for-free and impacts performance.

> What is the threat-model that this change is supposed to guard against?

It’s a limitation of a system that I feel has solution of providing the 
extension to kdestroy that destroys FS creds.

What’s the disadvantage of providing this feature? There are folks who 
have been asking for it. It tightens up the security.

> Looking that the syscall itself:
> 1/ why restrict the call to directories only?

No real reason. It seems unlikely that the practical unlog application would 
open a filesystem specific file and then call the unlog on that file. It’ll be
problematic as without creds no close can be done and would leave state
on the server?

> 2/ Every new syscall should have a 'flags' argument, because you never
>    know when you'll need one.

Ok.

> 
> NeilBrown
> 
> 
>> 
>> It seems like we can afford to be rather cavalier about destroying
>> creds here. Even if we purge creds for a user that should have remained
>> valid, we just end up having to re-upcall for them, right?
>> -- 
>> Jeff Layton <jlayton@xxxxxxxxxx>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux