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

[Robert Wittams]

Saw this on the eros list, had a couple of thoughts.. 
Well - its good to know someone is thinking about this stuff... 
btw - just constructive criticism, not a flame! ;-)

starting at section 5 (btw the index is misnumbered) - the rest seems
really good except background processes--
this isn't really to do with background processes as such, but with
least privelege. 
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. 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! 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!

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. 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. 
Eg to shared libraries.  So the package manager would install these
capabilities into the factory. 

The next part seems to be giving arguments to a factory method to make
an instance. 
I can't really work this out - this seems to be making a new instance,
and also a
new factory?  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. So when you
first import a
factory into your namespace, you would be prompted to create a profile.
This profile could then 
be activated and this would launch the program. Also, the prefs file
could just be part of the profile 
rather than a seperate document - asking people to remember or make up a
path for no good reason is not good. By part of the profile, I mean an
anonymous file the profile has a cap to.
So you would never see an icon for a factory, only for a profile. This
profile could 
then be duplicated, and modified. This is basically the same as what you
already have, but 
I find it a lot clearer to separate the factory and the user provided
caps. 

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.  Especially drive letters like C:\ are
either leaking information 
or are legacy warts. I presume this was done to make the screenshots
easier 
to produce.  I think an obviously user-specific namespace would be
clearer. 

eg 

/Docs/
/Music/

 I don't know whether basing the screenshots on the windows gui is good
either... it will lead
people to make unwarranted assumptions. 

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. 
( Did I hear you say circumvention device? DMCA, here we come... ) 
A default could be provided for each too, to make it quick in the simple
case. 

Untrusted documents - what is there to trust about documents? They are
declarative.
Unless this includes embedded scripting... eek.  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. What could it do? That  key to the factory
is about the 
only dodgy thing it has. ( It could do the equivalent of a fork-bomb.)
And I'm not convinced it wants that. 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. Eg launching a program it knows can deal with that mime
type. 
So files are plain data and do not have any keys. 

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. 
The title - most apps provide some information in their title bar. 
This should still be possible - 

eg App information  - OS provided name.



Also 5.4 revoking and reviewing privileges - this seems pretty complex. 
It also means that the display server or whatever is drawing the arrows
has the privilege
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. 
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 ;-) 

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

Robert Wittams