[9fans] a few Q's regarding cpu/auth server

[9fans] a few Q's regarding cpu/auth server

[Corey]

Just some scattered random questions I've accrued after successfully
getting a cpu/auth server up and running:


* I'm seeing an error on boot:

"/sys/log/cron: rc (cpurc): can't open: 'sys/log/cron' is a directory"

... not quite sure what to make of that. I guess I might have done
something wrong at some point, maybe related to the next question:



* Could anyone explain or tell me where I can find more information
regarding what all is going on with the following:

   con -l /srv/fscons
   prompt: uname bootes bootes
   prompt: uname sys +bootes
   prompt: uname adm +bootes
   prompt: fsys main
main: create /active/cron/bootes bootes bootes d775
main: create /active/sys/log/cron bootes bootes a664

... I've read con(1), and I can fathom the obvious basic premise:
I'm creating a user and assigning it to groups. But what is '/srv/fscons',
and what is 'fsys main' doing, and where can I find what other commands
are available and what they do?



* At one point I created a new user with 'auth/changeuser' that I didn't
need/want. What's the suggested means of removing this user?



* Similarly to the question above, how should I delete a user created
with uname via fscons?



* I'm somewhat confused with a bit of the process involved when creating
a hostowner for the cpu/auth server, and the (seemingly) many different
passwords which are created.

- a password is prompted/created when using auth/keyfs

- a password and a secstore key (prompted or created?) on first
reboot after nvram has been invalidated

- a password prompted or created when running 'auth/changeuser bootes'
which is supposed to match the password provided above?

... I only have a very limited understanding of how these all work together
and why; based on the somewhat limited and scattered and semi-incomplete
docs floating around out there. It's very difficult to piece this all together
coherently using just man pages, so I'm hoping someone can help me out.


* I hope I don't get beat up on this one (well, I hope I don't get too beat up
on _any_ of these questions...), but it seems strange that something as
important as a cpu/auth server would just go and boot up right into the
hostowner... apparently this a non issue - so what am I not understanding?



Thanks!

Re: [9fans] a few Q's regarding cpu/auth server

[Anthony Sorace]

> "/sys/log/cron: rc (cpurc): can't open: 'sys/log/cron' is a directory"
>
> ... not quite sure what to make of that.

that's weird. it shouldn't be a directory, just an append-only file
like most of the others in /sys/log. not sure how it got directoried.
remove and replace.

> * Could anyone explain or tell me where I can find more information
> regarding what all is going on with the following:
>
>   con -l /srv/fscons
>   prompt: uname bootes bootes
>   prompt: uname sys +bootes
>   prompt: uname adm +bootes
>   prompt: fsys main
> main: create /active/cron/bootes bootes bootes d775
> main: create /active/sys/log/cron bootes bootes a664
>
> ... I've read con(1), and I can fathom the obvious basic premise:
> I'm creating a user and assigning it to groups. But what is '/srv/fscons',
> and what is 'fsys main' doing, and where can I find what other commands
> are available and what they do?

/srv/fscons is the conventional location for you fossil console; see
fossilcons(8) for more information, including what uname, fsys, and
create do.

> * At one point I created a new user with 'auth/changeuser' that I didn't
> need/want. What's the suggested means of removing this user?

see keyfs(4). remove the directory.

> * Similarly to the question above, how should I delete a user created
> with uname via fscons?

you may or may not realize this, but it's sometimes non-obvious: users
on the auth server are different from users on a file server, and they
don't need to be the same (depending on what you want). changeuser and
keyfs work on the auth server; anything done on fossil's console
(/srv/fscons) is on the file server. again, see fossilcons(8).

> * I hope I don't get beat up on this one (well, I hope I don't get too beat up
> on _any_ of these questions...), but it seems strange that something as
> important as a cpu/auth server would just go and boot up right into the
> hostowner... apparently this a non issue - so what am I not understanding?

philosophy. plan9, like research unix before it, recognizes that if
you have physical access to the box, all bets are off anyway. security
consists of locking your door.

if you really, really need to get around that, you have a few options.
the closest to "out of the box" is to install and run a screen locker;
a few people have written those, although i'm not entirely certain any
are current. more ambitiously, there was a 3rd edition patch to detach
the console devices from the cpu server itself, asking for login and
treating it as an attached terminal. those are assuredly out of date,
but if you really need the functionality, that's where to start.

alternately, just run something on the console that doesn't have a
"quit" function. the console doesn't have interrupt functionality.

Re: [9fans] a few Q's regarding cpu/auth server

[Corey]

On Wednesday 05 August 2009 19:42:54 Anthony Sorace wrote:
> > "/sys/log/cron: rc (cpurc): can't open: 'sys/log/cron' is a directory"
> >
> > ... not quite sure what to make of that.
>
> that's weird. it shouldn't be a directory, just an append-only file
> like most of the others in /sys/log. not sure how it got directoried.
> remove and replace.
>

Easy enough!


> > * Could anyone explain or tell me where I can find more information
> > regarding what all is going on with the following:
> >
> >   con -l /srv/fscons
<snip>
> /srv/fscons is the conventional location for you fossil console; see
> fossilcons(8) for more information, including what uname, fsys, and
> create do.
>

Aha - thanks, I was looking at fs(8) -- which wasn't helping me.


> > * At one point I created a new user with 'auth/changeuser' that I didn't
> > need/want. What's the suggested means of removing this user?
>
> see keyfs(4). remove the directory.
>

Works like a charm.  Knowing the the correct manual page(s) to be looking
at certainly helps!  <grin>

I can't help though but be curious as to why there's no command, or
an additional switch to changeuser, to remove users from the keyfile.
I guess due to Plan 9's simplicity motto?


> > * Similarly to the question above, how should I delete a user created
> > with uname via fscons?
>
> you may or may not realize this, but it's sometimes non-obvious: users
> on the auth server are different from users on a file server, and they
> don't need to be the same (depending on what you want). changeuser and
> keyfs work on the auth server; anything done on fossil's console
> (/srv/fscons) is on the file server. again, see fossilcons(8).
>

Thanks, yes I was aware (superficially) that there was a difference between
users on the auth server and users on the file server.

I read through fossilcons(8) though, and I'm still not sure how to delete
a filesystem user. I almost got the impression that it's not possible -
due to the mention that "Once an id is used in file system structures
archived to Venti, it is impossible to change those disk structures, and
thus impossible to rename the id"; but reading on, I guess to remove
a user, I just need to manually edit the user table? Will it hose things if
I edit /adm/users directly, from a shell, rather than executing
'users [ -r file ]' on /srv/fscons?

Again, it's seems lacking that there isn't simply a 'uname -name'  switch.
(I'm not complaining, just bewildered.)


> > * I hope I don't get beat up on this one (well, I hope I don't get too
> > beat up on _any_ of these questions...), but it seems strange that
> > something as important as a cpu/auth server would just go and boot up
> > right into the hostowner... apparently this a non issue - so what am I
> > not understanding?
>
> philosophy. plan9, like research unix before it, recognizes that if
> you have physical access to the box, all bets are off anyway.
>

Well, sounds like a flawed philosophy taken too far.

Flawed, because all bets are not necessarily off with physical access;
and taken too far, because... dang, what harm is there in providing
that last means of interference to a hostile?

Cpu/Fs/Auth server says: "If you can touch me, I'm _all_ yours..."

What a fascinatingly... loose... form of security, if you catch my drift.


> security consists of locking your door.
>

... which means bootes is just a quick hacksaw or boltcutter or
crowbar away... so why even bother with a locked door?

Security is ultimately about the price/time/effort/skills a potential
attacker (or vandal) is willing (and able) to put forth in order to overcome
a system's security measures. A password is amazingly effective for a
vast number of the most common circumstances encountered in many
typical environments.

Anyhow... I guess there's no reason to argue/debate! Looks like I
have some options:

> if you really, really need to get around that, you have a few options.
> the closest to "out of the box" is to install and run a screen locker;
> a few people have written those, although i'm not entirely certain any
> are current. more ambitiously, there was a 3rd edition patch to detach
> the console devices from the cpu server itself, asking for login and
> treating it as an attached terminal. those are assuredly out of date,
> but if you really need the functionality, that's where to start.
>
> alternately, just run something on the console that doesn't have a
> "quit" function. the console doesn't have interrupt functionality.
>

Thanks for the suggestions!

That 3rd ed. detached console devices patch seems to be the best path,
but probably the least trivial.


Cheers,

Corey

Re: [9fans] a few Q's regarding cpu/auth server

[John Floren]

On Wed, Aug 5, 2009 at 11:15 PM, Corey<corey@bitworthy.net> wrote:
> On Wednesday 05 August 2009 19:42:54 Anthony Sorace wrote:
>> > * I hope I don't get beat up on this one (well, I hope I don't get too
>> > beat up on _any_ of these questions...), but it seems strange that
>> > something as important as a cpu/auth server would just go and boot up
>> > right into the hostowner... apparently this a non issue - so what am I
>> > not understanding?
>>
>> philosophy. plan9, like research unix before it, recognizes that if
>> you have physical access to the box, all bets are off anyway.
>>
>
> Well, sounds like a flawed philosophy taken too far.
>
> Flawed, because all bets are not necessarily off with physical access;
> and taken too far, because... dang, what harm is there in providing
> that last means of interference to a hostile?
>
> Cpu/Fs/Auth server says: "If you can touch me, I'm _all_ yours..."
>
> What a fascinatingly... loose... form of security, if you catch my drift.
>
>
>> security consists of locking your door.
>>
>
> ... which means bootes is just a quick hacksaw or boltcutter or
> crowbar away... so why even bother with a locked door?
>
> Security is ultimately about the price/time/effort/skills a potential
> attacker (or vandal) is willing (and able) to put forth in order to overcome
> a system's security measures. A password is amazingly effective for a
> vast number of the most common circumstances encountered in many
> typical environments.
>

