[OpenAFS] Home directory in AFS

Charles Clancy security@xauth.net
Sat, 20 Apr 2002 11:52:50 -0500 (CDT)


>     Derek> Are you crazy, or just unaware of the security
>     Derek> implications?  Since AFS is a global file system, you are
>     Derek> leaving yourself open to a wide range of attacks.  Do you
>     Derek> allow users to create their own accounts?
>
> Home directories and User accounts are two separate issues... I can't
> think of ANY attack, exept 'tempfile rase conditions' (?)

One of the great features of AFS is that security is based on the user
level, and not at the host level.  For example, if you have an NFS setup
where your home directories are shared to many workstations, then if one
of those machines gets hacked, then the intruder has access to EVERYONE's
home directories.

With AFS, access to the filesystem depends on what AFS token you have.
Therefore user root on a workstation does not have any special priveledges
or access to files in AFS.  Otherwise, anyone in the world could add your
cell to their CellServDB, su to root, and have complete access to your
cell.

It's possible to make your PAM module "afs-aware", just as Derek
described, however there are big security implications.  You'll basically
need to keep a cleartext administrator password somewhere on the local
filesystem -- e.g. in the binary itself or in a K5 keytab.  Then, if your
machine gets hacked by any other means, someone has complete access to
your cell.  This model is sometimes acceptable on a server, where only
administrators can log in -- someone would have to find a remote-root
exploit in order to gain access.  However on public workstations there are
likely to be many more local-root exploits available to those who can log
in as ordinary users.

Basically, in doing this, you're bringing the overall threshold of
security below that of NFS.

>     Derek> How   do  you   provision  LDAP   with  a   user's  account
>     Derek> information?   How  do you  provision  Kerberos with  their
>     Derek> password?   However you  do  it, at  that  time you  should
>     Derek> create their AFS homedirectory:
>
> LibNSS-LDAP/LibPAM-LDAP. Same way that I whould have done it if I where
> running NIS/NIS+. I tell the NSS system that I should look in LDAP for
> hosts, users, groups etc...

Why not just use pam_krb5?!  Like I asked before, using LDAP for
authentication just seems redundant.  LDAP for NSS is probably somewhat
useful.

I assume you have some script that updates your LDAP database and creates
Kerberos entries when you create new users.  Why not just add a couple
lines to that to also create an AFS home directory?

> Same way I do it now, in non-AFS space. ALL users share a 8Gb disk (my
> old 36Gb crashed, this is the temporary disk). IF I run out, I add
> a new disk (either using LVM or do Linear RAID). Both can be done more
> or less on a runtime basis (as long as no users is logged in :).

... and one of the other major features of AFS is that you don't have to
do it this way anymore.  There are "better ways".

>     Derek> Yes, this is a duplication of data.  No, there is no way to
>     Derek> have PTServer look at LDAP.  Yes, you can programatically
>     Derek> get LDAP to feed data to PTServer.  No, I do not have the
>     Derek> code to do this.
>
> If we talk theory here (I asume you know the inner workings of the
> AFS daemons), would it be possible to 'remove' the PTServer, and have
> whatever software that talks to it, talk to a SLAPD/KDC instead to get
> the information needed?

People have brought it up before, but it's just not practical.  The data
is *mostly* static, and not very redundant.  Even in very large
environments, moving to LDAP wouldn't make administration any more or less
difficult.

[ t. charles clancy ]--[ tclancy@uiuc.edu ]--[ www.uiuc.edu/~tclancy ]
coordinated science laboratory | university of illinois | crypto group