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

[Bas Wijnen]

On Wed, Nov 02, 2005 at 10:47:14PM +0100, Emmanuel Colbus wrote:
> 
> Hello, Bas,

Hi,

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

In many settings users can do that as well, since AFAIK most (non-business)
system administrators don't read the logs either.  But if we make a system
which is theoretically uncrackable, then we should be safe.  As long as there
aren't any random bit flips, that is...

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

I don't think I know any.  However, there are quite some administrators who
cannot work without others noticing them.  It does happen that the
administrator is not the original installer.  If the users know that the
administrator shouldn't need to reboot the machine, and he doesn't get a
chance to do so without the user present, then that should help (at least a
bit).

But more importantly is the non-hostile case IMO.  If I administer such a
machine, I know I cannot break the system itself.  That's a reassuring
thought.

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

Of course we're building a system with a security model which depends on this,
so we do allow such revocation.  We should be careful with the design to make
sure we're not missing something though.

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

If the disk is full and I think everyone really needed the space, I buy a new
hard disk.  If I think someone is wasting space, I send a notice around that
they should clean up.  If I think a particular person is actively hostile,
I'll talk to him.  If he doesn't have a good explanation and doesn't clean up,
I'll revoke his hard disk space (thereby removing all his files).  Obviously I
don't expect that last thing to happen in practise, but it is possible.
Nowhere in the process do I need to access the contents of his part of the
system without his consent.  I may need to access it with is consent in the
explanation part, but in that case he can allow me access.

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

That depends on your view of how employees should be treated. :-)  Some
employers say that they shouldn't be allowed to do anything non-work-related
on the company computer.  To enforce this, they need to spy on them.  If they
think this is a good idea, I expect them to install software which allows
this.

I don't like the idea, and so I don't feel a need to support it.  Note though
that in the theoretical Hurd system this is possible, by installing a session
manager which does this.  It's just not the default.

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

I agree, I know from personal experience that people need not feel a strong
temptation. :-)

> 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 do have accounts on computers where I have no idea who the administrators
are.  Those computers are permanently running, so things that can only be done
at boot will be noticed, since the machine doesn't usually boot.  Resisting
the temptation should be a lot easier if giving in to it means you'll have to
explain why you were rebooting the machine. :-)

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

I agree with this.  Perhaps the protection isn't worth very much in practice,
but I think it should theoretically be there.

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

If he has capabilities to all user sessions, then "only" seems like an
understatement.  Those are the most important capabilities in the system.
Allowing a single bug to access all of them is a high risk.  Since there's no
reason to take it, let's not.

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

I agree that on a well designed system, it's very hard to break into a user's
shell.  However, if it does work and it happens to be the admin, it's very bad
if the whole machine is compromised.  And again, there's no reason to allow
the admin access to the data.  (He should be allowed to destroy it, but not to
look at it).

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