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

[Bas Wijnen]

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

No, I will _have bought_ a new hard disk if urgent things like that can
happen.  Hard disks don't cost much.  If the company needs to respond quickly,
there must be a spare hard disk somewhere.

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

Removing files when I don't know what they are is just as dangerous.  It comes
down to not touching the files if the user is not there, which means I don't
need access to his files: If he's there, he can give it to me.

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

I fix the problem quickly by plugging in a spare disk (or having done that
before and starting to actually use it).  This is only about solving it
permanently.  He's going to be there eventually, he's working there, remember?

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

Sounds unlikely, but perhaps it's possible in some environments.  Well, I'd
have e-mailed him and warned him that I'd remove his account before actually
doing so.  Also, this would probably have to go through some other management,
since he's likely to be fired simultaneously.

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

Very true indeed.  Unfortunately there's nothing we can do about that.

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

I don't think many of the users will need to be threatened with account
deletion in practice.  It's just the final measure which gives the
administrator the power to demand things.

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

If your employees are actively hostile against the company, you have bigger
problems than your system administration.

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

Very actively hostile administrators find ways to do what they want, and they
cannot be stopped as long as nobody finds out about their hostility.

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

Those capabilities must be clustered somewhere so they can be given to the
administrator.  That cluster is very sensitive.  I'd rather not have it.

And in particular, I see no reason to have it.  If users want to allow the
admin to see what they're doing, they can give him the capability.  The admin
can also give himself the capability when he creates the account.  I just
wouldn't do this by default (but it can be in the account creation script).

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

He can still do this if there is strong security, as I wrote above.  Adding
extra code (potentially with bugs) to the TCB when the same can be achieved in
a safe way does not sound good to me.

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