Re: Capsicum: Object capabilities for Linux

Jed Donnelley <capability-iCFHVraI1K1Wk0Htik3J/[email protected]>
Newsgroups gmane.comp.capabilities.general
Message-ID <[email protected]>
On 10/10/2013 12:53 AM, Bennie Kloosteman wrote:
> Capsicum has always been about getting capabilies into existing apps 
> as easy as possible  so its not an ideal implementation but gets the 
> job done.

I don't know about "ideal", but I do know the value of what Dr. Robert 
Watson refers to as "arbitrary interposition of all operations".  
Without that much (most?) of the value of capability systems disappears 
(in my view).  Can you explain (or point to a discussion) of why an 
interface that supports arbitrary interposition was considered to be 
incompatible with 'getting capabilities into existing apps as easy as 
possible'?  It isn't clear to me why there would be a conflict, but I 
expect I could understand the answer if somebody explained it.

> One common way which works well is to start the app as normal and than 
> activate capsicum mode which requires non powerbox caps being set 
> beforehand.  This is pretty easy eg i added it to mono eg load the C# 
> app , jit etc , then activate cap mode and run the program. And then 
> file.io <http://file.io> didnt work which is what i wanted as i wanted 
> a new cap file API (winrt) to be used , changing everything to caps 
> would have been far too much workbut they support that as well.  ( 
> Capsicum does have a client server mode where you split the app into 
> trusted and untrusted but its a big job changing existing apps) .

I think I can understand the work involved, but not why the amount of 
work depends on the support of non-support of "arbitrary interposition 
of all operations" in the capability interface.

I'd love to hear a bit about how directory capabilities work in Capsicum 
- e.g. compared to the way they work in the Tahoe file system or to 
GNOSIS or any of many other interfaces.  Driven by Unix symantics no 
doubt, but how does access right "masking" work when referencing through 
a directory capability?  How are links (hard and soft) handled?

> 4.  He mentioned Power Boxes.  Has any work been done on a windowing
> environment where it's the window manager that creates the "sandboxes"
> for applications that run with capability access only?
>
> I believe so .. on freebsd and X at any rate . ( check 
> gpowerboxserver.cpp).

Sorry, but I was unable to find any references by searching for 
"gpowerboxserver.cpp" or any of the many variations I tried.  Can you be 
a bit more explicit?

