FW: [IP] The Third Annual Workshop on Economics and Information Security (fwd)

>  >
>  >                  The Third Annual Workshop on
>  >                Economics and Information Security
>  >                            (WEIS04)
>  > 		       May 13-14, 2004
>  >                    University of Minnesota
>  > 	       http://www.dtc.umn.edu/weis2004
>  >
>  > Submissions due: March 1, 2004
>  >
>  >    How much should we spend to secure our computer systems?  Can we
>  > determine a.which investments will provide the best protection?
>  >  How will
>  > we know when we've reached our goals?  Can market forces 
> ensure that
>  > firms will act to improve security?  Can incentives align 
> the goals of
>  > employees with the security goals of their employers?
>  >
>  >    While security technologies have benefited from decades 
> of study,
>  > there has been a dearth of research into decision making
>  > tools required
>  > to choose among these technologies and employ them properly.  The
>  > growing importance of information security and the failings of
>  > technology-centric approaches have made security economics an
>  > area ripe
>  > for new research.  There is much work to be done both in applying
>  > existing economic tools to today's security questions and in
>  > pioneering

Enforcement of limited transfer of capabilities

Re: Enforcement of limited transfer of capabilities

On Tue, Dec 09, 2003 at 05:20:48PM +0200, Netta Ganor wrote:
> Describe a mechanism by which an operating system can enforce limited
> transfer of capabilities: Process A might transfer a capability to
> process B, but A wants to prevent B from transfering the capability to
> any other processes.  Your design should include a description of the
> activities performed by A, B & the operating system, plus the
> information maintained by the OS. No programming here, just theory. 

That looks a lot like an assignment. But I can certainly point you in
the right direction. This is one of two possible problems, the first is
confinement, addressed in [1], and the second is non-forwardable
credentials, which (IIRC) is impossible/useless in a capability system.

[1] http://zesty.ca/capmyths/ (my favorite paper)

--

-- 
Taral <taral@...>
This message is digitally signed. Please PGP encrypt mail to me.
"Be who you are and say what you feel, because those who mind don't
matter and those who matter don't mind." -- Dr. Seuss

Re: Enforcement of limited transfer of capabilities

On Wed, 2003-12-10 at 12:16, Taral wrote:
> On Tue, Dec 09, 2003 at 05:20:48PM +0200, Netta Ganor wrote:
> > Describe a mechanism by which an operating system can enforce limited
> > transfer of capabilities: Process A might transfer a capability to
> > process B, but A wants to prevent B from transfering the capability to
> > any other processes.  Your design should include a description of the
> > activities performed by A, B & the operating system, plus the
> > information maintained by the OS. No programming here, just theory. 
> 
> That looks a lot like an assignment. But I can certainly point you in
> the right direction. This is one of two possible problems, the first is
> confinement, addressed in [1], and the second is non-forwardable
> credentials, which (IIRC) is impossible/useless in a capability system.
> 
> [1] http://zesty.ca/capmyths/ (my favorite paper)

Can be implemented. Cannot be useful.

shap

Re: Enforcement of limited transfer of capabilities

On Wed, Dec 10, 2003 at 11:16:40AM -0600, Taral wrote:
> On Tue, Dec 09, 2003 at 05:20:48PM +0200, Netta Ganor wrote:
>> [ assignment for non-copyable capabilities ]
> That looks a lot like an assignment. But I can certainly point you in
> the right direction. This is one of two possible problems, the first is
> confinement, addressed in [1], and the second is non-forwardable
> credentials, which (IIRC) is impossible/useless in a capability system.

I'm not sure it is impossible or useless; a Time To Live counter in the
capability that is decremented every time the kernel is asked to transfer
a capability could solve this. Or, if it was a supported feature for
one process to ask the kernel which other process performed the request,
a proxy could be written to ensure only process B invokes the capability.

Of course, in both casses, B could act as a proxy. Confinement problem..

--

-- 
A: No.
Q: Should I include quotations after my reply?

Re: Enforcement of limited transfer of capabilities

In a social policy system, limited transfer may make sense.

In a computational system, limited transfer is inherently advisory: if
the software holding the authority is hostile, it can proxy whenever it
cannot transfer.

