Jay Oliveri:
> I don't know what to really think, since conveniently most of
> their evidence is under NDA.

Devising access control and permissions schemes to limit the
capabilities of code processing malicious data is a tricky business.
The question that needs to be constantly asked is, "Exactly what
capabilities does this program currently need?"

For instance, to play a movie from a file, mplayer needs to do three
things:

        (1) read the file
        (2) write to the screen
        (3) write to the sound card

It should not be allowed to do _anything_ else. Upon initialization,
mplayer should parse its options, determine that the user wants to
play a file from the disk, acquire from the OS those three
capabilities, and then irrevocably freeze them.

Capability definitions can be very explicit and sophisticated.
Consider the command:

        wget ftp://user:[EMAIL PROTECTED]/file.mp3

Like mplayer, we can specify that it needs to:

        (1) create "file.mp3" and write to it
        (2) establish a tcp connection to server.com

But (2) can be more specific; in fact, security demands that it be.
What if wget is compromised by some malicious server response, and
rather than merely downloading "file.mp3", deletes all your files on
the server instead?

The FTP commands wget may use must be explicitly specified!

Now, what is the most generic and powerful way to accomplish these
things?

One solution: upload a routine to the OS which may be called later.
In the case of wget, the network code, configured at initialization
time to only do what is necessary to download "file.mp3", is
uploaded to the OS, and its capabilities are extended to include
connecting to server.com:ftp. wget then freezes its capabilities,
revoking permanently its ability to upload any further routines or
acquire any further capabilities, and executes normally, making use
of the uploaded networking code when necessary.

Of course, if the uploaded code itself is vulnerable to exploits,
the elevated capabilities of the uploaded code may be exploited.

_______________________________________________
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl

Reply via email to