There are a number of people who seem to think that my original
complaint is ill-founded.  Let me try restating things.

I don't think that any command in the AFS suite should allow you
to do things on other machines without giving an explicit password
So, I think bos commands affecting other machines,
vos commands affecting other machines, etc, ought either

(1) require a token for an AFS userid who is in system:administrators, or
(2) require a password at execution time.

Commands like 'bos shut' or even 'bos exec' whose server is the
same as the current machine might not require this.  Personally,
I don't think the vos commands should allow -loc at all.

For example, if you are root on a fileserver (or in our cell on
any machine), you can, without any tokens at all, use 'vos dump'
to dump any volume.  You can read the files in the dumped volume
with no difficulty.  If you know what you're doing, you can then
modify the dump and restore it, overwriting the original volume.

I would like to see all of these volume manipulation commands restricted
so that authentication is required for them, either by possessing a
token, or by typing a password explicitly when you give the command.
I would like to see those bos commands which affect other machines
restricted similarly.

One person from Transarc wrote to me suggesting that instead of all
this, I should lock up all file servers so that noone has access
to them.  I think this completely misses the point.  True, I have
modified my machines so that noone can log in as root on any terminal;
the root password in /etc/passwd is '*'.  I have modified the system
so that no machine can boot up in single user mode without having
a password.  But I am not so naive as to believe that my systems are
secure.  Surely every Unix system out there has security holes.
If someone hacks into my system by exploiting some vulnerability in
the operating system, I don't want to see Transarc's software giving
him a bonus of access to all other machines in the cell.

     -- Owen
     [EMAIL PROTECTED]

Reply via email to