Re: About explicit security bypass (Was : Re: Changing from L4 to something else...)

[Bas Wijnen]

On Sun, Oct 30, 2005 at 10:54:11PM +0100, Emmanuel Colbus wrote:
> > > - 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);

Errors at system install should not happen.  If they do, it is not
unacceptable to need a reinstall to correct the problem.  Note that those
errors, if they occur, are errors from the system developers, not from the
administrator.

Errors at any later time should be correctable with the same permissions that
were needed to make the errors.  If they aren't, the system is badly designed
IMO.  Since we will not make a badly designed system, this will not happen.
:-)

> > I agree. However, most administrator errors can be divided into two
> > categories:
> > 
> >   - mistakes in configuration (which we agree needs to be correctable)

and that should be possible without additional rights (that is, the person who
had the rights to change the configuration and make these errors will also
have the rights to correct them.)

> Yes, but the problem is that we can't be prepared to any error which can
> be done on a system. Therefore, sometimes, they will be no tool available : 
> the administrator will need his knowledges, and all the data the system
> can give him, to solve the problem. 

If the system does proper resource accounting, it is none of the
administrator's business how those resources are used.  Only if the user can
blow up the system in a way that harms other users is such administrator
intervention needed.  We hope to accomplish preventing the system to be blown
up in the first place.

> As a consequence, there is a need for some means giving the administrator a 
> very extensive knowledge about the state of the whole system.

The administrator can get all the knowledge she needs, and that doesn't
include what users are doing with the resources that they are allowed to use.
Since the users cannot use more resources then are allocated to them, their
actions cannot be the cause of the problems.

> >   - errors that result from trying to bypass security and botching it.
> >     The best fix for this is not to allow security bypass.
> 
> Theoretically, yes, but that's like unplugging a computer to protect
> him : it solves a problem by removing a functionnality. As you don't want
> the functionnality, it doesn't create you any trouble, but others (like
> me) may disagree. 

No, it's like renting a house to someone and not keeping a key to it for
yourself.  What they do in that house is their business.  If I have trouble
paying my bills, then nothing in that house is going to help me with that:
It's simply not a relevant part in the problem.

Sure, I can keep a key so I can "break in" and check if I didn't accidentily
leave 100 euro in it.  But when would I have done that?  If I didn't have a
key, then I didn't mess up in there.

> So, let's discuss it : 
> 
> > > - 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.

If you succeed in making the system available at the cost of security, then
that wasn't a durable solution I think.

Still people may want this, indeed.  I think they should get a GNU/Linux
system, or some other insecure thing.  Breaking a very nice architecture
because someone wants to do unwise things is not something that I prefer. ;-)

> > 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.
> 
> A feature that you remove _or_ that you tell your users not to use. 
> There is a problem, but it doesn't means _you_ (the system) have to solve 
> it : I think it has to be solved by education, not coding.

Without this feature, the administrator cannot access the user's programs and
data.  That means the user's privacy is protected.  With it, the user is never
sure.  You may trust the installer of the sytem enough that he didn't put in
back doors.  But do you trust the administrator that he always resists the
temptation in practice?  I think we want a system which does not allow the
administrator to spy on users, because users will feel safer on such a system.

> > 2. If security is ever deactivated on a live system, it is almost
> >    impossible to re-establish.

What's worse (and I guess you know much more about this than I do) is that
it's probably impossible to guarantee that security is re-established.
Without this guarantee, I think you should assume that it isn't.

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

I don't see the relevance of this comment at all in this discussion...

> We could allow only some known users to deactivate the security, and
> only toward themselves (that's the way the root account and the wheel
> group usually work). The fact the administrator has bypassed all securities
> doesn't means the security has been deactivated towards anything else
> than his actions; and, if you consider his actions were "not aggressive",
> then security hasn't been *ever* compromised.

As long as his programs didn't have bugs which were exploited.  And the
problem is, that you may not have noticed this.  If you have a system where it
cannot happen by design, then you know it's working and secure until the end
of time.

> > 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.
> 
> I understand. But I personnally think that the problem is in this absence
> of liability, and that it has to be solved here; not in the system design.

Well, you can make people pay money if they break the rules, but if it's
technically possible, it seems better to me to enforce the rules so they
cannot break them.  Then there are no free riders, because they just don't
manage to get a ride.

