[cap-talk] Architectural Choices for Security - moving forward - How to migrate SOA from IBAC to ABAC

[ken]

I agree that Cap-Talk is a good place to discuss this and all the various
alternatives underway should be followed but I would like unearth some
issues at a strategic level. For example "How might we move to SOA based on
ABAC"? I see this as an essential first step towards a Global eTrading
network.

Consider the SOA situation so beautifully reviewed in the paper
'Authorization-Based Access Control for the Services Oriented
Architecture' Alan H. Karp, HP Laboratories Palo Alto
http://www.hpl.hp.com/techreports/2006/HPL-2006-3.pdf   

The IBAC scalability problem cannot be solved by one client and/or the
server on their own. Why? My mind equates the situation to that of a "pre
paper money" society, the pre-industrial generation of hand-laborers. Growth
was capped, because trade was "movement of goods" based (Cut and Paste?) and
where new business grew from sweat-equity (roll your own code?). 

Paper money - an un-forgeable, transferable right - the "Capability" to gold
changed everything - I think that B Franklin made the case first for
America; in any event it proved right then and will prove necessary again
for eTrade to globalize. (Just try to conceive of any global alternative
using IBAC!)

In the early days banks printed their own paper money - today each system
prints its own Capabilities. Then local trade started to take off. It
worked. After a time the Federal Reserve took over to maintain the integrity
of the Banking System for all. Using various alternatives, the same process
could work again for moving to ABAC using Capabilities. 

Plessey 250 used two hardware engines per PP250 CPU. One did all the usual
"Data" functions the other was failure independent - an orthogonal monitor
[an independent server?]. It impartially executed all communication related
messaging while providing Capability based integrity checking. This
interdependence was a check-and-balance covering at least all single
failures. 

We will need such integrity in a Global SAO trading network to prevent
errors, failures and deliberate crime. An equivalent (independent) function
to impartially manage Capabilities for Networked Traders. 

Like early Banks, today's Capability Machine can start with various styles
of Capability currency (E has one good networked example, PP250 had another
- others will exist) but they all enable the same thing - the integrity to
trade securely at a distance, in the abstract, on an industrial and global
scale. 

Why so? - Because (in addition to and because of all the well known security
benefits) automating ABAC is both obligatory and verifiably possible. While
after many years we have not yet been able to automate group IBAC policy.
Hence the IBAC scalability limits. 

So today, eTrade is restricted by its high risks, the manual work (fielding
800 calls, hand fixing passwords, changing roles and on and on) fixing
Business Policy (read security) that will never be computerized across
Client-Service boundaries on a Global basis.

If some agree then... How might such a future Global eTrading network start?
Could it grow? 

I would be interested to read other views that address such topics.
k

-----Original Message-----
From: cap-talk-bounces at mail.eros-os.org
[mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of Jed Donnelley
Sent: Monday, November 12, 2007 3:43 PM
To: General discussions concerning capability systems.
Subject: [cap-talk] Architectural Choices for Security - moving forward

On 11/12/2007 10:08 AM, ken wrote:
> Mark et al
> For 35 years Moore's Law has changed everything except Computer Security.

I agree that computer security is in a sorry state.  However, I
think many areas of computer technology haven't benefited directly
from Moore's Law improvements.  Almost any software area (which
have progressed, but mostly independent of Moore's Law) seems
to fit into that category.

> We are working with a 40 year old paradigm that failed to adapt to new
needs,
> changes in scope and performance

Agreed.  I believe POLA is an obvious and workable paradigm shift
that is (and was) available to help - though it seems curiously
difficult to get more POLA adopted.  I have my thoughts for
some of that difficulty (e.g. see my approach to move forward
below), but others may differ.

> and no corporation knows how or dare fix it. 

Of course it is people who will have to do the fixing, whether
from corporations or academia or government or wherever.  Many
of the people on this list work for corporations (e.g. MarkM
with Google, Alan Karp, Marc Steigler, and Tyler Close for HP,
etc.), so I wouldn't be inclined to leave corporations out of
the solution.

> So I put that presentation together to elevate the level of understanding
in
> my local user community and start to work from the grass roots. There is a
> big need to fill a serious void in understanding. 

Agreed!

> I now believe that Computer Security and Information Protection will only
> develop from Open Source solutions (just like E), solutions that show the
> way, challenging free thinkers with independent efforts to change the
> equation (c.f. Google Lunar X prize).

Open source seems to have some promise, but I hope we stay open to any
source of solutions.  E.g. Plash is open source but Polaris (and I
guess CapDesk?) are not.  They all provide value in "showing the way"
in my opinion.

> Leaving Computer Security to
> corporations is like living under King George and doing nothing about it. 

Heh.  Spoken like a converted Brit ;-)  I focus on the people - whether
working for corporations or not - and the concepts and technologies.

