> You need the keyfile on all fileservers. On any other machine, a canny
> hacker can run upclient, and get the KeyFile.
If a canny cracker can run upclient to get the KeyFile,
either (a) you have got upclient misconfigured, or
or (b) upclient is inherently broken. In either case,
the answer is the same: don't run upclient/upserver until
you can be sure it's not a security problem.
> 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.
If users have physical access to the machine, they can
remove the hard drives, or, in most cases, there *is*
some way to become SU - it may just be harder. For
instance, on many machines, momentarily disconnecting
CMOS ram power, is sufficient to restore the machine
to a default state where it will boot from removable
media.
Here at the UofM, at some of the computing sites - students
figured out how to crack the cases and extract the hard
disk drives of the workstations. These machines
were being watched, and had physical interlocks designed
to discourage theft. Fortunately, they were just
macintoshes. It was just money & inconvenience, not many
people's files, or the security of the cell.
I do not know why you would NOT want to lock up such machines.
If you've got a large enough cell to justify AFS file servers,
you undoubtedly have a large enough cell that it's also
worthwhile to *dedicate* those machines to being *JUST* AFS
file servers, at which point there's no advantage to them
being publically accessible, and locking them up makes
it harder for people to accidently flip power switches or
pour cans of coke into the keyboards.
I hope you lock up your backup tapes too.
> > 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.
I think you're missing the point. The only purpose of
bos *IS* to control what programs you run. Being able
to do a "bos create" and "bos install" is exactly equivalent
to being able to do a "bos exec". By the time you
get rid of all the equivalent features, you might
as well not be running "bos" at all. In fact, if
that's really what you want to do - you can use init,
and some shell scripts, to do that very thing. You
would lose the ability to remotely administer your
cell.
So far as "-localauth" - that's commands executed by people
on the file servers. You certainly shouldn't be letting
regular users on the machines; and you probably shouldn't
be letting anybody who you wouldn't trust with root onto
the machine. One of the first rules to improve security is
to simplify the situation as much as possible. The more people
you let onto the machine, and the more access you give those
people, the more of a security exposure you've got, and machines
are comparitively cheap enough these days that there should be
little reason to risk the exposure.
So far as "vos release" - the reason why that is a
problem is because, so far as the file server is concerned,
it *IS* a "vos dump" / "vos restore". It's the
vos client binary, that is coordinating the activity
between the vldb, and the file servers; and so it is
the vos client that is ultimately being trusted to do
the right thing. That's why something like "adm"
or "sysctl" is a good way to handle "vos release";
not only can it do a better job of deciding who can
release which things, but it also puts the trusted
"vos release" part somewhere besides on your workstation.
-Marcus Watts
UM ITD RS Umich Systems Group
