Re: [9fans] Drawterm and security

Re: [9fans] Drawterm and security

[Brian L. Stuart]

In message <Pine.BSI.4.61.0502191055110.3971@malasada.lava.net>, Tim Newsham wr
ites:
>When you try to connect to sources (for example, you
>do a replica/pull, or 9fs sources) it connects to the
>machine and the machine asks you to authenticate to
>the outside.plan9.bell-labs.com authdom.

I almost literally heard the bell ring this time.  So
when I try to initiate an authentication, it's up to the
server to tell me what authentication domain he wants to
use.  Then I look up to find a auth= autodom= entry so
that I know who to talk to in order to do authenticate
in that domain.  So if I have an authdom=home entry in my
local network section, then anyone who wants to connect
to my server will be told to authenticate using the
home domain.  It's then up to the client to know what
auth server to use.

Somehow I never caught that part of it.  I think I can
now classify it as grey magic instead of black magic.
I'm still fuzzy on some bits, but it's getting a little
clearer.

Thanks,
Brian L. Stuart

Re: [9fans] Drawterm and security

[Russ Cox]

> >When you try to connect to sources (for example, you
> >do a replica/pull, or 9fs sources) it connects to the
> >machine and the machine asks you to authenticate to
> >the outside.plan9.bell-labs.com authdom.
>
> I almost literally heard the bell ring this time.  So
> when I try to initiate an authentication, it's up to the
> server to tell me what authentication domain he wants to
> use.  Then I look up to find a auth= autodom= entry so
> that I know who to talk to in order to do authenticate
> in that domain.  So if I have an authdom=home entry in my
> local network section, then anyone who wants to connect
> to my server will be told to authenticate using the
> home domain.  It's then up to the client to know what
> auth server to use.

All this is true except that the choice of authdom=home
does not come from your local network section.  The choice
of authdom comes from factotum, and it offers the client
a list of possible domains.  In particular, it offers any domain
on a p9sk1 key that isn't marked with role=client.

Russ

Re: [9fans] Drawterm and security

[Brian L. Stuart]

In message <ee9e417a05021914422bf17403@mail.gmail.com>, Russ Cox writes:
>> I almost literally heard the bell ring this time.  So
>> when I try to initiate an authentication, it's up to the
>> server to tell me what authentication domain he wants to
>> use.  Then I look up to find a auth= autodom= entry so
>> that I know who to talk to in order to do authenticate
>> in that domain.  So if I have an authdom=home entry in my
>> local network section, then anyone who wants to connect
>> to my server will be told to authenticate using the
>> home domain.  It's then up to the client to know what
>> auth server to use.
>
>All this is true except that the choice of authdom=home
>does not come from your local network section.  The choice
>of authdom comes from factotum, and it offers the client
>a list of possible domains.  In particular, it offers any domain
>on a p9sk1 key that isn't marked with role=client.

That makes sense.  So the putting auth= and authdom= into
the local network section is to tell your clients the
appropriate domain->server mapping for your network,
right?  It also raises the question, where does factotum
get that first key so that he has a dom to send out-
from nvram?

Thanks,
Brian L. Stuart

[9fans] Drawterm and security

[Brian L. Stuart]

I'm about to drive my fist through the monitor.  I think
I'm generally a fairly intelligent person and I generally
understand the Plan9 paper on security, but I'm having
a serious disconnect between that and how it's implemented
in practice.  Last night I was successfully connected between
a Linux box and my Plan9 file/cpu server with drawterm.
This morning I realized that I was unable to authenticate
to sources from the fs/cpu server so started to try to
fix my /lib/ndb/local to address the problem.  Nothing
seemed to work and worse yet, now drawterm is broken with
the infamous "cannot authenticate with p9" message even when
returning to the same /lib/ndb/local.  What exactly are the
necessary and sufficient conditions for making drawterm work
and likewise for access to sources?  auth/debug appears to be
fine and /sys/log/auth also seems fine.  I'm assuming that the
auth=sources... line must be there.  Does it break things to
have additional auth=bootes and authdom=home in the section
that describes the local net?  factotum is the only piece of
the current security system that hasn't seemed like black
magic to me.  Any wisdom is welcome.  Even a recipe would
be welcome at this point.

Brian L. Stuart

Re: [9fans] Drawterm and security

[andrey mirtchovski]

> Even a recipe would be welcome at this point.

Ingredients:

    * 1 part Vodka
    * 1 part Tequila
    * 1 part Rum
    * 1 part Gin
    * 1 part Triple sec
    * 1 1/2 part Sour mix
    * 1 splash Coca-Cola

