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

[Emmanuel Colbus]

Hello, Bas,


Thank you for your answer. Now I understand better what you was meaning : 
I hadn't realized that you made a difference between the system administrator
and the machine administrator.

Clearly, yes, this protection has a sense towards a system administrator 
who is not also a machine administrator (but I would add a little warning : 
if the machine administrator is not verifying what the system administrator
makes, then the system administrator has the ability to try as many attacks as
he wants to overpass these limitations (as nobody except himself will ever 
read the logs who would normally have warned the admin about repeated attemps),
therefore, he may succeed in bruteforce attacks or attacks requiring very much
time).

But I think we need to ask this question now : how many system administrator
are not also machine administrators?

Personnaly, I've never been confronted to the case. On the contrary, the admins 
I knew were too concerned about the problem of possible man-in-the-middle 
attacks to administrate their machines from remote (at least when they didn't 
also controlled all the network between the two computers).

So, are there enough system-but-not-machine administrators in the world, or are
we only speaking about some (unhappy) fews? In the second case, this protection 
will practically never be used.

> 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 that's not as easy as it seems. For example, it doesn't work between 
two normal users under a classical UNIX : if user#1 has accidentally granted 
the right to user#2 to read one of his files, he can remove the right, but not
remove the read capability on this file an eventual process user#2 has get.

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

Yes they can. For example, suppose you have 100 users, and one 10 Go hard drive.
In order to use the disk at best, you won't allocate only 1OOMo to each of 
them : the needs for disk space are changing quickly, sometimes, some users 
need more than this, often, they need fewer. It's clearly impossible to manage 
manually each temporary change in the needs. Therefore, a good idea would be to 
limit the users to 1Go each.

But now, it's clear that some users are able to block the whole system.
If they do this, what are you going to do?

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

Yes, but the administrator is not "renting" anything : he is administrating
the computers of his company, for his company, who owns them; and the users 
(the other employees) are using them for free and (theoretically) in the
interests of the company. Therefore, the situation is a bit different.

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

In practice, and as a UNIX system administrator ;-), I've never felt to the 
temptation, and I've never feel it difficult at all to resist to. I also 
believe I'm not the only one in my situation.

Well, they can clearly _be_ such administrators, but I don't believe they are 
the majority. By the way, I've also never heard of any complaint about problems
of trust with any of the administrators I knew.

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

Same answer. I personnaly would feel far more secure on a system which would be
administrated by someone I know as honest than on a system who would claim he 
can protect me from the administrator, even if he hasn't been ever defeated 
in this task.

Social engineering-based attacks are is the most powerful ones, but honest and 
intelligent people at the key places are the best protection.

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

Yes, but this is highly unlikely. If the system is well designed, then
only the programs he used for his special actions could be attacked, 
and they would only be useful for the capacities they had gotten.

Consider this example : the administrator wants to read a file
he hasn't the right to. In order to do this, he would do for example a: 
$ grant_admin_right --open_any_file_here cat userfile | less.

If the "cat" provided by the system if good enough, he will open() the
userfile, then revoke itself the right to "open any file here", and then start
reading it. If anybody achieves into taking control of this process after
this point, the only thing this person will be able to do is to also read
the userfile - not a good thing, but not deadly dangerous. Taking control
of this "less" is not more usefull : it has no special rights, so he is not 
more usable than any normal "less" started by the admin.

By the way, if these programs are all good designed, in that they revoke
their rights in their beginning, as soon as they don't need it anymore, 
then they are not more dangerous than the programs the user uses to do 
the same operations; and taking control over them gives as many possibilities
as taking control of user's processes.

Therefore, such a system can also remain secure.

By the way, even in a system into which this can't happen by design, you're
not secure until the end of time... Consider for example a process which would 
launch some instructions, then check if he executes himself with kernel
rights, and so on until, by the help of a wrongly-executed instruction
or a bit-flip in the processor, he achieves into getting kernelspace protection.

Now, what is the most to fear, the very unlikely exploit which
would allow to grab an administrator's capability before it has been revoked,
or the stupid hardware-error-trying attacker, which is also very unlikely
to achieve? Maybe the first, but I'm not sure of it.

Emmanuel