[EROS-Arch] Re: [E-Lang] Re: Interaction Design for End-User Security

[Ka-Ping Yee]

Hi, Robert.  Thank you very much for taking the time to read the paper
and write your comments about it.  I look forward to a stimulating and
productive discussion on this list!

On 17 Mar 2001, Robert Wittams wrote:
> Ie why did the back orifice installer ever get access to a network
> connection/ 
> file system etc in the first place.
> Background processes would be a pretty madcap
> removal from a general purpose os.

I think you've misunderstood what we're proposing.  The requirement
is that background processes have to be *visible*.

I agree with you that Back Orifice should be confined in an
environment with least privilege (here the Explicit Privilege
principle applies).  We're suggesting an *additional* requirement
with the Visibility principle.

> Also, the ability of any random process to list 
> all processes is an information leak which reveals the implementation of
> services, not a good thing!

Where did you get this idea?  I don't remember suggesting anything
like that.

> There is no way to protect the user if he allows "pranksters" to access 
> a machine with his authority. Thats why everyone should lock their
> screens!

Markm will probably argue with me on this also, but in my opinion
this statement seems representative of a very unfortunate approach.
The attitude is pervasive in computer interaction design, and boils
down to disclaiming responsibility because "the user is stupid".
While it is true that it would be nice to have perfect users, it's
simply not a realistic position to hold.

You can make errors less likely, but you can't prevent them all.
Hence there must be a mechanism for *recovery* from error.

If the phone rings and i turn away from my computer for a minute
while i have a conversation with a friend, i don't want that to
result in a complete collapse of any trust i have in my computer.
I can't afford to start over from ground zero whenever i am not
paying attention to my computer 100% of the time.  So the system
has to provide a way for me assess the state (e.g. see that there
are no background processes holding dangerous privileges) so that
i can re-synchronize my mental model with the computer and proceed.

> The whole idea of executable installers is suspect. A declarative
> package would be
> far easier to verify. This could also give requirements as to shared
> libraries, fonts, etc (including version information). 
> From this information, a factory could be created.

Part of this is addressed by what we were proposing.  The factory has
to declare what permissions to ask the user for.  The user interface
inspects this list and generates the startup dialog.  The startup
dialog is like a UI representation of a method signature; from an
API point of view, the application provides a "start" method, and
the UI examines an interface specfication to figure out what
arguments have to be sent along with this message.

The reason i think we need executable installers is that there are
often many decisions to be made when setting up an application.
Sometimes the dependencies and permission requirements will depend
on these decisions, so they can't be declared statically in the
installer.  And it didn't seem like much of a risk to me -- the
installer only gets one capability that you explicitly give: the
ability to write into a freshly-created directory.

> It is stated that a factory has no capabilities - 
> this seems a bit broken. A factory can have capabilities that every
> instance of the app will need.

I'm confused again.  I don't remember ever saying this.  I believe
that the design you're suggesting is what we proposed:

    After selecting privileges to grant, the user can create
    a new factory that carries these privileges and can launch
    an instance with them in future.

Maybe the paper doesn't explain the procedure well enough?

> The next part seems to be giving arguments to a factory method to make
> an instance.

Which part of the paper are you referring to?

> I can't really work this out - this seems to be making a new instance,
> and also a new factory?

No, that wasn't the intent.  Here is the basic idea:

    An installer installs files and produces a factory.
    A factory can be invoked to start a running instance.

    A user can provide the application with privileges in three ways:

        - Store persistent privileges in a factory.  Then
          every instance started with that factory gets
          those privileges.

        - Provide privileges upon starting a particular
          instance.  Just the one instance gets the privileges.

        - Provide privileges while an instance is running,
          by sending a message to the instance.  Again, just
          the one instance gets the privileges.

> I think maybe what is needed is a new concept - a
> "profile" (pick a better name!). 
> This would be a remembered set of arguments to a factory.

I believe you've just described what a factory is.  Are you drawing
a distinction between factories and profiles that i'm missing here?

> I'm not sure whether the presence of windows-like filenames in the
> dialog boxes 
> really inspires confidence, however. It implies (to me at least ) a
> global namespace, 
> which is not good for security.

The namespace is local.  It can look like a Windows filesystem if
that makes users more comfortable, but there is no implication that
it is global.  Applications never see paths and filenames (or, if
needed for compatibility, they would see only locally-made-up names
that the system has generated to satisfy legacy filesystem APIs
like open()).  I think you have made it clear that we should
explicitly talk about this and you are right.

> The giving access to devices - it would be nicer to be able to drag a
> cap supporting the 
> right interface onto these bits. This would allow you to have multiple
> devices, and also to 
> interpose filters, which could eg modify the sound coming from one app,
> or record it to a file. 

Indeed.  I think this is entirely good.  We didn't want to go into
too much detail about how the user could compose their own data flows,
but we definitely want to leave open the possibility.  We mentioned
the "printer service" proxy in section 5.3, but we could add other
examples.

