[Linux-cluster] Testing a fence program

[John Anderson]

>Have them go reread the man page on specifying commands and associating
them with keys. 

 

Visa and MasterCard mandate that direct superuser access will not be
allowed remotely.  In other words, their auditors must see the line
"PermitRootLogin no" in our sshd configs.  Our security guys have very
little say in that respect.

>oh? I don't know anything about running Xen. But I fail to grasp the
rationale behind denying both SU or logins as root. It sounds like the
"security" people can't tell the difference between real security
management and somebody's >naive policy assertion. It's rather telling
that they think some home-grown application is a more secure/acceptable
solution.

It's not su- that's disabled.  The obvious reason I was speaking of is
the authentciation after su - is invoked.  Given the following shell
script excerpt;

#!/bin/bash

ssh nobody at host -c "su -; xm shutdown domain3"

We can't very well pass the root password to su with expect,  that's
just bad practice in anyone's book.  Neither can we allow nobody to su
without authentication, that's even worse practice.  

Making xm setuid  and protecting it with RBAC controls is not an option
either, beause xm is a python script.  I would have to make python
setuid, and that's the worse scenario yet.

So it seems that a small daemon running on the xen host that receives a
request from a fence agent, then makes the appropriate libvirt call to
destroy the instance is both relatively simple while remaining secure.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-cluster/attachments/20060822/0ec07d38/attachment.htm>