[Freeipa-devel] Maintaining Identity in a large cluster

[Simo Sorce]

On Fri, 2008-06-27 at 00:03 +0100, Matthew Booth wrote:
> 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.

You can even just allow su or sudo, the point is in using only user
credentials to login to other machines. with a distributed shell, the
first command can then be: 'sudo su -'
This is fine, gives you access on all machines (but never directly as
root) and you will see who and when became root.
Most task done as root in a cluster are anyway done because of laziness,
not because root is actually needed, in many cases limiting most admins
to a few sudo commands is the right approach security wise.

> I'm really looking to improve accountability without breaking features.

Giving root and ssh keys is certainly not the right way then. Especially
ssh keys which cannot be centrally revoked and do not expire.

> 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.

It really boils down to the usage pattern, but denying root login and
allowing 'sudo su -' without password is imo better than giving everyone
the root password or an ssh key that let you login as root.

> >> 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.

Yet, this is a sound security principle, identity changes should be
minimized as much as possible.

> >> 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.

On a single machine it is very rare to share process between groups. |It
it a computational cluster specific characteristic. You should really
use batch tools that run the processes for you, enforce quotas and
precedence, and audit trails what happens to job, who requests a job to
be killed, check if it is allowed and so on.

The real problem here is that you should firmly distinguish between an
admin user doing cluster related maintenance tasks, and cluster users.

An admin may have legitimate needs to do root level operations on all
nodes.
A user generally not, and shouldn't even know how to jump on other
nodes, it should be given access only to a front-end component to the
cluster and a tool that provide the operations necessary to request
cpu/disk/memory within the limit of the system and run process, a batch
system.

Simo.

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