[cap-talk] The simple security and *-properties, and why you don't want them

David Hopwood 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 
> cap-talk.

So far so good...

> However, I think they are a wonderful challenge problem for 
> developing a taxonomy of what's logically possible within different 
> frameworks.

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
   as unreasonable".)

   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
   to :-)

 - 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 --
do you?

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 mailing list