Re: foreign fs security features (was Re: NCPFS overhaul)

Andrej Presern (andrejp@luz.fe.uni-lj.si)
Mon, 06 Apr 1998 17:11:02 +0200

Alan Cox wrote:
>
> > The "per-user hidden file" concept is very important.
> > The UFS filesystem is going to need it for Digital Unix
> > filesystems with multi-level secure directories enabled.
> > Novell Netware support needs it. I'd guess most "Trusted *"
> > systems have the concept.
>
> Its actually something thats quite hard to do right because of the
> discovery by creation problem. That requires two people have different
> files with the same name. Then a third person who can see both comes
> along - what do they see. And more interestingly what the hell goes in
> the dcache :)
>
> [the discovery by creation problem]
>
> A directory fred exists you cannot see
>
> You do
>
> mkdir fred
>
> do you
>
> a) return -EEXIST revealing the invisible space
> b) create another fred
>
> if b) what does a user with rights to see both now have to watch.

The first problem is really a confinement problem (by returning an error
the filesystem leaks information). The second gets even more intresting
if the third user wants to access the file; which file is it going to be
served (they both have the same name)?

The solution: you implement a object oriented capability model (pure,
not POSIX capabilities), then rebuild a UNIX (or any other) filesystem
on top of that if you still need it. Or, you keep the classic
filesystem, and enforce that the names be unique and don't try to hide
them (because it can be found out if they exist or not anyway, there's
no use hiding them; marginal security provided is zero).

Explanation:
- mkdir fred returns a capability to 'fred'
- object 'fred' is accessed by the capability, not the name (so you can
have any number of 'fred's)
- object receiving the capability from mkdir delegates the capability to
other objects (that it wants to have access to fred); if the first two
users want the third one to have access, they give him the (two
different) capabilities to the files they created - the third user can
tell the files apart becase he received two different capabilities for
two different files.
- objects that don't hold the capability to other objects, can't access
them (more precisely, they don't even know that any other objects exist
(and if they exist what their contents are), so why would they want to
even try to access them?)

If you choose to use unique public names, you will need an additional
control access mechanism (since the name is public, it cannot hold
rights to the file because those rights could be easily forged by
copying the name which is public). Because you need to control which
users/programs can access the file with the specified name, you create
an access control list and become Inefficient (TM of ACLs; the more
finely grained control you want, more checks will need to be performed -
the code's inefficiency will grow proportionally with the desired
granularity of access control).

Andrej

-- 
Andrej Presern, andrejp@luz.fe.uni-lj.si




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu