> >For example, if you are root on a fileserver (or in our cell on
> >any machine),
>
> I still don't under stand this. How is this possible unless you either
> a) have the keyfile on all machines (which seems to be misconfigured then)
> b) people leave tokens around or don't use PAG based tokens
You need the keyfile on all fileservers. On any other machine, a canny
hacker can run upclient, and get the KeyFile.
> >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.
>
> I don't think this misses the point at all. This is just good
> administration, especially considering these machines' special role.
It misses the point because, at least in our cell, physical access to
machines does not allow you to become root, to boot in single user mode,
or to have any other advantage that I know of. This is just good
administration, especially considering the porous nature of security
once you become root.
> Good administration ideas too, although if those machines are suns, I
> wouldn't put too much faith in the ability to keep people from booting
> single user :-)
No, our only Suns are well locked up.
> My suggestions would be to:
> 1) separate out the privileges for bos and vos. I would like to be able
> to give permission to someone to release volumes. I don't want to
> implicitly give them root on my servers because of this though.
Yes, this is an excellent idea.
> 2) Have transarc either provide an extra bosserver that *doesn't* have
> a -exec option for those of us who think bos -exec is too big of a hole,
> or maybe just add a -noexec option to the bosserver so those sites who
> don't want -exec can start the bosserver without it.
I like this one as well. I would add
(3) Bos and vos commands such as dump, restore, adduser, removekey,
rename, and other serious functions should not allow -loc; they
should require either a token for a user in UserList on the remote
machine, or the password for such a user at execution time.
-- Owen
[EMAIL PROTECTED]
