Re: [9fans] SSH server

Re: [9fans] SSH server

[erik quanstrom]

> Reading /mnt/factotum/ctl only gives you the keys you are allowed to use.
>
> factotum(4) says:
>
>           The factotum owner can use any key stored by factotum.  Any
>           key may have one or more owner attributes listing the users
>           who can use the key as though they were the owner.  For
>           example, the TLS and SSH host keys on a server often have an
>           attribute owner=* to allow any user (and in particular,
>           `none') to run the TLS or SSH server-side protocol.
>
> Therefore the example in ssh(1) for generating a key should say:
>
> 	auth/rsagen -t 'service=sshserve owner=*' >/mnt/factotum/ctl

none doesn't have access to eve's factotum, so you have to
run sshserve from a trusted listen anyway.  double-checking
with my own ssh server, i have (keys deleted)
key proto=rsa service=sshserve size=1024 ek=B !dk= n= !p= !q= !kp= !kq= !c2=
so i don't think that '*' is required.  however i think that
running from /rc/bin/service.auth is.

- erik

Re: [9fans] SSH server

[lucio]

> none doesn't have access to eve's factotum, so you have to

Not true, the permissions are quite relaxed (at least, this agrees
with my experience):

	tickle% ls -ld /mnt/factotum
	d-r-xr-xr-x M 642 proxima proxima 0 Nov 27 17:14 /mnt/factotum
	tickle% ls -l /mnt/factotum
	-lrw------- M 642 proxima proxima 0 Nov 27 17:14 /mnt/factotum/confirm
	--rw-r--r-- M 642 proxima proxima 0 Nov 27 17:14 /mnt/factotum/ctl
	-lr-------- M 642 proxima proxima 0 Nov 27 17:14 /mnt/factotum/log
	-lrw------- M 642 proxima proxima 0 Nov 27 17:14 /mnt/factotum/needkey
	--r--r--r-- M 642 proxima proxima 0 Nov 27 17:14 /mnt/factotum/proto
	--rw-rw-rw- M 642 proxima proxima 0 Nov 27 17:14 /mnt/factotum/rpc

I presume that the actual server is applying discretion :-)

	tickle% cat /dev/user
	luciotickle% cat /mnt/factotum/ctl

++L

Re: [9fans] SSH server

[Richard Miller]

> none doesn't have access to eve's factotum, so you have to
> run sshserve from a trusted listen anyway.

Maybe your configuration is non-standard.  Normally /lib/namespace
mounts /srv/factotum on /mnt, and /mnt/factotum/ctl has rw-r--r--
permission so anyone can read it.

> so i don't think that '*' is required.  however i think that
> running from /rc/bin/service.auth is.

You can do one or the other.

Re: [9fans] SSH server

[lucio]

>> so i don't think that '*' is required.  however i think that
>> running from /rc/bin/service.auth is.
>
> You can do one or the other.

The latter should be deprecated, the former uses the Plan 9 security
model as intended.  At least, that's my _opinion_.

++L

Re: [9fans] SSH server

[lucio]

> /mnt/factotum/ctl has rw-r--r--
> permission so anyone can read it.

In fact /mnt/factotum/rpc has rw-rw-rw- permissions.  I think that's
telling (to state the obvious).

++L

Re: [9fans] SSH server

[erik quanstrom]

> tickle% cat /mnt/factotum/ctl
> key proto=rsa service=sshserve owner=* size=1024 ek=19 n=E6468F8D8C04826CD398EFCBDE2593187A8A6C5CE76351ABDF52A15A4682F58582992B14005A6CE18ADDF8029AC94CBD3E32D6DCECEB6D441897D6D50199F9531D7666BAD87BD59148F3C6EF36D2BA8B5BB795385FD7E12810E25BCB0499B01B169011C839BD01452967DE93CFBFA16FED03E480E56C847D1DA9FDFCEC02A5C3 !dk? !p? !q? !kp? !kq? !c2?
>
> even though the user is "lucio" and not "eve".

sure, but that's not a key eve can see.
so a process forked from listen won't see it.

- erik

Re: [9fans] SSH server

[erik quanstrom]

> >> so i don't think that '*' is required.  however i think that
> >> running from /rc/bin/service.auth is.
> >
> > You can do one or the other.
>
> The latter should be deprecated, the former uses the Plan 9 security
> model as intended.  At least, that's my _opinion_.

they're not equivalent.  giving none the ability to
authenticate with the host's ssh key seems like a
really bad idea to me.  trivial attack: none could
run a hacked ssheserve with a key logger.

- erik

Re: [9fans] SSH server

[erik quanstrom]

On Fri Nov 27 10:22:32 EST 2009, 9fans@hamnavoe.com wrote:
> > none doesn't have access to eve's factotum, so you have to
> > run sshserve from a trusted listen anyway.
>
> Maybe your configuration is non-standard.  Normally /lib/namespace
> mounts /srv/factotum on /mnt, and /mnt/factotum/ctl has rw-r--r--
> permission so anyone can read it.

but you'll notice there's nothing in the file and that
/mnt/factotum/* point to a different instance.  since
listen's becomenone() is almost the same as auth/none,

	; ls -l /mnt/factotum/ctl
	--rw-r--r-- M 11 eve eve 0 Nov 27 11:21 /mnt/factotum/ctl
	; cat /mnt/factotum/ctl
	key proto=p9sk1 user=eve dom=mydom.com !hex? !password?
	; auth/none
	; ls -l /mnt/factotum/ctl
	--rw-r--r-- M 53 eve eve 0 Nov 27 11:22 /mnt/factotum/ctl
	; cat /mnt/factotum/ctl
	;
- erik

Re: [9fans] SSH server

[lucio]

> 	; ls -l /mnt/factotum/ctl
> 	--rw-r--r-- M 53 eve eve 0 Nov 27 11:22 /mnt/factotum/ctl
> 	; cat /mnt/factotum/ctl

But once I add an RSA key with an owner=* attribute, I get:

tickle% cat /mnt/factotum/ctl
key proto=rsa service=sshserve owner=* size=1024 ek=19 n=E6468F8D8C04826CD398EFCBDE2593187A8A6C5CE76351ABDF52A15A4682F58582992B14005A6CE18ADDF8029AC94CBD3E32D6DCECEB6D441897D6D50199F9531D7666BAD87BD59148F3C6EF36D2BA8B5BB795385FD7E12810E25BCB0499B01B169011C839BD01452967DE93CFBFA16FED03E480E56C847D1DA9FDFCEC02A5C3 !dk? !p? !q? !kp? !kq? !c2?

even though the user is "lucio" and not "eve".

++L

Re: [9fans] SSH server

[erik quanstrom]

On Fri Nov 27 05:34:24 EST 2009, lucio@proxima.alt.za wrote:
> And another equally silly question, maybe there's someone else out
> there that can learn from my mistakes and/or ignorance: the factotum
> on the CPU server does not contain all the keys "eve" is entitled to,
> in fact, it only contained a key that could be constructed from the
> NVRAM contents (what does the !hex=?  entry represent?).

this is documented in factotum(4) at the top of the section
"Key Tuples".  the key relationshop is that
	hex := f(password)
where f is passtokey (/sys/src/libauthsrv/passtokey.c).  so
hex and password have equivalent functionality.
/sys/src/cmd/auth/factotum/p9sk1.c:/^p9skaddkey
shows how they're used.

- erik

Re: [9fans] SSH server

[lucio]

> this is documented in factotum(4) at the top of the section
> "Key Tuples".  the key relationshop is that
> 	hex := f(password)
> where f is passtokey (/sys/src/libauthsrv/passtokey.c).  so
> hex and password have equivalent functionality.

Appreciated, thank you.

++L

Re: [9fans] SSH server

[lucio]

>>If it is, there's a depth of cleverness in the new Plan 9
>>security model that I had missed until now, namely the elimination of
>>the intermediate "superuser" step required by the Unix paradigm.
>
> indeed that's the point.

Too clever for my ageing brain :-) Of course, I knew the facility
existed, but I didn't associate it with the absence of "root" and the
elimination of setuid().  I think this type of subtle cleverness
should be documented more explicitly, I'm sure I'm not the only one to
overlook its ramifications.  Like, as another example.  the use of
groups in Plan 9, together with the group leader: nowhere are there
good examples that clarify how different these are from the Unix
model.  And documenting these principles is not easy: you need to
understand them very well.

++L

[9fans] SSH server

[lucio]

On my installation, moving tcp22 from /rc/bin/service to
/rc/bin/service.auth makes all the difference in gaining access to my
CPU server using SSH.

The failure mode was reported as a missing "service=sshserve" key in
factotum, whereas it seems to have been a file access (permissions?)
problem (none can't get where eve can).  That none can Bopen()
/mnt/factotum/ctl but can't read its contents is also a bit strange.

What am I missing?

++L

Re: [9fans] SSH server

[Richard Miller]

> The failure mode was reported as a missing "service=sshserve" key in
> factotum, whereas it seems to have been a file access (permissions?)
> problem (none can't get where eve can).  That none can Bopen()
> /mnt/factotum/ctl but can't read its contents is also a bit strange.

Reading /mnt/factotum/ctl only gives you the keys you are allowed to use.

factotum(4) says:

          The factotum owner can use any key stored by factotum.  Any
          key may have one or more owner attributes listing the users
          who can use the key as though they were the owner.  For
          example, the TLS and SSH host keys on a server often have an
          attribute owner=* to allow any user (and in particular,
          `none') to run the TLS or SSH server-side protocol.

Therefore the example in ssh(1) for generating a key should say:

	auth/rsagen -t 'service=sshserve owner=*' >/mnt/factotum/ctl

Re: [9fans] SSH server

[lucio]

> Therefore the example in ssh(1) for generating a key should say:
>
> 	auth/rsagen -t 'service=sshserve owner=*' >/mnt/factotum/ctl

This is the stuff that my literal mind copes poorly with :-) I would
never have picked this up.  If you don't mind, there's more
clarification I need on this issue: how is the sshserver process
running as "none" going to upgrade to, say, user "lucio"?  Is this a
result of the exchange of credentials, using the "capabilities"
driver?  If it is, there's a depth of cleverness in the new Plan 9
security model that I had missed until now, namely the elimination of
the intermediate "superuser" step required by the Unix paradigm.  I
guess I ought to have figured it out before now...

And another equally silly question, maybe there's someone else out
there that can learn from my mistakes and/or ignorance: the factotum
on the CPU server does not contain all the keys "eve" is entitled to,
in fact, it only contained a key that could be constructed from the
NVRAM contents (what does the !hex=?  entry represent?).  It's
possible that the secstore was not accessible to "eve" on boot (I've
extended the expiry date as soon as I discovered it had lapsed), is it
a given that the CPU server's factotum is invoked with the "S" option
or should I check somewhere to make sure before I reboot the server?

++L

Re: [9fans] SSH server

[Charles Forsyth]

>If it is, there's a depth of cleverness in the new Plan 9
>security model that I had missed until now, namely the elimination of
>the intermediate "superuser" step required by the Unix paradigm.

indeed that's the point.