I argued this once too, but eventually came around to the Plan 9 way
of thinking. Once you have physical access to the machine, it's yours
anyway. Just boot the Plan 9 CD and mount the fossil or any of the
other possibilities that arise when you are able to physically insert
bootable media into a system and force it to reboot.

If your Linux system is sitting out, oh no, there's a big scary login
prompt! First thing I try is rebooting and adding "single" to the end
of the kernel options. If that doesn't work, I grab a bootable Linux
CD, boot it, and mount your filesystem. Unless you're encrypting the
disk (probability: low), it's all mine now.

I don't remember the procedure, but I'm pretty sure VMS (reputedly one
of the most secure OSes, if not the most secure OS, in use today) has
a similar option for bypassing the console password on boot, and of
course you can always steal the disk and take it elsewhere, mount a
new boot tape, etc.


John
--
"Object-oriented design is the roman numerals of computing" -- Rob Pike

Re: [9fans] a few Q's regarding cpu/auth server

[Corey]

I imagine this is probably a subject full of landmines, so I don't want to
start a war!  I won't press the issue, just want to respond to this, and
then I'll just leave the status quo well enough alone.

I respect those opinions which differ from my own.

On Wednesday 05 August 2009 23:30:38 John Floren wrote:
> On Wed, Aug 5, 2009 at 11:15 PM, Corey<corey@bitworthy.net> wrote:
> > On Wednesday 05 August 2009 19:42:54 Anthony Sorace wrote:
> >> philosophy. plan9, like research unix before it, recognizes that if
> >> you have physical access to the box, all bets are off anyway.
> >
> > Well, sounds like a flawed philosophy taken too far.
> >
> > Flawed, because all bets are not necessarily off with physical access;
> > and taken too far, because... dang, what harm is there in providing
> > that last means of interference to a hostile?
> >
<snip>
> >> security consists of locking your door.
> >
> > ... which means bootes is just a quick hacksaw or boltcutter or
> > crowbar away... so why even bother with a locked door?
> >

That wasn't a rhetorical question.  Why bother locking your door?

Any intruder worth his weight in salt can circumvent such a simple
security mechanism with ease.


> > Security is ultimately about the price/time/effort/skills a potential
> > attacker (or vandal) is willing (and able) to put forth in order to
> > overcome a system's security measures. A password is amazingly effective
> > for a vast number of the most common circumstances encountered in many
> > typical environments.
>
> I argued this once too, but eventually came around to the Plan 9 way
> of thinking.
>

( I'm going to repeat what I've already written to someone else offlist )

The Plan 9 way of thinking (wrt the security of physical terminal access)
completely undermines, or somehow fails to recognize, the very real fact that
there is always a cost/risk effort/reward equation at play.

Out of X number of would-be intruders, only a small fraction of those would,
under most circumstances, have the balls and the time to dismantle the server
without being noticed; versus all those who would (perhaps even out of sheer
curiosity/mischievousness) love to get quick and easy, unauthorized access to
an open terminal for a quick opportunistic, low-risk "look-see", or to play
around, or to simply outright f*ck sh*t up and bail.

Fact is... I would _rather_ force that rare motivated and prepared intruder
into taking down the box... sheesh, at least I'd be alerted that something
went wrong rather quickly. Versus having some ghost in the shell merrily have
his way with the system for a period of time.

It's weird, it seems so obvious.  Passwords help with security. Anyone who
relies on them too heavily is being foolish; but regardless - they're most
certainly a useful and proven preventative measure to a vast majority of
likely potential situations.


> Once you have physical access to the machine, it's yours
> anyway. Just boot the Plan 9 CD and mount the fossil or any of the
> other possibilities that arise when you are able to physically insert
> bootable media into a system and force it to reboot.
>

This assumes that:

1 - the intruder came prepared with a Plan 9 disk

2 - the machine in question does in fact have a cdrom/floppy attached


So I say again:  whenever you happen to find yourself with physical
access to any given computer, it is _not_necessarily_ yours. There
are a large number of circumstantial situations that are most often
than not likely to make the dismantling of the machine a much higher
risk operation. In all those situations, where a screw driver simply is
not an option - boy oh boy what fun can be had with a wide open
terminal... it's practically begging you to mess around; even if just
for a quick couple of minutes before you bugger off. However, it is
_certainly_ yours if it's a total no-brainer to simply start entering
commands as a privileged user.


> If your Linux system is sitting out, oh no, there's a big scary login
> prompt! First thing I try is rebooting and adding "single" to the end
> of the kernel options. If that doesn't work, I grab a bootable Linux
> CD, boot it, and mount your filesystem. Unless you're encrypting the
> disk (probability: low), it's all mine now.
>

We're talking Plan 9, not *nix.

Anyhow - whatever!  I can only imagine this has already been gone through
before; and it's not going to make me stop using Plan 9 even though I
think it's absurd.  (c8=


Regards!

Corey

Re: [9fans] a few Q's regarding cpu/auth server

[Robert Raschke]

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

On Thu, Aug 6, 2009 at 8:52 AM, Corey <corey@bitworthy.net> wrote:

>
> I imagine this is probably a subject full of landmines, so I don't want to
> start a war!  I won't press the issue, just want to respond to this, and
> then I'll just leave the status quo well enough alone.
>
> I respect those opinions which differ from my own.
>
> On Wednesday 05 August 2009 23:30:38 John Floren wrote:
> > On Wed, Aug 5, 2009 at 11:15 PM, Corey<corey@bitworthy.net> wrote:
> > > On Wednesday 05 August 2009 19:42:54 Anthony Sorace wrote:
> > >> philosophy. plan9, like research unix before it, recognizes that if
> > >> you have physical access to the box, all bets are off anyway.
> > >
> > > Well, sounds like a flawed philosophy taken too far.
> > >
> > > Flawed, because all bets are not necessarily off with physical access;
> > > and taken too far, because... dang, what harm is there in providing
> > > that last means of interference to a hostile?
> > >
> <snip>
> > >> security consists of locking your door.
> > >
> > > ... which means bootes is just a quick hacksaw or boltcutter or
> > > crowbar away... so why even bother with a locked door?
> > >
>
> That wasn't a rhetorical question.  Why bother locking your door?
>
> Any intruder worth his weight in salt can circumvent such a simple
> security mechanism with ease.
>
>
Why lock your door, when you're living in a gated community?

I think the bit you are leaving out is the fact that a "proper" Plan 9
installation "needs" terminals.

Your cpu/auth/filesystem machines can be somewhere safe, with as much
physical safety as you need (physical barriers are much easier to set up and
administer that electronic ones). If all is set up properly, you will never
have to touch those machines again. Unless the machines break and you need
to look at the hardware.

Your terminal, on the other hand is ephemeral and you have go through the
usual security checks if you want to access your cpu and filesystem servers.

Robby