Mixing instructions:

Mix ingredients together over ice in a glass.  Pour into shaker and
give ONE brisk shake.  Pour back into glass and make sure there is a
touch of fizz at the top.  Garnish with lemon.

as for authentication, what do you mean by 'auth/debug is fine'
exactly?  is auth/keyfs running?  what's the drawterm message?  do you
have factotum running?

Re: [9fans] Drawterm and security

[Brian L. Stuart]

Let's try this again.  It didn't seem to get out before.

In message <0857c7e34289332af716f9b0ef5a55c2@plan9.ucalgary.ca>, andrey mirtcho
vski writes:
>> Even a recipe would be welcome at this point.
>
>Ingredients:
>
>    * 1 part Vodka
>    * 1 part Tequila
>    * 1 part Rum
>    * 1 part Gin
>    * 1 part Triple sec
>    * 1 1/2 part Sour mix
>    * 1 splash Coca-Cola

Truely tempting.

Well, I was going to repeat all the stuff I had tried to send before,
but suddenly things are working for drawterm.  The last step was
to invalidate the nvram, reboot and reset all the passwords.  I'm
not sure how things got mangled, but drawterm is now working.
replica/pull still isn't however.  I definitely have the auth=sources
line in /lib/ndb/local now.  But even before factotum asks for
a user and password, I'm getting:

srv tcp!sources.cs.bell-labs.com: mount failed: authentication failed

I get the same thing if I manually try to 9fs soruces.  Any ideas on
that one?

Thanks to everyone for your help.  The really frustrating part of
all of the authentication stuff is that I don't seem to yet see
the connections between fault symptoms and causes.  I still don't
know why wiping the nvram and resetting everything has made drawterm
happy.

Brian L. Stuart

Re: [9fans] Drawterm and security

[Russ Cox]

After editing /lib/ndb/local (or any files in /lib/ndb),
it is a good idea to do

    echo -n refresh >/net/cs

to tell cs to reload the ndb files *now*.  It will eventually
notice that they have changed and reload them itself,
but not necessarily immediately.  That could well be the
cause of your confusion and frustration.

Russ

Re: [9fans] Drawterm and security

[blstuart]

In message <ee9e417a0502191058484e4422@mail.gmail.com>, Russ Cox writes:
>After editing /lib/ndb/local (or any files in /lib/ndb),
>it is a good idea to do
>
>    echo -n refresh >/net/cs

Thanks for the tip.  I had been resorting to killing and
restarting cs, and even frequent reboots.  Are there any
other processes that need to know if there are changes
there?

That had certainly been part of the frustration.  I still
feel like I'm editing /lib/ndb/local using a random walk,
however.

Thanks,
Brian L. Stuart

Re: [9fans] Drawterm and security

[Russ Cox]

> Thanks for the tip.  I had been resorting to killing and
> restarting cs, and even frequent reboots.  Are there any
> other processes that need to know if there are changes
> there?

You can echo -n refresh >/net/dns too, but you weren't
changing DNS-related stuff.

Russ

Re: [9fans] Drawterm and security

[blstuart]

In message <ee9e417a05021911205354182a@mail.gmail.com>, Russ Cox writes:
>You can echo -n refresh >/net/dns too, but you weren't
>changing DNS-related stuff.

Cool.  What about changes to authdom?  Who uses authdom
and how?  In response to Andrey's questions (which I seem
to have sent just to him instead of the list), my local
file has the normal auth=sources... line and it also
has an authdom=home in the section for my local network.
I'm not quite sure what it means for both of them to be
there.  In fact, when I first set the system up, I commented
out the auth=sources line.  But today, I figured that was
at the heart of my problem getting replica/pull to work.

Brian L. Stuart

Re: [9fans] Drawterm and security

[andrey mirtchovski]

> In message <ee9e417a05021911205354182a@mail.gmail.com>, Russ Cox writes:
>>You can echo -n refresh >/net/dns too, but you weren't
>>changing DNS-related stuff.
>
> Cool.  What about changes to authdom?  Who uses authdom
> and how?  In response to Andrey's questions (which I seem
> to have sent just to him instead of the list), my local
> file has the normal auth=sources... line and it also
> has an authdom=home in the section for my local network.
> I'm not quite sure what it means for both of them to be
> there.  In fact, when I first set the system up, I commented
> out the auth=sources line.  But today, I figured that was
> at the heart of my problem getting replica/pull to work.
>
> Brian L. Stuart

i don't seem to have received your message. i blame the university's email servers.

