[29953] in Kerberos

home help back first fref pref prev next nref lref last post

Re: Kerberos Ldap Integration

daemon@ATHENA.MIT.EDU (Simo Sorce)
Wed Jun 11 10:19:35 2008

From: Simo Sorce <ssorce@redhat.com>
To: Turbo Fredriksson <turbo@bayour.com>
In-Reply-To: <87zlpsb9rs.fsf@pumba.bayour.com>
Date: Wed, 11 Jun 2008 10:17:04 -0400
Message-Id: <1213193824.26517.89.camel@localhost.localdomain>
Mime-Version: 1.0
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="utf8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit

On Wed, 2008-06-11 at 11:28 +0200, Turbo Fredriksson wrote:> >>>>> "Rodrigo" == Rodrigo Castro <rdccosmo@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, youcan certainly constrain root too, and make it impossible for it toaccess some resources even if it successfully 'su user' because you canalways check who the user really is via SELinux.
Granted such configuration is not easy to build on your own, but it isfeasible, in theory and practice (as long as the malicious admin can'treboot 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'sfiles on NFS as that user. Remember NFS (except when sec=krb5 is used)always fully trust the client machine. Root squash only prevents you towrite/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 clientmachine but requires authentication to access resources as a specificuser. Yet kernel client drivers not always enforce that, and in somecases they let users share their own access with all the users of themachine. We are working on fix it on the linux side by adding kerberossupport.
Simo.
-- Simo Sorce * Red Hat, Inc * New York
________________________________________________Kerberos mailing list           Kerberos@mit.eduhttps://mailman.mit.edu/mailman/listinfo/kerberos

home help back first fref pref prev next nref lref last post