[-- Attachment #2: Type: text/html, Size: 2667 bytes --]

Re: [9fans] a few Q's regarding cpu/auth server

[Steve Simon]

I cannot imageine the senario where random people will have access
to the cpu/auth/file server's consoles. It just doesn't happen
if you are serious about security.

However if you want to protect your console against your friends
I wrote a script to do it /n/sources/contrib/steve/rc/conslock
you may also want to look at screenlock(1)

Incidentially I may use this at home to protect my servers console
against my 2 year old who rather likes keyboards, though this is
a different type of security.

-Steve

Re: [9fans] a few Q's regarding cpu/auth server

[erik quanstrom]

> Works like a charm.  Knowing the the correct manual page(s) to be looking
> at certainly helps!  <grin>
>
> I can't help though but be curious as to why there's no command, or
> an additional switch to changeuser, to remove users from the keyfile.
> I guess due to Plan 9's simplicity motto?
[...]
> I read through fossilcons(8) though, and I'm still not sure how to delete
> a filesystem user. I almost got the impression that it's not possible -
> due to the mention that "Once an id is used in file system structures
> archived to Venti, it is impossible to change those disk structures, and
> thus impossible to rename the id"; but reading on, I guess to remove
> a user, I just need to manually edit the user table? Will it hose things if
> I edit /adm/users directly, from a shell, rather than executing
> 'users [ -r file ]' on /srv/fscons?

the reason there are few provisions for deleting a user, is because that
doesn't make much sense if you have a worm filesystem.  at best you
can remove the user from the active filesystem, but not the dump.

this is the same reason that renaming users is difficult.  (ken's fs
doesn't have this problem since there's a level of indirection between
the name and strictly-internal user id.)

i just disable the user's authentication and make the user's mailbox
unwritable; i've never had a reason to rename a user.

- erik

Re: [9fans] a few Q's regarding cpu/auth server

[erik quanstrom]

> That wasn't a rhetorical question.  Why bother locking your door?

> Any intruder worth his weight in salt can circumvent such a simple
> security mechanism with ease.
[...]
> Out of X number of would-be intruders, only a small fraction of those would,
> under most circumstances, have the balls and the time to dismantle the server
> without being noticed; versus all those who would (perhaps even out of sheer
[...]
> Fact is... I would _rather_ force that rare motivated and prepared intruder
> into taking down the box... sheesh, at least I'd be alerted that something
> went wrong rather quickly. Versus having some ghost in the shell merrily have
> his way with the system for a period of time.
>
> It's weird, it seems so obvious.  Passwords help with security. Anyone who
> relies on them too heavily is being foolish; but regardless - they're most
> certainly a useful and proven preventative measure to a vast majority of
> likely potential situations.
>
> > Once you have physical access to the machine, it's yours
> > anyway. Just boot the Plan 9 CD and mount the fossil or any of the
> > other possibilities that arise when you are able to physically insert
> > bootable media into a system and force it to reboot.
> >
>
> This assumes that:
>
> 1 - the intruder came prepared with a Plan 9 disk
>
> 2 - the machine in question does in fact have a cdrom/floppy attached
>

i think you're arguing three ends against the middle.
if the intruder is willing to break down doors, the intruder
can just take the machines, too.  on the other hand, you
argue that you'd need to be prepared to use a live cd or
whatnot.  but that's just not the case.  you can smash and
grab.  or bring a bootable usb stick and either
erase or copy files.

first step in understanding security is understanding
what the real threats are.  or that failing, what threats
one would like to protect against.

for example, in the office there's a lock and alarm on
the front door, a lock into the suite but there's no
lock on the machine room door, nor the physical
consoles.  this has increased system availablity.
since i've been able to talk people through problems
when i wasn't on site.

sure anyone in the company could go mess with the
fileserver or auth server.  but, that wouldn't be too
smart.  and the sr with the fileserver's storage has
hot swap drives.  it would be easier to hose the fs
by pulling drives than anything else.  great plausable
deniablity.  the disk drives could have gone nuts.  in fact the only
physical security problem we've had was an accident.
somebody pushed the big red button during a machine
move.  demonstrating that it's hard to get to step one
of security: understanding what the real threats are.

by the way, if you want to lock the console, it's not hard
to write such a program.  just do it.

- erik

Re: [9fans] a few Q's regarding cpu/auth server

[David Leimbach]

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

On Wed, Aug 5, 2009 at 11:30 PM, John Floren <slawmaster@gmail.com> wrote:

> On Wed, Aug 5, 2009 at 11:15 PM, Corey<corey@bitworthy.net> wrote:
> > On Wednesday 05 August 2009 19:42:54 Anthony Sorace wrote:
> >> > * I hope I don't get beat up on this one (well, I hope I don't get too
> >> > beat up on _any_ of these questions...), but it seems strange that
> >> > something as important as a cpu/auth server would just go and boot up
> >> > right into the hostowner... apparently this a non issue - so what am I
> >> > not understanding?
> >>
> >> philosophy. plan9, like research unix before it, recognizes that if
> >> you have physical access to the box, all bets are off anyway.
> >>
> >
> > Well, sounds like a flawed philosophy taken too far.
> >
> > Flawed, because all bets are not necessarily off with physical access;
> > and taken too far, because... dang, what harm is there in providing
> > that last means of interference to a hostile?
> >
> > Cpu/Fs/Auth server says: "If you can touch me, I'm _all_ yours..."
> >
> > What a fascinatingly... loose... form of security, if you catch my drift.
> >
> >
> >> security consists of locking your door.
> >>
> >
> > ... which means bootes is just a quick hacksaw or boltcutter or
> > crowbar away... so why even bother with a locked door?
> >
> > Security is ultimately about the price/time/effort/skills a potential
> > attacker (or vandal) is willing (and able) to put forth in order to
> overcome
> > a system's security measures. A password is amazingly effective for a
> > vast number of the most common circumstances encountered in many
> > typical environments.
> >
>
> I argued this once too, but eventually came around to the Plan 9 way
> of thinking. Once you have physical access to the machine, it's yours
> anyway. Just boot the Plan 9 CD and mount the fossil or any of the
> other possibilities that arise when you are able to physically insert
> bootable media into a system and force it to reboot.
>
> If your Linux system is sitting out, oh no, there's a big scary login
> prompt! First thing I try is rebooting and adding "single" to the end
> of the kernel options. If that doesn't work, I grab a bootable Linux
> CD, boot it, and mount your filesystem. Unless you're encrypting the
> disk (probability: low), it's all mine now.
>
> I don't remember the procedure, but I'm pretty sure VMS (reputedly one
> of the most secure OSes, if not the most secure OS, in use today) has
> a similar option for bypassing the console password on boot, and of
> course you can always steal the disk and take it elsewhere, mount a
> new boot tape, etc.



You can boot firewire macs (at least the PPC variety, maybe also the intel
ones) in "target disk mode".  This makes them mountable as a disk from any
computer that knows how to do so with firewire.

Physical access makes security pretty much impossible.   The latest thing
people do to thwart prying eyes is to encrypt the filesystem itself (or at
least the home directory).  Even that was poorly done as an unencrypted swap
file often had passwords in plaintext available on the mac.

Perhaps storing secure data in the cloud is always safer?  :-)

Dave


>
>
> John
> --
> "Object-oriented design is the roman numerals of computing" -- Rob Pike
>
>

[-- Attachment #2: Type: text/html, Size: 4284 bytes --]

Re: [9fans] a few Q's regarding cpu/auth server

[Corey]

On Thursday 06 August 2009 01:19:35 Robert Raschke wrote:
> On Thu, Aug 6, 2009 at 8:52 AM, Corey <corey@bitworthy.net> wrote:
<snip>
> > That wasn't a rhetorical question.  Why bother locking your door?
> >
> > Any intruder worth his weight in salt can circumvent such a simple
> > security mechanism with ease.
>
> Why lock your door, when you're living in a gated community?
>

A few possible answers:

Because I'm convinced that multiple redundant layers of security is
most effective.

Because I _don't_ live in a gated community.

Because anyone can hop a fence, the silly pathetic lock (password) on
my front door (auth server) is my last line of defense; and it will be
immediately and clearly obvious that someone broke in because... well..
they _broke_ in (turned off and dismantled the server)... they didn't
just walk in without further ado (began issuing commands as hostowner
on the open terminal) and leave without immediate and clear evidence
(no broken/missing case, no powered off server and missing drives, etc)


> Your cpu/auth/filesystem machines can be somewhere safe, with as much
> physical safety as you need (physical barriers are much easier to set up
> and administer that electronic ones). If all is set up properly, you will
> never have to touch those machines again. Unless the machines break and
> you need to look at the hardware.
>

Meanwhile, here on terra firma, I would like to be able to have my
Plan 9 servers sitting on a rack in a common affordable co-lo somewhere.


I think the actual root of the situation, is simply that Plan 9 currently
tends to reside within domains with much more strict and secure
or trustworthy environments vs. being prevalent within the sphere of
the great unwashed masses of the industry where strong physical
security is either unobtainable, unaffordable, and/or unreliable at best.

_Within_such_environments_, simple passwords remain an effective and
proven means of _deterrent_ from the most common, random, unforeseen
encounters that may occur on a near every day situation.


The phone guys have to enter the server room - you trust them with bootes?

Various contractors have to enter the server room - you trust them with
bootes?

The sysadmin forgets to lock the door to the server room before heading
out for lunch - you trust all your visitors, customers, affiliates and
employees with a terminal sitting at a bootes prompt?

The hosting provider has all number of people walking in and out of the
server room constantly, every day - you trust each and every one of these
random unknown people with a bootes prompt to your co-lo'd cpu server?

Now here's the important part -- in each of these cases (those are just a few,
it doesn't take much of an imagination - or much actual experience - to come
up with countless more), the _real_ concern is _not_ over that rare motivated,
focused, risk-taking bad guy with a plan who's come prepared with a
screwdriver and usb rootkit and assorted bootdisks... the concern is all the
ad-hoc opportunistic, curious and/or malicious passer-by's, armed with
nothing more than their fingers, who just might take up the chance to goof
around with that open terminal connected to the server.

I have a much higher level of trust that X person won't walk off with or
dismantle a server vs. the level of trust I have that X person won't execute
commands on an open terminal. It's really quite simple.

If your servers aren't under you direct control, and they're not guaranteed
continually locked behind a bio-metrically secured room under constant video
surveillance - then you don't have physical security.

If you don't operate within a contained, peer-based trusted environment (lab,
research center, spec. dept., etc), then you don't have physical security.

Most of the industry at large... does _not_ have trusted physical security.

And if you don't have trusted physical security, then an open terminal is
beyond the pale of recklessness.

Passwords make an excellent form of _additional_deterrent_ under the sort
of lowest common denominator environment that tends to comprise the
industry at large. (from AnyTec, to Bob's coffee house, to Standford & Son's
automotive repair, to The Law Offices Of Larry H. Parker, to Data Entry Inc.)

I honestly can't believe that this is even up for debate!  <grin>

It's just bizarre.

