[OpenAFS] bos cron jobs and tokens

[Marcus Watts]

Juha =?UTF-8?B?SsOkeWtrw6Q=?= <juhaj@iki.fi> writes:
> From: Juha =?UTF-8?B?SsOkeWtrw6Q=?= <juhaj@iki.fi>
> To: openafs-info@openafs.org
> Message-id: <20070405134814.703cb3dd@noether.tfy.utu.fi>
> Subject: [OpenAFS] bos cron jobs and tokens
> Sender: openafs-info-admin@openafs.org
> 
> Hi!
> 
> Is there any way to run bos cron jobs out of /afs? It does not look like
> a job started by bos has tokens, so that would require system:anyuser rl
> ACLs on the whole AFS tree leading to the program to be run. Is there
> another way? One that would not require opening up the ACL's. Or is it
> simply Bad Idea to run bos cron stuff from afs?
> 
> -Juha

Yes and no, yes, and yes.

You can mount /afs on a machine, install bosserver & KeyFile, and
run things.  A job started by bos has all the rights that bos has.
Since bos has the KeyFile, the job can access the KeyFile.  That
in turn gives it the ability to forge service tickets.  "-localauth"
forges tickets for a fictional entity which has special rights over
afs, but no distinct user identity.  However, there's nothing that
stops the application run from bos from grabbing the keys and forging
its own ticket on behalf of any person it wants to impersonate.
If it wasn't obvious before, yes, that means the KeyFile is something
you want to keep as secure as possible.  You don't say what you want
your bos job to do - but in general, what you could do with bos cron jobs
& the KeyFile is probably not what you really want to use.

One thing you particularly don't want to do is to have a "god" job that
crawls through arbitrary afs space owned by users ("find ...").  An
astute user who knows this is happening and has write access can do all
sorts of interesting things with race conditions, symbolic links, and
the like.  Even something simple like making another mount point for
"root.afs" will produce inconvenient results for your script.

The "right minded" way would be to use some other *less* privileged
server, one that does NOT have KeyFile or bos on it, run your chosen
cron or other scheduling service on it, then in the job you spawn from
that, invoke it using "pagsh", and inside that script, use "kinit"
(with a keytab), followed by "aklog", to get tokens, do whatever
you need to do, then use unlog + kdestroy at the end of your script to
clean up.  The principal this uses then does not need "god" rights on
AFS, it only needs whatever the least privileges that are necessary to
accomplish your chosen task.  You could run multiple different instances
with different rights from the same machine - and run them with different
UIDs != root to gain even more local security.  If you provide a way
for IT providers in your enterprise to acquire keytabs & corresponding
pt instances, then they too can use this trick to deploy applications in
their IT environment to perform unattended processing requiring
authenticated access to AFS resources.

If you find pagsh+kinit+aklog too onerous to deal with, you might want
to use Russ Allbery's "k5start" instead.
	http://www.eyrie.org/~eagle/software/kstart/k5start.html
For a cron job, this won't do anything that pagsh+kinit+aklog will do for
you, but you might find it easier to use.  k5start is probably most
valuable if you need to run a long-running job, and you want something
to automatically renew tokens while the job is running.

					-Marcus Watts