[cap-talk] POLA v. Trojans

[Jed Donnelley]

Jonathan S. Shapiro wrote:
> On Wed, 2007-07-11 at 12:32 -0700, Jed Donnelley wrote:
>
>   
>> It would only be if the IT community felt strongly that POLA and
>> capabilities were
>> the right (only, effective, ...) solution to an important problem
>> (e.g. Trojan horses
>> in their various forms) that such work would be seen as important,
>> would get
>> funded and would be done.
>>     
>
> Unfortunately, on this point the IT community was partly right.
>
> There are two types of Trojan Horses:
>
>   1. Programs that behave maliciously.
>   2. Programs that exfiltrate information.
>
> The first category certainly wasn't ignored, but in the context of
> TCSEC, a great deal of attention was being focused on the second
> category, and particularly on exfiltration via covert channels.
>
> So far as I know, capabilities don't help the covert channel suppression
> problem. Indirectly, I think they *do* help because they tend to lead to
> system architectures with more precise models of resource multiplexing,
> but that is an *opinion*, not a testable fact. Of course, ACLs don't
> help against covert channels either. Neither does RBAC. Prayer may help,
> but controlled experiments are thin on the ground. :-) My opinion is
> that covert channel suppression is mostly unrelated to *overt* access
> control.
>   
We agree.  I also believe that suppression of covert channels is almost 
entirely
theoretical and not practical.  Are there any covert channels being 
exploited in
the field?  Perhaps if there were a need - that is if there weren't so 
many overt
channels so readily available for exploitation - then covert channels 
would be
a more significant problem.

That's the basic problem.  We simply have so many overt channels 
available for
exploitation.  Nearly any program that runs anywhere has complete access to
the Internet - how much more overt can you get?

What POLA does is to explicitly limit the number of overt channels available
to running programs to just those necessary to get at the objects needed for
the programs function.

POLA (whether in the form of object/capabilities) or in any other form 
doesn't
really address covert channels.  They are by definition "covert" - that 
is, outside
the prescribed forms of access control.
> Unfortunately, Lampson didn't distinguish covert from overt
> communication in his description of the confinement problem.
I agree, though in the context of the time it's understandable (me 
supporting Lampson.
That's a new one).
> One of the
> major critiques of our later verification proof was that by failing to
> consider covert channels we were effectively redefining the confinement
> property. Avi Silberschatz gleefully reiterated this accusation as
> recently as three years ago while acting as a customer advisor. The
> accusation is, of course, completely correct. We saw no reason to
> promulgate a useless and misleading conflation.
>
> Problem is: academics don't argue for what makes sense. They argue for
> what can be published or what will serve to re-establish [human]
> dominance. Avi understands perfectly well that his accusation is, at
> best, disingenuous. In my opinion it's an open flame in a munitions
> factory. Avi doesn't care. The statement let him put down a junior
> colleague and made him look good in front of his employer of the day.
>
> The other thing about academics (and everyone else, of course) is that
> they do not critically scrutinize favorite ideas as carefully as
> opposing ideas. I have *never* seen ACLs criticized on the grounds that
> they cannot defeat covert channels.
>   
Or provide anything approximating POLA.  As we know the basic problem 
with ACLs
is the dynamics.  Entries are made and removed from ACLs explicitly 
(e.g. by commands
like chgrp, chmod, etc. in Unix systems) - e.g. by "owners" or objects.  
The dynamics
of object/capability access control changes are exactly that of 
communication of
parameters from time immemorial in computer systems - namely parameters 
communicated
as object references - including permission to access the object 
(without which such a
parameter communication would of course be meaningless).

The old argument about ACLs and capabilities just being different ways 
to look at the
same access matrix (subject/object) completely misses the main point 
about how the
entries in the matrix are established.  With capabilities they are 
established through
common parameter communication.  With ACLs they have to be established 
though
much more complex separate calls through some sort of TCB and with some 
sorts of
policies (e.g. MAC/DAC policies) that further complicate things and 
discourage
fine grained access control to the extent that in practice it is never 
extended to
running programs.
> And in this type of area science readily becomes politics. If you get a
> bad meme in circulation, you can shift rationales to perpetuate it. The
> initial bad meme inserted by Boebeck and Air Force redactors gave
> capabilities a bad name. Once that was established,
Remember (as I know you do Jonathan - I'm reminding all readers) that 
Boebert's view was
specifically with regard to MAC MultiLevel Security (MLS).  He expressed 
no concerns
in the area of discretionary access controls - where most of the 
relevant issues are these
days.
> Boebert's view came
> under challenge and people like Avi and others shifted arguments to the
> covert channel issue. It didn't matter that the issue couldn't be
> addressed in other systems; it was sufficient to show that capabilities
> were not a universal solution justifying a major investment shift.
>
> Anybody who thinks that science is an apolitical process doesn't
> understand human nature. Anybody who thinks that science doesn't suffer
> from orthodoxy doesn't understand either science or religion.
>   

I agree.  However, I believe that the concerns of the IT security community
(mostly the defense community) with capabilities includes much more than
just MAC/MLS and covert channels - even if we discount the legacy
compatibility issues (which I accept are huge).

At it's root it's concerned with the communicating conspirators
problem (which I argue that 'user' [ACL] based systems also
don't effectively address - though even you, Jonathan, seem to
have some reservations there) and with the issue of tracking
responsibility (logging/auditing, etc.).

I believe that we can make progress (difficult I accept) if we answer
all of the fundamental objections and leave 'only' the practical
issues such as backward compatibility.

After all, I believe there is pretty much universal agreement that
POLA is a useful concept that could provide significant additional
value (protection from malicious programs like Trojan horses
and from inadvertently destructive programs) if it could be
added with all other things (e.g. user interfaces, performance
and other sorts of costs, etc.) being equal.  It's those other
costs that are the primary issues.  If we can show that there
are no fundamental underlying system costs (like the cooperating
conspirators, MAC/MLS, responsibility tracking/audit/logging,
etc.) but that the only costs are those for converting, then it
seems to me that we would at least have defined a direction
that we could all work toward.

That would be huge progress!

I see Horton as providing one piece of this argument - the
responsibility tracking/identity/audit/logging/people
management piece.  Fundamentally the defense (MAC/MLS)
people don't trust other people.  They long for a world in which
just a few trusted administrators set and control policy and
all the rest of us are constrained to conform.  We may be
allowed to collaborate, but only as allowed by these mandatory
policies and those who enforce them.  Their grudgingly
accepted role for discretionary access controls is rather limited,
and certainly doesn't include collaborating communicators
that they can't control (AKA conspiring communicators).

If there are more legitimate arguments against the object/capability
form of POLA, lets drag them out to be reviewed.  I don't know
of (have at the tip of my fingers certainly) any others.

I suggest dealing with the legitimate technical and administrative and
practical issues, and let the politics fall where they may.

--Jed  http://www.webstart.com/jed/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20070711/8a09f297/attachment.html