[Freeipa-devel] Maintaining Identity in a large cluster

[Matthew Booth]

Jan-Frode Myklebust wrote:
 > An option would maybe be to do all root-tasks trough sudo. And use the
> NOPASSWD:-option in the sudoers config. Establish a policy that one
> should never log in as root, and always use sudo.
> 
>     %sysadmin   ALL=(ALL)       NOPASSWD: ALL
> 
> Or to encourage your sysadmins to not cheat:
> 
>     Cmnd_Alias     SHELLS = /bin/ash,  /bin/ksh,  /bin/bash, /bin/sh, /bin/bsh, /bin/tcsh, /usr/sbin/sesh, /bin/csh, /sbin/nash
>     Cmnd_Alias     TERMINALS  = /usr/bin/gnome-terminal, /usr/bin/konsole, /usr/bin/xterm, /usr/bin/uxterm
>     Cmnd_Alias     SU = /bin/su
>     %sysadmin  ALL = (ALL) NOPASSWD: ALL, !SU, !SHELLS, !TERMINALS
> 

This would effectively amount to denying an unfettered root shell to the
system administrators. I wouldn't want to do this on any machine I
administered, so I can see it not being accepted (and therefore
circumvented). For example, descending a directory structure for which
my user account has no privilege suddenly breaks tab completion. Not to
mention the additional finger ache from prefixing every individual
command with sudo.

I'm really looking to improve accountability without breaking features.
Auditing is pretty low on a cluster administrator's priority list, as
I'm sure you're aware ;) I wouldn't want to rely on selling a solution
which will make their jobs miserable.

>> The solution is typically ssh keys shared across the cluster. The effect 
>> of this is that anyone who can perform an identity change on any machine 
>> can become anonymous on the cluster just by logging on to another node 
>> after the identity change.
> 
> Don't allow identity changes. 

See above for discussion of root, below for discussion of processing users.

>> In practise, most/all users will be able to 
>> perform an identity change. If they are administrators this will be to 
>> root. If they are users, this will be to a processing user.
> 
> I don't see why users should need to change to a processing user. Why
> can't they run as their login user ?

A job might run for 2 months, and there's a team of people who might
start it, poke it or kill it. It might also be started automatically
(another interesting case in itself). Going back to the single machine
analogy, imagine:

* Running a daemon as jbloggs and relying on group permissions.
* Running database backups as jbloggs from cron, and relying on group
permissions.

You just wouldn't do that.

Matt
-- 
Matthew Booth, RHCA, RHCSS
Red Hat, Global Professional Services

M:       +44 (0)7977 267231
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490