So my objection to limited transfer is that it is (a) expensive and (b)
ineffective. The TTL counter you propose has been implemented in several
systems, but has never provided any security benefit.

shap

More details on Membrane pattern?

I've been reading a lot about capabilities-based security since discovering
erights.org, but I don't think I've quite got my head around the Membrane
pattern yet. It might be helpful if I could look at some code or at least
pseudocode.

Questions I have:

1. What is the rigorous definition of the boundary of the membrane?
2. How is a membrane to be implemented?
3. How do/can N membranes coexist and "intersect" - does this cause any
complications, or no?
4. What are the efficiency implications?

It seems to be somewhat related to the problem of advising specific object
instances in aspect-oriented programming, which I briefly looked at when at
uni. However, in that context I was wrapping co-operative code - or to
be more precise, my own code - and I don't recall working out a completely
general pattern for it. It's just vaguely reminiscent, that's all, so I
just thought I'd mention it - might be some useful crossover there, but I'm
not sure.

Cheers,
--

-- 
Robin
GNU/vegan transhumanist

Re: Enforcement of limited transfer of capabilities

Jonathan S. Shapiro wrote:

> In a social policy system, limited transfer may make sense.
> 
> In a computational system, limited transfer is inherently advisory: if
> the software holding the authority is hostile, it can proxy whenever it
> cannot transfer.
> 
> So my objection to limited transfer is that it is (a) expensive and (b)
> ineffective. The TTL counter you propose has been implemented in several
> systems, but has never provided any security benefit.

Clearly the original question was set by a Microsoft-sponsored 
university. As I've pointed out before, Palladium would permit you to 
construct a system where you could enforce limited transfer.

Assuming, that is, you can make Palladium work.

Cheers,

Ben.

--

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Re: Enforcement of limited transfer of capabilities

At 02:04 AM 12/19/2003  Friday, Ben Laurie wrote:
>Clearly the original question was set by a Microsoft-sponsored university. 
>As I've pointed out before, Palladium would permit you to construct a system 
>where you could enforce limited transfer.
>
>Assuming, that is, you can make Palladium work.

Assuming you can make Palladium (or a Palladium-like system) work, what is 
it you're claiming would be enforceable? A limited transfer of permissions[*]
is trivially enforceable in any object-capability system without need for 
hardware support. But it's useless because: Limited transfer of authority[*] 
seems unenforceable in any system, whether there is special hardware support 
or not.

[*] See the definitions of "permission" and "authority" in section 2 of 
Paradigm Regained http://www.erights.org/talks/asian03/index.html .

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

        Cheers,
        --MarkM

Re: Enforcement of limited transfer of capabilities

Thanks again.

A Microsoft-sponsored university...hehe...

      V
    (o o)
   (  V  ) http://go.to/netta
 ---m-m---

----- Original Message ----- 
From: "Ben Laurie" <ben@...>
To: <cap-talk@...>
Sent: Friday, December 19, 2003 12:04 PM
Subject: Re: [cap-talk] Enforcement of limited transfer of capabilities

> Jonathan S. Shapiro wrote:
>
> > In a social policy system, limited transfer may make sense.
> >
> > In a computational system, limited transfer is inherently advisory: if
> > the software holding the authority is hostile, it can proxy whenever it
> > cannot transfer.
> >
> > So my objection to limited transfer is that it is (a) expensive and (b)
> > ineffective. The TTL counter you propose has been implemented in several
> > systems, but has never provided any security benefit.
>
> Clearly the original question was set by a Microsoft-sponsored
> university. As I've pointed out before, Palladium would permit you to
> construct a system where you could enforce limited transfer.
>
> Assuming, that is, you can make Palladium work.
>
> Cheers,
>
> Ben.
>
> -- 
> http://www.apache-ssl.org/ben.html       http://www.thebunker.net/
>
> "There is no limit to what a man can do or how far he can go if he
> doesn't mind who gets the credit." - Robert Woodruff
> _______________________________________________
> cap-talk mailing list
> cap-talk@...
> http://www.eros-os.org/mailman/listinfo/cap-talk