[cap-talk] The simple security and *-properties, and why you don't want them
david.nospam.hopwood at blueyonder.co.uk
Sun Jul 30 17:39:39 EDT 2006
Mark S. Miller wrote:
> Btw, I do not mean to imply that the *-properties have much practical utility.
> I doubt they do, and I sympathize with other expressions of such skepticism on
So far so good...
> However, I think they are a wonderful challenge problem for
> developing a taxonomy of what's logically possible within different
It's not very often that I disagree with MarkM so strongly.
I think that the ss/*-properties are unenlightening as challenge problems,
and that their influence as such has been an unmitigated disaster:
- Expressiveness of an access control framework is *only* relevant insofar
as it lets us express realistic policies that are likely to be helpful to
security in the environments that users are actually faced with. The ability
to express unrealistic or unhelpful policies is at best useless, and could
encourage users to employ those policies when they would not otherwise do
so. It may also complicate the framework or hinder its general usability,
even when those policies are not used.
- The ss/*-properties do not just state a high-level security goal; they
require a particular infrastructure in which subjects are assigned
clearance levels and objects are assigned labels. While it is usually
possible for any framework to simulate this infrastructure, the simulation
makes some frameworks look significantly more complicated than they would
be in typical use.
- The assignment of clearances and classification labels is normally assumed
to be centralized and essentially static. The ss/*-properties do not test a
framework's ability to handle dynamic authority changes, or to distribute
responsibility for expressing the desired policy between users.
- The *-property (no write down) is fundamentally in opposition to POLA.
If a High subject P wants to delegate a service to another subject S, then
POLA says that P *should* use an S that has the least possible access to
objects other than those needed to perform the service. The *-property,
OTOH, effectively says that S *must* have an equally high clearance level
to P (and therefore, if the ss-property is the only other rule in effect,
it is able to read anything that P can read).
In other words, the *-property makes it as difficult as it could be to
delegate a task to a subject that is trusted only for that specific task.
This is true even if the property is interpreted as discretionary, since
a human user would have to intervene for each instance of delegation.
The problem here is that the policy assumes a single per-subject clearance
level, which is conflated with trustworthiness for any particular task.
(Role-Based Access Control tries to address this by adding yet more
complexity. Capability systems, OTOH, support delegation rather than
impeding it, and focus attention on the issue of communicating just the
needed authorities to the delegate.)
- Boebert's paper gives the following motivation for these properties:
Trojan Horse Attacks
These restrictions are imposed to prevent what are called "Trojan
Horse attacks," in which a malicious program abuses the clearance it
temporarily possesses (as the consequence of executing on behalf of
a trusted user) in order to compromise the information to which that
user has a legitimate right to access. In the typical Trojan Horse
attack, a program written by a malicious party is made publicly
available. An unwitting user invokes the program, bestowing upon it
(for the period of the invocation) the clearance level of the user.
The program then performs, in addition to its publicly known function,
a clandestine examination and transfer of information to which its
author does not have legitimate access.
The appropriateness of the Simple Security Property is obvious, since
it states that no program may access information whose sensitivity
exceeds the trustworthiness of the user on whose behalf the program is
executing. The *-Property is less obvious; it exists to prevent the
trivial circumvention of the Simple Security Property by means of
Write access. Without the *-Property, it would be possible for a
malicious program to write sensitive information (to which it
temporarily has legitimate access, as a consequence of being invoked
unwittingly be a trustworthy user) into a storage object of low
classification. Such information could then be read later by a
program executing on behalf of a user of low trustworthiness, thereby
compromising the sensitive information. The restriction imposed by
the *-Property prevents this "de facto declassification."
Notice that this whole argument proceeds from the implicit assumption
that programs run with the permissions (clearance level, in this case)
of their invoking user.
The cause of the problem has more to do with excess authority of the
potential Trojan program, than it has to do with the rules governing
how this program can communicate. In letting the program read *any*
file of the same or lower level than the user, and then trying to stop
it from communicating the contents, the *-property attempts to close
the stable door after the (Trojan?) horse has bolted. This approach
simply does not work: it would only be valid if outward bit confinement
were possible, which it isn't.
(Please let's not re-hash the argument about limiting covert channel
The appropriateness of the ss-property is certainly not obvious. On
the contrary, it is way too lax in determining what can be read.
Only files that the user explicitly chooses to open with the Trojan
program should be vulnerable to being leaked, not all files that the
user *could* open.
(This is significant because the "proof" that the *-property cannot be
enforced, even if we accept some of its other erroneous assumptions,
does not apply to systems that enforce restrictions on reads stronger
than the ss-property. That is, the title of the paper should have been
something like "On a certain class of capability systems' inability to
enforce the *-property given that the only other security restriction
in force is the ss-property.")
Similarly, the potential Trojan should only be able to write to
locations that the user has explicitly chosen to write to. This would
achieve a similar effect to discretionary declassification, especially
if any trusted dialog asking for the location were to inform the user
that the effect will be a declassification.
- The Bell-LaPadula (BLP) ss and *-properties only attempt to address
confidentiality. For information integrity (assuming we are using the
same framework of ambient authority with clearances and labels that I
criticised above), the properties that have been suggested to control
information flow between levels are exactly dual to the BLP ones:
The disadvantages of the Biba properties are also dual to those of
the BLP properties -- for example the Biba-ss-property ("no read down")
works against POLA in a similar way to the BLP-*-property ("no write down"),
because it forces a delegate that we need to read information from to
have as high a clearance level as us.
However, the Biba properties are not, per se, any more unreasonable as
an attempt to enforce integrity, than the BLP properties are as an
attempt to enforce confidentiality. (Perhaps I should say "exactly
Within an ambient-authority clearances-and-labels framework, if we
want to enforce both confidentiality and integrity, then we need to
apply the composition of the Biba and BLP properties. But this is a
strict isolation model (no information flow between levels), which is
clearly too restrictive.
- Given the above points, whether an "unmodified capability system" could
express the *-property or not should never have been an issue; it is
simply not important. (To some extent, I think that even discussing this
subject on cap-talk is a waste of time, which I apologise for contributing
- Many of the papers discussing these properties are IMO pretty shoddy work.
They are littered with unstated assumptions, and sometimes downright
fallacious reasoning. I cannot see that they have contributed anything
useful to the field of access control.
In general, I think that the ss/*-properties are not at all illuminating in
terms of testing a framework's ability to solve more important security
problems. If you want to test whether a framework can handle important issues
like confused deputy attacks, resistance to trojans, etc., then develop
problems that specifically test those issues; don't use the ss and *-properties
as proxies for them.
> Once a crisp difference has been so illuminated, we may find other
> unnoticed implications of this difference, and some of these may have
> practical implications.
That's two "may"s. I don't know of any actual examples of such implications --
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>
PS. I will be away from a net connection until Thursday.
More information about the cap-talk