for authdom= the only requirement that's really important is to make
sure you've synchronized it with what cpu server user (bootes in most
cases) thinks it's running in.  i.e.  when you boot it make sure your
authdom= in nvram is the same as the authdom= entry in ndb for the
network you're booting in:

ipnet=ucalgary ip=136.159.220.0 ipmask=255.255.255.0
	proto=tcp
	[...]
	authdom=plan9.ucalgary.ca

when i invalidate the nvram (or change the password) i supply
plan9.ucalgary.ca as the authdom on the next boot of the cpu server.

andrey

Re: [9fans] Drawterm and security

[Skip Tavakkolian]

With drawterm, everything is running on the cpu, and drawterm
is just 'exportfs'ing your local namespace (for things like keyboard,
mouse, etc.) I'm guessing that YOUR factotum (your authentication
agent) is not running.  I've attached dt_factotum, which I
got from geoff.  You run it on the cpu (in you're drawterm session),
once you've successfully drawterm'ed in.

term% cat $home/bin/rc/dt_factotum
#!/bin/rc

if (! test -f /srv/factotum.$user)
	auth/factotum -s factotum.$user
mount -b /srv/factotum.$user /mnt

> I'm about to drive my fist through the monitor.  I think
> I'm generally a fairly intelligent person and I generally
> understand the Plan9 paper on security, but I'm having
> a serious disconnect between that and how it's implemented
> in practice.  Last night I was successfully connected between
> a Linux box and my Plan9 file/cpu server with drawterm.
> This morning I realized that I was unable to authenticate
> to sources from the fs/cpu server so started to try to
> fix my /lib/ndb/local to address the problem.  Nothing
> seemed to work and worse yet, now drawterm is broken with
> the infamous "cannot authenticate with p9" message even when
> returning to the same /lib/ndb/local.  What exactly are the
> necessary and sufficient conditions for making drawterm work
> and likewise for access to sources?  auth/debug appears to be
> fine and /sys/log/auth also seems fine.  I'm assuming that the
> auth=sources... line must be there.  Does it break things to
> have additional auth=bootes and authdom=home in the section
> that describes the local net?  factotum is the only piece of
> the current security system that hasn't seemed like black
> magic to me.  Any wisdom is welcome.  Even a recipe would
> be welcome at this point.
>
> Brian L. Stuart

Re: [9fans] Drawterm and security

[blstuart]

In message <8e10ef025f295ae275886fa840d1bc1b@9netics.com>, Skip Tavakkolian wri
tes:
>With drawterm, everything is running on the cpu, and drawterm
>is just 'exportfs'ing your local namespace (for things like keyboard,
>mouse, etc.) I'm guessing that YOUR factotum (your authentication
>agent) is not running.  I've attached dt_factotum, which I
>got from geoff.  You run it on the cpu (in you're drawterm session),
>once you've successfully drawterm'ed in.

The problem is that I'm not getting that far.  drawterm
bails a few seconds after I enter the correct password.
The file/cpu server does have a factotum running as user
bootes.  I get the same behavior whether I try to log
in as either bootes or as myself.

Still, I'll hang on the script.  Looks like it will be
useful when I do get successfully drawterm'ed in.

Thanks,
Brian L. Stuart

Re: [9fans] Drawterm and security

[Robert Raschke]

Skip Tavakkolian wrote:
> term% cat $home/bin/rc/dt_factotum
> #!/bin/rc
>
> if (! test -f /srv/factotum.$user)
> 	auth/factotum -s factotum.$user
> mount -b /srv/factotum.$user /mnt

Hmm, all I do is start a plain auth/factotum in my profile when I
recognise that I'm running a drawterm connection.  What is the reason
for ensuring an explicit service name?  By default it doesn't announce
a service, and if I understand correctly, the /mnt/factotum/ is going
to be the correct one (i.e., not the one mounted by bootes) for the
drawterm session.

About the original problem of factotum not prompting for passwords,
one of the issues I had in the early days was that factotum attempted
to collect my password from the console.  And that didn't work when I
connected via drawterm.  I got around that by starting fgui explicitly
via 'window -hide auth/fgui' in my riostart script.

Robby

Re: [9fans] Drawterm and security

[geoff]

> What is the reason for ensuring an explicit service name?

As usual, one posts a service to permit (or at least encourage)
sharing.  In this case, one also wants to avoid a possible
collision with an existing (bootes) /srv/factotum on a CPU server.
By creating a /srv/factotum.$user at first login, it's
then possible for later logins by $user to share the same
factotum (by just mounting /srv/factotum.$user on /mnt).

It does make one's profile (or at least my profile) a little
messier, probing for suitable existing factota in /srv and
/mnt/term/srv.