[EROS-Arch] Installers

[Pascal J. Bourguignon]

> From: "Jonathan S. Shapiro" <shap@eros-os.org>
> 
> > The  declarations  probably has  been  computed  some  time ago  (when
> > generating the package, be it by software or by wetware). Therefore, I
> > don't  see the  difference and  the  advantage to  request a  _static_
> > declaration of  the authorities the  installer needs over  having some
> > installation program or script compute them at installation time. What
> > did I missed?
> 
> You missed a social (human) problem.
> 
> As the person installing the software on a system, I want to know in advance
> what authority is required and make active decisions about whether I will
> agree to grant that authority. This should be done at install time, not
> incrementally as the software comes to realize that it needs more authority.

Any well thought installer will first ask everything it needs, then do
its job.   But of course, this is  easier to ensure if  we provide the
only installer program in the system...


> The problem with the incremental strategy is that over time I will forget
> what authority a program holds, and I might slowly give it combinations of
> authorities that are well-suited to misuse or abuse.

A good point.

But were  we not to have a  good feed back of  the assigned capacities
from the user interface ? This probably should be general: each time a
capacity is  to be  assigned to an  entity, the user  interface should
list the capacities the entity already holds.

And by the same token, it may be very interesting, security-wise, that
the "file" choosers show what other  entity may have a capacity on the
element to be  selected and assigned to the  calling entity. We'd like
to know explicitely that a file  that we're giving a write capacity to
to a program X, another program Y already holds a read capacity on to,
or  vice-versa, because  those programs  may  not belong  to the  same
"security  ring", and them  sharing a  file may  be dangerous  for the
system. (I write  "file" here, but the same is  valid for any resource
actually).
 

> In fact, I want to give it all dangerous authorities in a way that can be
> disabled, because I may later decide that this software cannot be trusted
> due to a security flaw, but after fixing that flaw I may want to restore the
> software to operation.
> 
> In any case, knowing (in advance) the authority required by a program is
> part of my decision about whether to install it or not. Therefore, a static
> list is appropriate.

Perhaps I don't  understand exactly what is meant  by "authority" with
respect to "capacity". Aren't capacities all that can be required by a
program and all  that is needed? Wouldn't an  authority be implemented
by a capacity?
 
> Finally, note that a dynamically generated list is unlikely to be useful. As
> a practical matter, most dynamic decisions concern resource *allocation* as
> distinct from the *authority to allocate*. Access to exceptional authorities
> can certainly be captured by prior static description.
> 
> Jonathan


-- 
__Pascal_Bourguignon__              (o_ Software patents are endangering
()  ASCII ribbon against html email //\ the computer industry all around
/\  and Microsoft attachments.      V_/ the world http://lpf.ai.mit.edu/
1962:DO20I=1.100  2001:my($f)=`fortune`;  http://petition.eurolinux.org/