I agree entirely that least privilege is the only intelligent policy, and e-speak encourages it. It is unfortunate that our users demand the familiar, insecure approach. This fact doesn't prevent a careful user from doing things safely.
Look at the various ways that "cp" could be provided.
% cp foo.txt bar.txt
providing his personal names for the two files associated with the labels "foo.txt" and "bar.txt", along with names of key rings containing the access rights to be applied. The service receives the request and knows what access rights the client has. The request fails unless these rights include read on foo.txt and write on bar.txt. The default behavior, as demanded by our users, is all the access rights of the client, even though we can construct a key ring with exactly the minimum set of rights needed for the operation.
By the way, the names foo.txt and bar.txt may have no relation at all to the actual name of the files on the disk. This feature allows the file system to move files around as needed without invalidating names provided by clients. It also means that the file system does not need to understand the name syntax used by the client. Further, there are no attacks based on guessing names of someone else's files or names on the disk.
2. "cp" is a method in a service that does not own the disk. In this case, the client must transfer rights to the service. In e-speak Developer Release (DR) 3.0 (the new name for Beta 3.0), SPKI attribute certificates are delegated. In e-speak Beta 2.2, a new key ring is created with exactly the rights being granted. The request to the service now includes a name bound to this key ring. The service now has names bound only to the files named by the client and a key ring with exactly the privileges needed. It can now submit the request to the "real" file system service. Note that in e-speak Beta 2.2 we can revoke the delegated privilege by simply destroying the key ring. We can even revoke the name bindings. (If you really want to know, I'll tell you.)
A service constructed this way is subject to fewer attacks than a real file system. If constructed properly, it will remove all the bindings associated with a given request as soon as the command has been processed. This "outer scope provides no authority ...", as you put it. Thus, even an attack that gets the service to execute an arbitrary piece of code can't get the service to do something that the client could not have done. In other words, we've simplified the code needed to prevent the deputy from being confused.
3. "cp" is a program running client's process using child processes of the client. In this case, one child reads one file and another writes the other. One child can be given read privilege, and the other, write access. This approach reduces the chance that a write would occur even if the read fails. Delegation of authority can be done exactly as in case 2.
Note that in the latter two cases, a careless user might forward a key ring with more than the minimum authorities required to do the job. However, two features of e-speak provide some protection for such a user. Firstly, all the user need do is destroy this key ring to revoke all the granted privileges. Secondly, the service only has name bindings for files provided by the client. Since names are meaningless outside a client's name space, there is no way for the service to affect other files even while holding privileges to them. Thus, a careless user is at more risk than a careful one, but we've reduced the number of things that he needs to get right.
Now, let's get back to grepping a large number of files. There is no way to escape the fact that the process doing the grep needs read permission on each file. I could, of course, grant the child the permissions one at a time as it needed to open the files, but I bet the performance would be pretty bad, and I'd need to be sure to revoke one before giving out the next. Instead, in e-speak Beta 2.2, I'd construct a key ring with the key(s) granting read permission to these files and pass a name binding for it to the child. I'd also give the child access to the part of my name space containing bindings for the files to be searched.
> -----Original Message-----
> From: Mark S. Miller [mailto:markm@caplet.com]
> Sent: Sunday, July 09, 2000 11:18 AM
> To: Karp, Alan
> Cc: 'Jonathan S. Shapiro'; e-lang@eros-os.org
> Subject: RE: Split Capabilities: Making Capabilities Scale
>
>
> At 11:11 AM 7/6/00 , Karp, Alan wrote:
> > > As an aside, I'ld argue that it is *rarely* the case that
> > > users may wish to
> > > share objects in bulk, and *never* the case that correctly
> > > designed programs
> > > should do so. Up to a point, the fact that capabilities means
> > > that they
> > > reinforce good design practices.
> >
> >Actually, I think the situation is quite common. Many times
> when I fork a
> >process, I'd like the child process to have a substantial
> fraction of my
> >privileges. Not every time, but many timmes. For example,
> a word processor
> >I spawn will need access to fonts. A build will need access
> to source and
> >object files and the required executables. Each of these
> requires transfer
> >of a potentially large number of capabilities.
>
> This is a defining issue of conventional capability style:
> The principle of
> least authority. For non-legacy-oriented code, we believe
> the child process
> (or whatever) should be given access to exactly those
> capabilities plausibly
> needed for it to carry out its duties. A great example (from
> Dean Tribble)
> is the difference between a file copy routine written in the
> Unix style vs
> the capability style. In the Unix style, we understand
>
> % cp foo.txt bar.txt
>
> to be passing the strings "foo.txt" and "bar.txt" to the
> program designated
> by "cp". The shell evaluates (sort of) the name "cp" to a
> program, but it
> does not evaluate the arguments to files. Instead, it leaves
> it to the cp
> program to do so. Therefore, the cp program needs access to
> the invoker's
> entire accessible file system merely in order to look up
> these two names!
> Any such system is begging for trojan horse viruses.
>
> By contrast, the corresponding E command line
>
> ? cp ( <file:foo.txt> readOnly, <file:bar.txt> )
>
> gives the "cp" function access only to the File objects that the two
> arguments evaluate to. It would not have access to anything
> else. To
> understand the authority needed to issue this command line,
> we need to
> expand the URI syntactic sugar:
>
> ? cp ( file__uriGetter get("foo.txt") readOnly,
> file__uriGetter get("bar.txt"))
>
> The outer scope for interactive commands or top-level *.e
> scripts (the E
> equivalent of "main") contains powerful capabilities (like
> file__uriGetter)
> that provide all the authority of their process. Under
> legacy OSes, this is
> normally also all the authority of their "user". This is a dangerous
> environment, and the E programmer should do very little in
> this scope other
> than to invoke other services (like the above hypothetical
> "cp") with well
> chosen narrow authorities derived from these broad
> authorities. I take it
> this dangerous scope corresponds to the E-speak root name
> frame or the
> KeyKOS root login directory?
>
> Invokable services (like "cp") are defined in *.emaker files,
> whose outer
> scope provides no authority whatsoever to effect the world outside of
> itself, other than to use computational resources. (Note:
> this claim has
> yet to be fully implemented.)
>
> An E user that's sloppy about the principle of least authority might
> leave out the "readOnly" above, in which case everything
> would still work if
> "cp" operates correctly. If "cp" is buggy or malicious, the
> extra damage
> would be limited to modifications to the file named
> "foo.txt", rather than,
> as in the Unix case, all files modifiable by this user. Why
> is this safety
> so free of notational cost? Because we have to designate to
> cp what files
> we're interested in anyway. As long as these designations
> are evaluated in
> the invoking context rather than the invoked context, as is
> the case in any
> lexically scoped programming language, we're most of the way there.
>
> From what I've read, E-speak has a similar perspective on
> names. So perhaps
> it can dispense with granting authority en-masse to child processes?
>
>
> Cheers,
> --MarkM
>