headers
Jonathan S. Shapiro | 6 Sep 2007 18:33

Re: Forward: some thoughts about map vs. copy vs. membranes

On Thu, 2007-09-06 at 05:00 +0200, Marcus Brinkmann wrote:
> At Wed, 05 Sep 2007 14:48:40 -0400,
> "Jonathan S. Shapiro" <shap <at> eros-os.com> wrote:
> > 
> > 	cresult = c0->method(data args, c0, c1, ..., cn)
>
> I think the example you are bringing up is interesting.  However, I am
> not sure why you think that cresult in your example should generally
> be limited by any other capability than c0.  There are peculiarly few
> operations involving capabilities as arguments, and even less return
> capabilities, so use cases to analyze are rare....

I think this because the membrane that has been under discussion on
cap-talk is the one in which this is the defined behavior.

The problem is that the term "membrane" is being overloaded: it is both
a generic term meaning "a mechanism (in our context: a process) that
enforces transitive revocation policies by injecting wrappers and
tracking propagation'. We have also used it to refer to an particular
instantiation that implements the particular policy that I have
described above.

I suggest that in the future, to avoid ambiguity, we should call this
the Causal Dependency Membrane.

The causal dependency membrane is certainly not the only possible
membrane.

So: I should restate what I said about L4 implementing membranes:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Toby Murray | 17 Sep 2007 11:51
Picon
Picon

"The Thing from the Internet!" Humorous POLA Motivation

I thought a few on this list might find the following poster amusing:
http://itpo.iu.edu/media/04_Attachments_SMALL_black.jpg

"The Thing from the Internet: The Next File You Open Could Be Your Last"

It's a pretty humorous ad for POLA methinks.

Indiana University produced a series of these 50s horror movie themed
"security awareness" posters sometime ago for something called National
Cyber Security Awareness Month (does anyone in the US know whether this
month of awareness worked? ;)

Other posters and information are available here, including hi res
images for printing etc.
http://itpo.iu.edu/education/ncamkit.html

This is one of those images that could be a good ice breaker at the
beginning of any POLA related talk perhaps. No idea what copyright
restrictions might apply to the images though.

Cheers

Toby
Permalink | Reply | 1 comment |
headers
Toby Murray | 17 Sep 2007 12:04
Picon
Picon

Reinterpreting POLA - "Authority Must Not Exceed Trust"

Hi cap-talk,

In my work on formalising authority, I've found it useful to strengthen
the usual notion of POLA to arrive at a more general definition of what
it means for a system to be 'secure'.

The traditional definition of POLA says that 

"the authority of each object/subject/program/process/user/whatever
should not exceed that needed for it to perform its function(s)."

This is useful but doesn't admit notions such as "separation of duty"
which need to be defined separately (because they appear orthogonal to
the above definition).

It also presumes there is some global administrator that can define the
correct function(s) of each entity in the system.

Instead, I've found that a better definition of what we might desire is

"the authority of each object/subject/... should not exceed that which
we trust it to wield."

In the case where "we" is a global system administrator and all entities
are trusted to perform all of their functions, this collapses to
traditional POLA. But it is also more general than POLA. 

It allows security to be defined separately from multiple points of
view, for each of the stakeholders/actors in a system.
(Continue reading)

Permalink | Reply | 52 comments |
headers
Mark Miller | 17 Sep 2007 12:12
Picon
Gravatar

Fwd: [hcisec] Apparent implementation of a CapDesk-like system for Windows

---------- Forwarded message ----------
From: pgut001@... <pgut001@...>
Date: Sep 16, 2007 9:21 PM
Subject: [hcisec] Apparent implementation of a CapDesk-like system for Windows
To: hcisec@...

I recently ran across something that looks like a commercial CapDesk-like
system, a bit like Polaris but it's an actual shipping commercial product.
Unfortunately the info on their web site,
http://www.gentlesecurity.com/technology.html, is a rather fuzzy, and the only
detailed review I've seen of it is in German (this month's iX magazine).  Like
CapDesk, GeSWall jails apps unless they're given extra rights to perform
certain operations (there are predefined rulesets for common Windows apps like
IIS, Apache, Oracle, and so on).

There's a pile of interesting features there, for example alongside the usual
RWXD ACL settings there's also a "redirect" setting that provides access to a
virtualised version of the original resource (for example a registry key), in
the same way that MLS Unixes virtualised the tmp directory.

GeSWall also adds integrity labels to all data, providing mandatory integrity
controls.  Overall, it's an interesting application, and surprising that it's
taken so long for something like this to appear for Windows.

(Disclaimer: I don't have any association with the product or the vendor, just
 thought it was something interesting to point out).

Peter.

Yahoo! Groups Links
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Miller | 17 Sep 2007 12:20
Picon
Gravatar

Re: [hcisec] Apparent implementation of a CapDesk-like system for Windows

On 9/16/07, pgut001@...
<pgut001@...> wrote:
> I recently ran across something that looks like a commercial CapDesk-like
> system,

