|
>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@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. |
-- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
