[cap-talk] Music organizer example (was: Capabilities and Freedom vs. Safety)

[David Hopwood]

James A. Donald wrote:
>  > > > Could you detail how a Trojan or malware could be
>  > > > designed as to effective when run confined?
> 
> James A. Donald:
>  > > Imagine a program that plays music, and gets free
>  > > legal music off the internet, and organizes your
>  > > music files and reports your music files to the RIAA
>  > > through backchannels that exist during its downloads
>  > > of free legal music.
> 
> Pierre THIERRY
>  > That sounds like an application of the Principle of
>  > Most Authority... Why would I ever want to have a
>  > single program have so much authority at once?
>  >
>  > Why wouldn't I just have the following separated
>  > programs:
>  >
>  > - one to play music (only authorities: reading files I
>  > ask to play and
>  >   sound output),
>  > - one to organize my music (authority: reading all my
>  > music files, maybe
>  >   some kind of powerbox to delete them),
>  > - one to download music (authority: restricted network
>  > access and adding
>  >   new files to an incoming directory),
> 
> The you have to download music, then run another program
> to play what you just downloaded - you the human has to
> transport information between these two programs by
> hand.
> 
> An all in one program provides substantial convenience.

If you simply assume that all users want the same thing, then
you necessarily reduce security for any users who would be
perfectly happy with separate programs.

It's very common to hear the argument "users won't accept that",
without any evidence of an attempt to ask users what they want
after first explaining the security consequences.

> More convenient to play as it is being downloaded, and
> after the song is finished, decide to add it to your
> file collection, or not.

That is straightforward to implement without requiring that a
single program have all the permissions involved.

Player instance:
 - sound output
 - read access to a data pipe
 - access to its own window if needed

Organizer:
 - read all metadata of files in the music database
 - send a file to the player's data pipe
 - access to its own window

Downloader instance:
 - communicate with some set of Internet sites
 - send a file to the player's data pipe
 - add a file to the music database
 - access to its own window

(The Downloader is a role that a program can have, not
necessarily a single program. A web browser or a file sharing
client can be given permission to add to the music database,
for instance, perhaps only with user confirmation. Communication
with different sites should be isolated.)

Now, since there is no Organizer -> Downloader information
channel, the contents of the music database cannot leak.
(Well, it can potentially leak over covert or side channels,
but we can audit the Organizer source for attempts to set up
a covert channel more easily than we can audit it for any
possible security flaw.)

Each site that provides music can report to the RIAA what
files it has provided, but it cannot report what files other
sites have provided.

This is implementable in a protected capability system, but
in an unprotected system, we cannot guarantee that the
Organizer will not obtain a capability-as-data that allows
it to leak the database contents.

> And then of course you want to
> browse your file collection.  Inconvenient to switch
> programs at that point.

Why? A single program would probably have separate windows
for downloading new files and for browsing existing ones, anyway.
As long as there is an "Add this file to my music database"
control in the Downloader, I don't see what the usability
issue is here.

If you insist on the Organizer and the Downloader sharing a
window, then it becomes very difficult to stop them from
having two-way communication.

> You could browse it with the
> standard file powerbox, in which case the program would
> only detect copyrighted music when asked to play it,
> though that would be bad enough, but it is useful to
> browse your music file collection organized as music, in
> which case the program would need to be empowered to
> detect all of it.

I certainly don't want any sound file that happens to be
stored on my hard disk to be automatically treated as a music
file. I want only files that have been explicitly added to the
database to be accessible to the Organizer.

(I might do a search for sound files using the shell, and then
choose to add some of those to the database, but there is no
need for the Organizer itself to have the authority to do that
search.)

-- 
David Hopwood <david.hopwood at industrial-designers.co.uk>