> "5.  He says that Google is working on a port for Linux?  Is that still
> active work?  If so, what is it's state?  If the Linux work is a true
> "port", does that suggest that the interfaces will go over unchanged (no
> hope for a more true object capability interface??"
>
> They have been saying that for years but i havent seen anything .. It 
> will be hard getting kernel changes approved.
>
> https://github.com/google/capsicum-linux
>
> There does seem to be work on the port.
>
> At any rate these are not big projects so dont expect too much.
>
> For the much larger linux community there is a lot of momentum  , so 
> hard to change  its not the OS  but getting all the apps to be 
> rewritten  , newer runtimes do have caps eg Android has some 
> capabilites and winrt has a really good model

Pointers?  Does any one person (or a few people) know enough about these 
capability models to contrast them with historical capability models 
and, in particular, with the "arbitrary interposition of all operations" 
property?

> but both platforms allow traditional apps.

That seems entirely reasonable to me, but if they support an object 
capability interface model (e.g. as discussed on this list) then there 
is the opportunity to start building a code base for essentially POLA 
applications, libraries, etc.

> There is hope on the desktop though as Capsicum seems to be the 
> default and in the Kernel on FreeBSD making FreeBSD attractive as a 
> secure platform .

Particularly with children now out of college and a secure retirement, I 
could see spending some time contributing work to such a "secure 
platform".  However, if the interface doesn't have the arbitrary 
interposition of all operations property then it would take quite a bit 
of wind out of my sails.

Is anybody doing any programming for any of these platforms who can 
discuss how "object" these capability models are?

This area really seems to me like a terrific topic for a friam meeting 
discussion if there is anybody (or perhaps a group of people?) 
knowledgeable enough to speak to it.

Sorry if I haven't been keeping up enough to know that this topic has 
already been addressed.  I've taken some quick looks through the archive 
and didn't see anything like this that caught my attention.

--Jed

<the rest is historical>

> Ben
>
>
> On Thu, Oct 10, 2013 at 3:09 PM, Jed Donnelley 
> <capability-iCFHVraI1K1Wk0Htik3J/[email protected] <mailto:capability-iCFHVraI1K1Wk0Htik3J/[email protected]>> wrote:
>
>     On 10/9/2013 12:56 PM, Tony Arcieri wrote:
>     > Seems relevant to this list's interests:
>     >
>     > https://github.com/google/capsicum-linux
>
>     Well...  I see Capsicum (misspelled in the subject - I corrected it in
>     this message) has been discussed on this list in the past.  It didn't
>     catch my attention before as I've been lurking and not very
>     active.  Now
>     that it has caught my attention I'd like to bring up some topics
>     (questions, etc.) and see if there are others interested enough to
>     comment.  Sorry if the questions are naive.
>
>     The first 5 questions refer to this 2010 talk by Robert Watson:
>
>     http://www.youtube.com/watch?v=raNx9L4VH2k
>
>     1.  At about 13:39 he says, "There are some ways in which our kernel
>     capabilities are not fully featured in a true capability system sense.
>     For example, we don't support arbitrary interposition of all
>     operations
>     on kernel provided capabilities - which leads to some design downsides
>     which we'll talk about as well."
>
>     He wasn't truthful about that in that he didn't talk about it later.
>     So...  Inquiring minds want to know.  Why didn't they allow arbitrary
>     interposition of all operations on kernel provided capabilities?  For
>     that matter, what are the operations on 'capabilities' (kernel
>     "provided" or otherwise)?  I guess I would like to hear about the
>     'design downsides' that he refers to, though I think I can pretty well
>     imagine at least some of them (see #7 below).
>
>     2.  I notice he mentioned JoeE.  Is there any work seeing if JoeE can
>     operate in one of these Capsicum sandboxes so as to support a faithful
>     mapping between the Capsicum implemented capabilities and JoeE
>     objects?
>
>     3.  Same question for E.
>
>     4.  He mentioned Power Boxes.  Has any work been done on a windowing
>     environment where it's the window manager that creates the "sandboxes"
>     for applications that run with capability access only?
>
>     5.  He says that Google is working on a port for Linux?  Is that still
>     active work?  If so, what is it's state?  If the Linux work is a true
>     "port", does that suggest that the interfaces will go over
>     unchanged (no
>     hope for a more true object capability interface??
>
>     ---  Just a mild style comment on the talk:  Dr. Watson seems very
>     deferential in his discussion of comparisons with MAC mechanisms -
>     such
>     as SELinux.  I have to admit that I have an automatic gag reflex
>     whenever I write or speak the word SELinux, but I think that even
>     objectively Dr. Watson didn't make clear just how problematic the
>     global
>     policy mechanisms of something like SELinux are.  It's like trying
>     to be
>     God or a Communist government developing a 10 year plan and tracking,
>     via explicit policy, everything that goes on in a computer system (not
>     to mention network).  Things change too quickly.  It simply can't be
>     done.   With capabilities (access control objects) you allow the
>     programmers to manipulate access control where it makes sense through
>     the communication channels between what he refers to as
>     "sandboxes" (in
>     other contexts processes or domains).  I believe this distinction is
>     significantly more than religion.
>
>     Now diverging a bit from the talk:
>
>     6.  How do people feel about the possibility of, uh, 'moving'
>     (pulling,
>     perhaps dragging) security interfaces in the direction of objects by
>     transiting code in Unix from ambient authority to capability access
>     control through a mechanism like Capsicum?
>
>     7.  If there is any hope for such movement, isn't it important to get
>     the capability model 'right' (at least supporting 'arbitrary
>     interposition' - as Robert puts it) to allow mechanisms like membranes
>     and perhaps [dare I say it?] things like network capabilities (trying
>     not to wet my pants) and perhaps a mechanism like Horton?
>
>     8.  Speaking of network capabilities - does anybody see any
>     opportunities for productive synergies between Capsicum and Waterken?
>
>     Thanks for any time folks might have to respond.  I'll try to stay
>     tuned
>     in for any discussion.  I'd be quite interested in any friam meeting
>     that would focus on opportunities and issues presented by Capsicum.
>
>     --Jed
>     _______________________________________________
>     cap-talk mailing list
>     [email protected] <mailto:[email protected]>
>     http://www.eros-os.org/mailman/listinfo/cap-talk
>
>
>
>
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.