Re: [9fans] secstore

Re: [9fans] secstore

[presotto]

man consolefs.  We plug all our consoles (including Unix ones)
into a serial line panel on our auth server.  That way we can manage
everything from one place.  If you con(1) to a console
in consolefs then you join a session of people on that console.
You can all type and you all see the output.  Also a message
comes out whenever anyone joins or leaves the group.

It makes managing a large number of machines a little easier.
It also cuts down on the number of monitors and mouse-kbd-display
switches in the machine room.  On some machines we connect the reset
button to a relay that's controlled by DTR and plug them in too.
That way, for our testing machines, we can push the reset button
remotely.

We also have a program (clog) that connects to a console and
writes each line into a file with a timestamp, ala syslog.  It's useful
for crashes and for autditing what was done, when systems
rebooted, etc.

Re: [9fans] secstore

[Lucio De Re]

On Wed, May 15, 2002 at 09:33:33AM -0400, presotto@plan9.bell-labs.com wrote:
>
> man consolefs.  We plug all our consoles (including Unix ones)
> into a serial line panel on our auth server.  That way we can manage
> everything from one place.  If you con(1) to a console
> in consolefs then you join a session of people on that console.
> You can all type and you all see the output.  Also a message
> comes out whenever anyone joins or leaves the group.
>
Hm, I saw the idea in consolefs(?), but it seemed too good to be true.
It would seem that with the trivial addition of /dev/null one could
build an IRC-like facility too :-)

> It makes managing a large number of machines a little easier.
> It also cuts down on the number of monitors and mouse-kbd-display
> switches in the machine room.  On some machines we connect the reset
> button to a relay that's controlled by DTR and plug them in too.
> That way, for our testing machines, we can push the reset button
> remotely.
>
I was considering very seriously going that route for my own array of
low-power obsoletes, and my main client has a similar need with none
of the ready expertise I can throw at my equipment.  We use a console
switch, but that's more out of familiarity than convenience, although
having a locked computer room does reduce the number of console
accidents.

I have a power panel I'm considering switching through a somewhat more
selective signal than DTR as occasionally a remote operation causes
chaos (I shut down the firewall last weekend, had to drive 60km there
to bring it back up, a DTR-RESET would have been very handy in that
case).

The power panel has the advantage of allowing us to power down
equipment when the UPS batteries risk running out, and power equipment
back up in a chosen sequence.  You folks are lucky in that you seem to
have a fairly homogenous system, my client lives in the twilight zone
of SCO Server, NetBSD (various versions), WinNT and a poorly
administered network of sundry Win95 workstations.  We seem to be in a
truce period right now, but I don't expect it to last.

A full-blown Venti server could make a huge difference, but we're also
in a transition phase with the parent company perceived as the
providers of IT resources in the future, and they are committed to
Windows as an infrastructure.

> We also have a program (clog) that connects to a console and
> writes each line into a file with a timestamp, ala syslog.  It's useful
> for crashes and for autditing what was done, when systems
> rebooted, etc.

I suppose there are lots of cool ideas with which you are all so
familiar, you don't think they may benefit anyone else.  In this
particular case, I specifically appreciate the confirmation that where
I was hoping to go is in fact a workable option elsewhere.

++L

Re: [9fans] secstore

[rsc]

If you can't handle typing ctl-U, connect to
a system console and run

	cat >/dev/null

And then talk.

Russ

Re: [9fans] secstore

[presotto]

