[cap-talk] Reducing Ambient user authority in a Type Safe /Memory Safe OS.

Thu Jan 14 22:10:48 PST 2010

Hi Shap , 

Completely agree.  

Considering capabilities can be central or not based on policy I see no
reason why not to have centralized management and try to encourage as much
as possible/practical to be user self administered as the organization
allows or is comfortable with (especially if your are implementing a new OS
which is hard enough to get over the line).   it's very difficult to
challenge the status quo in IT, yet easy to deliver slight evolutions. 

I have read all of Alan's exploits as well as the earlier submission of
papers to conferences from members on the list and that is exactly what I
see , being right doesn't always help as most established people are
scarred/dread something unfamiliar.  

Regards, 

Ben 

From: jonathan.s.shapiro at gmail.com [mailto:jonathan.s.shapiro at gmail.com] On
Behalf Of Jonathan S. Shapiro
Sent: Thursday, January 14, 2010 8:51 AM
To: bklooste at gmail.com; General discussions concerning capability systems.
Subject: Re: [cap-talk] Reducing Ambient user authority in a Type Safe
/Memory Safe OS.

Ben:

First: it isn't my paper.

Second: while I think the conclusions of the paper are fine as far as they
go, the paper doesn't go far enough in the systemic analysis. While the
impact (cost) on the first-order victim may be very low, the systemic impact
is much larger and much harder to account for.

The main point that I think is relevant to cap-talk is that "structural
security" is vital to any resolution. What I mean by "structural security"
is system architecture in which the natural thing for a naive developer to
do usually pushes them in the direction of the "pit of success".
Capabilities are certainly not a universal cure-all, but when used
strategically they are most definitely a useful structural security
mechanism.

If you look at the things that security groups need to configure under the
general heading of centralized security policy, I think you'll find that it
falls into three categories:

1.	Legitemately centralized policy. This category exists because the
effect of weak security is systemic and the local user's costs and benefits
are not aligned well (or even badly) with those of the organization as a
whole. The users who provide vulnerable end systems are not feeling pain
directly, even though the victim of the DDoS attack feels a whole lot of
pain.
2.	Centralized policy that is required as a consequence of the absence
of locally structural security or the presence of local bugs that constitute
exploitable vulnerabilities.
3.	Centralized policy that guards against computer-unrelated liability.
Example: companies are liable if unlicensed software gets installed, so they
have a legitemate interest in preventing that.

Administrators routinely mis-assess all of these categories; sometimes
through ego, sometimes through error, and sometimes through ignorance. But
the key point here is that the role of centralized policy specification is
both legitemate and pragmatically necessary, and especially so given the
misalignment of defensive incentives.

Until we get to the day that users can install their own malware with
confidence that they remain in control, the need for centralized policy
won't go away. Once users can do that, the need for centralized policy will
continue to exist as a countermeasure against other centralized policy (e.g.
installation controls as a guard against copyright violation).

shap

On Wed, Jan 13, 2010 at 4:32 PM, Ben Kloosterman <bklooste at gmail.com> wrote:

Hi Jonathan , 

While this is undoubtedly correct, only a company like Microsoft or maybe
Apple or  Google can change the behaviour of security departments  with lots
of marketing and people explaining it ( hundreds of books , blogs, developer
conferences  etc)  . If you want people to use a new more secure operating
system the best market is the high security  niche which means you need to
convince the existing security people.   As capability systems can do
centralized management at least you give the security departments an option
and something to think about. 

Take your Walmart example, what you are trying to do is not build a WalMart
but change an existing more corrupt organization to become more honest which
is a different kettle of fish. 

Regards, 

Ben Kloosterman

From: cap-talk-bounces at mail.eros-os.org
[mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of Jonathan S. Shapiro
Sent: Thursday, January 14, 2010 5:00 AM
To: jamesd at echeque.com; General discussions concerning capability systems.
Subject: Re: [cap-talk] Reducing Ambient user authority in a Type Safe
/Memory Safe OS.

Relevant to this:

http://research.microsoft.com/en-us/um/people/cormac/papers/2009/SoLongAndNo
Thanks.pdf

On Sat, Dec 19, 2009 at 12:18 PM, James A. Donald <jamesd at echeque.com>
wrote:

Ben Kloosterman wrote:
> -          The desire by admins ( and hence organizations) to allow only
> system/security admins to approve certain functions which may includes
> installing applications in some organizations.   This includes the
> centralized control of rights.

People desire what is not good for them.  What they desire is that other
people are required to do certain tasks, and then required to seek
permissions to accomplish those tasks - which pretty much guarantees
that users will work to subvert security.  And since the end user has
physical control of the box or the data, the end user will always
succeed.  The petty bureaucrat, by maximizing his power within the
organization, undermines the organization's security.

Observe that one of the big reason's for walmart's success is that other
big box company purchasing managers routinely accept bribes from
salesmen, while Walmart purchasers are notoriously honest.

Meeting admin desires is in this case meeting admin desire to undermine
security for personal benefit.  Security mechanisms have to benefit the
person who has physical control of the data and the box on which it
resides, not the admin, or else they will always be bypassed.

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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20100115/ff101737/attachment.html 