>From a brief glance, I notice that the diagram they use at
<http://www.gentlesecurity.com/pix/005_1.png> is an almost perfect
transpose of the diagram we've been using to explain the benefits of
the CapDesk-like approach, though
<http://www.gentlesecurity.com/comparison.html> makes no mention of
CapDesk, Polaris, Plash, or Bitfrost.

--

-- 
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM
Permalink | Reply | 0 comments |
headers
David Hopwood | 17 Sep 2007 16:35
Picon

Re: Reinterpreting POLA - "Authority Must Not Exceed Trust"

Toby Murray wrote:
> Hi cap-talk,
> 
> In my work on formalising authority, I've found it useful to strengthen
> the usual notion of POLA to arrive at a more general definition of what
> it means for a system to be 'secure'.
> 
> The traditional definition of POLA says that 
> 
> "the authority of each object/subject/program/process/user/whatever
> should not exceed that needed for it to perform its function(s)."
> 
> This is useful but doesn't admit notions such as "separation of duty"
> which need to be defined separately (because they appear orthogonal to
> the above definition).
> 
> It also presumes there is some global administrator that can define the
> correct function(s) of each entity in the system.

Correct function does not have to be decided by an administrator.

> Instead, I've found that a better definition of what we might desire is
> 
> "the authority of each object/subject/... should not exceed that which
> we trust it to wield."

I don't think that switching from "needed to perform its function" to
"which it is trusted to wield" is an improvement on the definition
of POLA. I think it's defining something else. A program can very well
satisfy POLA, and a particular user still does not trust it. A user's
(Continue reading)

Permalink | Reply | 19 comments |
headers
David Hopwood | 17 Sep 2007 16:48
Picon

Re: Reinterpreting POLA - "Authority Must Not Exceed Trust"

I missed part of Toby's mail:

Toby Murray wrote:
> It also naturally admits separation of duty:
> 
> We might have an accounting package whose functions include writing and
> approving purchase orders, for example. A running instance of that
> package might be trusted to perform the former but not the latter (and
> vice versa) in order to prevent it from approving its own purchase
> orders.

In this case the package's intended function is for each instance to
be able to write or approve (but not both) a set of purchase orders.
I don't see that any generalization is needed to cover separation of
duty; it is part of what I've always considered POLA to cover.

A more common example is that each instance of an editor should only
be able to read and write files designated by the user for that
instance; not any file that the editor program has ever been asked
to edit. (There is a nontrivial, but solvable, design problem here in
how to support 'Recently used file' lists.)

--

-- 
David Hopwood <david.hopwood@...>
Permalink | Reply | 1 comment |
headers
Jonathan S. Shapiro | 17 Sep 2007 17:00

Re: Reinterpreting POLA - "Authority Must Not Exceed Trust"

On Mon, 2007-09-17 at 15:35 +0100, David Hopwood wrote:
> Toby Murray wrote:
> > Instead, I've found that a better definition of what we might desire is
> > 
> > "the authority of each object/subject/... should not exceed that which
> > we trust it to wield."
> 
> I don't think that switching from "needed to perform its function" to
> "which it is trusted to wield" is an improvement on the definition
> of POLA.

More strongly: I think it's a significant weakening of the concept and a
misguided statement of design goal (Toby: I'm objecting to the framing,
not necessarily to your true goal).

There are two problems with this framing:

1. The trust decisions of most users are ill-informed. Bluntly, the
overwhelming majority of users are incapable of exercising good judgment
in these decisions, because they don't know enough about the
consequences of their decisions. In consequence this framing would make
POLA useless as a design principle.

2. In a well-designed system, many entities will operate just fine with
considerably less trust than I might be willing to give them. For
example, the entire security of any system rests on the correct
execution of its authentication system. It does NOT follow that I should
grant that system greater authority than it absolutely requires. Indeed,
the *reason* that I might be willing to trust it further is essentially
intertwined with the fact that, as designers, we chose NOT to extend it
(Continue reading)

Permalink | Reply | 16 comments |
headers
Toby Murray | 17 Sep 2007 17:08
Picon
Picon

Re: Reinterpreting POLA - "Authority Must Not Exceed Trust"

On Mon, 2007-09-17 at 15:35 +0100, David Hopwood wrote:
> Toby Murray wrote:
> > Hi cap-talk,
> > 
> > In my work on formalising authority, I've found it useful to strengthen
> > the usual notion of POLA to arrive at a more general definition of what
> > it means for a system to be 'secure'.
> > 
> > The traditional definition of POLA says that 
> > 
> > "the authority of each object/subject/program/process/user/whatever
> > should not exceed that needed for it to perform its function(s)."
> > 
> > This is useful but doesn't admit notions such as "separation of duty"
> > which need to be defined separately (because they appear orthogonal to
> > the above definition).
> > 
> > It also presumes there is some global administrator that can define the
> > correct function(s) of each entity in the system.
> 
> Correct function does not have to be decided by an administrator.

Good point.

