marantz@porthos.rutgers.edu (Roy Marantz) (11/16/89)
We're thinking of using Kerberus here at Rutgers and have a few
questions we would appreciate someone (or all of you) answering.
We'll summerize responses.
1) Can login work with accounts that have no password? (eg. who, sync, ...)
2) How are dual homed host (more than one internet address) handled?
automatically? manually?
3) How is /etc/srvtab protected from being read by root? i.e. How is
someone stopped from acting like a daemon?
These are probably more related to NFS implications.
4) Are (time)shared workstations allowed? or how does one prevent it
from happening? (don't run rlogind, ...)
5) Can "permanently" mounted disk partitions be protected?
6) Is group access supported/allowed?
Roy & Don
--
uucp: {backbone}!rutgers!cs.rutgers.edu!marantz
arpa: marantz@cs.rutgers.edujon@MIT.EDU (Jon A. Rochlis) (11/19/89)
1) Can login work with accounts that have no password? (eg. who, sync, ...)
Sure, if the version of login you're using lets one login with because
there's no password field in /etc/passwd (or hesiod or yellow pages or
whatever). I'm pretty sure the version of login supplied with
Kerberos does this. Of course those accounts won't be able to make
use of network services which *require* authentication, but how could
they?
2) How are dual homed host (more than one internet address) handled?
automatically? manually?
Poorly. Basically the requester's address is sealed inside a Kerberos
ticket. When you send the ticket to a server it compares the address
in the ticket with the source address of the packet/connection
containing the ticket. If they don't match the ticket is rejected.
So if a multi-homed hosts happens to use the same interface for the
Kerbeos request and the service request you'll never notice a problem.
You can force this to happen with judicious use of bind, but that's
gross. V5 kerberos will have provisions to multiple addresses sealed
in a ticket (include address families). Some of us would like to see
the address removed totally, but I think we've lost that battle.
3) How is /etc/srvtab protected from being read by root? i.e. How is
someone stopped from acting like a daemon?
It isn't. It you're root all bets are off. You can do worse that
steal the srvtab, you can scribble over all the raw devices ...
These are probably more related to NFS implications.
4) Are (time)shared workstations allowed? or how does one prevent it
from happening? (don't run rlogind, ...)
Sure. But see above. If a user can become root he can steal other
user's tickets and impersonate them.
5) Can "permanently" mounted disk partitions be protected?
What do you mean? Local disks, from local users? If so the answer is
no. Unix provides plenty of access control there and if you have a
uid you've autheticated yourself to the kernel.
6) Is group access supported/allowed?
Again, I'm not sure what you mean here? Group NFS-wise? If so what
happens is that you authentication yourself via kerberos to an NFS
server. The NFS server (if it is running the Kerberos NFS kernel mods)
takes your kerberos credential and looks you up in the "credentials
database" (*not /etc/passwd*, you don't need an account on a
fileserver to use its files). The credentials file looks like
kerberos name:unix uid on server:unix group id 1:unix group id 2:etc.
So you wind up belonging to groups as you would expect.
Remember that Kerberos itself only provides authentication (i.e. who
you are) to an application. The application (NFS in this case) must
make its own authorization decisions based upon its on criteria (the
credentials database in this case).
-- Jon