Kerberos Ldap Integration

[Simo Sorce]

On Wed, 2008-06-11 at 11:28 +0200, Turbo Fredriksson wrote:
> >>>>> "Rodrigo" == Rodrigo Castro <rdccosmo at gmail.com> writes:
> 
>     Rodrigo> I guess I haven't made myself clear. In my work
>     Rodrigo> environment we have many labs. Some of them have root
>     Rodrigo> priveleges to administrate their own lab. So with their
>     Rodrigo> root account they can become any ldapuser. This is
>     Rodrigo> undesirable.  Is there any kerberos/ldap configuration to
>     Rodrigo> disable this?
> 
> This can't be avoided. If they are root on the machine, they have
> full access _to that machine_, including any home directories etc
> for users only in LDAP.

It depends on the OS, using SELinux on a linux kernel for example, you
can certainly constrain root too, and make it impossible for it to
access some resources even if it successfully 'su user' because you can
always check who the user really is via SELinux.

Granted such configuration is not easy to build on your own, but it is
feasible, in theory and practice (as long as the malicious admin can't
reboot and disable the selinux controls).

> HOWEVER, there is (at least) one way around this. Use AFS as
> storage for user home directories etc... Then set appropriate
> access control for the directories.
> 
> You could also use NFS (with the "squash_root" or whatever the
> option in the exports was - it's been more than eight years since
> I touched NFS last :).

Root squash is useless i this case.

> That way, it doesn't matter if the are root, they won't have access
> to the directories any way. In the first case, they must have a
> valid Kerberos V ticket to get a token for the AFS share.
> 
> In the other case (NFS), the root access is 'squashed' and they have
> 'anonymous' access on the share in question. That require that the
> access mode on the directories are smart enough to stop this.

root can always "su user", from that point on he will access the user's
files on NFS as that user. Remember NFS (except when sec=krb5 is used)
always fully trust the client machine. Root squash only prevents you to
write/read files *as* uid 0 on the server.


> There might be other network file system which will give you the
> same solution, but other than that there's no way to stop a local
> root to have full access on the local machine!

CIFS/SMB is another network file system that does not trust the client
machine but requires authentication to access resources as a specific
user. Yet kernel client drivers not always enforce that, and in some
cases they let users share their own access with all the users of the
machine. We are working on fix it on the linux side by adding kerberos
support.

Simo.

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