> I think the bit you are leaving out is the fact that a "proper" Plan 9
> installation "needs" terminals.
>
> Your terminal, on the other hand is ephemeral and you have go through the
> usual security checks if you want to access your cpu and filesystem
> servers.
>

That's understood; and I'm well impressed by the way that particular portion
of the model works.


Ok, well I think I've said all I can possible say -- so unless I get any
direct questions I won't follow up on this; I don't want to annoy the list -
9fans is my only means of assistance for this interesting os - plus, I've
already been provided with solutions from which I can roll my own.


Cheers,

Corey

Re: [9fans] a few Q's regarding cpu/auth server

[John Floren]

On Thu, Aug 6, 2009 at 4:28 PM, Corey<corey@bitworthy.net> wrote:
> On Thursday 06 August 2009 01:19:35 Robert Raschke wrote:
>> On Thu, Aug 6, 2009 at 8:52 AM, Corey <corey@bitworthy.net> wrote:
> <snip>
>> > That wasn't a rhetorical question.  Why bother locking your door?
>> >
>> > Any intruder worth his weight in salt can circumvent such a simple
>> > security mechanism with ease.
>>
>> Why lock your door, when you're living in a gated community?
>>
>
> A few possible answers:
>
> Because I'm convinced that multiple redundant layers of security is
> most effective.
>
> Because I _don't_ live in a gated community.
>
> Because anyone can hop a fence, the silly pathetic lock (password) on
> my front door (auth server) is my last line of defense; and it will be
> immediately and clearly obvious that someone broke in because... well..
> they _broke_ in (turned off and dismantled the server)... they didn't
> just walk in without further ado (began issuing commands as hostowner
> on the open terminal) and leave without immediate and clear evidence
> (no broken/missing case, no powered off server and missing drives, etc)
>
>
>> Your cpu/auth/filesystem machines can be somewhere safe, with as much
>> physical safety as you need (physical barriers are much easier to set up
>> and administer that electronic ones). If all is set up properly, you will
>> never have to touch those machines again. Unless the machines break and
>> you need to look at the hardware.
>>
>
> Meanwhile, here on terra firma, I would like to be able to have my
> Plan 9 servers sitting on a rack in a common affordable co-lo somewhere.
>
>
> I think the actual root of the situation, is simply that Plan 9 currently
> tends to reside within domains with much more strict and secure
> or trustworthy environments vs. being prevalent within the sphere of
> the great unwashed masses of the industry where strong physical
> security is either unobtainable, unaffordable, and/or unreliable at best.
>
> _Within_such_environments_, simple passwords remain an effective and
> proven means of _deterrent_ from the most common, random, unforeseen
> encounters that may occur on a near every day situation.
>
>
> The phone guys have to enter the server room - you trust them with bootes?
>
> Various contractors have to enter the server room - you trust them with
> bootes?
>
> The sysadmin forgets to lock the door to the server room before heading
> out for lunch - you trust all your visitors, customers, affiliates and
> employees with a terminal sitting at a bootes prompt?
>
> The hosting provider has all number of people walking in and out of the
> server room constantly, every day - you trust each and every one of these
> random unknown people with a bootes prompt to your co-lo'd cpu server?
>
> Now here's the important part -- in each of these cases (those are just a few,
> it doesn't take much of an imagination - or much actual experience - to come
> up with countless more), the _real_ concern is _not_ over that rare motivated,
> focused, risk-taking bad guy with a plan who's come prepared with a
> screwdriver and usb rootkit and assorted bootdisks... the concern is all the
> ad-hoc opportunistic, curious and/or malicious passer-by's, armed with
> nothing more than their fingers, who just might take up the chance to goof
> around with that open terminal connected to the server.
>
> I have a much higher level of trust that X person won't walk off with or
> dismantle a server vs. the level of trust I have that X person won't execute
> commands on an open terminal. It's really quite simple.
>
> If your servers aren't under you direct control, and they're not guaranteed
> continually locked behind a bio-metrically secured room under constant video
> surveillance - then you don't have physical security.
>
> If you don't operate within a contained, peer-based trusted environment (lab,
> research center, spec. dept., etc), then you don't have physical security.
>
> Most of the industry at large... does _not_ have trusted physical security.
>
> And if you don't have trusted physical security, then an open terminal is
> beyond the pale of recklessness.
>
> Passwords make an excellent form of _additional_deterrent_ under the sort
> of lowest common denominator environment that tends to comprise the
> industry at large. (from AnyTec, to Bob's coffee house, to Standford & Son's
> automotive repair, to The Law Offices Of Larry H. Parker, to Data Entry Inc.)
>
> I honestly can't believe that this is even up for debate!  <grin>
>
> It's just bizarre.
>

Oh, if we're just protecting against people wandering by who are
obviously there by mistake--since we're discounting anyone coming
prepared for serious maliciousness--how about just not having a
terminal connected to your file server? My cpu/auth/file servers don't
have anything connected except an ethernet cable and a remote serial
console. Oh, sure, there's a crash cart over in the corner that you
could drag over and plug in, but you've decided that we're only
talking about opportunists who see a prompt and decide to type some
stuff, so it's not a problem.

