Replacing "arc" and "cmd" in the kerberos 5 environment

Overview

This document describes a plan for replacing our current tools for granting limited authorization, "arc" and "cmd". It starts with an overview of arc and cmd usage, proceeds with suggestions for replacing each of them, and gives details on maintaining "arc"'s functionality of allowing commands to be run under the AFS "admin" principal. Finally a brief discussion of possible drawbacks is given.

Overview of arc and cmd usage

Currently we use "arc" in the AFS environment, mainly to allow various users to release AFS product volumes, even though it is in fact a more general utility to run commands under alternate permissions. Similarly, we use "cmd" to let users run specific commands on the local host under a different user-id.

Possible cmd replacement mechanism

Under kerberos 5, the ksu command can be trivially wrapped to give the effect of "cmd", with the "functions" file being replaced by the .k5users file of the appropriate target accounts, to wit: 
   ksu target-account -e $CMDSCRIPTS_DIR/library/$*
where the .k5users file lists the principal, and the full path to the $CMDSCRIPTS_DIR/library/whatever script the user is allowed to run. The main issue introduced is management of the .k5users files involved; therefore one of the scripts included with k5arc should be one to manage '.k5users' files.

Suggested arc replacement

Arc can similarly be replaced by a script of the form: 
   rsh target-host -f -l arcuser \
 	ksu target-user -n user@realm -e $CMDSCRIPTS_DIR/library/$*
where the user must exist in the .k5login for "arcuser" (which would be a local, unprivileged account), *and* have an entry in the .k5users file of target-user.

To prevent abuse, (since getting a foot in the door even with an unprivelidged account can be disasterous) a restricted login shell for "arcuser" would be needed, which would allow only "ksu" commands to be run.

Similarly here, the script that manages .k5users files should also maintain the .k5login for the arcuser account.

Making AFS admin privilege work

We can:
  1. drag along 3 binaries from the kerberosIV distribution, afslog, kauth, and kdestroy, and use a kerberosIV keytab to obtain a token (for opo2), as the existing arc does. This has been prototyped, and works
  2. Get a kerberosV principal for an admin id (i.e. opo2), dump it into a kerberosV keytab, and use the kerberosV kinit -k, aklog, and kdestroy instead. This requires less ongoing maintenance, and is what I reccomend we do.

Maintenance command

So the model I'm thinking of here is some sort of command that helps you manage a bunch of hosts, and a bunch of users on that host, and their respective .k5users files. So it needs to keep a table of hosts and users for which it is maintaining lists, and:

Drawbacks of the system

Permissions Checks

Currently, the "cmd" utility goes to great lengths to check that the script being executed (i.e. the scripts in $CMDSCRIPTS_DIR/library) is not writable other than by the user or group under whose id the script is being run. This system as proposed relies on ksu for any such checks, but currently they are not as strong as those used by cmd, so this scheme is more prone to having a configuration related security hole, such as a script executed under the id of a privileged user which is world writable, or in a writable directory, etc. and thus possible to subvert.

On the other hand, cmd is oblivious to AFS permissions, and so is unable to actully fulfill its design in this regard in many cases; a directory may look fine as far as unix permissions, but have AFS ACL's of "system:anyuser rlidkwa", and cmd will happily allow its use.