[cap-talk] Reducing the authority of a file browser in a capability OS.

[David-Sarah Hopwood]

Rob Meijer wrote:
> On Tue, December 22, 2009 03:37, David-Sarah Hopwood wrote:
>> Ben Kloosterman wrote:
>>> the file explorer browser
>>> will invoke via a file association the word processor it will then pass
>>> in its own browse capability to the file to indicate the file ( this
>>> being more secure than passing in the file name) . The word processor
>>> itself will check if it has a higher level capability for the file.
>> Why would the wordprocessor already have a more powerful capability?
>>
>> First, you don't appear to be distinguishing between applications and
>> application instances. This is a common mistake that almost inevitably
>> leads to systems that require excess authority.
>>
>> The user has only just indicated that they want *a new instance* of the
>> wordprocessor to be able to edit the file. For either the instance or
>> the application to *already* have a capability to do that is not needed,
>> and would defeat the advantage of the powerbox pattern in maintaining
>> POLA.
> 
> I know I have tried to make this point a few times before, but one reason
> why the word-processor could already have a more powerful capability may
> be that the word-processor created the file.

I answered that already in this thread:

# Ben Kloosterman wrote:
# > or it may have it [a r/w capability to the file] 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.)

> If the system has some way to
> restart the instance that created the file (a pseudo persistent process),
> than this instance would have persistent access to the files it created.

Why should it? If we're just talking about document files, then that's
excess authority.

> For example if we have the word processor that created the file, and the
> file is your resume. There seems no reason why you would for example want
> to place the rw cap into the main shell (powerbox) its namespace. A ro cap
> yes, as you may want to mail it, print it, etc, but no other application
> should need to update the file, so the user would not need to link the
> powerful cap into the shell/powerbox its namespace.

A similar effect could be obtained by having the app seal the file contents
with a sealer for which only it holds the unsealer. Note that the app can
do this on its own; it doesn't need cooperation from the browser.

However, doing that (or any other approach that only grants access to the
file to one application) prevents the user from making use of interoperable
file formats and switching between compatible applications. That is, the
assumption that "no other application should need to update the file"
results in the user's data being fragile and dependent on a particular app.
I certainly wouldn't want to do this for my resume, or any other important
file.

-- 
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/f8ef1a97/attachment.bin