The whole friggin' point of a colo is that you trust the people
running it--also, that they don't leave terminals connected to every
single one of their hundreds of customer machines. It's a locked room
in a corporate building... this ain't your little brother banging on
keys (a far more realistic reason for password-protecting a cpu
server, if you're going to be dumb enough to leave the head attached).

I have a Plan 9 server sitting in a lab at my university. Over the
last 2+ years, it has been in the same place, powered on, connected to
a keyboard, mouse, and monitor. The only deterrent to unauthorized
users has been that I keep the monitor off, and in those 2 years I
have not found a single sign that anyone has so much as touched the
keyboard, much less done "rm -r /" or whatever it is you're afraid of.
I'm afraid you'll have to forgive me if I find the probability of
someone improperly accessing your headless colo'd box rather low.

I invite you, though, to create some form of logging protection system
for the box. Put the box in a colo, and then in 3 years send us your
logs. I guess we'll see how many people tried to get into your cpu
server.


John
-- 
"Object-oriented design is the roman numerals of computing" -- Rob Pike

Re: [9fans] a few Q's regarding cpu/auth server

[ron minnich]

Short form:

on today's machines, if someone gets physical access, you're owned.
Not much more to say except that with the kind of features vendors
insist on embedding in the systems, you can easily be owned without
physical access -- see the recent Black Hat articles, and I'm not
naming names so I don't get fired. If the colo is doing their job, and
they'd better be!, then physical access is not an issue because it
won't happen, or, when it does happen, the people are trusted and
won't mess with your box.

9grid.net has been at, first, UNM computing center for 2 years and,
second, at LBL for 2 years. In all the time, there have been no
issues. The people at those places are trusted.

If colo staff can't own it by physical access then you've solved a
hard problem and might want to start selling it. In that case, you
need hardly worry about trusting your colo, so put it there anyway.

Screensaver + password seems rather quaint in light of these realities.

ron

Re: [9fans] a few Q's regarding cpu/auth server

[John Floren]

On Thu, Aug 6, 2009 at 5:01 PM, John Floren<slawmaster@gmail.com> wrote:
>
> Oh, if we're just protecting against people wandering by who are
> obviously there by mistake--since we're discounting anyone coming
> prepared for serious maliciousness--how about just not having a
> terminal connected to your file server? My cpu/auth/file servers don't
> have anything connected except an ethernet cable and a remote serial
> console. Oh, sure, there's a crash cart over in the corner that you
> could drag over and plug in, but you've decided that we're only
> talking about opportunists who see a prompt and decide to type some
> stuff, so it's not a problem.
>
> The whole friggin' point of a colo is that you trust the people
> running it--also, that they don't leave terminals connected to every
> single one of their hundreds of customer machines. It's a locked room
> in a corporate building... this ain't your little brother banging on
> keys (a far more realistic reason for password-protecting a cpu
> server, if you're going to be dumb enough to leave the head attached).
>
> I have a Plan 9 server sitting in a lab at my university. Over the
> last 2+ years, it has been in the same place, powered on, connected to
> a keyboard, mouse, and monitor. The only deterrent to unauthorized
> users has been that I keep the monitor off, and in those 2 years I
> have not found a single sign that anyone has so much as touched the
> keyboard, much less done "rm -r /" or whatever it is you're afraid of.
> I'm afraid you'll have to forgive me if I find the probability of
> someone improperly accessing your headless colo'd box rather low.
>
> I invite you, though, to create some form of logging protection system
> for the box. Put the box in a colo, and then in 3 years send us your
> logs. I guess we'll see how many people tried to get into your cpu
> server.
>
>
> John

A note, please don't take this as a flame. I asked exactly the same
sort of thing in 2005/2006, and what I wrote here is the synthesis of
my experiences and changing viewpoints since then, shaped to apply to
the specific situations posed. Basically, even in the environment of a
university lab, considerably more hostile than a trusted colo, your
house, or your corporate machine rooms, I haven't had a problem, which
I attribute partially to the monitor/keyboard/mouse all being old
scruffy refugees, and partially to the fact that I keep the monitor
off. Realistically, I should have the peripherals unplugged and moved
away from the server, because it's *not* a particularly safe place--it
should either be headless, or indeed use some form of locker.

Everybody asks these questions, I think, if only to themselves. The
answers usually become evident, though--in my case, I had to get
grouched at by the curmudgeonly 9fans before I "got" it.

hasta~

John
--
"Object-oriented design is the roman numerals of computing" -- Rob Pike

Re: [9fans] a few Q's regarding cpu/auth server

[Roman Shaposhnik]

On Aug 6, 2009, at 4:47 AM, erik quanstrom wrote:
>> Works like a charm.  Knowing the the correct manual page(s) to be
>> looking
>> at certainly helps!  <grin>
>>
>> I can't help though but be curious as to why there's no command, or
>> an additional switch to changeuser, to remove users from the keyfile.
>> I guess due to Plan 9's simplicity motto?
> [...]
>> I read through fossilcons(8) though, and I'm still not sure how to
>> delete
>> a filesystem user. I almost got the impression that it's not
>> possible -
>> due to the mention that "Once an id is used in file system structures
>> archived to Venti, it is impossible to change those disk
>> structures, and
>> thus impossible to rename the id"; but reading on, I guess to remove
>> a user, I just need to manually edit the user table? Will it hose
>> things if
>> I edit /adm/users directly, from a shell, rather than executing
>> 'users [ -r file ]' on /srv/fscons?
>
> the reason there are few provisions for deleting a user, is because
> that
> doesn't make much sense if you have a worm filesystem.  at best you
> can remove the user from the active filesystem, but not the dump.
>
> this is the same reason that renaming users is difficult.  (ken's fs
> doesn't have this problem since there's a level of indirection between
> the name and strictly-internal user id.)
>
> i just disable the user's authentication and make the user's mailbox
> unwritable; i've never had a reason to rename a user.

It also seems that most of organizations I know have that same kind
of permanency in place even at HR level. If you leave the company
and then get rehired you feel like you've never left -- you badge id
and sorts of HR assigned credentials are simply enabled, not created
anew. Don't know whether this is a function of IT influencing HR
decisions or whether there's an HR reason for doing it that way.

Thanks,
Roman.

Re: [9fans] a few Q's regarding cpu/auth server

[hiro]

don't forget to take away the connectors from the power and reset
buttons, otherwise good security concepts;)

Re: [9fans] a few Q's regarding cpu/auth server

[Corey]

On Thursday 06 August 2009 17:01:30 John Floren wrote:
> On Thu, Aug 6, 2009 at 4:28 PM, Corey<corey@bitworthy.net> wrote:
<snip>
> > I honestly can't believe that this is even up for debate!  <grin>
> >
> > It's just bizarre.
>
> Oh, if we're just protecting against people wandering by who are
> obviously there by mistake--since we're discounting anyone coming
> prepared for serious maliciousness--how about just not having a
> terminal connected to your file server?
>

Ok, that's reasonable. Especially when considering the idea that,
apparently, once a Plan 9 cpu/auth/fs server has been set up, there's
no reason to require further periodic access to its terminal.

Removing the Plan 9 server's terminal peripherals is equivalent to - and
follows the same exact line of reasoning for - implementing a password
for said server's terminal.

i.e. - both techniques increase the level of difficulty and effort and
inconvenience one must suffer through before gaining unauthorized
access to a hostowner prompt.

In light of this, I'm still unconvinced that a terminal password is totally
without merit. At least with a password, I don't force trusted admins
to lug out the peripherals.


> My cpu/auth/file servers don't
> have anything connected except an ethernet cable and a remote serial
> console. Oh, sure, there's a crash cart over in the corner that you
> could drag over and plug in, but you've decided that we're only
> talking about opportunists who see a prompt and decide to type some
> stuff, so it's not a problem.
>

True.


> The whole friggin' point of a colo is that you trust the people
> running it--
>

I have direct experience as a contractor where I have entered
many a co-lo; and was unimpressed with their security to say the least.
I had constant and easy access to a large number of nameless servers,
it's a nobrainer to access keyboard/monitor pairs in many of these places.

Interestingly enough - that simple, worthless password prompt is what
made it effectively impossible to do anything with said servers. It was easy
for me to reach keyboards; but would have been risky and difficult - and
would have had _zero_ plausible deniability - to pop a chassis and snag
hard drives.


> I have not found a single sign that anyone has so much as touched the
> keyboard, much less done "rm -r /" or whatever it is you're afraid of.
>

I'm afraid of all the same things you're afraid of - all the same reasons
why authentication is necessary when accessing the server remotely.

As far as I'm concerned, physical access to the terminal is no different
than remote access. I differentiate between the server's terminal and the
server's chassis, though they are often within reaching distance of each
other.

To conflate the terminal with the server, as Plan 9 servers apparently
do, is a lazy and unnecessary abstraction in my mind.


> I'm afraid you'll have to forgive me if I find the probability of
> someone improperly accessing your headless colo'd box rather low.
>
> I invite you, though, to create some form of logging protection system
> for the box. Put the box in a colo, and then in 3 years send us your
> logs. I guess we'll see how many people tried to get into your cpu
> server.
>

The co-lo situation was just one example. I agree the risk is sleight -
after all, there are _lots_ of servers in a co-lo. So what's the chances
of _mine_ getting abused?

On Thursday 06 August 2009 17:17:19 John Floren wrote:
> A note, please don't take this as a flame.
>

Not at all! It's good to hear others experiences and conclusions.


Cheers,

Corey

Re: [9fans] a few Q's regarding cpu/auth server

[blstuart]

> It also seems that most of organizations I know have that same kind
> of permanency in place even at HR level. If you leave the company
> and then get rehired you feel like you've never left -- you badge id
> and sorts of HR assigned credentials are simply enabled, not created
> anew. Don't know whether this is a function of IT influencing HR
> decisions or whether there's an HR reason for doing it that way.

That's for sure.  I just started to work for a company that I
did some consulting for about 15 years ago.  It was easier
paperwork to put me in the system as a part-time employee
back then.  So when I started again a few weeks ago, my
employee ID number was still in the system to the surprise
of the HR girl who handled the initial paperwork.

BLS

Re: [9fans] a few Q's regarding cpu/auth server

[blstuart]

> Incidentially I may use this at home to protect my servers console
> against my 2 year old who rather likes keyboards, though this is
> a different type of security.

In that situation, the most important security measure it
to place the power switch at an altitude beyond the little
one's reach.  I speak from experience.  It was just like a
movie; I was moving in slow motion saying "noooooo" as
I reached to block the power switch from my daughter's
finger.  I was too late.  Fortunately, I hadn't done too
much since I last saved...

BLS

Re: [9fans] a few Q's regarding cpu/auth server

[Anthony Sorace]

this is silly. the philosophy has been explained. several people have
given lots of "real world" usage where it holds up just fine. i'd go
as far as to say the vast majority of plan9 installations are in such
environments.

but regardless, correcting what may be a whole in your environment is
easy; just do so and be done with it.

Re: [9fans] a few Q's regarding cpu/auth server

[Daniel Lyons]

On Aug 6, 2009, at 6:59 PM, hiro wrote:

> don't forget to take away the connectors from the power and reset
> buttons, otherwise good security concepts;)

Just out of curiosity, is it possible to simply unbind the console on  
one of these servers after bootup in some startup script? Or perhaps  
unbind the keyboard device, so you can see messages but not type  
anything in? Maybe use cat /dev/kprint instead of rc? It seems like it  
ought to be possible to disable the physical console this way. I ask  
simply as a way of reducing worry about passerby, not as a security  
solution.

—
Daniel Lyons

Re: [9fans] a few Q's regarding cpu/auth server

[John Floren]

On Thu, Aug 6, 2009 at 8:04 PM, Daniel Lyons<fusion@storytotell.org> wrote:
>
> On Aug 6, 2009, at 6:59 PM, hiro wrote:
>
>> don't forget to take away the connectors from the power and reset
>> buttons, otherwise good security concepts;)
>
> Just out of curiosity, is it possible to simply unbind the console on one of
> these servers after bootup in some startup script? Or perhaps unbind the
> keyboard device, so you can see messages but not type anything in? Maybe use
> cat /dev/kprint instead of rc? It seems like it ought to be possible to
> disable the physical console this way. I ask simply as a way of reducing
> worry about passerby, not as a security solution.
>

You should be able to hack /sys/src/cmd/init.c to make it start
whatever you want after booting, based on init(8), but I haven't tried
it. The man page says it prompts for a password on the cpu server, but
that doesn't happen; the source has a pass function but it's not
called anywhere.

I don't have a real terminal or cpu server at my apartment, so I can't
test it right now.


John
--
"Object-oriented design is the roman numerals of computing" -- Rob Pike

Re: [9fans] a few Q's regarding cpu/auth server

[Steve Simon]

> ...by the curmudgeonly 9fans...

For those who follow British comedy:

	Father Jack, my alter ego!

Others may find this enlightening
http://www.youtube.com/watch?v=kHiDhERvJ4I

-Steve

Re: [9fans] a few Q's regarding cpu/auth server

[erik quanstrom]

> You should be able to hack /sys/src/cmd/init.c to make it start
> whatever you want after booting, based on init(8), but I haven't tried
> it. The man page says it prompts for a password on the cpu server, but
> that doesn't happen; the source has a pass function but it's not
> called anywhere.

it actually says this

         On a CPU server, init requires the machine's password to be
          supplied before starting rc on the console.

it can  be gotten from nvram (fake nvram on pcs) or
from the console.