> > 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.
> 
> This classification is interesting, but I think it's incomplete.
> We also have to take into account the skills of these people.
> 
> What if the administrator is highly skilled and hostile? Then, all your 
> attempts to protect the users from him will simply fail : as he needs
> access to the security-critical components of the system, he can simply
> recompile them after having added all the hole he needed.

He doesn't need access to security-critical parts of the system.  On a
well-designed system, it seems to be possible to let users handle their own
data.  The system administrator cannot touch that, and he cannot touch parts
that directly handle it (such as the hard disk driver).  The system installer
made a choice for those components, and booting from a different medium is
required to change that.  On current systems administrators need the right to
boot from different media.  This need not be the case on the new Hurd.  They
probably still have that right, since the administrator and installer are
often the same person.  But their responsabilities can (and should IMO) be
seperated.  The administrator should not have rights that he doesn't need for
his job.

> Worse, by claiming your system can protect the user from an hostile 
> administrator, you have given the owner of the computer a wrong feeling
> of security, which will certainly make the actions of the hostile 
> administrator far more easy.

We should not claim we can protect them from a hostile _machine_
administrator.  However, we can indeed protect them from a hostile _system_
administrator, provided that he doesn't have direct access to the machine.

> Now, what if he is highly skilled and absolutely honest? Then, by taking 
> him some possibilities away, you will maybe make him unsatisfacted with your
> system, and he will possibly try to use another one. Don't also forget two
> points : firstly, some of these people's opinion will be followed by an
> impressive number of least skilled ones, secondly, if a new system comes up,
> it's of course most likely to be accepted at first by such people, so the
> importance of this population is far higher than his numeric count.

I think the highly skilled system administrator will like this approach.
After all, there are huge parts of the system which cannot be reached by him,
and therefore the problem cannot be located there.  So it actually makes his
job easier by showing him only the parts that are relevant.

> And what if the administrator is hostile, but has only average skills? 
> Happily, nobody can (currently) control the information on the Internet,
> but it also means that the hostile administrator will be able to find
> everything he needs to make his attacks somewhere. So he may also
> succeed in his actions.

If even a skilled administrator cannot succeed in being hostile, a less
skilled one will not succeed at all.

However, note that anyone, including an administrator, with below average
technical skills but good social skills, can perform a social engineering
attack which will probably succeed.  We do not pretend we can protect the user
from that.

> And even if the administrator has bad skills, he will remain able to
> do some very dangerous actions : for example, reading or modifying
> user's data (as he needs to be able to save and restore it).

No, he doesn't.  The user can save and restore his own data if he feels this
is important.  The administrator can make this the default for new users (at
user creation time), but he cannot do it once the user exists.

> 1) The administrator has to be *always* *completely* trusted; and the
> owner of the computer has to be aware that it is impossible to provide
> *any* protection from the administrator.

I do not agree.  There is no protection from a person who has physical access
to the computer when you are not there.  But this need not be the case for the
administrator.

> 2) The end user has to be *able* to bypass the securities, but not by 
> default. The operations needed in order to do it could be a little bit 
> complex, and should always be clearly labelled as "very dangerous", 
> "for experts only" and "no normal administrator needs to do something 
> like this", but it has to be possible.

He is able to do this, by booting the system from a different medium (such as
a CD).  That is, a person with physical access to the computer is able to do
that.  The administrator is not able to do it, and that is a good thing.

> This removes any false security feeling, keeps the "normal user" secure
> (except if he is stupid enough to bypass the securities anyway, but
> fighting human stupidity is a goal that would delay the Hurd some additional 
> thousands of centuries), and provides the skilled ones with the ability to 
> do what they want.

Skilled users are not looking for solutions in places where they will not find
them.  The only thing that adding a super-user to the system does is allow
spying by the administrator.

> My own view may also not be the right one for the Hurd, and it's not up to
> me to take the decision.

Which is true for me as well.

> Unfortunately, it seems me that the one who takes the last decisions
> here is RMS,

I'm not sure if he does.  He definitely doesn't on his own.  Formally, the FSF
can decide on these issues I suppose, and RMS seems to have absolute power
there if he wishes to use it.  However, if he would decide something which the
majority of the current Hurd developers don't like, they will probably go
away, resulting in no new GNU/Hurd system at all for the forseeable future.
He is probably wise enough not to want that, which limits his power for
practical purposes. :-)

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature