[cap-talk] Reducing Ambient user authority in a Type Safe/Memory Safe OS.

[David-Sarah Hopwood]

Ben Kloosterman wrote:
>>>> What process is this code in, and why does it have the authority to
>>>> amplify any FileCapability to r/w (i.e. where did it get KeyStore
>>>> from)?
>>>
>>> The code is in a trusted system library but it runs in the programs
>>> address space ( really object space) ,
>>
>> The browser program, I assume?
>>
>> So the browser has authority to amplify any browse capability to a r/w
>> capability. This raises several questions:
> 
> No the elevation code would run from the word processor.

That doesn't help, because now you've greatly increased the wordprocessor's
authority. I showed in my other follow-up how to reduce the authority of
both the browser and the wordprocessor.

>  > - how did it get this authority?
> 
> The RW ?  It can only elevate to a RW the word processor would have.
> The word processor may have the authority because it has RW authority
> to all the users doc files

As I said earlier, that is far in excess of what is needed.

> or it may have it because the document was created with the word processor.

That doesn't imply that any new instance of the wordprocessor should
have it.

(Although different instances need to share configuration information,
it's possible to allow that without allowing them to share documents,
provided that the code which modifies the configuration is reviewed to
make sure that it is not making use of it as a covert channel. Even
without such review, isolating instances helps against implementation
bugs, and potentially against attacks via scripts or macros, for a
wordprocessor that is not actively malicious.)

>  > - why should it have it? (it certainly seems like excess authority)
> 
> The ability to escalate an incoming request to your defined authority
> would mean you could reduce the level of authority the caller needed. 

No, the implicit escalation effectively increases the authority of callers,
since a caller can pass a browse capability, but have the target actually
use a r/w capability. This makes a browse capability effectively equivalent
to a r/w capability whenever the target of the call has the latter. It
also *requires* the target to have the latter, even when that is excess
authority.

A reduction in authority is only achieved if the caller is a subject that
would otherwise have needed to hold r/w capabilities to the same files.
In the BrowserManager approach suggested in my other follow-up, that is
indeed the case because:

 - only the intended browser instance is given the BrowsableFilesystem
   containing browse capabilities.
 - the amplification also requires explicit use of the 'open' capability,
   which can be restricted to the code in the browser that needs to open
   files.

Also, in my suggested approach the wordprocessor instance is *not* required
to already have the r/w capability, which is a reduction in its authority.
This is actually more important than reducing the authority of the browser,
since we can perform a security review of the browser, but there is no
realistic prospect of reviewing the security of all applications, and the
wordprocessor is just standing for an arbitrary application.

In your approach, there is nothing to guarantee that the browse capability
is held by a process that would otherwise have held a r/w capability; and
you are requiring *every* instance of the wordprocessor to hold a r/w
capability for *all* the user's wordprocessor files. (This really matters,
because the user might well have different levels of trust in different
wordprocessors that are capable of reading the same file formats.)

Note that the inference that the wordprocessor should be granted the r/w
authority is sufficiently justified by the user selecting the file for
editing (and even if we wanted to apply some VOC policy limiting which files
can be edited, the solution to that would not be to give the wordprocessor
capabilities to those files in advance).

>  > - why is it not represented as a capability, and not delegatable?
> 
> The ability to escalate , it certainly could be , since you can only
> escalate incoming capabilities to your own authority for the same
> file/cap  it seems there is no risk ?

Yes, there is risk. In the original confused deputy example, for instance
(http://en.wikipedia.org/wiki/Confused_deputy_problem), nothing depends on
the use of filenames represented as strings. Suppose that the output file
of the compiler were specified as a browse capability to the billing file,
which is amplified to a r/w capability because the compiler already holds
it. Then the attack works just as before.

Besides the confused deputy problem, I think your reasoning here includes
a subtle mistake that occurs quite frequently in the design of security
mechanisms. The form of argument is:

  I can reduce the risk of granting authority A to subject S by
  requiring that S already holds A.

This sounds superficially reasonable, but consider: A may or may not be
excess authority for S. If we wait until we have some reason to grant A
to S, then that reason provides some evidence that A wasn't excess authority
for S. But if we require that S already holds A, then we're not just
imposing that requirement for A itself, but for all similar authorities
that we *might* have needed to grant to S. So such a requirement can be
expected to lead to the user configuring a laxer security policy than
was actually necessary, as a result of having to estimate in advance what
permissions might be needed.

> Practically it's probably part of the Keyring and since all processes
> have this there is no need to pass it around. 
> 
>> - why is it exercised implicitly when the browser sends a message
>    by IPC to any other process?
> 
> Let me explain normally when you open a word processor in say Windows
> the UI goes winword.exe fileToOpen.docx ( and it knows its winword
> because it is associated with that document or is manually selected
> with openwith) .

Believe it or not, I have used Windows :-) That wasn't what I was asking.

Observing what the user sees can only give you a lower bound on the
authorities needed. In this case, a wordprocessor instance ends up
with at least r/w authority to a particular file, while that instance
is open. That doesn't dictate how it got that authority, i.e. what
OS-level access control and authority propagation mechanisms were
involved, and it doesn't determine how much more authority than the
minimum will be granted by any particular system and policy.

In the case of Windows, the wordprocessor normally has the same
authority as the user. That's very obviously broken, so we cannot use
Windows (or any other OS with the same property, which is almost all of
them) other than as an example of what not to do.

> We don’t have such a command line so the browser though we could send
> the filename.  However rather than send the file name to indicate what
> you are trying to open you can send you browse capability ( if you had
> R/W you could send that ) which tells the system what the file is since
> the Capability is a reference to an underlying FileObject. 

As pointed out above, the confused deputy problem does not depend on the
use of string names.

> All im doing is replacing the  lookup of "fileToOpen.docX" string which
> would search the capabilities Winword has access too, with a strongly
> typed mechanism where I send the Browse Capability ( which references
> a file) and the store can doing an exact type safe lookup.

Looking up a filename in all the capabilities that the wordprocessor has
access to is the Wrong Thing, but that doesn't imply that looking up
some other designator is the Right Thing just because it isn't a string.

>> This all seems strictly worse from a security point of view than the
>> design I suggested where the browse capabilities are sealed r/w
>> capabilities. 
> 
> Im just a bit cautious here as I have seen so many holes with file
> association

Most of those holes in existing systems can be attributed to granting
excess authority, but to the invoked app, not directly the browser.

> and sending the R/W  seems to me to create more risk. 
> 
>> In particular, the implicit amplification on IPC would interfere with
>> splitting the browser into multiple processes, and makes it unnecessarily
>> difficult to see where the amplification authority is exercised in a
>> security review (since only a small proportion of the browser's uses
>> of IPC actually need this amplification).
> 
> I would agree if it was done in transmission but it gets done within
> the receiving process. 

That implies that the wordprocessor (or any application, since there is
nothing special about the wordprocessor) cannot receive a capability
without it being amplified, therefore cannot defend itself against
becoming a confused deputy. For instance, if the wordprocessor receives
a read capability then that will presumably also be amplified to a r/w
capability if a r/w capability to that file is already held. I hope it's
clear from my explanations above why that shouldn't happen.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20091222/7f4d3169/attachment-0001.bin