i'm sure the reason you weren't asked for a password
was that you have a usable fake nvram.

this doesn't lock the console, however.  it prevents
the machine from booting.

- erik

Re: [9fans] a few Q's regarding cpu/auth server

[Ethan Grammatikidis]

On Thu, 6 Aug 2009 11:33:18 +0100
"Steve Simon" <steve@quintile.net> wrote:

> I cannot imageine the senario where random people will have access
> to the cpu/auth/file server's consoles. It just doesn't happen
> if you are serious about security.
>
> However if you want to protect your console against your friends
> I wrote a script to do it /n/sources/contrib/steve/rc/conslock
> you may also want to look at screenlock(1)
>
> Incidentially I may use this at home to protect my servers console
> against my 2 year old who rather likes keyboards, though this is
> a different type of security.
>
> -Steve
>

Speaking of family, I'd imagine a little password protection might go a long way to keeping the peace in many families. Respect for siblings' property isn't exactly hard-wired into human nature, is it?


--
Ethan Grammatikidis

Those who are slower at parsing information must
necessarily be faster at problem-solving.

Re: [9fans] a few Q's regarding cpu/auth server

[Iruata Souza]

On Fri, Aug 7, 2009 at 9:05 AM, Ethan Grammatikidis<eekee57@fastmail.fm> wrote:
> On Thu, 6 Aug 2009 11:33:18 +0100
> "Steve Simon" <steve@quintile.net> wrote:
>
>> I cannot imageine the senario where random people will have access
>> to the cpu/auth/file server's consoles. It just doesn't happen
>> if you are serious about security.
>>
>> However if you want to protect your console against your friends
>> I wrote a script to do it /n/sources/contrib/steve/rc/conslock
>> you may also want to look at screenlock(1)
>>
>> Incidentially I may use this at home to protect my servers console
>> against my 2 year old who rather likes keyboards, though this is
>> a different type of security.
>>
>> -Steve
>>
>
> Speaking of family, I'd imagine a little password protection might go a long way to keeping > the peace in many families. Respect for siblings' property isn't exactly hard-wired into
> human nature, is it?

no password protection will suffice when ethics fails.

iru

Re: [9fans] a few Q's regarding cpu/auth server

[Ethan Grammatikidis]

On Thu, 6 Aug 2009 22:50:33 -0400
Anthony Sorace <anothy@gmail.com> wrote:

> this is silly. the philosophy has been explained. several people have
> given lots of "real world" usage where it holds up just fine. i'd go
> as far as to say the vast majority of plan9 installations are in such
> environments.

Oh God, not the everyday examples == proof argument, PLEASE. The common
case in the present time is that people EXPECT server terminals to be
password protected so they're not likely to bother looking. Suppose
it gets to be common knowlege that server terminals are rarely
password-protected. Now suppose co-lo host X is well-known for hosting
a large number of Plan 9 machines -- at the rate interest in Plan 9 is
growing this could happen in only a year or two from now. Now please
stretch your imagination to include Frank.

Frank is a contractor, called in to perform some maintenance in X's
cages. Frank is bored out of his skull. His wife hasn't left him
(yet), but there's no love left nor any real hate either; just cold
apathy. His workday has been flat-dull so far, he's had a succession
of extremely tedious jobs and now he has another one. Frank sees a lot
of Plan 9 machines next to him. Password cracking is time-consuming
and potentially very boring, but few Plan 9 machines have one. Frank
is on a schedule and already bored out of his skull, and best of all,
if he tampers no-one will ever know it wasn't a remote exploit!

Now here's the point. I and a billion other people HAVE MORE FUN THINGS TO
DO THAN FRET ABOUT SECURITY. A weak OS needs me to put in boring work...


--
Ethan Grammatikidis

Those who are slower at parsing information must
necessarily be faster at problem-solving.

Re: [9fans] a few Q's regarding cpu/auth server

[Ethan Grammatikidis]

On Fri, 7 Aug 2009 09:29:25 -0300
Iruata Souza <iru.muzgo@gmail.com> wrote:

> On Fri, Aug 7, 2009 at 9:05 AM, Ethan Grammatikidis<eekee57@fastmail.fm> wrote:
> > On Thu, 6 Aug 2009 11:33:18 +0100
> > "Steve Simon" <steve@quintile.net> wrote:
> >
> >> I cannot imageine the senario where random people will have access
> >> to the cpu/auth/file server's consoles. It just doesn't happen
> >> if you are serious about security.
> >>
> >> However if you want to protect your console against your friends
> >> I wrote a script to do it /n/sources/contrib/steve/rc/conslock
> >> you may also want to look at screenlock(1)
> >>
> >> Incidentially I may use this at home to protect my servers console
> >> against my 2 year old who rather likes keyboards, though this is
> >> a different type of security.
> >>
> >> -Steve
> >>
> >
> > Speaking of family, I'd imagine a little password protection might go a long way to keeping > the peace in many families. Respect for siblings' property isn't exactly hard-wired into
> > human nature, is it?
>
> no password protection will suffice when ethics fails.

ETHICS? In a SEVEN YEAR OLD who knows what rm does????? What the fuck planet are you from? Don't get me started on my teenage years.


--
Ethan Grammatikidis

Those who are slower at parsing information must
necessarily be faster at problem-solving.

Re: [9fans] a few Q's regarding cpu/auth server

[Iruata Souza]

On Fri, Aug 7, 2009 at 9:39 AM, Ethan Grammatikidis<eekee57@fastmail.fm> wrote:
> On Fri, 7 Aug 2009 09:29:25 -0300
> Iruata Souza <iru.muzgo@gmail.com> wrote:
>
>> On Fri, Aug 7, 2009 at 9:05 AM, Ethan Grammatikidis<eekee57@fastmail.fm> wrote:
>> > On Thu, 6 Aug 2009 11:33:18 +0100
>> > "Steve Simon" <steve@quintile.net> wrote:
>> >
>> >> I cannot imageine the senario where random people will have access
>> >> to the cpu/auth/file server's consoles. It just doesn't happen
>> >> if you are serious about security.
>> >>
>> >> However if you want to protect your console against your friends
>> >> I wrote a script to do it /n/sources/contrib/steve/rc/conslock
>> >> you may also want to look at screenlock(1)
>> >>
>> >> Incidentially I may use this at home to protect my servers console
>> >> against my 2 year old who rather likes keyboards, though this is
>> >> a different type of security.
>> >>
>> >> -Steve
>> >>
>> >
>> > Speaking of family, I'd imagine a little password protection might go a long way to keeping > the peace in many families. Respect for siblings' property isn't exactly hard-wired into
>> > human nature, is it?
>>
>> no password protection will suffice when ethics fails.
>
> ETHICS? In a SEVEN YEAR OLD who knows what rm does????? What the fuck planet are you from? Don't get me started on my teenage years.
>

having respect for the shared (or private if you wish) stuff is
ethical. if only prohibition is applied, no password protection will
work.

a seven year old in anger can surely set fire on the computer or
whatnot if ethics fails him.

iru

Re: [9fans] a few Q's regarding cpu/auth server

[Ethan Grammatikidis]

On Fri, 7 Aug 2009 10:02:27 -0300
Iruata Souza <iru.muzgo@gmail.com> wrote:

> On Fri, Aug 7, 2009 at 9:39 AM, Ethan Grammatikidis<eekee57@fastmail.fm> wrote:
> > On Fri, 7 Aug 2009 09:29:25 -0300
> > Iruata Souza <iru.muzgo@gmail.com> wrote:
> >
> >> On Fri, Aug 7, 2009 at 9:05 AM, Ethan Grammatikidis<eekee57@fastmail.fm> wrote:
> >> > On Thu, 6 Aug 2009 11:33:18 +0100
> >> > "Steve Simon" <steve@quintile.net> wrote:
> >> >
> >> >> I cannot imageine the senario where random people will have access
> >> >> to the cpu/auth/file server's consoles. It just doesn't happen
> >> >> if you are serious about security.
> >> >>
> >> >> However if you want to protect your console against your friends
> >> >> I wrote a script to do it /n/sources/contrib/steve/rc/conslock
> >> >> you may also want to look at screenlock(1)
> >> >>
> >> >> Incidentially I may use this at home to protect my servers console
> >> >> against my 2 year old who rather likes keyboards, though this is
> >> >> a different type of security.
> >> >>
> >> >> -Steve
> >> >>
> >> >
> >> > Speaking of family, I'd imagine a little password protection might go a long way to keeping > the peace in many families. Respect for siblings' property isn't exactly hard-wired into
> >> > human nature, is it?
> >>
> >> no password protection will suffice when ethics fails.
> >
> > ETHICS? In a SEVEN YEAR OLD who knows what rm does????? What the fuck planet are you from? Don't get me started on my teenage years.
> >
>
> having respect for the shared (or private if you wish) stuff is
> ethical. if only prohibition is applied, no password protection will
> work.
>
> a seven year old in anger can surely set fire on the computer or
> whatnot if ethics fails him.

Again, what planet are you from?! :) Setting fire to the computer will get him in so much trouble it'll hurt nastily, but a little messing with big bro's hobby, while risky, doesn't seem to be anywere near as bad.


--
Ethan Grammatikidis

Those who are slower at parsing information must
necessarily be faster at problem-solving.

