[Beowulf] CLuster - Mpich - tstmachines - Heeelp !!!!!!!!

[Robert G. Brown]

On Wed, 19 Jul 2006, hahn at physics.mcmaster.ca wrote:

> I think you mean passphrase-encrypted key - yes, that's what I meant.
> un-passphrase'd keys would be equivalent in crypto-strength, but anyone who 
> managed to get a hold of the private key would have complete access.

This is one of the many marginal cost issue associated with security.
nopasswd keys in plaintext give somebody complete access IF they get
into your account.  But if they get into your account then you're done
anyway, so many ways.

I'm waiting with great interest to see if "keyrings" make any
difference. In principle they protect your plaintext keys, but of course
that is at the expense of having to type a password to get at them.
Which in turn means that when somebody gets your account they get them.

>
>> The usage schema of sudo is inherently safer -- increase privilege for
>> one task only, then go back to SOP. Control is also more granular, so it
>> is more secure.
>
> the more often as password is typed, the less secure it is.

Yeah, I think y'all worry too much about the su/sudo/ssh passwd/nopasswd
issues (not just you, Mark, but everybody).  I don't think there is an
accepted "best practice" per se here, although there is much lore.  I
really think that it comes down to one thing.  "Good" admins watch their
systems like hawks, use a number of automated monitoring tools that look
for at least certain classes of anomaly that can indicate a compromise,
and master the security aspects of whatever method they prefer to access
root.

I myself dislike sudo -- for a variety of reasons that are all arguable,
as it is really more a matter of style rather than substance.  I just
don't want to bother making up a set of granular mappings between
people, tasks, privileges for anybody else and CERTAINLY don't want to
do it for myself.  When I'm root I'm root, when I'm not I'm not, and
yeah, I have to be responsible for knowing the difference and being
careful appropriately.  Over the last couple of decades I have learned
-- the hard way -- to be VERY CAREFUL as root.  Nothing like having to
rebuild or reinstall a system you've completely trashed because of an
injudicious keystroke (like that extra keystroke in "rm -rf * .txt" when
you meant "rm -rf *.txt":-) to teach one discretion...

To avoid having to constantly retype the root password, I find
installing e.g.

  alias z='suspend'

to be a really useful thing.  For example:

rgb at lilith|B:1011>su
Password: 
rgb at lilith|B:1001#echo "I'm root! "
I'm root! 
rgb at lilith|B:1002#z

[1]+  Stopped                 su
rgb at lilith|B:1012>echo "Now I'm not! "
Now I'm not! 
rgb at lilith|B:1013>fg
su
rgb at lilith|B:1003#echo "Yes I am! "
Yes I am! 
rgb at lilith|B:1004#z

[1]+  Stopped                 su
rgb at lilith|B:1014>echo "No I'm not! "
No I'm not!

Using this trick, one can su to root in an xterm/shell window to do some
particular task, do whatever you need to as root, and then just pop back
to your user shell.  Work away, do things as self without risk of
trashing the whole system.  Pop back into root to do another root-based
chore (like checking /var/log/messages) no password required as you
haven't exited the original root shell.  Done, back to work as a user.

Is this "good practice"?  Sure, why not?  If I'm careless and walk away
from a terminal with a background root shell, an Evil Person can fg it
and access root.  Of course if I walk away from a terminal with my
FOREGROUND shell still open, that same EP can booby trap my personal
account, install trojans for su and/or sudo and/or login and/or ssh --
basically anything you think is "secure" -- and trap the actual
passwords, just as a really nasty EP can put up a login splash screen
inside THEIR shell and trap your passwords that way.

(At the risk, of course, of being discovered by your VIGILANCE and being
suspended by their feet from the ceiling, beaten vigorously with a
sucker rod, and then chucked out of the window into a dumpster filled
with broken glass...;-)

So yeah, you have to be careful as root and with root privileges.
Period.  If you aren't confident in your ability to regulate activities
accordingly, sudo is lovely, have at it.  If you prefer to work through
the current system-config-X tools (with their little timed root access)
have at them.  If you like ssh root with or without passwords, fine, but
be aware that it is YOUR responsibility to figure out how to use either
one safely and YOUR responsibility to e.g. read the /var/log/secure logs
to see if "you" do something as root when, in fact, you didn't.

