Re: Vnode scope

[Elad Efrat <elad%NetBSD.org@localhost>]

On Tue, May 12, 2009 at 6:00 AM, David Holland 
<dholland-tech%netbsd.org@localhost> wrote:

>  > Moving access control to the VFS layer requires the following:
>  >   - Each file-system must provide means to convert its own
>  > permissions, ACLs, etc. to a normalized form. At the moment, for
>  > NetBSD and standard permissions, this is pretty much done using
>  > VOP_GETATTR() and isn't an obstacle.
>
> This is the wrong approach. First of all, for most parts of most code
> paths you want an abstraction for permissions, the same way that
> you've already set up abstractions for credentials.
>
> Only in the place where (real, non-abstract) credentials are tested
> against (real, non-abstract) permissions does it make sense to talk
> about canonical or normalized forms. And then in those cases, in
> general you want a canonical form for credentials, not a canonical
> form for permissions.
>
> In general, permissions are a mapping from pairs (credentials, object)
> to boolean. One can store or represent this mapping in a number of
> ways (capabilities, ACLs, traditional Unix permissions, etc.) but it
> relies on a coherent concept of credentials. I can "normalize" the
> permissions on my FS all you like, but it doesn't *mean* anything
> unless the credentials we use as a basis represent a shared
> understanding. That is, what you understand by "uid 5" better be the
> same as I mean when I say it. Otherwise, when I hand you a
> "normalized" ACL that says "uid 5 can jump up and down and whistle
> Dixie", your interpretation of it won't be correct.

Have you read the pseudo code I posted? it relieves you of having to
"normalize" permissions, and lets you have each file-system call
vaccess() on its own, just like they did for the past 16 years.

> However, given a canonical form for credentials, there's no need for
> normalizing anything: you present the credentials to the FS and it
> reads them and returns yes or no based on its internal data
> structures, and that's the beginning and end of it.

Whether this is good or bad is subjective. You have to normalize
everything whether you like it or not. When you chown, chmod, etc.,
your intentions are passed in a "virtual attributes" structure to the
file-system, which then "unwraps" it and applies it to the file-system
data-structures. Also, as I state below, one of kauth(9)'s goals is to
make decisions about security and access controls. Claiming that the
file-system should make its own decisions (and exceptions) is
basically like saying that bind() was designed so that uid-0 can
always bind to a privileged port. Both assumptions take us years
behind our current design and back in line with the one OS that
doesn't provide any sort of modern security mechanisms.

The file-systems should not make any exceptions: any ACL design should
never include exceptions, as files are objects being accessed *to* by
a user with credentials, and credentials are used everywhere for
access control to all subsystems. Therefore, a file-system should
perform the checks that are relevant to it (and if a *file-system*
assume uid-5, or 0, for that matter, is all-powerful, then it's badly
designed) and return a decision. That decision should then be passed
to the secmodel for final decision: if the secmodel acknowledges the
concept of root, having uid-0 will always cause it to succeed. If the
secmodel works like a MAC, no specific uid could (nor should) help
you, regardless of what the file-system says: the file-system is a
part of a system, and should comply with its security policy. If it's
unable to do so, again, it's badly designed.

> Your other mails seem to suggest that we shouldn't bother worrying
> about abstract credentials because everything uses only traditional
> Unix permissions. That's a horrible cop-out. I thought one of the
> points of kauth was to *avoid* hardwiring outdated assumptions into
> the design.

Is this what my mails suggest? because I recall two things that I said:

1. If we create today an abstraction that can cover everything that
was designed to this day we're pretty much fine (you can't satisfy
100% of the users, so why not satisfy 100% in the short/mid-term and
90% theoretically in the much longer term, instead of keeping them all
in stone age, like we did for so many years?)

2. We *can* call the file-system for a decision and pass that to
kauth(9) for further consulting, in cases where we don't have an
abstract representation. I have provided pseudo code to illustrate
that.

> Meanwhile, making every FS that wants to use some other kind of access
> control implement a kauth listener to substitute the right access
> check results in by sleight-of-hand... is really a bad plan. Access
> control code *has* to be simple and straightforward.

Here, too, you are somehow under the impression that *I* suggested
that, while I specifically spoke against it:

    http://mail-index.netbsd.org/tech-kern/2009/05/12/msg005078.html

> It seems to me that if you want to be able to override the permissions
> checks by specific kauth configuration (which seems like a really bad
> idea too, but apparently that's what kauth's about) then this logic
> needs to be per-FS specifically because it means different things to
> different FSes.

I'm not sure where you're coming from, but overriding permissions
checks by a specific "kauth configuration" has been in NetBSD long
before kauth(9): it's called securelevel, and it's a very good thing,
whether you agree with it or not.

It's the ability to tell administrators they have a quick way to
enforce a stricter policy on the entire system. What kauth(9) does is
extend that ability, and file-systems will have to cope in one way or
another... otherwise, what you're suggesting breaks the design of a
core part of the NetBSD kernel that has been present for some three
years now.

Thanks,

-e.