• Messages sorted by: [ date ][ thread ][ subject ][ author ]
• [ Next ][ Previous ] Maybe in reply to: Jonathan S. Shapiro

[Please note that I have moved this discussion to cap-talk, since it is not really EROS specific. The original problem was to prevent a program from leaking sensitive bank information. The second response is quoted at the bottom. ]

> I'm beginning to suspect I should shut up until I'm better acquainted
> with how EROS does things.

Actually, this is precisely why you *should* ask these questions. How else can the answers end up in the FAQ?

> I'm having problems understanding who "you" is and how "you" "hands"
> things about the place, what a "trusted system intermediary agent" is
> and how it "checks with you". And so on...

"You" is actually a program operating on your behalf. It holds a capability on your behalf, and can either transmit it or not transmit it.

The sorts of leaks you are concerned about can occur only when an untrusted program holds (simulaneously or in sequence) a capability conveying access to sensitive data and also a capability conveying authority to communicate with an unauthorized party.

The source of the confusion may lie in a POSIX assumption. In a POSIX system, any program can make a "socket" call and get their hands on a network connection. The right to create a socket is therefore part of a program's "intrinsic" authority.

In a capability-protected system, sockets can only be created if the program holds a capability for the networking subsystem. [ Such a program would not be considered confined, by the way. ] Further, two programs can communicate only if one holds a capability for the other. By being careful what capabilities are handed to a program, the sequence leading to exposure can be eliminated.

The "trusted agent" I had in mind is an "open file" utility. Instead of giving the application access to the file system, give it access to a utility that will ask the user where things should be stored, and can alert the user that the application may be working with sensitive data.

> > Suppose you have a system that is initially confined. This means that
> > it initially has access to none of your precious information, and also
> > that it initially has no outward communication channels.
> >
> > You control where things go from here. You can hand it precious data
> > or not. You can hand it an authenticated connection (presumably safe)
> > afterwards and still be safe. You can hand it the authority to make
> > arbitrary connections and lose your shirt. You can hand it the
> > authority to make arbitrary connections by means of a trusted system
> > intermediary agent that will check with you first and retain some
> > control.
> >
> > Provided that you control the outbound communication paths correctly,
> > there is no danger in handing a confined subsystem access to sensitive
> > information. More precisely, there is no additional danger beyond the
> > inherent exposure in performing the communications that were necessary
> > to perform the requested transaction.
> >
> > In your example, the more interesting case is actually in controlling
> > account access. You'ld like to know, for example, that the web page
> > generator that displays account balances does not have the authority
> > to do transfers between your accounts.
>

• [ Next ][ Previous ] Maybe in reply to: Jonathan S. Shapiro