su vs sodo is really very much like the C/C++ dichotomy.  C++ provides
various protections, C does not.  Some people like the comfort and
associated functionality of the protections, others just want the power
(and responsibility) of unprotected access.

>
>>> right - I don't have a problem with rsh as an internal cluster spawn
>>> method.
>>> though since you almost certainly also have sshd running, it makes sense
>>> to have fewer daemons.
>> It's okay for a small cluster where you have really good control over
>> the users.
>
> I understand why you would say this, but I don't think it's true:
> regardless of the size of the cluster or randomness of the user community, 
> once someone gets root, they get everything.  I don't see

This is dead on the money absolutely true.  And don't think that number
of users or size of cluster makes it safe.  Privilege needs to be
protected and due diligence needs to be exercised, as a root person can
violate ANYBODY'S privacy invisibly.  I have had to help clean up after
a mess created when a small research group was casual about root access
and in fact kept the root password on the bulletin board of their lab
cluster (which was otherwise very nicely protected and where the lab
itself was kept locked up with a real key).  Turns out that a postdoc
who was being casually employed to do some contract programming was an
Evil Person!  Who'd have thunk it.  This individual proceeded to steal
ALL the research results of ALL the members of the lab, making complete
copies of all of their personal and research space.  Private stuff,
intellectual property (which is apparently what they were after), the
whole nine yards.  Shipped back to the Eastern European country that
they came from, presumably to be filtered out and turned into money
somehow.

Don't think that this couldn't happen to you.  The individual in
question was booted from the system and banned from the University, but
knocked around in the research/computing industry and was last sighted
working for a major supercomputing center, quite possibly one near you
(and quite probably IMHO still shopping for IP to steal and ship home).
Trust is precious and needs to be granted only to trustworthy
professionals, and only then with due diligence, supervision, and with
signed agreements.

I personally think rsh is something that needs to disappear and never
return.  It is essentially impossible to secure -- easy to snoop, easy
to spoof.  However, I'm happy enough to respect alternative opinions
here, and sure, used INSIDE a "real beowulf" cluster design with only
research accounts on the head node (no private information) and with
everybody in the research group already trusted with all the research
data that might be on the cluster, it is clearly not a security problem.
That's pretty much the ONLY configuration in the known universe where
it's not a security problem, but I suppose it is comforting to know
there is one.

> why the number of nodes would make any difference (since they're probably all 
> running the same distro, therefore have the same holes).
> and I'm not sure the use-base matters either, except that more users
> mean more chances someone will go grey some weekend, or get compromised.

Ya.  In fact, a small, intimate research group can give you an entirely
unjustified sense of security.  The safest thing to do is to assume that
each and every one of your OBVIOUSLY trustworthy users is in fact a
personality disordered psychotic who takes secret pleasure from gaining
root privileges and cracking all the accounts of their "friends" and
their boss in order to snoop into their personal lives or steal IP.
Seriously.  If you make that assumption, you'll only be correct one time
in 100, or even one time in 1000, but sooner or later you'll be right.
It is your RESPONSIBILITY to ALL the users of your system to be vigilant
and structure the system's security so that they are protected from
a**holes, be they crackers hacking in from the outside or that grad
student who thinks they are 7337 because they've gotten a nifty rootkit
from somewhere that actually works (these days not so easy with yum
updating most systems within 48 hours of a security exploit).

The problem with stuff like rsh is that it can't be patched -- it is
insecure by design.  rsh patched to be secure is called ssh.  ssh
possibly is overprotective -- I personally miss the days when one could
configure it to run without data encryption (relying on the
point-to-point switch and protection of promiscuous mode access at the
endpoints) and use it only for host/user auth -- but with rsh used
passwordless in a cluster, anybody with a laptop and access to a LAN
port can almost certainly get into any user account.  Including yours,
making it fairly simple for them to boost to root...

Due diligence for a root-entrusted person is a state that strongly
resembles raving paranoia combined with the speak not of that which
should not be spoken of rules of a priest of physician.

   rgb

> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org
> To change your subscription (digest mode or unsubscribe) visit 
> http://www.beowulf.org/mailman/listinfo/beowulf
>

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu