[OpenAFS] Re: OpenAFS-info digest, Vol 1 #843 - 16 msgs

[James L Robinson]

On Wednesday 09 October 2002 07:32 am, openafs-info-request@openafs.org w=
rote:
> How can I make the file readable only to root on the clients, so lpd ca=
n
> read it? If the ACL is "system:anyuser rl" AFS ignores the Unix file
> rights (600) and the file is worldwide readable. Should I set up a
> separate usergroup for whatever user that runs lpd?

Not quite so simple. For some background WRT/ printing and AFS in
general, check out:

=09http://www.angelfire.com/hi/plutonic/afs-faq.html#sub2.12

The general problem is that LPD / whatever the printer spooler
subsytem is isn't usually running with a token, i.e. authenticated
to AFS in any way, and especially won't inherit the authentication
token of the user. Folks solve similar issues on non-interactively-used
locked-down server-type machines such as mail or web servers
through installing a keytab onto the local disk of the server machine,
then arranging it such that the startup script for the service will first
create a PAG and authenticate to AFS using the information in the
keytab. Then, said service runs authenticated in AFS's eyes, and can
then be referenced by ACLs in AFS. We use this technique to
deliver mail into AFS, as well as for webservers to be able to
access one's public_html subdir.

Complicating this issue is that AFS only supports ACLs on directories,
not files, so if you need to give access to a single file in a dir to an
authenticated entity, but not all files in said dir (such as the homedir)=
,
then you might work around that by creating a new subdir, moving
the file(s) in question to the new subdir, adjusting the ACL on the
subdir to grant the necessary access, then symlinking to the subdir/file
from the original dir. Lastly, you then need to grant the look right
to the principal in question on the original dir, so that they'll be able
to read where the symlink points to.

You could glue these two techniques together to get
the action you desire. But, it would include dropping a root-owned
mode 600 keytab file for your "printer" KA / PTS principal onto
the local filesystem of all of your interactive client UNIX boxes.
The keytab is relatively just as good as the password for that account,
and if anyone broke root on any of those machines, they then have
gained access to that keytab file, and can then authenticate themselves
as "printer" in the eyes of AFS, and can subsequently mine your cell
for all ~user/.novell/.novell-password files.

Perhaps you could set up an intermediate non-interactively-used UNIX prin=
t
spooler box that has the keytab file as per above, but also acts as an LP=
D
spooler gateway for all of your Novell queues. Then the interactive UNIX =
boxes
don't need to have any keytabs -- they think that those print queues are
remote LPD queues. This intermediary's LPD service runs authenticated
via a keytab, and can then look at ~user/ and read files in ~user/.novell=
/
to yank the username and password as it spools the job to novell-land.
Since this intermediary box is not general purpose, only admins should
be able to log into it (by SSH), so the range of possibilities to have ro=
ot
cracked on the box and the keytab exposed should be greatly reduced.

Lastly, by default AFS client <--> fileserver interactions for file data =
is
done in cleartext. Than can be changed to use some form of crypto
(single DES?) by issuing an "fs setcrypt on" command after your LPD
startup script obtains a token but before it performs the first interacti=
on
with the fileservers (i.e. before it starts up LPD). Since this file data
involves passwords in your case, this would keep those passwords from
flying around in cleartext as LPD reads 'em from AFS. But it would not
help when the client user saves that file per se, so someone sniffing you=
r
AFS traffic could still possibly snake some cleartext passwords in this
case.

All that said, there may well be better, simpler ways to solve your probl=
em
other than stashing user passwords into the filespace.

Good Luck.

--=20
James Robinson                          Phone: (704) 687-4876
College of Information Technology       FAX:   (704) 687-3516
UNC Charlotte                           Email: jlrobins@uncc.edu
Charlotte, NC 28223-0001                Director of Technology Services