This is a discussion on Re: Kerberos Ldap Integration - Kerberos ; Thanks a lot turbo and all. I'll study the best approach to apply here in the Uni. On Wed, Jun 11, 2008 at 6:28 AM, Turbo Fredriksson wrote: > >>>>> "Rodrigo" == Rodrigo Castro writes: > > Rodrigo> I guess ...
Thanks a lot turbo and all. I'll study the best approach to apply here in
On Wed, Jun 11, 2008 at 6:28 AM, Turbo Fredriksson
> >>>>> "Rodrigo" == Rodrigo Castro
> 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.
> 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 .
> 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.
> 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!
> Rodrigo> On Tue, Jun 10, 2008 at 10:28 AM, Daniel Savard
> Rodrigo> wrote:
> >> You cannot prevent root to su to any other local user. This is
> >> why root is called a superuser. This has nothing to do with
> >> Kerberos or LDAP, this is an OS issue.
> Another, more cumbersome solution would be to stop root access completely,
> and instead use sudo. Sudo can be setup so that there are 'command groups'
> (groups of accepted commands) and those groups can be applied to users.
> I don't have that config any more, but I used it a couple of years ago.
> The sudoers(5) man page have extensive examples on how to set this up.
> And this can be 'ldapified' (i.e. with external patch - included with
> Debian GNU/Linux if I'm not mistaken), the sudoers file can be 'put'
> in the LDAP database...
> It's just a matter of what you mean by 'administrate there own labs'.
> Being a little clever, you can write sudo rules instead of giving them
> full root access.
Rodrigo de Castro Cosme
Ciência da Computação - Universidade Federal do Espírito Santo
Suporte mailing list - email@example.com
MSN - firstname.lastname@example.org