What people are trying to tell you is that static passwords give you far
more illusion of security than real security.  If you get even a

I'm glad people are trying to tell me that.  I'll be sure to let the
hospitals know that we can't use static passwords...except, that's
what I'm not doing.  I don't want to use the forever passwords that
Tracy suggests.  I want to actually change them, like mandated.

*single* compromise that allows sniffing then your security is shot for
the entire system; you have no defense in depth.

again, people on this list are making assumptions, and not reading
what I'm writing.  Going single user with grub is no different than
being whimsical with root, IMO.  Grub has a password.  Root has a
password.  I simply would like a CLI tool for storing said passwords.

That tool, and the database that it is on, WILL be physically secure.
Physically secure to the extent that you don't just have to steal my
key to get in, you also have to steal my *finger*, as it uses a
combination biometrics and reg key.  Also, that just gets you into the
room itself; to get further, you'll need the key to the safe on the
wall, which is the pocket of the SYSIAO here.  So you need the keys
from his pocket, his other key, and his finger (one-stop shop, I
guess) before you can  have physical access to the jumpoff server
here.

Is that not secure enough?  Again, I really, *really* am not asking
for a security lesson.  I'm asking if anyone knows of a password safe
with access history and a CLI.  Pretty simple question.

In return, you are sticking your fingers in your ears and going "LA LA
LA LA I CAN'T HEAR YOU!".

No, I'm saying "you're making lots of completely incorrect
assumptions."  I have no physical access to the systems, and despite
what Tracy suggests when he suggests that grub alterations can be
casual but root can never ever be used, I treat grub alterations
seriously and there are in fact limited, yet important, uses for root.
Since half the systems are HPUX in trusted mode, and one can't just
tag init=/bin/sh on the end of the kernel for hpux in trusted mode, I
want a solution that works for *all* my systems, not just a quarter of
them.

Now, you may be constrained by the current system, current politics,
current budget, etc.  However, blowing 96 hours *per year* (2+
man-weeks!) just to change passwords *screams* for an actual solution
rather than a band-aid.

Absolutely, which is why I came here asking if anyone knew of a linux
password safe with a cli.

As a side note, you might want to think about how you could coopt
authorized_keys and the ssh key management utilities.  They would seem
to be a better match.

key-based auth for root?  Not happening, even if it wasn't disallowed
by the DoD.  Also, as I said, the almost-exclusive use for needing
root is when the system has problems and it needs to be started in
single-user mode via the console, iLO, etc.  key-based auth isn't an
option.  I need ~150 root passwords, and I need them in a better
method than what I currently have.

After looking elsewhere today, it seems the best thing for me to do is
simply write my own db managed by a perl utility, which encrypts the
passwords individually so they can be viewed individually (versus the
whole file being in an encrypted filesystem, or such).  Retrieval, as
described, needs to be available to a number of people with zero wait;
I need simply know that they did it, so I can check the system and
change the password.  If they do it frivolously, then that'll be their
problem with the gov, not mine (especially under DIACAP, which claim
is will start jailing people).  When an ER is down though, anything
that gets it back up sooner is what needs to happen - not some
philosophical debate on whether root should exist at all.  If root
shouldn't exist, why does it?  I'm not talking about logging in as
root, starting X, running firefox, etc.  I'm talking about needing it
in single-user mode, since I have to force single-user mode to still
require a password.

Brian


--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list

Reply via email to