Language changes, but you can't call a saddle a horse, even though you
really sit on the saddle when you ride a horse. You can still go to a
riding club and say that you want to ride a saddle, just don't look
surprised when you get to ride a saddle in the barn instead of on a
horse...
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
blatantly renamed capability lists into capabilities, that just makes
them incompetent when it comes to access control concepts, because when
you read literature, capabilities (aka key/lock mechanism) and
capability lists are two different things.
> The implementation of what Andrej prefers to call capabilities, has
And what the designers and implementors of L4, EROS, KeyKOS, GNOSIS,
XOK/EXOS, Grasshopper and other academic, experimental, commercial and
military capability based operating systems dating from today and all
the way back to 1960's, together with respected names of computer
security industry, such as Landau, Hardy, Schroeder, Saltzer and others,
prefer to call.
> 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.
In plain language this means that in a system with mandatory access
control you can't just give access to your file to anyone you wish, but
only to specified people.
In contrast, discretionary access control means that 1. the system
checks an entity's rights to access an object, but 2. the owner of the
object can override the decision made by the system (ie. he can grant
access privileges to anyone he wants to).
Discretionary and mandatory access control are access control
_policies_, not access control _mechanisms_ (implementations)! Examples
of popular access control implementations are access control lists
(ACLs), capability lists and capabilities.
> My reading of it, is that in addition to having MAC tokens (what
> Andrej would call "capabilities") they have added a notion of
> "dominance", where each MAC token is given a "level". In the model
> Andrej discusses, two objects must share a MAC token to be able to
> exchange information, the POSIX model includes the notion that there
> can be a restriction on the direction of flow of information based on
> which object has the dominating MAC token. (In general, it would
> appear that information may only pass from a lower level to a higher
> level.)
The notion of 'dominance' that you are describing means a separation of
multiple security domains. The system should be able to confine entities
from (intentionally or unintentionally) leaking information to other
security domains _after_ the access to the object has been given to the
entity. This is required in order to be able to have different and
_separate_ levels of security, such as the four military sensitivity
levels (top secret, secret, confidential and public), where information
must not leak outside a security domains.
It may be allowed that the information may only pass from a lower level
to a higer level (since this is relatively easy to do), such as is the
case with the above mentioned military sensitivity levels, but truly
secure systems allow you to fully separate individual domains (this
means that two competing companies can have data on the same computer
without worry that the other one will steal/damage/change it). In order
to be able to do that, you will have to solve the confinement problem
first, and I don't know of _any_ lists based operating system that does
that (you can do it with capabilities though).
> 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.
> > * You can't make a (good security) pie without breaking the (POSIX)
> > eggs..
>
> 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.
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