Re: [9fans] a few Q's regarding cpu/auth server

[Anthony Sorace]

Ethan wrote:

// Oh God, not the everyday examples == proof argument, PLEASE.

Er, what? everyday examples are a perfectly good existence proof,
which is all they're being used for here. You seem to be after a more
"universal correctness" sort of proof, for which they're entirely
inappropriate, but which they weren't being used for.

// The common case in the present time is that people EXPECT
// server terminals to be password protected so they're not likely
// to bother looking.

"Expect"? The console comes up and you get a prompt. Is that fact
really more hidden than you think a reasonable level of investigation
will get you? If so, then I expect you install unfamiliar OSs without
checking for running services, open ports, debug consoles, default
passwords, and the like, in which case having any conversation about
security is laughable. When installing any new system, you're expected
to determine whether the default behavior works in your circumstances.

I find it informative that while you object to "proof by real-world
examples" (which I hadn't even tried), you counter with "proof by
contrived examples".

// Now here's the point. I and a billion other people HAVE MORE
// FUN THINGS TO DO THAN FRET ABOUT SECURITY. A weak
// OS needs me to put in boring work...

Ah, yes, there's the point. You have a system in front of you that
doesn't quite operate the way you'd like, and rather than put in the
*trivial* work involved to change it, you instead want to convince the
community that they were somehow wrong for building it that way and
should change it to your desires.

This has gone from silly to stupid. The original question was why Plan
9 doesn't do this by default; that has been explained. The explanation
holds valid for very many Plan 9 systems, as evidenced by the
testimony here. Yet nobody has said you can't have what you want. In
fact, various options for getting there have been identified. The only
reason this conversation persists is because some participants are
intent on proving the abstract, universal correctness of their
position. That's dumb. Don't be dumb.

Run this on your console if you're still worried about Frank:
#!/bin/rc

lockword=`{cat /tmp/lockword}

while() {
	echo -n 'Enter lockword: '
	entered=`{read}
	if (~ $entered $lockword)
		exit
	if not
		echo 'Wrong. Die, Frank!'
}

Re: [9fans] a few Q's regarding cpu/auth server

[Wes Kussmaul]

> no password protection will suffice when ethics fails.
> 
> iru

English Lit grads please avert your eyes...


"Something there is that doesn’t love a wall…
He says again, “Good fences make good neighbors.”

         -Robert Frost, from Mending Wall


_Something There is That Needs a Wall_

Something that doesn’t love a wall is me
With other Internauts, I want to be free.

But some free spirits become disgrace
When liberated in cyberspace.

We’re slow to learn that after the Fall
We have not earned such license at all.

(Utopians are never eager to see
The ways that walls make people free.)

But when we meet, we meet in a place
Removed from the crazy highway race.

Something there is that needs a wall:
The preschool, the office, the shopping mall.

And so the mender might glean from his labors
Truly, good fences do make good neighbors.

Re: [9fans] a few Q's regarding cpu/auth server

[David Leimbach]

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

>
>
>
> Now here's the point. I and a billion other people HAVE MORE FUN THINGS TO
> DO THAN FRET ABOUT SECURITY. A weak OS needs me to put in boring work...
>

Hah... yes, that would be why I'm merely reading this thread instead of
adding to it...  Oh crap, nevermind :-)


>
>
> --
> Ethan Grammatikidis
>
> Those who are slower at parsing information must
> necessarily be faster at problem-solving.
>
>

[-- Attachment #2: Type: text/html, Size: 833 bytes --]

Re: [9fans] a few Q's regarding cpu/auth server

[lucio]

> The man page says it prompts for a password on the cpu server, but
> that doesn't happen; the source has a pass function but it's not
> called anywhere.

It used to, but the new security model invalidated that concept: some
of its foundations fell foul of the new design and were discarded.
That was where it was decided (I believe, I wasn't there) that console
security on CPU servers was a chimera that did not need further
effort.

I remember querying it out of habit at the time, I haven't looked back
since.

++L

Re: [9fans] a few Q's regarding cpu/auth server

[Corey]

On Wednesday 05 August 2009 19:42:54 Anthony Sorace wrote:
> > "/sys/log/cron: rc (cpurc): can't open: 'sys/log/cron' is a directory"
> >
> > ... not quite sure what to make of that.
>
> that's weird. it shouldn't be a directory, just an append-only file
> like most of the others in /sys/log. not sure how it got directoried.
> remove and replace.
>

I had this happen again when installing/configuring a new cpu/auth server...

Am I doing something wrong with the following:

term% con -l /srv/fscons
...
prompt: fsys main
main: create /active/sys/log/cron bootes bootes a664


... is create making it a directory vs. a file?

Re: [9fans] a few Q's regarding cpu/auth server

[Steve Simon]

This will create a n append only file, not a directory. The usual way to
initialised cron for a user is auth/cron -c (similarly for mail type mail -c)
when you have first logged in as that user.

if you run /sys/lib/newuser when you first login (i.e. the very first time, do
this only once) then these commands are run for you (cat /sys/lib/newuser for more
info).

-Steve

Re: [9fans] a few Q's regarding cpu/auth server

[Corey]

On Monday 10 August 2009 03:33:04 Steve Simon wrote:
> This will create a n append only file, not a directory. The usual way to
> initialised cron for a user is auth/cron -c (similarly for mail type mail
> -c) when you have first logged in as that user.
>
> if you run /sys/lib/newuser when you first login (i.e. the very first time,
> do this only once) then these commands are run for you (cat
> /sys/lib/newuser for more info).
>


Is the documentation erroneous?:

http://plan9.bell-labs.com/wiki/plan9/Configuring_a_Standalone_CPU_Server/

"
ADD A HOSTOWNER USER

[...]

con /srv/fscons
prompt: uname bootes bootes
prompt: uname adm +bootes
prompt: uname sys +bootes
prompt: fsys main
main: create /active/cron/bootes bootes bootes d775
main: create /active/sys/log/cron bootes bootes a664
"

Re: [9fans] a few Q's regarding cpu/auth server

[ron minnich]

> main: create /active/cron/bootes bootes bootes d775

This is right. It's supposed to be a directory.
cpu% ls -l /cron/bootes
--rw-r--r-- M 9758 bootes bootes 0 Sep 17  2008 /cron/bootes/cron

> main: create /active/sys/log/cron bootes bootes a664

This is right. It's supposed to be an append-only file.

cpu% ls -l /sys/log/cron
a-rw-rw-r-- M 9758 bootes bootes 8068019 Aug 10 12:00 /sys/log/cron
cpu%

I don't see the problem.

ron

Re: [9fans] a few Q's regarding cpu/auth server

[Corey]

On Monday 10 August 2009 09:01:39 ron minnich wrote:
> > main: create /active/cron/bootes bootes bootes d775
>
> This is right. It's supposed to be a directory.
> cpu% ls -l /cron/bootes
> --rw-r--r-- M 9758 bootes bootes 0 Sep 17  2008 /cron/bootes/cron
>
> > main: create /active/sys/log/cron bootes bootes a664
>
> This is right. It's supposed to be an append-only file.
>
> cpu% ls -l /sys/log/cron
> a-rw-rw-r-- M 9758 bootes bootes 8068019 Aug 10 12:00 /sys/log/cron
> cpu%
>
> I don't see the problem.
>

Here's the problem:

cpu% ls -ld /sys/log/cron
d-rw-rw-r-- M 81 bootes bootes 0 Aug 10 05:19 /sys/log/cron


Somewhere along the line '/sys/log/cron' is goes from being an append-only
file, to a directory.

"/sys/log/cron: rc (cpurc): can't open: 'sys/log/cron' is a directory"


This has occurred several times (on every one of my cpu/auth installs), and
I'm hoping to pinpoint what might going wrong so that I can avoid this in the
future. I've written a Plan 9 standalone cpu/auth server installation and
configuration howto - but I don't want any 'bugs' in the documentation, so I'd
like to try and weed this one out, but I'm unable to determine where/when this
particular issue might be cropping up.

I wonder whether 'auth/cron -c' is the culprit, when I first run
'/sys/lib/newuser' for bootes.

Re: [9fans] a few Q's regarding cpu/auth server

[erik quanstrom]

> I wonder whether 'auth/cron -c' is the culprit, when I first run
> '/sys/lib/newuser' for bootes.

no sense wondering.  read the source.  /sys/src/cmd/auth/cron.c
you could also use trump to trace the calls.

- erik

Re: [9fans] a few Q's regarding cpu/auth server

[Daniel Lyons]

On Aug 7, 2009, at 10:08 PM, lucio@proxima.alt.za wrote:

>> Story time. :)
>
> You're also falling into the trap of believing that because it _can_
> happen, it has to happen (Murphy's Law).  It punishes the many for the
> sins of the few and is a very poor foundation for progress.

It wasn't a position, just a story. Though I do think a Murphy's law
approach to security is better than a credulous one. But I don't think
the Plan 9 approach is credulous. It just places priority on the
network rather than the machine and assumes valuable machines will be
treated that way.

> Plan 9 has a good balance of cost of security against eventual real
> protection and forces you to re-evaluate the accepted paradigms.  That
> is sufficient reason to explore Plan 9, if not to adopt it wholesale.

I agree completely. When I have a budget for hardware I plan on
adopting it wholesale actually. I wouldn't be here if I weren't
interested in different paradigms and evaluating them.

--
Daniel Lyons

Re: [9fans] a few Q's regarding cpu/auth server

[lucio]

> "The Plan 9 way of thinking (wrt the security of physical terminal access)
> completely undermines, or somehow fails to recognize, the very real fact
> that there is always a cost/risk effort/reward equation at play."

Sure, but you used this against Plan 9 when you should have used it as
a stimulus for further investigation.  The Plan 9 developers added
factotum and the secstore and re-evaluated security out of necessity.
They highlighted what was already known, namely that physical security
is essential for real protection and based their efforts on this
discovery.  Merely acting on this principle was a break with tradition
for which they should be thanked, specially as they did not take away
the option to re-introduce the ability to pull the wool over the
system administrator's eyes.

You may do this if you want, I'd be curious to see what kind of
following you will find in this audience.

++L

PS: I think that illusion has some value in security, but the risk it
creates is much greater.  Like all security, what you see is more
important than what you have to dig to discover (a closed door is a
greater deterrent than an open one, even when it is unlocked).

PPS: The tone of your second reply suggests that my little barb had
much greater effect than you admitted.  Don't take it to heart, this
is a mailing list where the occasional insult becomes irresistible :-)

Re: [9fans] a few Q's regarding cpu/auth server

[lucio]

> Story time. :)

