Recipe 5.20 Sharing root Privileges via Kerberos su

5.20.1 Problem

You want to obtain root privileges in a Kerberos environment.

5.20.2 Solution

Use ksu .

To obtain a root shell:

$ ksu

To obtain a shell as user barney:

$ ksu barney

To use another Kerberos principal besides your default for authentication:

$ ksu [user] -n principal ...

To execute a specific command under the target uid, rather than get a login shell:

$ ksu [user] -e command

5.20.3 Discussion

Like the usual Unix su program, ksu allows one account to access another, if the first account is authorized to do so. Unlike su, ksu does authentication using Kerberos rather than plain passwords, and has many more options for authorization.

With su, one simply types su <target>. su prompts for the target account's password; if the user supplies the correct password, su starts a shell under the target account's uid (or executes another program supplied on the su command line). With ksu, both authentication and authorization are done differently.

5.20.3.1 Authentication

ksu performs authentication via Kerberos, so you must select a Kerberos principal to use. First, ksu tries the default principal indicated in your current Kerberos credentials cache (klist command). If you have no credentials, then it will be the default principal indicated by your Unix account name and the local Kerberos configuration. For example, if your Unix username is fred and the Kerberos realm of your host is FOO.ORG, then your default principal would normally be [e-mail] (note that Kerberos realm names are case-sensitive and by convention are in uppercase). If this principal is authorized to access the target account (explained later), then ksu proceeds with it. If not, then it proceeds with the default principal corresponding to the target account. The usual effect of this arrangement is that either your usual Kerberos credentials will allow you access, or you'll be prompted for the target account's Kerberos password, and thus gain access if you know it.

You may select a different principal to use with the -n option, e.g.:

$ ksu -n [e-mail] ...

but let's suppose your selected principal is [e-mail].

First, ksu authenticates you as [e-mail]; specifically, if this host is bar.foo.org, you need a service ticket granted to that principal for host/[e-mail]. ksu first attempts to acquire this ticket automatically. If you don't have exactly that ticket, but you do have valid Kerberos credentials for this principal that is, you have previously done a kinit and acquired a ticket-granting ticket (TGT) then ksu simply uses it to obtain the required ticket. Failing that, ksu may prompt you for [e-mail]'s password. Note two things, however: first, be careful not to type the password over an insecure link (e.g., an unencrypted Telnet session). Second, ksu may be compiled with an option to forbid password authentication, in which case you must have previously acquired appropriate credentials, or the ksu attempt will fail.

5.20.3.2 Authorization

Having authenticated you via Kerberos as [e-mail], ksu now verifies that this principal is authorized to access the target account, given as the argument to ksu (e.g., ksu barney; the default is the root account). Authorization can happen one of two ways:

1. User barney has allowed you access to his account by editing his Kerberos authorization files. The two authorization files are ~barney/.k5login and ~barney/.k5users. The first contains simply a list of principals allowed to access the account; the second contains the same, but may also restrict which commands may be executed by each authorized principal. So, to allow Fred to access his account via ksu, Barney would create ~/.k5login containing the single line:

   ~/.k5login: [e-mail]

   To allow Fred access only to run ~/bin/myprogram, Barney could instead place this line in ~/.k5users:

   ~/.k5users: [e-mail] /home/barney/bin/myprogram

2. Your Kerberos principal and the target account match according to the local Kerberos lname->aname rules. Normally, this is the simple correspondence of account barney and principal [e-mail]. This doesn't usually happen, since normally you would be accessing a different account than your own, and have Kerberos credentials for the principal corresponding to your account, not the target. However, you could arrange for this by first running kinit barney, if you happen to know the password for [e-mail].

Some additional notes:

• If either authorization file for an account exists, then it must specify all principals allowed access including the one corresponding to that account and otherwise allowed access by default. This means that if you create a ~/.k5login file to allow your friend access, you will likely want to list your own principal there as well, or you cannot ksu to your own account.

• By default, the Kerberos credentials cache for the created process, under the target uid, will contain not only the ticket(s) authorizing the session, but also valid tickets from the original user as well. If you want to avoid this, use the -z or -Z options.

5.20.4 See Also

ksu(1), and our Kerberos coverage in Chapter 4.