Towards a secure XMMS

[Jonathan S. Shapiro]

Let me try to tie up some of these loose ends by working through the
previously mentioned example: design of a secure XMMS. Please remember:
I'm not a media guy, so there are probably a lot of real-world
requirements that I do not understand. I'll be happy to iterate.

For the first description, I'm going to make some absurd
simplifications, including a completely unacceptable user interface that
asks too many questions of the user. All of these issues can and will be
fixed in subsequent refinements, but I would like to do things in steps.
Here are things that I will answer in later refinements:

  1. How to avoid asking the user about every file.
  2. How to stream from the internet
  3. How to give CXMMS real-time and pinning authority without
     giving this authority to users in general.
  4. How to do secure windowing in secure sessions. I will not
     address this in these notes -- go read the paper.

I want to make it clear that this design is not a simple thing. We are
asking CXMMS to defend us against hostile CODECs and hostile audio/video
(both of which really do exist), and ultimately to do so while accessing
the internet. There is no way that this is going to happen without
rewriting the XMMS "shell". We *should* be able to save almost all of
the CODECs, however.

Finally, some of the stuff I will do really needs to be packaged better.
Lots of applications do these things, and we need to make it easy to do
them safely. But the first goal is simply to show that it is *possible*
to do it safely.


Because it is a real-time application, CXMMS runs with a fair bit of
unusual authority. This includes the authority to pin pages and run
under a real-time schedule. We do not necessarily want the user to have
this authority, and we will need a protocol to guarantee that. I will
offer one tomorrow. For the moment, permit me to simply declare that
this can be achieved and that we will solve it as a separate problem.


Okay. For the very first version, let us build a CXMMS that plays
exactly one file which is opened interactively. The user holds a CXMMS
constructor and invokes it to create a new CXMMS, passing a window
manager context and a "power box". A power box is simply a collection of
programs that act entirely on behalf of the user, and stand between
potentially broken (or hostile) programs and the user's state.

Note one permission that CXMMS does NOT have:

  - No access to the user file system.

The first step is that CXMMS must get the file to play. Since it has no
direct access to the file system, it must ask a component in the power
box: the open/save-as tool. It goes to this tool and issues an RPC that
amounts to "OpenAFile()"

The job of the open/save-as tool is to act as the user's agent, not the
application's. The open/save-as tool *does* have access to the user file
system, and it has access to the window system that is independent of
CXMMS. The open/save-as program interacts with the user to learn what
file should be opened. This file is opened **by the open/save-as tool**
and a read-only capability is returned to CXMMS.

  Note that the first piece of security has already happened: CXMMS
  never has write access to the file or the user's file system.
  In fact, CXMMS never even knows the file name.

  Further, note that there is no way for CXMMS to bypass the user
  and open this file without the user's explicit consent.

  Finally, note that the open/save-as box is an existing, familiar
  idiom that the user understands. In this case we can (and will)
  do better than this, but the point is that a lot of security
  benefit happened simply by moving the open call into a
  user-trusted subsystem.

CXMMS now looks at the file to determine the appropriate CODEC type. In
order to do this, it must first learn what CODECs it has and how to
pattern match for the right one.

Obviously, we want installable CODECs, but let me pretend (temporarily)
that all CODECs were known at compile time. In this case they would have
been compiled in to the CXMMS constructor. These precompiled CODECs take
the form of individual CODEC constructors. CXMMS simply needs to start
the new CODECS one at a time and ask them to scan the image (this can
obviously be optimized). Before creating each CODEC, CXMMS creates a new
sub-bank from it's space bank.

  Note that because each CODEC is created by its own constructor, it
  is initially confined. Its storage and its schedule are restricted by
  CXMMS.

Assume that some CODEC says "I know that tune. Here, let me hum a few
bars."

CXMMS now requests that the song be played. It provides a capability to
the audio output system and the necessary capabilities to acquire a
real-time schedule and permission to pin pages. Each of these is a
*limited* capability -- CXMMS does not provide permission to grab
everything. It cannot. CXMMS never *had* this much permission.

The CODEC now runs. And runs. And runs. And doesn't play a thing. Slowly
it starts eating memory. At some point either the memory hits a limit or
the user says "forget it".

In either case, CXMMS must now kill an uncooperative CODEC. It does this
by simply destroying the appropriate sub-bank. Poof. No more CODEC.

In practice, we wish to configure new CODECs over time. The refinement
is to let CXMMS have read-only access to the CODEC directory (and *only*
the CODEC directory). This directory, in turn, holds CODEC constructors.

A very similar approach would allow us to skip the open/save-as box: we
can give CXMMS read-only access to the music directory (and ONLY the
music directory).


For the moment, this should be enough to generate considerable
confusion, so I will wait on the other refinements until this part is
clear enough. I am sure that my description is poor, because I am very
very tired. PLEASE ask questions!


shap