[cap-talk] Demonstrations and explanations (was: Re: Avoid overconfidence)
John McCabe-Dansted
gmatht at gmail.com
Wed Apr 9 23:54:54 CDT 2008
On Wed, Apr 9, 2008 at 3:08 AM, Jed Donnelley <jed at nersc.gov> wrote:
> On 4/8/2008 11:20 AM, Ivan Krstić wrote:
> > On Apr 8, 2008, at 2:07 PM, Jed Donnelley wrote:
> >> The above sounds like more argument/engagement.
> >
> > It is! But it's very much to be read as non-confrontational.
>
> There are huge amounts of non-confrontational reading material
> on the capability paradigm, systems, etc. available. The only
> time confrontation is needed is when somebody (particularly
> somebody considered an industry leader like Butler Lampson in
> a very visible keynote presentation) says, in effect,
>
> "This approach <POLP> has never worked and it never will
> for these reasons...>"
>
> At that point I believe "confrontation" is the only viable
> form of engagement. If the audience (many hundreds to
> a thousand? in that case) accepts such arguments (for that is
> what they are, all demonstrations to that point are shared)
> for lack of any effective counter arguments, then the 'door'
> that Fred Spiessens referred to is closed that much more firmly
The term POLP has been used in a wide variety of contexts, see e.g.
http://www.windowsecurity.com/articles/Windows-Vista-Principle-Least-Privilege.html
For many of such uses of POLP, he could well be right. Indeed he seems
right on the ball about Vista-POLP.
Arguing over whether or not such uses are correct is perhaps
unproductive, as we prefer the term POLA. Even then, I am not too sure
that POLA is useful unless we clearly define what we mean by "Least".
E.g. Median({5,2,2,2,2}) clearly only needs to know three elements of
the array. Someone who tries to figure out which three elements convey
the least authority really isn't on the same page as us. Rather, we
typically mean something more like "Least Authority required for this
well-factored object model", which AFAICT is equivalent to No Ambient
Authority. Perhaps a more accurate acronym would be something like NAA
or OO-POLA.
We could perhaps contextualize rather than confront these arguments
against POLP. For example, we could include snips such as the
following:
--
...
As Lampson notes, attempting to achieve perfect security can lead to
worse security; it can be very difficult to maintain the security
policies [1], and the inconvenience can out weigh the benefits [2].
Lampson suggests that "feasible security" requires "Costs less in
inconvenience than the value it protects" [2] is "Simple enough for
users to configure and manage" and is "Simple enough for vendors to
implement".
Although Lampson argues against POLP, we note that POLP has been used
in a variety of contexts [?,?,?]. While these approaches to achieving
POLP have focused on reducing the permissions each process holds, we
instead focus on limiting the authority (define) held by each process
... This is much easier to achieve, since programs, especially OO are
already centered around such scoping rules, and users are already
familiar object model of designation.
...
With FooDesk we do not require separate policies to be maintained.
Every object (class, user, process, device driver etc.) is limited
according to standard scoping rules that are familiar to to anyone who
has learnt a programming language. In many cases, this can achieve
near-perfect security without the programmer even considering
security, for example in FooBrowser the Bar attack would have been
avoided since the scoping rules mean that FooJPEG can at worst exhaust
the vats memory and trigger a page reload.
[Discuss Horton and Logging]
...
As the user is already familiar with objects such as files,
directories, ... this object-interface interface does not
inconvienence the user. Indeed, we tested this system with Y
MS-Windows users, all of the users were able to perform everyday tasks
such as opening files etc., additionally x of the 20 of the users were
able to share access to "Project.doc" with the FooDesk UI. By
comparision, only z users were able to share the file under windows
(the UI that they were familiar with), and nearly half of the z users
accidentally shared the entire Documents folder.
...
Conclusions
...
FooDesk could be extended to support Mandatory policies ... this can
inconvenience the user, such policies are frequently turned off by
exasperated admins, thus we do not rely on mandatory policies for
security. While some authors have suggested that mandatory policies be
used to achieve POLP, as Lampson notes POLP can degrade security, and
in most use cases we see little advantage of POLP over POLA. Thus we
see no need for such extensions to FooDesk at this time. Instead, we
intend to focus on ...
[1] http://www.eros-os.org/pipermail/cap-talk/2006-November/005876.html
[2] http://www.usenix.org/events/sec05/tech/lampson.pdf
...
We would probably want to emphasis Lamport less (OO Capabilities were
not invented solely to get Lamport's approval), but it still seems
possible to address Lamport's points without in anyway contradicting
him. We likewise we could address claims made by alternative
approaches to security without contradicting their claims, but rather
essentially arguing that POLA "Costs less in inconvenience than the
value it protects".
--
John C. McCabe-Dansted
PhD Student
University of Western Australia
More information about the cap-talk
mailing list