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

[Robert Wittams]

I cut e-lang out of the cc:

I also cut out the bits which have gone into other threads. 

On 21 Mar 2001 17:20:25 -0800, Ka-Ping Yee wrote:

> On 17 Mar 2001, Robert Wittams wrote:>
 > Ie why did the back orifice installer ever get access to a network


> > 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.

I think in the paper it said ps was a good thing on unix, as it allows
you 
to see what is running. 

Well, the visibility stuff is a good idea, but unless it can be proved
that
no one acting with your authority could hide things from you, (ie you
can't hide
stuff from yourself) then it is a false security. ( falsely believing
you are safe is worse than
being worried you are not).

> > 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.  

Well, thats not really true. This kind of stuff can be declared. 
See eric raymonds CML2 for an example ( probably a lot more complex than
anything needed
here) :  

http://www.tuxedo.org/~esr/cml2/


> 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 means that it is harder to work out what an installer does
statically. 
Ie a human has to run it to see what it does.
I don't see any benefit to executable installers.  

> > 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?


Ok... here is how I think of it.


A package is given to the package manager by a package installer front
end. 

A factory ( a process which can create instances of the program in the
package) is 
created by the package manager. 

The package manager gives a key to this factory back to the package
installer front end. 
This package installer then asks the factory for the arguments it needs
to create an instance
of the program. The user is prompted to create a profile (which consists
of bunch of keys and data to give the factory. It also has a key to the
factory.) as in your paper. The profile is inserted into
the users namespace wherever they like. It can then be duplicated and
modified. 

So I think the distinction is this:
The factory is the process which actually constructs the instance of the
program.
The profile is the set of arguments with which you wish to run it. 

They are not the same thing. I think trying to tie them together is a
bad idea. 

> > 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,

I don't think users care about namespaces looking different. 
Everyone uses lots of different ones.  filenames, urls... 
in fact urls would be more sensible to emulate than actually putting
drive letters there... 

 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.

This windows-ish ness would only really suit a windows emulator...
and is that emulator really interesting from a 

> > 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.

Well this sort of assumes the application has the power to do something
bad. 
The whole point of a capability based os is that this is not the case. 

> > 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.

I don't get this. How do you control it? How do you ever decide to
"trust" a document?
You try it out, and it breaks everything because you gave your app
stupid privileges?
Then what? 

Or you try it out in a sandbox. It seems ok. 
Lets let it out of the sandbox. Or - lets not! 
Everything runs in a least privelege sandbox already! So it doesn' t
matter at all!

The whole point is that untrusted stuff can be used within a trusted
framework. 
You only give them access to what they need. 

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

Why not? What is going to happen? 
What could they actually name it to which would harm you?

Note, I don't think it should be based on extension either. 
I think an attribute in the namespace would be better. 

> > 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.

Well, most apps should NEVER be allowed to put things in your namespace.
Or even read it. 
They have access to a trusted file dialog factory. This would display
any extended 
attributes that the app suggests, before inserting it in your namespace.

> Also consider what happens when there are multiple factories or 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.

Well the problem with this on the mac is when that app goes away, or you
decide you 
like another photo editor better. You have to change every file, messing
with resource 
forks.

> 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.


Well this argument is based on having a windows like registry that
doesn't work. 
This is another reason not to have executable installers. 


 

> > 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.

The problem with this is on taskbars etc.  Eg lots of browser windows.
The distinguishing feature is the document. 
It gets pretty annoying if it just has a big line of Netsc...

Maybe force the app name to the far right?
Then it is easy to see. 

 
> > 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.


Well, this only means it has access to everything the user has. (plus
perhaps the terminal input and output hardware.) 
*not* everything the rest of the system has. 

> > 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.

Yep, thats what I thought would be good ( and practical).
Unfortunately, it doesn't seem like there would be a way to show the 
delegation if the delegator doesn't want you to know. 

Bye

Rob