Re: Changing from L4 to something else...

[Jonathan S. Shapiro]

On Sat, 2005-10-29 at 21:28 +0200, Emmanuel Colbus wrote:

> I think some of the following tasks should also be taken into account : 
>  
> - Account destruction (and software uninstall ;-) );
> - Handle of hardware failures/problems, and everything made in order to 
> remain 
>   ready to handle them (I think notably, but not only, to saving data);
> - [Daemon start/stop/upgrade]

Yes. All of these fall into the categories I had in mind. Clearly, if
the administrator creates accounts they should be able to delete them. I
have already mentioned software install and update and service
enable/disable.

Recovery from hardware failure (and also initial system HW
configuration) were not on my list, but they should have been.

> - Handle of security-related issues (if a daemon has a dangerous bug, it may 
> need
>   to be stopped, upgraded, downgraded, patched, or whatever else). Well, it 
> could
>   maybe be done at the "normal user" level most of the time, but what if the 
> bug 
>   appears to be in a security-critical component?

There are some legitimate challenges hiding in here, but we must first
ask: why should any deamon have a security-critical component?

There are some very obvious examples of security-critical components
that really need to be part of the respective daemons. However, there
are also many security-critical elements of current daemons that exist
only because the underlying operating system provides inadequate
protection. When you correct these, the issues that remain mostly amount
to security policy configuration issues, which were already on my list
of adminstrator activities.

> - Recovery after his own errors (for example, if the users should never had 
>   access to the system speaker, but nobody noticed it before, the 
> administrator 
>   has to modify the configuration, but also to stop the annoying sound. It is 
> not 
>   realistic to believe that the administrators won't do any error);

I agree. However, most administrator errors can be divided into two
categories:

  - mistakes in configuration (which we agree needs to be correctable)
  - errors that result from trying to bypass security and botching it.
    The best fix for this is not to allow security bypass.

> 
> - Security bypass (!). I personnally think one should sometimes be able to 
>   do anything on the system, even to damage it if he explicitly wants it,
>   in order to handle _quickly_ any unexpected event. After all, the balance
>   between security and availability has to be set by the owner of the 
> computer;
>   and he may not care really about security, but very much about availability.

Wonderful! We have hit the first issue that I can identify where I have
looked at the issue and said "yes, I understand the argument, it is
credible, and I would not do it." Here is my answer for the Coyotos
native OS. I am not convinced that this is the right answer for Hurd.

I have three reasons for disliking this case:

1. Based on experience, the overwhelming majority of administrators do
   not understand the complexities of current systems well enough to do
   this properly and survivably. The issue you raise is still important.
   The problem is that the solution you propose almost always leads to
   a situation that is worse rather than better. A feature that leads
   to mistakes 95%+ of the time is something you remove, not something
   you justify.

2. If security is ever deactivated on a live system, it is almost
   impossible to re-establish. We *know*, for example, that the average
   time from power-up to penetration of a new Windows machine on a
   cable network is 12 minutes and falling.

3. Our current understanding of the proper balance between security and
   availability is based on a "free rider" economy: we are not liable
   to others for the consequences of our insecurity. I do not wish to
   support this free ride in my system designs.

At a meta-level, however, I have a different view that brings me to the
same conclusion.

All of us on this list (myself included) are the second or third
generation of the "computer lib" era. Our mentors (on in some cases,
their mentors) saw computing as a way to liberate society and promote
individual empowerment. It seems to me that this idea survives most
powerfully in the free software movement, and it is a beautiful idea.
Our notion that owners of computers are all administrators comes from
this value system.

The problem with this idea is that it is naive. The vast majority of
users lack the specialized skills to be effective computer
administrators or developers. When we fail to provide these users with
"turn key" solutions, we *disempower* them. We create situations where,
instead of being able to participate in the online world safely, they
are vulnerable and fearful. This is not liberation. It is a form of
social terrorism. Good intentions, but the result is terror on the part
of the broad user base. And the users are captive: they are afraid, but
they believe that getting off of computers would place them at an
impossible disadvantage.

And in the corporate setting, where professional administrators *do*
exist, we tend to forget that administrators are no better or worse than
the rest of the population. A few are superb. The majority are
imperfect, and a small number are actively hostile. It is very startling
how many people in the grey hat and black hat communities started as
system administrators. These are the very rare few, but they exist.

Whether to cope with evil or simply to survive the fact of natural human
error, I think that we need to structure the choices in our systems
better and more narrowly. I do not believe that arbitrary
configurability is liberating. I believe that the socially and
technically correct choice is to minimize options to a small and
manageable number, and then let evolutionary pressure and feedback teach
us how to adapt.

This applies several orders of magnitude more strongly to security
configuration options.


Well, that's my opinion. It may not be the right view for the Hurd.

shap