> > Instead, I've found that a better definition of what we might desire is
> > 
> > "the authority of each object/subject/... should not exceed that which
> > we trust it to wield."
> 
> I don't think that switching from "needed to perform its function" to
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jed Donnelley | 17 Sep 2007 17:08

Re: [hcisec] Apparent implementation of a CapDesk-like system for Windows

At 9:21 PM on Sep 16, 2007, Peter Gutmann wrote:

I recently ran across something that looks like a commercial CapDesk-like
system, a bit like Polaris but it's an actual shipping commercial product.
Unfortunately the info on their web site,
http://www.gentlesecurity.com/technology.html, is a rather fuzzy, and the only
detailed review I've seen of it is in German (this month's iX magazine).   ...

I looked a bit through what I could find on-line for iX magazine, I assume:

http://www.heise.de/ix/

but was unable to find the detailed review that Peter refers to.
Perhaps somebody (Peter?) could supply the URL?  My German is rather
weak, so I'm not confident I'd be able to get a detailed understanding
from the article, but I have a number of German colleagues who I might
be able to ask to review the description so that we could discuss
it, if that seems worthwhile.

At 03:20 AM 9/17/2007, Mark Miller wrote:
On 9/16/07, pgut001-kVWAYfnMFF2W8ldZTk/re6VXKuFTiq87@public.gmane.org <pgut001-kVWAYfnMFF2W8ldZTk/re6VXKuFTiq87@public.gmane.org> wrote:
> I recently ran across something that looks like a commercial CapDesk-like
> system,

>From a brief glance, I notice that the diagram they use at
< http://www.gentlesecurity.com/pix/005_1.png> is an almost perfect
transpose of the diagram we've been using to explain the benefits of
the CapDesk-like approach, though
< http://www.gentlesecurity.com/comparison.html> makes no mention of
CapDesk, Polaris, Plash, or Bitfrost.

Hmmm.  That "comparison" is awfully generic.  The description of their "access control policy" on:

http://www.gentlesecurity.com/restriction.html
_____________

The GeSWall access control policy determines how GeSWall will restrict access by applications to system resources. Resources are files, registry keys, processes etc. and all resources are categorized as either untrusted, trusted or confidential.

The access restriction policy is composed of both generic rules which apply to all applications and specific rules which apply to only one application.

The generic rules for an isolated application are that the application:
  1. Can read but cannot modify trusted resources.
  2. Cannot read or modify confidential resources.
  3. May create new untrusted resources, e.g. files.
  4. May read or modify untrusted resources.

The only generic rule for a non-isolated application is that the application cannot load untrusted executables into its address space. All other resources access are allowed.

These generic rules are overridden by any application specific rules in the application database.

All resources are trusted except those created by isolated applications. Resources created by isolated applications are untrusted. Confidential resources are any resources, which are marked as confidential in the database. By default, any files in a user My Documents\Confidential folder are confidential. You may specify additional untrusted and confidential resources explicitly by their name or ownership.
________________

sounds quite unlike POLA/capabilities to me:

Firstly with regard to POLA:  At least in so far as the discussion focuses on the "generic" access control policy for 'isolated' applications, it seems that they have an 'ambient' authority mechanism.

Secondly, with regard to the dynamics of access control (e.g. the permission as parameter mechanism that capabilities use):  I don't see anything that suggests how permissions are granted - namely added to their "application database".  However, the fact that it is referred to as an "application database" suggests to me that the changes are unlike parameter passing - i.e. unlike capabilities.

When they discuss their demo on:

http://www.gentlesecurity.com/demo.html

I have to admit that a description like:
____________
Please note attacks are simulation of actions identical mal-ware ones. No any info is really leaked or file deleted from your system. After every attack probe, script performs cleanup by deleting created files and registry keys.

Once script completed command prompt kept open, so you can review whole output or re-start the script again.
____________

doesn't inspire a lot of confidence.  I'm reluctant to trust this code on a Windows system that I need for anything else.

Has anybody else run the demo (e.g. with no apparent negative results from an install, run, uninstall)?

Also, they use the "mandatory" term, e.g. from:

http://www.gentlesecurity.com/technology.html

as, "The key feature of GeSWall is the unification of a mandatory multi-level security policy with usability."

Naturally one wonders what they mean by 'mandatory' in that context.  That is, 'mandatory' from what viewpoint?  I don't want to dive into that discussion here, but it certainly suggests that at least from the viewpoint of what they refer to as 'isolated applications', such applications are unable to dynamically effect access control.  E.g. unable to communicate permissions as 'capabilities'.  That to me sounds like something more along the lines of an "SELinux" add on that would likely be so rigid (from the viewpoint of running applications) and demand so much privileged attention (whoever or whatever is able to change the 'application database') as to be effectively unusable beyond a few canned demos.

Of course these thoughts are just from the rather limited information I've been able to get from their Web site.  I'd be interested to hear more about how their "application database" is managed and how it's access control restrictions are enforced.

--Jed  http://www.webstart.com/jed-signature.html 
_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk
Permalink | Reply | 0 comments |

Gmane