Re: Secure-linux and standard kernel

Andrew Morgan (morgan@transmeta.com)
Sun, 28 Jun 1998 18:24:53 -0700


Andrej Presern writes:
> > Just for reference, POSIX used to call these "capability lists"
> > privileges, but now they call them capabilities. Feel free to call
> > them whatever you want, but it will not change what they do.
>
> Language changes, but you can't call a saddle a horse, even though you

This is self contradictory. If enough people were to call a saddle a
horse, I, like other people would be understood when I said horse and
meant saddle...

> Powerful institutions like Microsoft have been doing naming stunts (can
> you tell me what a cluster is?) for ages and have been criticized for
> that. Righteously! What you're saying makes you no better. And if POSIX

Do you think M$ care? This sort of thing happens all of the time.
Those with the right amount of influence get to (re)define things when
they want. Sad but true. I'd be happy to call POSIX-capabilities
"bananas" but then anyone that was looking at Linux as a POSIX
compliant platform would get confused.

> > not been ignored by the POSIX people. In point of fact it occupies a
> > reasonably large fraction of my copy of the POSIX.1e draft (#15). The
> > term that POSIX use to refer to it is "Manditory Access Control".
>
> Mandatory access control simply means that 1. the system always checks
> an entity's rights to access an object and 2. neither the entity nor the
> owner of the object can ever override the decision made by the system.

> > Whatever, the case, this is a part of POSIX.1e that is not currently
> > implemented in the Linux kernel.
>
> I haven't read the draft so I can't tell what level of mandatory access
> control they had in mind when they designed the draft, but if you had in
> mind the confinement of different security domains that I described in
> the last paragraph, you probably won't have that in the kernel for the
> next 100 years (well, at least they haven't been able to solve the
> confinement problem with lists in the last 30 years) if you stick to
> POSIX.

I have just looked over the draft again. The MAC infrastructure they
describe makes no mention of lists. It seems to be entirely based on
tokens: each file & process has a MAC token associated with it. POSIX
does not define what the token contains (so I guess it could be a
'list' of keys but I could see the whole thing being implemented under
Linux as a set of stubs to a home-brew kernel module..). POSIX do
specify an interface for deciding if one token dominates another but
how this domination is determined seems to be implementation (kernel
module?) specific.

> > And you certainly cannot rule out POSIX based on a partial
> > implementation of the full model.
>
> Of course not. But you can rule it out based on the concepts it is based
> on.

I guess you're going to say POSIX is broken again, but perhaps you can
explain what is so broken about this seemingly (to me) general
framework.

Thanks

Andrew

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