Re: [fuse-devel] FUSE and the kernel key retention service

[Goswin v. B. <gos...@we...>]

Michael Sparks <ms...@ya...> writes:

>>> Suppose jack writes a plain kernel filesystem, loads and mounts it.
>>> He is then just as able to access your keys.
>>
>> Well, yes, but in that case he didn't do it as jack, but as root ---
>> which hopefully means I can sort of trust him...
>>
>>> The difference is that with the FUSE filesystem, he wouldn't
>>> necessarily need root privileges to do so.  I think that problem is
>>> solvable.  The security implications are similar to allow_other.
>>
>> Ok, I'm obviously being especially dense here.  With allow_other, jack
>> (as the guy who wrote the FUSE-FS) essentially allows me (and others)
>> access to his filesystem.
>>
>> But in your case, jack would write a filesystem that would essentially
>> give him access to my keys, possibly even without me knowing about
>> it.  Or wouldn't it?  Maybe I'm missing something obvious?
>
> The similarity to allow_other is that the only time information can be leaked to jack is if you access his mount point 
> and thereby cause information to go to his fuse program.  In this case, the leaked information (keys) is potentially 
> much more damaging than just a record of what filesystem activities you performed (as with allow_other).
>
> There are two ways I know of to contain the security risk, both of which restrict the fuse program to only accessing 
> keys of a certain type (for information on key types, see for example register_key_type in the keys.txt file).
>
> First is to require the fuse program to have root privileges on startup when it names the key type it will be interested 
> in.  This makes the situation more similar to that of the plain kernel filesystem in that jack is acting as root, and is 
> therefore trusted.  The fuse program would start as root and name the type of key it wants to read during 
> initialization, and then preferably drop root privileges.
>
> The second option is to require each new fuse mount to name a new unused key type, which would then be registered on its 
> behalf in the kernel.  This prevents it from looking at any existing keys that users may have, since users will not 
> already have keys for that new key type.  Users will have to deliberately install new keys with the appropriate type 
> before the fuse program would be able to see them.
>
> In both cases, I am assuming that the stated restrictions would be enforced by the fuse kernel module.

The thrid is to allow access to keys of the user accessing the FS but
only when that user is accessing the FS. I.e. as long as a fuse request
from an user is pending that users keys can be accessed.

MfG
        Goswin