RE: Kerberos Ldap Integration - Kerberos

This is a discussion on RE: Kerberos Ldap Integration - Kerberos ; A root user on a system can become any user ID on that system. That's just the way unix security works. What you are trying to prevent is a root user on system A accessing user data on system B ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: RE: Kerberos Ldap Integration

  1. RE: Kerberos Ldap Integration

    A root user on a system can become any user ID on that system. That's just the way unix security works.

    What you are trying to prevent is a root user on system A accessing user data on system B without knowing the users' credentials.
    This is precisely what Kerberos prevents. System B will not accept inbound sessions without a Kerberos ticket, and it is impossible
    for a root user on system A to gain a TGT for the user without knowing the users' credentials.

    Eric

    > -----Original Message-----
    > From: kerberos-bounces@mit.edu [mailto:kerberos-bounces@mit.edu] On Behalf Of Rodrigo Castro
    > Sent: Tuesday, June 10, 2008 9:07 AM
    > To: Daniel Savard
    > Cc: kerberos@mit.edu
    > Subject: Re: Kerberos Ldap Integration
    >
    > I guess I haven't made myself clear. In my work environment we have many
    > labs. Some of them have root priveleges to administrate their own lab. So
    > with their root account they can become any ldapuser. This is undesirable.
    > Is there any kerberos/ldap configuration to disable this?




  2. Re: Kerberos Ldap Integration

    "Eric Hill" writes:

    > What you are trying to prevent is a root user on system A accessing
    > user data on system B without knowing the users' credentials. This is
    > precisely what Kerberos prevents. System B will not accept inbound
    > sessions without a Kerberos ticket, and it is impossible for a root
    > user on system A to gain a TGT for the user without knowing the users'
    > credentials.


    Not true in general. The superuser has often the capability to read the
    user's credential cache (be it a plain file or something memory based)
    and could therefore impersonate the respective user - if already a valid
    ticket has been acquired by the user.


    Sebastian

  3. Re: Kerberos Ldap Integration

    Yes, local users with su access could obtain a user's tgt, and then use
    that ticket to access network services in the user's name. However, the
    impostor could only use the tgt until the tickets expire, so there is a
    limit to the damage. If you are worried about this in the labs, set the
    tgt's for the "lower users" to expire after an hour or two.

    Consider just giving them sudo access instead of full root access. Then,
    redirect syslog to a system outside the admins' control. This way, all
    sudo action is logged. Then, in your orientation, emphasize the fact
    that, while they can do rouge stuff, it will be logged if they do. Ha ha ha.

    You can also setup sudo to use ldap for sudoers, so the administrative
    headache is not as large.

    - Scott

    Sebastian Hanigk wrote:
    > "Eric Hill" writes:
    >
    >
    >> What you are trying to prevent is a root user on system A accessing
    >> user data on system B without knowing the users' credentials. This is
    >> precisely what Kerberos prevents. System B will not accept inbound
    >> sessions without a Kerberos ticket, and it is impossible for a root
    >> user on system A to gain a TGT for the user without knowing the users'
    >> credentials.
    >>

    >
    > Not true in general. The superuser has often the capability to read the
    > user's credential cache (be it a plain file or something memory based)
    > and could therefore impersonate the respective user - if already a valid
    > ticket has been acquired by the user.
    >
    >
    > Sebastian
    > ________________________________________________
    > Kerberos mailing list Kerberos@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos
    >
    >




  4. Re: Kerberos Ldap Integration

    True, I was going with the case of a lab of single person workstations
    in which no other creds would exist on the system. So root wouldn't
    be able to establish the creds.

    In the other case stealing the creds as root is certainly more
    difficult then accidental usage of root privileges. Again going with
    the lab problem posted here.

    Derek

    On Jun 10, 2008, at 9:37 AM, Sebastian Hanigk wrote:

    > "Eric Hill" writes:
    >
    >> What you are trying to prevent is a root user on system A accessing
    >> user data on system B without knowing the users' credentials. This
    >> is
    >> precisely what Kerberos prevents. System B will not accept inbound
    >> sessions without a Kerberos ticket, and it is impossible for a root
    >> user on system A to gain a TGT for the user without knowing the
    >> users'
    >> credentials.

    >
    > Not true in general. The superuser has often the capability to read
    > the
    > user's credential cache (be it a plain file or something memory based)
    > and could therefore impersonate the respective user - if already a
    > valid
    > ticket has been acquired by the user.
    >
    >
    > Sebastian
    > ________________________________________________
    > Kerberos mailing list Kerberos@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos




+ Reply to Thread