On Fri, Sep 5, 2008 at 10:12 PM, David-Sarah Hopwood
<david.hopwood at industrial-designers.co.uk> wrote:
> Ben Laurie wrote:
>> On Thu, Sep 4, 2008 at 10:39 PM, James A. Donald <jamesd at echeque.com> wrote:
>>> Ben Laurie wrote:
>>>> I agree that the problem of making the security decisions is
>>>> considerably harder than that of enforcing them.
>>> Hence the powerbox user interface model of piggybacking permission on
>>> designation.
>>
>> This particular assertion is beginning to really bug me. Designation
>> works fine for files, maybe, and for drag'n'drop, even more maybe (are
>> you granting read? write? a communications channel? is it permanent or
>> temporary? etc). But I've yet to see any evidence that it makes any
>> sense at all in the context of, for example, sockets.
>
> You can use it for sockets, but the problem there is that permission to
> access a socket is too low-level to be an understandable authority for
> most users.
>
> The powerbox UI pattern is more appropriate for permission to access an
> account for a particular protocol.
>
> For instance, an UI for configuring email account settings could easily
> be a trusted dialog (the one below is based on Thunderbird's current UI):
>
> -------------------------------------------------------------------------
> | E-mail account settings
> |
> | 'CapMail' is asking to configure a server and user account from
> | which it will be able to read e-mail.
> |
> | Server Type: [ POP3 v ] Port: [ 110 ] (default 110)
> | Server Name: [ _ ]
> | User Name: [ _ ]
> | Password: [ ******** ]
> |
> | Use secure connection:
> | ( ) Never ( ) TLS, if available (o) TLS ( ) SSL
> |
> | [ ] Use secure authentication
> |
> | [ Grant ] [ Cancel ]
> |
> -------------------------------------------------------------------------
>
> ('CapMail' is the pet name for the application that opened the trusted
> dialog.)
>
> So instead of getting authority to open a socket, the mail user agent would
> get authority to open a session, that allows it to read e-mail only for the
> given server and username. It doesn't get access to the password (which the
> user might have reused in several places), only the ability to use the
> password on this account.
>
> This would be implemented by having a library of proxies for common
> protocols:
>
> - Parts of the library (probably only small and easily reviewable parts)
> have to be trusted with arbitrary socket access.
>
> - The proxy for a particular protocol only has to be trusted with access
> to the given domain and port (under the assumption that the UI to
> specify the domain and port is trusted), and with the login details.
> Proxy instances are otherwise confined and memoryless.
>
> - The user agent application only has to be trusted with (revocable) access
> to the account; not with the login details for the account.
>
> The proxy for each protocol needs to have just enough knowledge of the
> protocol to be able to log in, and to enforce that the session stays in
> that account (for example in POP3, it might have to filter out USER, PASS,
> and APOP commands, if the server violates the spec and allows these other
> than in the AUTHENTICATION state).
This is effectively what factotum in plan-9 does.
The problem with this design, though, is that it relies on the user to
know that "aha, if an app wants to use the POP3 prototocol, then I
should insist that it uses the trusted POP3 component". Tying this to
port 110 is obviously not a great idea, so we're back to UI that is
going to confound most users, surely?
>
> Note that we are not doing any more work here than is already done by
> personal firewalls and by system libraries on existing operating systems.
> In fact we're probably doing less work: on existing OSes there are very
> likely to be several duplicates of this functionality, all of which have
> to be secure.
>
> Also note that the library is not conceptually part of the OS. If an
> application needs some completely oddball protocol, it can provide its
> own proxy for it, and then only that proxy needs to be reviewed in the
> same way that it would if it were installed centrally.
>
> This approach does not work so well for things like web browsers that need
> to access many different sites. However, I don't think there's any need
> to use a single approach for everything.
>
> --
> David-Sarah Hopwood
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>