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

[Emmanuel Colbus]

Bas Wijnen wrote:

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

In my case, if I administer such a machine, I know I cannot break the 
system itself as long as I haven't used the security-bypass feature. 
If the feature is correctly protected, I can choose between the complete 
reassurance you proposed, and a smaller reassurance, if I've reasons to do 
so.

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

This is a very good goal. I doubt it will be achieved, but it's worth the try. 

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

No : you _will_ buy a new one. In the real world, you need to fix the problem 
_now_.

> If I think someone is wasting space, I send a notice around that
> they should clean up. 

Doesn't work (real experience :-( ). What now? Removing files without
checking they're not necessary is dangerous for your company's business.

> If I think a particular person is actively hostile,
> I'll talk to him. 

What if he isn't here? (Yes, that's also experience). Not fixing
the problem quickly would mean a very poor QoS.

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

I also believe it's possible, and not uncredible at all (he may find tricks
not to meet with you instead of having an explanation).

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

(A little bit social engineering, an artificial problem, and the hostile 
sysadmin 
will get access over all the user's files... In the real world, users _are_ 
concerned about security, but very few of them _know_ about it enough to 
protect themself - that's what the sysadmin is for, isn't it?)

Works only if he is available, and comes to you, and if you have the time to 
have
such explanations. But if your system requires twice more sysadmins than the 
average,
it won't be worth using it.


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

Yes, I know, and I personnaly also don't support the idea of spying users, and 
not
letting them do any non-work-related activity. OTOH, if they're (even 
unvoluntarily)
blocking some other users by doing this, the admin will have to choose the
priorities - that is, the work-related activities.

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

"Internal power supply failure" - sorry, folks, I walked accidentally on the 
power 
cable, and I noticed it too late... 

It would work only towards the "not very actively hostile" administrators.

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

I also agree with this, I just think there should also be a way to deactivate
it.

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

He hasn't such capabilities, he has just the possibility to get them 
(by using a passphrase for example). He can also decide not to take it - and,
if your system is designed so well, he would never have to (but I've doubts
it will be ever achieved).

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

If it happens to the admin's shell, and he hasn't used the security-bypass 
feature,
it's not more dangerous than the breaking into any normal user's shell. The 
difference 
is that the sysadmin (and not his system) can take the decision not to use this 
strong 
security.

Thanks,
Emmanuel