(no subject)

[Emmanuel Colbus]

Bas Wijnen wrote:
> > > > > 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.

Hey, it's not a PC! There is configuration to do, for archiving data, raid
configuration, logical partitions, etc... On some servers, you can't plugg
a disk without shutting it down and opening it. And what if there is no more 
space to add any disk to the server?

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

No, it comes to removing all files you can identify as unneeded - for example,
all DiVX and mp3 files, if your company's business has nothing to do with them.

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

Although I've currently never been faced to the need to plug a spare disk into 
a UNIX server in emergency, I don't believe it is possible to do such a big
operation quickly enough to answer the problem in an acceptable amout of time.

Don't forget that the definition for such a delay will be done with a comparison
to the delay the problem would have required to be fixed on another system.

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

Very possible in university environment, where users are actually students (and
can't be fired for having just blocked a server).

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

Thay can also block other users without wanting to do it, for example, by eating
nearly all disk space without noticing it.

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

I agree adding it would mean adding a very sensitive piece.

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

That's also a way to do it. The problem I see is that, if the admin gives 
himself
these rights by modifying the account creation script, he is far more likely to
do it wrong than if it's done by the TCB creator. Additionnaly, he will also
have to cluster these capabilities somewhere, which force him to build his
own cluster for that - also dangerous. It's better if it came shipped along
with the TCB.

OTOH, the necessary code could be only shipped along with the TCB, but 
not included in it.

Thanks,
Emmanuel