"Stealing" the credential cache - Kerberos

This is a discussion on "Stealing" the credential cache - Kerberos ; The system is Debian Linux (Etch, krb-user 1.4.4-7etch5): I didn't expect, that the root user can simply copy the credentials cache file and re-use the ticket: -------------------------------------------------------------------------- # aklog aklog: Couldn't get xxxxxxx.de AFS tickets: aklog: No credentials cache found ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: "Stealing" the credential cache

  1. "Stealing" the credential cache

    The system is Debian Linux (Etch, krb-user 1.4.4-7etch5):

    I didn't expect, that the root user can simply copy the credentials cache
    file and re-use the ticket:

    --------------------------------------------------------------------------

    # aklog
    aklog: Couldn't get xxxxxxx.de AFS tickets:
    aklog: No credentials cache found while getting AFS tickets
    # cat /afs/xxxxxxxx/user/XXXXX/.bash_history
    cat: /afs/xxxxxxxx/user/XXXXX/.bash_history: Permission denied
    # whoami
    root
    # ls -l /tmp/krb5cc_*
    -rw------- 1 XXXXX users 894 2008-08-13 09:32 /tmp/krb5cc_556
    # cp /tmp/krb5cc_556 /tmp/krb5cc_0
    # klist -f
    Ticket cache: FILE:/tmp/krb5cc_0
    Default principal: XXXXX@XXXXXXX.DE

    Valid starting Expires Service principal
    08/13/08 09:31:45 08/13/08 19:31:45 krbtgt/XXXXXXX.DE@XXXXXXX.DE
    renew until 08/21/08 09:31:45, Flags: FPRIA
    08/13/08 09:31:45 08/13/08 19:31:45 afs@XXXXXXX.DE
    renew until 08/21/08 09:31:45, Flags: FPRAT

    Kerberos 4 ticket cache: /tmp/tkt0
    klist: You have no tickets cached
    # aklog
    # head -n1 /afs/xxxxxxx/user/XXXXX/.bash_history
    [protected data from username XXXXX]

    --------------------------------------------------------------------------

    Is this the expected behaviour, that the root user of a client (the user has
    no interactive access to the Kerberos and AFS servers) can use a copy of the
    credentials cache for getting an afs token?


    Thank you,
    Erik

    (Followup-To: alt.filesystems.afs)

  2. Re: "Stealing" the credential cache

    On Aug 13, 2008, at 07:55, E. Braun wrote:
    > Is this the expected behaviour, that the root user of a client (the
    > user has
    > no interactive access to the Kerberos and AFS servers) can use a
    > copy of the
    > credentials cache for getting an afs token?


    Yes. Finding a place where the superuser cannot access a user's
    credentials (either directly or by changing uid to the user, or in an
    extreme case, attach a user's process via ptrace or whatever, as if
    under a debugger, and extract the authentication info from the user's
    process) is a system-specific problem and not always possible; it
    requires that the OS enforce restrictions on a superuser account.

    I'm not familiar with whether the keyring code in Linux (optionally
    used in recent MIT Kerberos releases) enforces such restrictions. If
    we could hook into AFS process authentication groups, that might help
    raise the bar as well, to prevent casual copying but not the ptrace
    attack, but only on systems where AFS is installed (specifically
    implementations with PAGs). Ken Hornstein has patches around to use
    an extra, high-numbered file descriptor inherited across processes,
    with the process fd limit lowered to just below that fd, which
    restricts access to a login session (aside from the ptrace attack),
    but requires modifications to the login process to set up this file
    descriptor, and requires that no process close all the high-numbered
    file descriptors (which I gather is actually fairly uncommon to do
    above the lowered file descriptor limit).

    BTW, comp.protocols.kerberos is relayed to/from a mailing list;
    directing followups to a different newsgroup is not going to work for
    some readers.

    Ken

  3. Re: "Stealing" the credential cache

    On Wed, 2008-08-13 at 09:47 -0400, Ken Raeburn wrote:
    > On Aug 13, 2008, at 07:55, E. Braun wrote:
    > > Is this the expected behaviour, that the root user of a client (the
    > > user has
    > > no interactive access to the Kerberos and AFS servers) can use a
    > > copy of the
    > > credentials cache for getting an afs token?

    >
    > Yes. Finding a place where the superuser cannot access a user's
    > credentials (either directly or by changing uid to the user, or in an
    > extreme case, attach a user's process via ptrace or whatever, as if
    > under a debugger, and extract the authentication info from the user's
    > process) is a system-specific problem and not always possible; it
    > requires that the OS enforce restrictions on a superuser account.


    You should be able to use SELinux to achieve this goal, not sure how
    hard would it be to build the policy though.

    Simo.

    --
    Simo Sorce * Red Hat, Inc * New York


  4. Re: "Stealing" the credential cache

    Ken Raeburn writes:

    > I'm not familiar with whether the keyring code in Linux (optionally
    > used in recent MIT Kerberos releases) enforces such restrictions.


    You would probably need to also run something like SELinux to limit the
    capabilities of root, if my understanding of how the authorization model
    in the kernel works is correct.

    > If we could hook into AFS process authentication groups, that might help
    > raise the bar as well, to prevent casual copying but not the ptrace
    > attack, but only on systems where AFS is installed (specifically
    > implementations with PAGs). Ken Hornstein has patches around to use an
    > extra, high-numbered file descriptor inherited across processes, with
    > the process fd limit lowered to just below that fd, which restricts
    > access to a login session (aside from the ptrace attack), but requires
    > modifications to the login process to set up this file descriptor, and
    > requires that no process close all the high-numbered file descriptors
    > (which I gather is actually fairly uncommon to do above the lowered file
    > descriptor limit).


    This too only protects against casual attacks, since root can still get
    access to this ticket cache by trying hard enough.

    --
    Russ Allbery (rra@stanford.edu)

+ Reply to Thread