[-- Attachment #1: Type: text/plain, Size: 20 bytes --]

Watch your language!

[-- Attachment #2: Type: message/rfc822, Size: 1593 bytes --]

From: jmk@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] secstore
Date: Wed, 15 May 2002 12:30:51 -0400
Message-ID: <44dbaacf485563385d53e18eac8803ef@plan9.bell-labs.com>

On Wed May 15 12:24:19 EDT 2002, presotto@plan9.bell-labs.com wrote:
> There are (or at least were) do it yourself connectors from our
> store room and from Radio Shack that were a bit easier than
> soldering, just press the wires into the right pins and clip
> closed the connector.

You can still find such things, e.g. the MA9F-8TS at www.altex.com.
Don't forget to buy the insertion tool too.

Re: [9fans] secstore

[jmk]

On Wed May 15 12:24:19 EDT 2002, presotto@plan9.bell-labs.com wrote:
> There are (or at least were) do it yourself connectors from our
> store room and from Radio Shack that were a bit easier than
> soldering, just press the wires into the right pins and clip
> closed the connector.

You can still find such things, e.g. the MA9F-8TS at www.altex.com.
Don't forget to buy the insertion tool too.

Re: [9fans] secstore

[presotto]

[-- Attachment #1: Type: text/plain, Size: 209 bytes --]

There are (or at least were) do it yourself connectors from our
store room and from Radio Shack that were a bit easier than
soldering, just press the wires into the right pins and clip
closed the connector.

[-- Attachment #2: Type: message/rfc822, Size: 1807 bytes --]

From: anothy@cosym.net
To: 9fans@cse.psu.edu
Subject: Re: [9fans] secstore
Date: Wed, 15 May 2002 11:36:50 -0400
Message-ID: <20020515153656.556D3199EC@mail.cse.psu.edu>

// We did have to wire DTR high on the consoles to some machines
// like the Sparcs, because if our console server rebooted and DTR
// went down and up (or is it up and down), the Suns also rebooted.

i'm curious: did you buy somethign to do this, or did you make the
needed adaptors yourself? i'm using consolefs (under 3rd edition,
with an Avenstar) right now, to manage a few SPARCs and several
PCs, and i've had that problem, as well. i've addressed this in similar
situations in the past with a sharp knife and soldering iron, but i
was wondering if there might be a more reliable (and less prone to
slicing into my hand) solution.
ア

Re: [9fans] secstore

[anothy]

// We did have to wire DTR high on the consoles to some machines
// like the Sparcs, because if our console server rebooted and DTR
// went down and up (or is it up and down), the Suns also rebooted.

i'm curious: did you buy somethign to do this, or did you make the
needed adaptors yourself? i'm using consolefs (under 3rd edition,
with an Avenstar) right now, to manage a few SPARCs and several
PCs, and i've had that problem, as well. i've addressed this in similar
situations in the past with a sharp knife and soldering iron, but i
was wondering if there might be a more reliable (and less prone to
slicing into my hand) solution.
ア

Re: [9fans] secstore

[presotto]

>
> I'm amazed that the last equipment with a soft "stand-by" switch I've
> seen is the 3B2.  You'd think the idea would have taken root a long
> time ago.  APM looks a lot like it, but I'm not up to date with
> technology (I don't think I've ever been and it's getting
> progressively more difficult even to keep the front runners in sight).

Despite its size, I'm hopeful for the ACPI spec. It leaves
everything open (as in public, not GPL) enough to make
universal power management possible by tiny players like Plan 9.
Now, all I have to do is find the month and a half free
to implement it.  I wish it were simpler...

Re: [9fans] secstore

[Lucio De Re]

On Wed, May 15, 2002 at 10:15:42AM -0400, rob pike, esq. wrote:
>
> Why use /dev/null? We just choose a system console and talk there,
> hitting control-U after each line.
>
I'm a person of habit, getting the knack of pressing ^U at the end of
each line would take some getting used to.  I can imagine the damage
of pressing Enter instead :-(

Plus you have to remember the rest of the IRC culture, like fake logs
and other entertainment for l33t k1dz :-)  ^U would certainly cause
some psychological distress.

++L

Re: [9fans] secstore

[Lucio De Re]

On Wed, May 15, 2002 at 10:14:03AM -0400, presotto@plan9.bell-labs.com wrote:
>
> You should hack consolefs if you want a real IRC.  consolefs doesn't
> tag what the individual users type with their id.  Also, /dev/null
> isn't quite right.  Consolefs only broadcasts what comes out of the
> console, i.e., the echo of the typed stuff plus output.  You'ld need
> a /dev/echo.  However, if you just hacked consolefs, you could do
> away with that and have a real IRC.
>
I wasn't exactly serious, but the idea makes perfect sense.

> Our console server is in the machine room.  No sense putting it anywhere
> else.
>
Yes, but the console switch needs physical presence and we keep the
door locked.  You must realise that I'm the most competent system
person there :-)

> We just do the reset for our debugging machines.  A power panel that
> we could remotely shut down would be nice too.  When we lose power someone
> has to run in and shut down the machines before the UPS's give up.

We have someone with authority (and keys) living nearby, as power
outages seem to occur over weekends (mostly scheduled, which is where
the airconditioning becomes an issue).  But it will be nicer when we
can remotely switch equipment off and on in the right sequence.

Of course I have a very complicated (read: confused) network of the
most disparate objects in my office in Johannesburg and spend almost
half my life in Cape Town.  So I'm driven, but not too hard, by the
desire to manage that from an arbitrary location.