> Privileged modes and privileged users exist throughout the
infrastructure...

I agree that's a problem in many contexts.

> Threats grow on all sides. We need a "Revolutionary" approach to Computer
> Security starting with a Declaration of Independence!

Well...  What 'revolutionary' approach do you have in mind?  I
know one of the knocks on POLA approaches is that they are old
hat, failed approaches.  Been there, done that.  Approaches that
failed in the 1970s and then died out almost completely in the
1980s.  That's of course not how I feel, but that's a common
attitude/perception that I hear.

> I would like to join
> with others and discuss next steps perhaps leading to an On-Line
conference.
> Any interest?

I'm interested and happy to help as I can, but I'm also a bit
cautious.  In some ways cap-talk is a running on-line conference
with a focus very much like you seem to be suggesting.

What I consider wonderful about cap-talk is that it's composed of
a group of people who share a significant overlap in some core
beliefs (e.g. POLA).  If those core beliefs can contribute to the
revolution that you're looking for Ken, then write your Declaration
and we'll see how it goes!

What I have found interacting on cap-talk is that what people feel
are good approaches to fixing computer security problems and moving
toward more POLA are all over the map.

For example, just speaking for myself - I:

1.  recently spent some time looking closely at the complaints
(fears, etc.) that people had about POLA and capabilities - e.g.
as in:

"Traditional Capability-Based Systems: an Analysis of Their
Ability to Meet the Trusted Computer Security Evaluation
Criteria":

http://www.webstart.com/jed/papers/P-1935/

I found what I consider to be legitimate concerns.  Mostly
that people felt (and feel) that capability systems have
failed to deliver on an effective "take back"/"do over"
when it comes to granting authority.  While acknowledging
that revocation can work with capabilities, the criticism
is that there is no information environment in which to
interface to revocation.  That is, with an ACL you can
see who putatively has access to what.  If you want to
remove some access, it is right there in front of you.
How do you do that with capabilities?

The above is what prompted me to get started with what
became Horton.  I didn't see why the same sort of
user/information interface for associating object
access with identities ("users") couldn't work in
pure capability systems.  With MarkM leading the way
on the implementation we showed that such a user
interface/mechanism is indeed possible in the Horton
paper and reference implementations.

With that done my next step is to:

2.  Demonstrate a user interface to access control with
the properties that Horton demonstrated.  I'm motivated
at least partly by a wonderful environment that I had
access to at LLNL in the 1970s and 1980s where access
was delegated by a "dup" function in a shared file
system.  "dup" copied a reference (a capability) from
one shared environment (a directory) that I have
access to into another that some other set of users
may have access to.  It's what today would likely
be implemented with a copy and paste.  In those days
we didn't have Horton or really any effective means
of doing revocation.  I'm sure we can do better today,
but that's what I want to demonstrate.

I believe that with people comfortable with the
directed graph nature of the Web these days, such
a copy and paste delegation mechanism (e.g. including
pasting into an email that will then be sent and thus
shared or pasting into a shared Web "page") along
with the Horton facility for viewing who (IDs) has
been delegated which objects along with the ability
to revoke such access will appeal to people.  My dream
is that it will enable a new level of Web development -
a Web with integrated access control (vs. all the varying
kludges that we have today for such access control -
generally not available to users).


The above is my current vision.  As you know MarkM
is a champion of language based POLA - e.g. with
E and Joe-E and with his latest Caja to enable
POLA mashups.

While I'm supportive, I don't see how we can succeed
with the sort of 'revolution' that you speak of until
we can put access control into the hands of the users,
intuitively.  People may disagree about whether
copy and paste of capabilities is intuitive (e.g. I
know David Wagner expressed reservations), but I've
seen it work and am optimistic.

Others have yet other thoughts for best ways to move
forward.  Jonathan Shapiro is still pursuing an OS
level approach along the lines of KeyKOS and EROS.
I saw KeyKOS and NLTSS and a number of other OS based
approaches extinguished along that path and I've seen
the dominance of the user interfaces for Windows and
Unix that I don't believe will be easily displaced.
I'm not hopeful for that approach (even in the narrower
real time OS environment), but I also wish him luck
and am supportive as I can help.

Others have again other approaches for moving 'forward.'

If you could add some cohesion to this well meaning
(and I believe generally well directed) rabble, then
perhaps it could help.  I think (?) that would require
developing some consensus on how to most effective
move forward.  Got some ideas on that from your
lurking on cap-talk?

I'm ready to help as I can.

--Jed  http://www.webstart.com/jed/
_______________________________________________
cap-talk mailing list
cap-talk at mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk