Linux Security Cookbook [Electronic resources] نسخه متنی

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

fred@FOO.ORG (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 wilma@FOO.ORG ...

but let's suppose your selected principal is

fred@FOO.ORG .

First, ksu authenticates you as

fred@FOO.ORG ; specifically, if this host is

bar.foo.org , you need a service
ticket granted to that principal for
host/bar.foo.org@FOO.ORG. 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 principalthat 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

fred@FOO.ORG '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

fred@FOO.ORG ,
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:
   fred@FOO.ORG

   To allow Fred access only to run
   

   ~/bin/myprogram , Barney could instead place this
   line in ~/.k5users:

   ~/.k5users:
   fred@FOO.ORG /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

   barney@FOO.ORG . 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

   barney@FOO.ORG .

Some additional notes:

• If either authorization file for an account exists, then it must
  specify

  all principals allowed
  accessincluding 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 Chapter 4.