> Luckily, we only need that on our stand alone machines and the file
> servers.  We also have a mixed environment.  Pretty much everything
> imaginable is controlled by the plan 9 consolefs.  The admins liked
> having secure access to the console server(s).  We have 3 of them now,
> there are a lot of machines back there.  We did have to wire DTR high
> on the consoles to some machines like the Sparcs, because if our console
> server rebooted and DTR went down and up (or is it up and down), the
> Suns also rebooted.

I'm amazed that the last equipment with a soft "stand-by" switch I've
seen is the 3B2.  You'd think the idea would have taken root a long
time ago.  APM looks a lot like it, but I'm not up to date with
technology (I don't think I've ever been and it's getting
progressively more difficult even to keep the front runners in sight).

++L

Re: [9fans] secstore

[rob pike, esq.]

> Hm, I saw the idea in consolefs(?), but it seemed too good to be true.
> It would seem that with the trivial addition of /dev/null one could
> build an IRC-like facility too :-)

Why use /dev/null? We just choose a system console and talk there,
hitting control-U after each line.

-rob

Re: [9fans] secstore

[presotto]

> Hm, I saw the idea in consolefs(?), but it seemed too good to be true.
> It would seem that with the trivial addition of /dev/null one could
> build an IRC-like facility too :-)

You should hack consolefs if you want a real IRC.  consolefs doesn't
tag what the individual users type with their id.  Also, /dev/null
isn't quite right.  Consolefs only broadcasts what comes out of the
console, i.e., the echo of the typed stuff plus output.  You'ld need
a /dev/echo.  However, if you just hacked consolefs, you could do
away with that and have a real IRC.

> I was considering very seriously going that route for my own array of
> low-power obsoletes, and my main client has a similar need with none
> of the ready expertise I can throw at my equipment.  We use a console
> switch, but that's more out of familiarity than convenience, although
> having a locked computer room does reduce the number of console
> accidents.

Our console server is in the machine room.  No sense putting it anywhere
else.

> The power panel has the advantage of allowing us to power down
> equipment when the UPS batteries risk running out, and power equipment
> back up in a chosen sequence.  You folks are lucky in that you seem to
> have a fairly homogenous system, my client lives in the twilight zone
> of SCO Server, NetBSD (various versions), WinNT and a poorly
> administered network of sundry Win95 workstations.  We seem to be in a
> truce period right now, but I don't expect it to last.

We just do the reset for our debugging machines.  A power panel that
we could remotely shut down would be nice too.  When we lose power someone
has to run in and shut down the machines before the UPS's give up.
Luckily, we only need that on our stand alone machines and the file
servers.  We also have a mixed environment.  Pretty much everything
imaginable is controlled by the plan 9 consolefs.  The admins liked
having secure access to the console server(s).  We have 3 of them now,
there are a lot of machines back there.  We did have to wire DTR high
on the consoles to some machines like the Sparcs, because if our console
server rebooted and DTR went down and up (or is it up and down), the
Suns also rebooted.

Re: [9fans] secstore

[Lucio De Re]

On Wed, May 15, 2002 at 08:33:41AM -0400, presotto@plan9.bell-labs.com wrote:
>
> To answer lucio, it's not a matter of obscurity.  You
> just don't want the files on a shared file server .  If
> it gets backed up, then a mistake of permissions on the file
> can last forever in the dump and not be noticed except by
> attackers.
>
Yes, Nigel brought that up.  I think it is critical not to record the
keys on any medium other than for use.  Again, reality interferese
here, or at least human fallibility.  I keep wondering what would
happen if I had a fatal accident and my client needed to access
hardware to which I alone hold the root password :-(

In fact, the main attraction of Plan 9 4ed is very much its
authentication service (and Venti, hopefully soon), at least to me.

> Whether or not you let others cpu or rx to the machine which is
> the auth server is a separable question.
>
Well, one has to measure security from the wrong end, so the fewer
opportunities for intrusions, the better.

> This still leaves the auth server open to trojan horses and
> the like.  I'ld be happier with a standalone auth server that
> noone can log onto except for a select few.  There are less

My fascist instincts suggests this has to be the recommended route.
Each alternative has a risk attached to it and the administrator must
be aware of it.  The problem, off the cuff, that I see is that you
can't plug holes in security if you move from the prescribed, you can
just hope they aren't exploited - you may be able to monitor, but that
becomes a new burden.

> mistakes you can make that compromise security.  Of course,
> we don't even do that.  Our auth server is also our console
> server so that everyone that needs console access logs on.

Punishment also helps :-)  But an ounce of prevention and all that...

++L

PS: Bell Labs are privileged to have "sophisticated" users, both
intellectually and, at least apparently, in a social/communal sense.
It is hard to remember from that perspective that the enemy outside
the Labs lurks in every corner.  I'm pleased Nigel asked the question
because I would not have spotted the need for additional care.

