Root password escrow
David Lawver
We are looking for suggestions on how to make root passwords available
when needed in a situation where sys admin duties are shared among
several individuals.
We make use of sudo all we can, but situations can arise when someone
absolutely needs the real root password. What we'd like is something
where the principle admin for a host sets the password, then places it
in an escrow situation where everyone can get it in an emergency, but
it becomes immediately obvious that now a second individual knows it
so that it's time for a change.
We're open to both low-tech and high-tech solutions, ranging from
a lockbox with sealed envelopes in the boss's desk to some fancy
encrypted app that e-mails everyone in the world when it gets invoked.
How have others of you solved this?
--
-----------------------------------------------------------------------
David Lawver - speaking for me, not UW-Madison, DoIT, or anyone else
dmla...@facstaff.wisc.edu dla...@doit.wisc.edu la...@world.std.com
"Those who would do away with essential liberties for the sake of a
little safety deserve neither liberty nor safety." - Benjamin Franklin
Rune Mossige
We put the root password in a sealed envolope, and change the password
on irregular intervals, and whenever the seal is broken. The envolope is
placed in a safe, and only a few selected individuals know where the key
is hidden. Also, very few actually know about this secret envolope...
David Lawver (dmla...@facstaff.wisc.edu) wrote:
: We are looking for suggestions on how to make root passwords available
: when needed in a situation where sys admin duties are shared among
: several individuals.
: How have others of you solved this?
: --
: -----------------------------------------------------------------------
: David Lawver - speaking for me, not UW-Madison, DoIT, or anyone else
: dmla...@facstaff.wisc.edu dla...@doit.wisc.edu la...@world.std.com
: "Those who would do away with essential liberties for the sake of a
: little safety deserve neither liberty nor safety." - Benjamin Franklin
--
------------------------------------------------------------
Rune Mossige, Systems Support Tel : +47 515 98 922
Western Geophysical, Stavanger, Norway Fax : +47 515 98 999
Rune.M...@norway.waii.com Priv: +47 514 24 771
Mobile: +47 908 71 024
Andrew Dunstan
Rune Mossige (stt...@airgun.wg.waii.com) wrote:
: We put the root password in a sealed envolope, and change the password
: on irregular intervals, and whenever the seal is broken. The envolope is
: placed in a safe, and only a few selected individuals know where the key
: is hidden. Also, very few actually know about this secret envolope...
and now, presumably, all your users who read Usenet ...
cheers
andrew
--
-------------------------------------------------------------------------
There's nothing either good or bad, but thinking makes it so - Hamlet
http://www.gr-lakes.com/~andrew (including PGP key)
PGP Key fingerprint = 5C 44 7D E4 76 A3 31 DE 3D 11 FA 15 4D 87 1F 5E
-------------------------------------------------------------------------
Shaun Lowry
In article <5ir26n$m...@mail1.wg.waii.com>,
Rune Mossige <stt...@airgun.wg.waii.com> wrote:
>
>We put the root password in a sealed envolope, and change the password
>on irregular intervals, and whenever the seal is broken. The envolope is
>placed in a safe, and only a few selected individuals know where the key
>is hidden. Also, very few actually know about this secret envolope...
Umm, not anymore.
Shaun.
--
Shaun Lowry | March Systems Ltd., http://www.march.co.uk/
PGP Key available | 14 Brewery Court, High St.,
from key servers or | Theale, UK. RG7 5AJ
via e-mail on request | +44 118 930 4224
Dan Odom
stt...@airgun.wg.waii.com (Rune Mossige) writes:
> We put the root password in a sealed envolope, and change the password
> on irregular intervals, and whenever the seal is broken. The envolope is
> placed in a safe, and only a few selected individuals know where the key
> is hidden. Also, very few actually know about this secret envolope...
Until now, that is. <grin>
Good plan. Since we have console access to our servers here (and
hence can reboot in to single user mode if we forget the password) we
just make sure that everyone who needs it knows the password and we
don't write it down. It helps to pick long passwords that are easy to
remember (my favorite was at a place where I used to work -- the root
password was "This is the root password.").
>
>
> David Lawver (dmla...@facstaff.wisc.edu) wrote:
> : We are looking for suggestions on how to make root passwords available
> : when needed in a situation where sys admin duties are shared among
> : several individuals.
>
> : How have others of you solved this?
>
> : --
> : -----------------------------------------------------------------------
> : David Lawver - speaking for me, not UW-Madison, DoIT, or anyone else
> : dmla...@facstaff.wisc.edu dla...@doit.wisc.edu la...@world.std.com
> : "Those who would do away with essential liberties for the sake of a
> : little safety deserve neither liberty nor safety." - Benjamin Franklin
>
> --
> ------------------------------------------------------------
> Rune Mossige, Systems Support Tel : +47 515 98 922
> Western Geophysical, Stavanger, Norway Fax : +47 515 98 999
> Rune.M...@norway.waii.com Priv: +47 514 24 771
> Mobile: +47 908 71 024
--
Daniel Odom | product designer | PGP key available via finger
"Without going out of your door, you can know the ways of the world.
Without peeping through your window, you can see the way of heaven.
The farther you go, the less you know." -- Tao Te Ching chapter 47
Roman Drahtmueller
In Posting <334EC3...@facstaff.wisc.edu>,
David Lawver <dmla...@facstaff.wisc.edu> wrote:
>We are looking for suggestions on how to make root passwords available
>when needed in a situation where sys admin duties are shared among
>several individuals.
>
>absolutely needs the real root password. What we'd like is something
>where the principle admin for a host sets the password, then places it
>in an escrow situation where everyone can get it in an emergency, but
>it becomes immediately obvious that now a second individual knows it
>so that it's time for a change.
>
>We're open to both low-tech and high-tech solutions, ranging from
>a lockbox with sealed envelopes in the boss's desk to some fancy
>encrypted app that e-mails everyone in the world when it gets invoked.
>
>
Hello David,
Why don't you solve it like this: Install a small program which
checks for the id who called the thing; then fork a shell (or "script")
if the user is listed in a table, otherwise execute some
kills, a "fortune -o" or a "passwd -l", if that happens more than once.
Access could be additionally restricted by another, independent password.
This makes your system (e.g. the superuser-account) as secure as the
individual accounts that are permitted to "lift" themselves to root.
( -> though inherently insecure! )
Anyway, if there is a need for it, I believe that this is the most
convenient and probably the most secure way to share a superuser-account,
as I'd never send the root-password over the network or the keyboard
in plain.
In all cases, I'd add a feature that mails a log-message to an account that
is unreachable from the cluster where the the command resides, _and_
call syslog(). Otherwise you'd never find out that some guy broke
into some privileged user's account...
In addition, I'd force the privileged users to use ssh for login, disable
ftp and so on.
Others might say that making the root-password accessable in some way
would be easier and less risky. I prefer this way.
Regards,
Roman.
--
___________________________________________________________
/ Roman Drahtmüller \
> Albert-Ludwigs-Universität Freiburg im Breisgau <
\_______________ mailto:dr...@uni-freiburg.de ______________/
Matthew D. Healy
In article <5ir26n$m...@mail1.wg.waii.com>, stt...@airgun.wg.waii.com (Rune
Mossige) wrote:
> We put the root password in a sealed envolope, and change the password
> on irregular intervals, and whenever the seal is broken. The envolope is
> placed in a safe, and only a few selected individuals know where the key
> is hidden. Also, very few actually know about this secret envolope...
>
>
There also exist cryptographic algorithms (you might ask on sci.crypt)
by which one can pick a completely random password, then generate
a number, N of inscrutable strings with the mathematical property that
from any M of them, the password can be reconstructed.
Then each of the N trusted people keeps in a secure place of his or
her own choosing one of those N magic strings. In case of need, you
get M people to bring their pieces of paper to the console.
Each person has two copies of his or her slip -- one for a secret
place at home, and one for purse or wallet.
By this kind of system, it is possible to ensure: (1) that no single
person can become root without the knowledge of others, (2) that no
single person's portion of the shared secret is irreplaceable.
---------
Matthe...@yale.edu
http://paella.med.yale.edu/~healy
"But I thought it was pointed at the rabbit *between* my feet!"
Tony Langdon
It's 14 Apr 97 13:38:47,
We'll return to stt...@airgun.wg.waii.com and All's
discussion of Root password escrow
st> We put the root password in a sealed envolope, and change the password
st> on irregular intervals, and whenever the seal is broken. The envolope
st> is placed in a safe, and only a few selected individuals know where the
st> key is hidden. Also, very few actually know about this secret
st> envolope...
st> David Lawver (dmla...@facstaff.wisc.edu) wrote:
st> : We are looking for suggestions on how to make root passwords
st> available : when needed in a situation where sys admin duties are
st> shared among : several individuals.
st> : How have others of you solved this?
Our approach is to create aliases for root, and each admin uses one of
those aliases. That way, there's no need to distribute password
changes. Each admin's password is independent of the others, so can be
changed at short notice, if necessary.
... BodyBuilders go for the PUMP.......................
--
|Fidonet: Tony Langdon 3:632/367.2
|Internet: tl...@freeway.apana.org.au
|
| Standard disclaimer: The views of this user are strictly his own.
Rune Mossige
We also use Matt Bishop's 'lsu' utility, that allows an ordinary user to
su to root by using their own password. This way, we don't really need
the root password...We also use sudo when we need to execute just one
command as root. lsu is great, as the users listed in the lsu control
file can su to any user, and just use their own passwd. Crack runs
pretty often against these special priviledge accounts...
Andrew Dunstan (amd...@its.maynick.com.au) wrote:
: Rune Mossige (stt...@airgun.wg.waii.com) wrote:
: : is hidden. Also, very few actually know about this secret envolope...
: and now, presumably, all your users who read Usenet ...
: cheers
: andrew
: --
: -------------------------------------------------------------------------
: There's nothing either good or bad, but thinking makes it so - Hamlet
: http://www.gr-lakes.com/~andrew (including PGP key)
: PGP Key fingerprint = 5C 44 7D E4 76 A3 31 DE 3D 11 FA 15 4D 87 1F 5E
: -------------------------------------------------------------------------
Neil Moore
dr...@sibm1.ruf.uni-freiburg.de (Roman Drahtmueller) writes:
> Why don't you solve it like this: Install a small program which
> checks for the id who called the thing; then fork a shell (or "script")
> if the user is listed in a table, otherwise execute some
> kills, a "fortune -o" or a "passwd -l", if that happens more than once.
> Access could be additionally restricted by another, independent password.
See `sudo', which does pretty much exactly what you describe. Using
it would preferable to writing your own; sudo has had extensive use
and testing, and is thus less likely to have exploitable bugs.
--
-Neil Moore http://www.sfhs.floyd.k12.ky.us/~amethyst/
(finger amet...@valjean.sfhs.floyd.k12.ky.us for my Geek Code)
Dennis Kelly
David Lawver (dmla...@facstaff.wisc.edu) wrote:
: We are looking for suggestions on how to make root passwords available
: when needed in a situation where sys admin duties are shared among
: several individuals.
: We make use of sudo all we can, but situations can arise when someone
: absolutely needs the real root password. What we'd like is something
: where the principle admin for a host sets the password, then places it
: in an escrow situation where everyone can get it in an emergency, but
: it becomes immediately obvious that now a second individual knows it
: so that it's time for a change.
: We're open to both low-tech and high-tech solutions, ranging from
: a lockbox with sealed envelopes in the boss's desk to some fancy
: encrypted app that e-mails everyone in the world when it gets invoked.
: How have others of you solved this?
I would set up Raccounts for the users that will need root occasionally.
Given a username, "foobar", create another user "Rfoobar" with a
uid and gid of 0, and a gcos of "Super User". example:
Rfoobar:enscrypted:0:0:Super User:/root:/bin/bash
This way you can track of who does what to a machine, and if you can't
trust someone with an Raccount, then why let them ever use root period.
Bernd Felsche
>In article <5ir26n$m...@mail1.wg.waii.com>,
>Rune Mossige <stt...@airgun.wg.waii.com> wrote:
>>
>>We put the root password in a sealed envolope, and change the password
>>on irregular intervals, and whenever the seal is broken. The envolope is
>>placed in a safe, and only a few selected individuals know where the key
>>is hidden. Also, very few actually know about this secret envolope...
>Umm, not anymore.
You won't know that the password has been compromised until
you go to change (or look up) the one in the safe.
Better is a glass case in the computer room. Only one key exists; the
password is in a sealed envelope that's clearly visible but
inaccessible, other than by breaking the glass. The more paranoid will
put an alarm on the case, and seal it with some sort of wax seal.
--
Bernd Felsche {speaking for himself}
MetaPro Systems Pty Ltd, Redcliffe, Western Australia
Phone: +61 9 479 3722 Fax: +61 9 479 3720
Unauthorised distribution, storage or resale of this information is prohibited.
Robert L Braico
David Lawver wrote:
> We are looking for suggestions on how to make root passwords
> available
> when needed in a situation where sys admin duties are shared among
> several individuals.
> ........
I'm relatively new to system administration, so you should definitely
get a second opinion.
What if you wrote a suid script that was owned by root and executable by
your system administrators, it would:
1. Capture the UID of the person executing the script.
2. Send a message to a predetermined account outside your system with
the UID of the person executing the script, time etc.. It must be
outside or at least somewhere that root on the server in question can't
get to it. This may not work at all depending on how sendmail is
configured.
3. Append a line to etc/passwd like jschmoe:Qw#i8:0::Admin
acccount/users/jschmoe:/bin/bash
I believe that this adds a user, jschmoe, with the password ????. You
could know the password in advance by setting up a fictitious user and
copying that password from etc/passwd. For example I setup user bob
with passwd bob and in crypts to Qw#i8.
This also gives jschmoe UID 0 which belongs to root and should give him
root access.
I can see one problem in that anyone that knew the format of that e-mail
could send it from any fake address they wanted.
It might work.
David Richards
David Lawver wrote:
>We are looking for suggestions on how to make root passwords
>available
>when needed in a situation where sys admin duties are shared among
>several individuals.
For a small site, you'd look into something like 'sudo', for a larger
site there are commercial distributed authentication and logging systems
to ensure accountability for actions performed as root, which I presume
is your primary concern here.
Remember, anybody who has physical access to the machine might as well
have root access- and conversely, if you lose the root password, if
you have physical access it's easy enough to reset the password.
peter hakanson
I have used a sealed envelope containg all useful passwords.
At emergency, anyone may break it (on their own responsibility)
Works well, costs very litte.
The enevelope has to be kept reasonably unacceccible for
outsiders though....
Robert L Braico (brai...@mcs.net) wrote:
: David Lawver wrote:
: > We are looking for suggestions on how to make root passwords
: > available
: > when needed in a situation where sys admin duties are shared among
: > several individuals.
: > ........
: I'm relatively new to system administration, so you should definitely
: get a second opinion.
: What if you wrote a suid script that was owned by root and executable by
: your system administrators, it would:
: 1. Capture the UID of the person executing the script.
: 2. Send a message to a predetermined account outside your system with
: the UID of the person executing the script, time etc.. It must be
: outside or at least somewhere that root on the server in question can't
: get to it. This may not work at all depending on how sendmail is
: configured.
: 3. Append a line to etc/passwd like jschmoe:Qw#i8:0::Admin
: acccount/users/jschmoe:/bin/bash
: I believe that this adds a user, jschmoe, with the password ????. You
: could know the password in advance by setting up a fictitious user and
: copying that password from etc/passwd. For example I setup user bob
: with passwd bob and in crypts to Qw#i8.
: This also gives jschmoe UID 0 which belongs to root and should give him
: root access.
: I can see one problem in that anyone that knew the format of that e-mail
: could send it from any fake address they wanted.
: It might work.
--
--
<peter....@cyklop.volvo.se> (remove ".devnull" before use!)
Peter Hakanson VolvoData Dep 2580 phone +46 31 66 74 27
Mark Murdock
>
> Robert L Braico (brai...@mcs.net) wrote:
> : David Lawver wrote:
>
> : > We are looking for suggestions on how to make root passwords
> : > available
> : > when needed in a situation where sys admin duties are shared among
> : > several individuals.
> : > ........
>
Does your system support the sudo command? That will allow you to set
up a list of individuals that can perform some/all root privledges and
log their commands. That way, you don't have a number of people logging
into your root account and doing whatever. It's a more controlled, more
monitorable method.
Mark
Matthew D. Healy
In article <E91n9...@research.bell-labs.com>, to...@bell-labs.com wrote:
>
> My problem with sudo is this. I assume that bad people are sniffing
> the network for passwords. If you set sudo up to grant a significant
> level of privilege, then you increase the value (to the bad person) of
> sniffing a non-superuser password.
If you're worried about sniffers, then don't send passwords, especially
passwords of privileged accounts, in cleartext. There are basically
three ways to avoid this problem:
o one-time passwords (such as S/Key)
o challenge-response (such as Kerberos)
o Encryption (such as ssh)
My preference is for encryption. SSH is elegant, easy to install,
easy to administer, and very secure. Lurk on comp.security.ssh
for a while, or take a look at http://www.ssh.fi/ and at
http://www.datafellows.com for more details.
Basically, ssh uses two-way public-key crypto to provide both strong
crypto and strong authentication for both ends of the connection. All
traffic is encrypted, including passwords, so sniffing is pretty much
useless (unless the sniffer can crack RSA or Diffie-Hellman).
---------
As of 19 Apr 1997, 986 days till Y2K....
Matthe...@yale.edu
http://paella.med.yale.edu/~healy
"But I thought it was pointed at the rabbit *between* my feet!"
---------
Help a victim of severe email harrassment, see
http://www.geocities.com/~hitchcockc/story.html#fund
---------
Tom Reingold
Neil Moore <amet...@maxwell.ml.org> writes:
> dr...@sibm1.ruf.uni-freiburg.de (Roman Drahtmueller) writes:
> > Why don't you solve it like this: Install a small program which
> > checks for the id who called the thing; then fork a shell (or "script")
> > if the user is listed in a table, otherwise execute some
> > kills, a "fortune -o" or a "passwd -l", if that happens more than once.
> > Access could be additionally restricted by another, independent password.
> See `sudo', which does pretty much exactly what you describe. Using
> it would preferable to writing your own; sudo has had extensive use
> and testing, and is thus less likely to have exploitable bugs.
My problem with sudo is this. I assume that bad people are sniffing
the network for passwords. If you set sudo up to grant a significant
level of privilege, then you increase the value (to the bad person) of
sniffing a non-superuser password.
--
Tom Reingold, Bell Labs
Murray Hill, NJ, USA
to...@bell-labs.com
Stefan Monnier
to...@bell-labs.com (Tom Reingold) writes:
> My problem with sudo is this. I assume that bad people are sniffing
> the network for passwords. If you set sudo up to grant a significant
I fail to see how this is specific to sudo. Basically what you want to is
disallow "passwords in the clear". So, get rid of telnet, rlogin and fiends
and use SSH instead.
Stefan
Sam Tregar
Tom Reingold (to...@bell-labs.com) wrote:
: My problem with sudo is this. I assume that bad people are sniffing
: the network for passwords. If you set sudo up to grant a significant
: level of privilege, then you increase the value (to the bad person) of
: sniffing a non-superuser password.
Do you have a solution? I generally think that there are two solutions to
the non-root user needing root access - sudo and SUID available to a
specific group. As far as one being better than the other, I tend to
think that sudo is smarter. It avoids the annoyance of writing c wrappers
for SUID scripts. Also it is not immediately evident to the casual
observer that somebody other than root can run secure_cmd_x. Seeing an
entry with the SUID bit and an unusual group is a big ol' flag saying
"hack that group." Of course, sudoers is too, but a less regularily waved
one.
How about a switching HUB? Or ssh?
-sam
bpo...@australianinternetadvertising.com.au
> We are looking for suggestions on how to make root passwords available
> when needed in a situation where sys admin duties are shared among
> several individuals.
>
> absolutely needs the real root password. What we'd like is something
> where the principle admin for a host sets the password, then places it
> in an escrow situation where everyone can get it in an emergency, but
> it becomes immediately obvious that now a second individual knows it
> so that it's time for a change.
>
> We're open to both low-tech and high-tech solutions, ranging from
> a lockbox with sealed envelopes in the boss's desk to some fancy
> encrypted app that e-mails everyone in the world when it gets invoked.
>
> How have others of you solved this?
>
> -----------------------------------------------------------------------
> David Lawver - speaking for me, not UW-Madison, DoIT, or anyone else
> dmla...@facstaff.wisc.edu dla...@doit.wisc.edu la...@world.std.com
> "Those who would do away with essential liberties for the sake of a
> little safety deserve neither liberty nor safety." - Benjamin Franklin