[cap-talk] ... enforcement - hope? Capabilities as clumsy, not

[Jed Donnelley]

At 11:38 PM 9/27/2004, Lorens Kockum wrote:
>On Mon, Sep 27, 2004 at 08:57:49PM -0700, David Wagner wrote:
> > Similarly, suppose a program executes:
> >   execv("./foo", {"./foo", "bar", NULL});
> > Should argv[1] ("bar") be interpreted as the name of a file,
> > or as a string containing ASCII text?  For instance, how do you
> > programmatically distinguish between the following two cases in
> > a way that respects capability discipline?
> >   $ echo Hello world
> >   $ cp notes notes.bak
> > Likewise, you can think of what you'll do if you see the
> > corresponding calls to execv().
>
>I think that for invokations like these, you'll need some
>kind of "capability interface description" (hereafter CID)
>that defines the interface in terms of what is on the command
>line. That would be David Wagner's third step: "some way (e.g.,
>policies) to tell which forms of sharing are safe and should be
>allowed."[1]
>
>Sure, the parsing of the Unix command line is not quite
>clear-cut, but it should be possible to make some kind of xml
>description of each program that would permit pointing out
>the resources to which read or read-write access is needed
>based on an analysis of the command line and mabe of stdin in
>some cases. Parsing the command line twice is a small problem
>that will go away in time, a smoot transition is much more
>important. The same CID can be used to define the rights the
>program needs, in a general "policy" way, so that when you
>install a third-party program, you need only review the CID, and
>not read the source line by line three times and recompile. The
>same syntax could be used to define the general rights of
>users (that one can make network connections with any program
>he wants, those ones have to use an administrator-installed
>browser, that one has no network access at all).

I agree that command line parsing to define rights communication
is an important compatibility issue.  We had some considerable
discussion on this topic on this list in the April/May time frame,
e.g.:  http://www.eros-os.org/pipermail/cap-talk/2004-April/001585.html

I don't think command line syntaces in the form they appear in Unix today
would exist if Unix had been a capability based system from the beginning
(sadly).  Still, they evolved as they did and we have to deal with them
or replace them.

However, I again point out that this issue is independent of the
value of using "object capabilities" for rights communication
across domains.  The various forms of command lines that arose
in Unix over the years (mostly the early years) arose out of the
assumption of ambient authority.  Namely, that the application
had exactly the rights of the user running it.  If applications were
typically run in a restricted domain of their own (which I hope we
all agree is a good idea for security reasons - mostly Trojan
horse issues) then they would likely have had a different syntax,
whether run as chrooted with restricted access or run in a
domain restricted to rights communicated by capability.

>...
>
>I want the OS, even at the cost of the Unix CLI that has eased
>the past ten years of my life, but I can have my capability OS
>and keep my CLI.

I pretty much agree with the issues as discussed above.

--Jed http://www.webstart.com/jed/