You're also falling into the trap of believing that because it _can_
happen, it has to happen (Murphy's Law).  It punishes the many for the
sins of the few and is a very poor foundation for progress.

Plan 9 has a good balance of cost of security against eventual real
protection and forces you to re-evaluate the accepted paradigms.  That
is sufficient reason to explore Plan 9, if not to adopt it wholesale.

++L

Re: [9fans] a few Q's regarding cpu/auth server

[Corey]

On Thursday 06 August 2009 21:19:05 lucio@proxima.alt.za wrote:
<snip>
> If you think it's worth it, then you need to put your money where your
> mouth is.
>

Like I said:

"Anyhow... I guess there's no reason to argue/debate! Looks like I
have some options"

... and later:

"[...] plus, I've already been provided with solutions from which I can roll
my  own."


> You are forgetting that the cost of security must be commensurate with
> the risk.
>

I'm forgetting what?

"The Plan 9 way of thinking (wrt the security of physical terminal access)
completely undermines, or somehow fails to recognize, the very real fact
that there is always a cost/risk effort/reward equation at play."


> When Plan 9 is popular enough for random visitors to desire to crack it,
> then the extra security will be worth the extra effort.  Until then, we can
> all save ourselves the bother
>

Sheesh:

"I think the actual root of the situation, is simply that Plan 9 currently
tends to reside within domains with much more strict and secure
or trustworthy environments vs. being prevalent within the sphere of
the great unwashed masses of the industry where strong physical
security is either unobtainable, unaffordable, and/or unreliable at best."


> Am I remembering wrong that 2nd Edition had password control on CPU
> servers?  I missed it briefly, then forgot about it.  Oh, yes, the
> change arose from the new security infrastructure, Bell Labs did not
> have the resources to port it so they abandoned it.  I adapted the old
> password check for something else, but what with NVRAM's failings and
> the effort involved, I never tried to get the CPU server to have a
> secured console.
>

I mention there are reasonable use-cases for a secured console on Plan 9
servers, and everybody attempts to show me why such a concept is completely
unnecessary.... but in fact it's simply a matter of Bell Labs and others not
having the resources to implement it in later editions.  And in fact it was
a feature that previously existed.


> PS: Off the cuff, I'd say that adding auth/as to init(8) on a CPU
> server would be almost all that's needed, just like in Unix.  So this
> discussion has been quite unnecessary.
>

Cool, it's a total no-brainer to implement; the discussion can end now.

Re: [9fans] a few Q's regarding cpu/auth server

[Corey]

On Thursday 06 August 2009 21:19:36 lucio@proxima.alt.za wrote:
> > I have direct experience as a contractor where I have entered
> > many a co-lo; and was unimpressed with their security to say the least.
> > I had constant and easy access to a large number of nameless servers,
> > it's a nobrainer to access keyboard/monitor pairs in many of these
> > places.
>
> That would be vandalism.  You didn't indulge in it, why would you
> expect someone else in your situation to do differently?  Or are you
> lying to us?
>

You'll have to do alot better than that if you want to get under my skin.

Begone, troll.

Re: [9fans] a few Q's regarding cpu/auth server

[Daniel Lyons]

On Aug 6, 2009, at 10:19 PM, lucio@proxima.alt.za wrote:

>> I have direct experience as a contractor where I have entered
>> many a co-lo; and was unimpressed with their security to say the  
>> least.
>> I had constant and easy access to a large number of nameless servers,
>> it's a nobrainer to access keyboard/monitor pairs in many of these  
>> places.
>
> That would be vandalism.  You didn't indulge in it, why would you
> expect someone else in your situation to do differently?  Or are you
> lying to us?


Story time. :)

Several years ago I worked for a company here that had decided to  
colocate a server locally (yeah, brilliant, in Albuquerque) instead of  
getting a hosted server somewhere with better access. I wound up going  
down there a few times to add RAM to the system. Apart from my  
company, there were a smattering of other smalltimers with big tower  
computers from Dell on this rack and off on the other side of the  
facility was a fenced off area with four or five racks of Dell  
hardware. The owner casually mentioned to me that the company who  
owned the racks had something to do with airline ticket sales. I guess  
because I chuckled at that, he also mentioned to me that the computer  
next to ours was hosting the governor's re-election website. I thought  
about doing something malicious, because I'm not a big fan of  
Richardson, but decided it wasn't worth the trouble.

Later on one of the owners of the colo facility got bought out and  
blew up. He went into the facility and ripped out the primary router,  
then took the upstream cable and plugged it into another port on the  
backup router such that the packets wound up going in a cycle. Then he  
damaged the backup power system and flew out the door with the primary  
router.

Not really taking a position here but your comments reminded me of the  
story. I guess there's always a bigger jerk out there and sometimes he  
runs your colo facility.

—
Daniel Lyons

Re: [9fans] a few Q's regarding cpu/auth server

[lucio]

> I have direct experience as a contractor where I have entered
> many a co-lo; and was unimpressed with their security to say the least.
> I had constant and easy access to a large number of nameless servers,
> it's a nobrainer to access keyboard/monitor pairs in many of these places.

That would be vandalism.  You didn't indulge in it, why would you
expect someone else in your situation to do differently?  Or are you
lying to us?

++L

Re: [9fans] a few Q's regarding cpu/auth server

[lucio]

> I honestly can't believe that this is even up for debate!  <grin>
>
> It's just bizarre.

It's not.  Nothing stops one  from putting the extra layer of security
in place, it's just a user-level change, just like it is in Unix to go
 from single-user to multi-user mode.  The fact that no-one has yet
found it necessary or worthwhile speaks volumes.  If you think it's
worth it, then you need to put your money where your mouth is.

As for me, I have way too much trouble understanding a hybrid of MIPS
and PC architecture to worry about securing equipment no one really
seems to want to break into.  You are forgetting that the cost of
security must be commensurate with the risk.  When Plan 9 is popular
enough for random visitors to desire to crack it, then the extra
security will be worth the extra effort.  Until then, we can all save
ourselves the bother, including trying to remember different passwords
for different hosts.

Am I remembering wrong that 2nd Edition had password control on CPU
servers?  I missed it briefly, then forgot about it.  Oh, yes, the
change arose from the new security infrastructure, Bell Labs did not
have the resources to port it so they abandoned it.  I adapted the old
password check for something else, but what with NVRAM's failings and
the effort involved, I never tried to get the CPU server to have a
secured console.

++L

PS: Off the cuff, I'd say that adding auth/as to init(8) on a CPU
server would be almost all that's needed, just like in Unix.  So this
discussion has been quite unnecessary.

Re: [9fans] a few Q's regarding cpu/auth server

[lucio]

> I honestly can't believe that this is even up for debate!  <grin>
>
> It's just bizarre.

It's not.  Nothing stops one  from putting the extra layer of security
in place, it's just a user-level change, just like it is in Unix to go
 from single-user to multi-user mode.  The fact that no-one has yet
found it necessary or worthwhile speaks volumes.  If you think it's
worth it, then you need to put your money where your mouth is.

As for me, I have way too much trouble understanding a hybrid of MIPS
and PC architecture to worry about securing equipment no one really
seems to want to break into.  You are forgetting that the cost of
security must be commensurate with the risk.  When Plan 9 is popular
enough for random visitors to desire to crack it, then the extra
security will be worth the extra effort.  Until then, we can all save
ourselves the bother, including trying to remember different passwords
for different hosts.

Am I remembering wrong that 2nd Edition had password control on CPU
servers?  I missed it briefly, then forgot about it.  Oh, yes, the
change arose from the new security infrastructure, Bell Labs did not
have the resources to port it so they abandoned it.  I adapted the old
password check for something else, but what with NVRAM's failings and
the effort involved, I never tried to get the CPU server to have a
secured console.

++L

PS: Off the cuff, I'd say that adding auth/as to init(8) on a CPU
server would be almost all that's needed, just like in Unix.  So this
discussion has been quite unnecessary.