PPS: I don't quite understand the concept of a "console" server, what
is it actually used for?  Management of headless hosts such as FSs?

Re: [9fans] secstore

[presotto]

To answer lucio, it's not a matter of obscurity.  You
just don't want the files on a shared file server .  If
it gets backed up, then a mistake of permissions on the file
can last forever in the dump and not be noticed except by
attackers.

Whether or not you let others cpu or rx to the machine which is
the auth server is a separable question.

This still leaves the auth server open to trojan horses and
the like.  I'ld be happier with a standalone auth server that
noone can log onto except for a select few.  There are less
mistakes you can make that compromise security.  Of course,
we don't even do that.  Our auth server is also our console
server so that everyone that needs console access logs on.

Re: [9fans] secstore

[nigel]

In the light on Lucio's comment, if I was paranoid, I would need to prevent
the casual user from binding '#'S, or rather, opening /dev/sdC0/fs, since
they could root around in there, rather than use /srv/kfs.

So, for the paranoid, a separate auth server is more sensible. At least,
those paranoid about security. Those of us more paranoid about heat, noise,
and the electricty bill will probably choose a bit of hacking of pccpu.

Assuming the kfs on the cpu server is not protected, the presumably,
keeping secstore on the fileserver is no more insecure?

I'm really only interested in the convenience of having to give a single
password all day.

Re: [9fans] secstore

[presotto]

[-- Attachment #1: Type: text/plain, Size: 231 bytes --]

I'ld do the same thing for keyfs also, i.e., put /adm/keys and /adm/secsore
on the kfs and not make them visible to most processes.  You'll have
to protect /srv/kfs and /srv/kfs.cmd also so that only the hostowner
can open them.

[-- Attachment #2: Type: message/rfc822, Size: 1428 bytes --]

From: nigel@9fs.org
To: 9fans@cse.psu.edu
Subject: Re: [9fans] secstore
Date: Wed, 15 May 2002 12:58:16 +0100
Message-ID: <80dc9d46780953d37104e05c11fbed0f@9fs.org>

So a suitable solution for a combined cpu/auth server would be to use
kfs and bind it over /adm/secstore for the secstored process only?

I note that my cpu sever has a 15Gb disk which is only used for swap
at the moment so I suppose I ought to make better use of it.

Re: [9fans] secstore

[Lucio De Re]

On Wed, May 15, 2002 at 12:58:16PM +0100, nigel@9fs.org wrote:
>
> So a suitable solution for a combined cpu/auth server would be to use
> kfs and bind it over /adm/secstore for the secstored process only?
>
I doubt it.  It smacks of "security by obscurity" as other users on
the CPU server would be able to mount it too.  I think that, like
Kerberos, the auth server ought to be a physically secured unit.

Of course, you may not need such paranoia, but in a technical sense at
least, that would be mandatory.

++L

Re: [9fans] secstore

[nigel]

So a suitable solution for a combined cpu/auth server would be to use
kfs and bind it over /adm/secstore for the secstored process only?

I note that my cpu sever has a 15Gb disk which is only used for swap
at the moment so I suppose I ought to make better use of it.

Re: [9fans] secstore

[presotto]

We keep it on a stand alone auth server that not everyone has
access to and don't let it be generally readable.  Otherwise,
it's open to dictionary attack.  Depends on how paranoid you
want to be.

Re: [9fans] secstore

[forsyth]

[-- Attachment #1: Type: text/plain, Size: 100 bytes --]

i suspect it appears only on a standalone authentication server
that doesn't use the file server.

[-- Attachment #2: Type: message/rfc822, Size: 1624 bytes --]

To: 9fans@cse.psu.edu
Subject: [9fans] secstore
Date: Wed, 15 May 2002 12:19:13 +0100
Message-ID: <2ee5435c0b752aaefbcc264e23522b67@9fs.org>

The manul page says that there are deliberately no backups of the secstore,
and that -r is irrevocable.

It looks to me that secstore is sotred in /adm/secstore, so wouldn't
it be saved in a fileserver dump, or am I supposed to bind something
more local to the auth server over /adm/secstore before starting
secstored?

What is the practice at the labs?

[9fans] secstore

[nigel]

The manul page says that there are deliberately no backups of the secstore,
and that -r is irrevocable.

It looks to me that secstore is sotred in /adm/secstore, so wouldn't
it be saved in a fileserver dump, or am I supposed to bind something
more local to the auth server over /adm/secstore before starting
secstored?

What is the practice at the labs?