> Untrusted documents - what is there to trust about documents? They are
> declarative.

We think it will be common for users to want to associate application
factories with documents.  If a document triggers the launching of an
application or the application makes decisions based on the contents
of the document, then we now have to trust the document to some degree.

> Unless this includes embedded scripting... eek.

Sure, i mean, some documents could be scripts, for example.

> I think having to associate every gif
> file with a gif program is unlikely to be popular.

> And doing that for the sake of some 
> word files... surely it wouldn't matter anyway. The app would only have
> caps to itself and the untrusted document.

Most apps are going to require some capabilities to work with upon
launching; that's what the factories are for.  So if you associate
a factory with a document, then activating the document can cause
a new application instance to appear and start invoking the
capabilities provided by its factory.  That's behaviour people
definitely want, but that one should be able to control.

(Certainly the association shouldn't come about just because the
document has been named with a particular extension by somebody else!)

> I think that a property of the file in the 
> namespace could be its type ( extended mime type) and whatever program 
> you grant access to the namespace (eg file browser) can work out what to
> do with it.

That's not a bad idea, but then how do you deal with applications
that save files?  It's simpler to directly associate the app factory
with the file, because then an app like Word can have the privilege
to create files that are associated with its own factory.  If the
MIME type was all you had, then you'd have to additionally set up a
list of allowable file types that an application could create.

Also consider what happens when there are multiple factories for a
particular application.  I know we don't specifically address the
multi-user situation in the paper, but we want to accommodate it.
If there are multiple users using Word, then the system can have
just one installed copy of Word and each user can have his or her
own factory.  I associate my documents with my factory (which knows
about my preferences, etc.), you associate your documents with yours
and everybody is happy.

In a way, this is like the distinction between type and creator on
the Macintosh.  (An excellent decision which i sorely miss on Unix
and Windows systems.)  Each file has both a type (to indicate what
kind of thing it is and what you can do with it) and a creator (to
indicate what application to launch).  The two properties are
independent.

This way, a single application can create files of many different
types while still associating them with the application.  And you
can have multiple applications that deal with the same type -- let's
say you install two competing text editors -- and there's no endless
battle over the registry.

> Re window management:
> also should mention making active apps very obviously different from
> inactive. 
> Eg making inactive apps half  transparent.  And having very different
> window borders. 

Right.  We stated that one window would have keyboard focus at
any given time, but we were never clear about how the user would
know that.  Good point.

> The title - most apps provide some information in their title bar. 
> This should still be possible - 
> 
> eg App information  - OS provided name.

What we had in mind was that the API for setting the window title
(let's say "title(x)") would cause the title to show
"App instance name: x".  The app name should come first so it's
always in a predictable place.

> It also means that the display server or whatever is drawing the arrows
> has the privilege

A general point -- we argue that the user interface has to be
ultimately trusted because it represents the user's intent to
the rest of the system.  It is in cahoots with the operating
system, so to speak.  So it can in theory do anything.

> to look at the capabilities that each app has and work out the
> designated object. 
> To do that is quite a high level of access to the internal state of keys. 
> Either that or there is some kind of intermediary indirection service
> which the arrow 
> drawing thingy has access to (and which can revoke caps - by destroying
> indirections). 
> The problem with this is that the capabilities could have been passed in
> another way 
> (not going via the indirection service). So it would not be able to show
> the entire state of the caps. 

You are right.  We hadn't updated this part of the paper sufficiently
to reflect our last discussion about visibility with Mark and Norm.

Here's the plan: what we had in mind, but failed to explicitly state,
is that each granting action produces a revocable forwarder that the
user interface keeps.

The inspection and revocation of privileges then operates at this level,
on the revocable forwarders that correspond to the granting actions the
user took.  Suppose i give capability C to an application X.  In the
course of doing its job X delegates some work to some module Y and
passes on C in the process.  When i inspect the privileges, i only
see X, not Y; i see that X has received capability C.  If i tell the
user interface to revoke C, the forwarder is erased and neither X nor
Y can invoke C any more.

The interface probably wouldn't look any different from the way it
looks now.  It's just a matter of keeping the abstraction boundary
clear.

> The smallest folder containing one end of the cap thing? I think that
> this will end up with 
> hundreds of arrows going to the root of the namespace, or wherever
> "profiles" are kept. 
> But still, I can't think of anything better ;-) 

The arrows only appear while you're asking about a particular object
(application or resource), so we're hoping that this would only be
on the order of five or six at a time.  (Keep in mind that only user
granting actions appear as arrows.)

> Anyway, good ideas, hope some of this was helpful. 

Yes, thanks!  I hope you continue to think about and discuss these
issues with us.


-- ?!ng

Happiness comes more from loving than being loved; and often when our
affection seems wounded it is is only our vanity bleeding. To love, and
to be hurt often, and to love again--this is the brave and happy life.
    -- J. E. Buchrose