[9fans] factotum/802.1x catch 22?

[9fans] factotum/802.1x catch 22?

[Axel Belinfante]

I'm finally playing again with my 802.1x supplicant.
(minor fix, adding the factotum related things russ
 suggested in answer to an earlier question)


when I want to boot and take root from file server,
I run the supplicant early in the boot process
to enable access to the network.
then I encounter a problem: it seems I have to start
factotum both before and after the supplicant.
(supplicant depends on factotum, to get keys;
 factotum depends on supplicant, to enable network)
so, that is what I do.
I'm wondering if there could be a better way.

(another problem is that when I start the supplicant
 so early, it is started before it can see a /sys/log/file
 so all log messages go to the console -- and continue
 to go there, even after we have a root fs with /sys/log/file)


what I do:

I run the supplicant in /sys/src/9/boot/bootip.c:/^configip
before program ipconfig is run.

the supplicant uses auth_getuserpassword to get
realm, user name and password, and thus I must start
factotum even earlier in the boot process,
before /sys/src/9/boot/boot.c:
		mp = rootserver(argc ? *argv : 0);
		(*mp->config)(mp);
because that is where configip is invoked.
(I also start kbmap();  earlier, just to be sure)

the problem now is that when I start factotum
this early, it is started before the auth addr
is set (and before the network is up).
therefore, when some time later it has to
access the auth server, it fails to do so:
it cannot access '#s/cs' while it was invoked
without '-a authaddr' command line option,
and thus it gives up. root fs mount fails.
(also, it does not contact the secstore).

therefore, I start a second factotum,
at the point where it normally is started,
after the rootserver() and (*mp->config)(mp);
(before starting it I
      unmount("#s/factotum", "/mnt");
      remove("#s/factotum");
 to make sure the second one will start)

the second factotum once more asks for the
hostowner (due to the -u flag).
it sees the network, and thus tries secstore.


I do not kill the first factotum (should I?) -
it remains running even though we cannot access it.
it does still have the 802.1x related keys that
I entered by hand during booting, but I guess
there is no way to transfer them to the second factotum?

right now I do not need these keys because the
supplicant remembers them. a nicer way of using
factotum would be for the supplicant to ask factotum
to build the 802.1x protocol messages that need
keys/passwords (such that the supplicant itself
never 'touches' them), but then the fact that
the second factotum does not have the 802.1x
related keys would become unfortunate. 


so, could there be a better way?

I have been thinking about additional factotum ctl
messages to essentially give it some time later
stuff that was not available when it was started, like
 - the equivalent of '-a authaddr' command line
 - tell it to try to access secstore
to be able to have just a single instance of factotum
running, but I'm not sure that would be the way to go...


Axel.

Re: [9fans] factotum/802.1x catch 22?

[erik quanstrom]

- erik

Re: [9fans] factotum/802.1x catch 22?

[Axel Belinfante]

I wrote, at the end of a description of a scenario
where factotum needs to be started before the network
is configured, to aid in enabling the network access,
such that it cannot do those things it normally
does during startup, like accessing secstore:

> I have been thinking about additional factotum ctl
> messages to essentially give it some time later
> stuff that was not available when it was started, like
>  - the equivalent of '-a authaddr' command line
>  - tell it to try to access secstore
> to be able to have just a single instance of factotum
> running, but I'm not sure that would be the way to go...

I tried that to see if it would work. it does.

I've extended my factotum with an 'authaddr' ctl verb.
(don't know wat can of worms it opens...)
reseiving it it will also trigger an attempt to access
secstore if it wanted to do that on startup but couldn't
(like because there was no network configured yet.)

I adapted my boot.c to start factotum before the root fs access
method is configured, such that, if config of root fs access
method needs factotum to handle keys to enable the network,
factotum will be there.
after config of the root fs access method authaddr is passed
on to the running factotum, if it was set.

Axel.

Re: [9fans] factotum/802.1x catch 22?

[lucio]

> I've extended my factotum with an 'authaddr' ctl verb.
> (don't know wat can of worms it opens...)

Sure, anything in security has its risks.  It may be safer if this
could occur exactly once and that if "-a authaddr" was previously
given, the command was rejected.  But that may be overkill.  Still,
I'd do it.  And -A would override for those who like living
dangerously.

> reseiving it it will also trigger an attempt to access
> secstore if it wanted to do that on startup but couldn't
> (like because there was no network configured yet.)

That is also a useful function in itself and I see no risks in it.  If
you add it in as a separate function, make sure we can add the
location of the secstore.  Mind you, that might be necessary in the
"authaddr" command, too, possibly as an option.

I second such changes, can you submit them here if "patch" does not
like them?  :-) :-)

*** Off Topic ***

I had a brief chat with "patch" and it strikes me now that the delay
in accepting complex patches might be alleviated if such patches could
be reviewed by 9fans, that is to say, publicly, by request.  Say, for
example, that we are asked to comment on Axel's patch and we return a
verdict, as part of the "patch" process.  No need to publish the
request, those interested can look on sources and post the result
there.

Two factors would seem important: usefulness as well as correctness.
Maybe on a scale of 1 to 5.  I don't know if I'm skilled enough to
alter patch/* accordingly, but I could try.

++L

Re: [9fans] factotum/802.1x catch 22?

[Uriel]

> *** Off Topic ***
>
> I had a brief chat with "patch" and it strikes me now that the delay
> in accepting complex patches might be alleviated if such patches could
> be reviewed by 9fans, that is to say, publicly, by request.  Say, for
> example, that we are asked to comment on Axel's patch and we return a
> verdict, as part of the "patch" process.  No need to publish the
> request, those interested can look on sources and post the result
> there.

That was precisely the purpose of my original patch notification
system, which russ didn't like and forced me to shut down.

I proposed doing a similar thing in the plan9-changes list for whoever
wanted to participate, but russ didn't like that either.

If you like I can open up plan9-changes (I'm not sure, but I suspect
it doesn't track new patches anymore, but that could be easily
changed), or we could create a new plan9-patches where only new
patches are posted (patches would get posted to plan9-changes when
they are accepted or rejected.)

In any case, without the collaboration of whoever sits at the other
end of patch(1), the whole exercise is pointless.

uriel

Re: [9fans] factotum/802.1x catch 22?

[Noah Evans]

U-man,

The code is not guarded by winged monkeys. You've shown a great deal
of positive leadership during the GSOC application process, why not
extend that leadership by forking the code base? It would be easy
enough to establish a forked server with replica and allow the gsoc
mentors modification access.

This would allow an "unstable" version of the code for the gsoc
students to play with and share their contributions. This would also
let *you* be the master of your destiny. It would also allow the Plan
9 community to more easily try out wildly speculative changes.

Why not?

Noah

On 3/22/07, Uriel <uriel99@gmail.com> wrote:
> > *** Off Topic ***
> >
> > I had a brief chat with "patch" and it strikes me now that the delay
> > in accepting complex patches might be alleviated if such patches could
> > be reviewed by 9fans, that is to say, publicly, by request.  Say, for
> > example, that we are asked to comment on Axel's patch and we return a
> > verdict, as part of the "patch" process.  No need to publish the
> > request, those interested can look on sources and post the result
> > there.
>
> That was precisely the purpose of my original patch notification
> system, which russ didn't like and forced me to shut down.
>
> I proposed doing a similar thing in the plan9-changes list for whoever
> wanted to participate, but russ didn't like that either.
>
> If you like I can open up plan9-changes (I'm not sure, but I suspect
> it doesn't track new patches anymore, but that could be easily
> changed), or we could create a new plan9-patches where only new
> patches are posted (patches would get posted to plan9-changes when
> they are accepted or rejected.)
>
> In any case, without the collaboration of whoever sits at the other
> end of patch(1), the whole exercise is pointless.
>
> uriel
>

Re: [9fans] factotum/802.1x catch 22?

[erik quanstrom]

let's not.

right now shouldn't be the enemy of right.
and voting is no substitue for deliberation.

- erik

On Thu Mar 22 00:53:55 EDT 2007, lucio@proxima.alt.za wrote:
> *** Off Topic ***
> 
> I had a brief chat with "patch" and it strikes me now that the delay
> in accepting complex patches might be alleviated if such patches could
> be reviewed by 9fans, that is to say, publicly, by request.  Say, for
> example, that we are asked to comment on Axel's patch and we return a
> verdict, as part of the "patch" process.  No need to publish the
> request, those interested can look on sources and post the result
> there.
> 
> Two factors would seem important: usefulness as well as correctness.
> Maybe on a scale of 1 to 5.  I don't know if I'm skilled enough to
> alter patch/* accordingly, but I could try.
> 
> ++L

Re: [9fans] factotum/802.1x catch 22?

[Joel C. Salomon]

On 3/22/07, erik quanstrom <quanstro@coraid.com> wrote:
> let's not.
>
> right now shouldn't be the enemy of right.
> and voting is no substitue for deliberation.

Can anyone run patch/note, or only maintainers?  If patch/note started
a thread on 9fans or plan9-changes, we could get discussion and
deliberation while the final decision still lies with the maintainers.

--Joel

Re: [9fans] factotum/802.1x catch 22?

[Axel Belinfante]

> > reseiving it it will also trigger an attempt to access
> > secstore if it wanted to do that on startup but couldn't
> > (like because there was no network configured yet.)
> 
> That is also a useful function in itself and I see no risks in it.
> If you add it in as a separate function, make sure we can add the
> location of the secstore.

I'm a bit unsure what is best regarding secstore;
I hesitate to replicate functionality we alread have,
and we already have the possibility of doing:

  auth/secstore -G factotum | read -m >/mnt/factotum/ctl


what you say seems to imply 'copying' (functionality of)
secstore(1) flags, like '-s server'.
but then, where to stop?
do we also need something like -g/-G for the filename?
that would allow e.g.

   echo secstore -s server -G filename >/mnt/factotum/ctl

but then, what about e.g. -n?
the more I think about it, the less certain I become.


It was suggested to me off-list to use a shell script
as boot program for more flexibility. in that case
doing the auth/secstore + read  to deal with secstore
would be trivial.

> Mind you, that might be necessary in the
> "authaddr" command, too, possibly as an option.


Axel.

Re: [9fans] factotum/802.1x catch 22?

[Uriel]

> It was suggested to me off-list to use a shell script
> as boot program for more flexibility. in that case
> doing the auth/secstore + read  to deal with secstore
> would be trivial.

Replacing /sys/src/9/boot/boot.c and friends with a set of shell
scripts has been in my TODO for a while now, the current code is too
rigid and inflexible, and expanding it would make it too complex,
replacing it with easily customizable shell scripts would solve many
problems.

Best wishes

uriel

Re: [9fans] factotum/802.1x catch 22?

[lucio]

> what you say seems to imply 'copying' (functionality of)
> secstore(1) flags, like '-s server'.
> but then, where to stop?

Perhaps.  As I see it, there are conventions in factotum designed to
handle the case where keys are needed from the secstore.  I can only
presume that the default secstore in this case is found in the same
place as the auth server, as described for the -a option:

          -a   supplies the address of the authentication server to
               use.  Without this option, it will attempt to find an
               authentication server by querying the connection
               server, the file <mtpt>/ndb, and finally the network
               database in /lib/ndb.

Either that, or there is an analogous approach for the secstore that I
am not familiar with (it isn't obvious from the description of the -S
option in the man page, perhaps it ought to be).

If you allow a command to trigger the operation of the -S option, then
in any case the conventions will apply, but it seems to me that they
may need qualification.  In fact, they probably already do, but
convention rules.  Certainly, factotum as built into the kernel does
not use secstore to retrieve the keys a CPU server may need, so adding
a minute and optional amount of selectivity isn't likely to hurt as
much as adding rc to the kernel image.

And that of course raises the question of what to do if the only form
of networking available is 802.1x and the secstore is remote.  But I
must qualify what may be a stupid question with the disclaimer that I
know nothing about 802.1x and I may well be making a fool of myself
here.

++L

Re: [9fans] factotum/802.1x catch 22?

[lucio]

> Replacing /sys/src/9/boot/boot.c and friends with a set of shell
> scripts has been in my TODO for a while now, the current code is too
> rigid and inflexible, and expanding it would make it too complex,
> replacing it with easily customizable shell scripts would solve many
> problems.

Which shell?  I thought rc(1) was deemed obsolescent?

++L

Re: [9fans] factotum/802.1x catch 22?

[erik quanstrom]

the bootstrap process  is *supposed* to be rigid.  it's only job is to start enough
stuff so one can connect to the fileserver.  services that can start
after one has a filesystem are started by cpurc or termrc.  for most
machines, this means setting up the network and authentication.

if one is running fossil(+venti) locally as a root fs, there is a bit more
configuration.  one needs to do setup the loopback and interact
with sd.

perhaps i suffer from myopia, but could you give an example of a
situation where a scriptable bootstrap would be helpful?

i don't think the suplicant/factotum interaction is one of them.
if code needs to be added to the bootstrap process to feed factotum
wireless keys and to later point factotum at the secstore server, then
that code needs to be added.

flexable security code seems oxymoronic to me.

in addition, all the files used as part of the bootstrap process need
to be built into the kernel.  if one wants to use rc, you need to build
rc, rcmain and the script into the kernel.  if you want to call an executable
like grep or test from from a bootstrap script these also need to be built
into the kernel.

btw, even linux has a static, compiled-in boot process until the root
filesystem is mounted.  if you use initrd, it is your root filesystem until
you pivotroot.  regardless, the kernel just mounts the root fs and runs
/sbin/init.

the linux and plan 9 boot process are very similar until the first user
process is started, which shouldn't be suprising.

- erik

On Sun Mar 25 09:56:01 EDT 2007, uriel99@gmail.com wrote:
> Replacing /sys/src/9/boot/boot.c and friends with a set of shell
> scripts has been in my TODO for a while now, the current code is too
> rigid and inflexible, and expanding it would make it too complex,
> replacing it with easily customizable shell scripts would solve many
> problems.
> 
> Best wishes
> 
> uriel

Re: [9fans] factotum/802.1x catch 22?

[lucio]

> if code needs to be added to the bootstrap process to feed factotum
> wireless keys and to later point factotum at the secstore server, then
> that code needs to be added.

This has my vote, too, in case I didn't make myself clear previously.

++L

Re: [9fans] factotum/802.1x catch 22?

[Axel Belinfante]

> if code needs to be added to the bootstrap process to feed factotum
> wireless keys and to later point factotum at the secstore server, then
> that code needs to be added.

just to give some background of what 802.1x is about,
and the role of my current 802.1x supplicant.
(see also http://en.wikipedia.org/wiki/802.1x )
I'll reply to lucio in a separate message.

802.1x is a standard for port-based Network Access Controls,
to allow access to the LAN only to those that have proven
themselves worthy. the network hardware (switch, access point)
does not allow those unauthenticated to talk any protocol other
than 802.1x, which is to be used for authentication with (e.g.)
a radius server (not even dhcp may be available yet).
there is the concept of a 'realm' to allow roaming: the realm
tells which radius server (could be off-site) should be
contacted to do the authentication.
a site can choose from many possible authentication methods.
at our univ a tls tunnel must be set up through which a
user/passwd is passed (this is the ttls-pap method).
other methods may involve e.g. certificates or challenge/resp.

I think 802.1x was originally developed to control access to
wired networks. when used on wireless networks 802.1x can be
used to distribute (and periodically renew) wep keys.


my 802.1x supplicant takes care of setting up the tunnel
and passing the user/passwd over it. it uses factotum
to obtain the user/passwd that is to be passed; it should
(but does not) use factotum to do the passing such that the
supplicant never sees user/passwd.
for other auth methods (when implemented) factotum might
play a bigger role (our univ now also supports peap
which uses mschap).
the supplicant receives wep keys passed via 802.1x and
feeds them directly to the wavelan driver (by writing
to /net/ether0/0/ctl). also here factotum could be used,
but I guess that would only complicate things (I have
a vague recollection that russ advised against passing
the wep keys to via factotum, but I could be wrong).

only after the supplicant has authenticated itself
for the first time (and obtained wep keys in the process)
it will be useful to run ipconfig, because dhcp may not work
until authenticated.
I wrote 'may not' because this seems to be a local decision.
at our univ dhcp does not work until authenticated.
at a different univ (where I can use the wireless net
via a roaming agreement, and authentication is done
using our univ radius server) dhcp is also available when
unauthorized (but ip is disabled until auth-ed).

after the supplicant has authenticated itself and
obtained wep keys it continues to run in the background
to do the periodic re-authentication and obtain new
wep keys and pass them to the wavelan driver.


Axel.

Re: [9fans] factotum/802.1x catch 22?

[Charles Forsyth]

>Which shell?  I thought rc(1) was deemed obsolescent?

what? i seem to have missed something.

Re: [9fans] factotum/802.1x catch 22?

[lucio]

>>Which shell?  I thought rc(1) was deemed obsolescent?
> 
> what? i seem to have missed something.

What?!  You were one of the objectors, unless my memory was failing
me.  It was Vita Nuova's own "sh" that was deemed to be the way into
the future.  Or should I have added a diode in my message?  I must
have thought this was alt.folklore.computers.

++L

Re: [9fans] factotum/802.1x catch 22?

[Charles Forsyth]

>What?!  You were one of the objectors, unless my memory was failing
>me.  It was Vita Nuova's own "sh" that was deemed to be the way into
>the future.

i'm fairly sure i didn't say the latter, so something must have
been misunderstood.  i did make some comment about the conventions
of the various shells not having changed much since the start, but
even that was a suggestion as to what someone else might have meant
by an apparently disparaging remark.

Re: [9fans] factotum/802.1x catch 22?

[lucio]

> i'm fairly sure i didn't say the latter, so something must have
> been misunderstood.  i did make some comment about the conventions
> of the various shells not having changed much since the start, but
> even that was a suggestion as to what someone else might have meant
> by an apparently disparaging remark.

You did not indeed make any claims about the Inferno shell, sorry that
I'm having too much fun being sarcastic to be accurate in reporting.

It was suggested (a) that rc was old and tired and (b) that the
Roger's Inferno shell was so superior as to be the obvious
replacement.  None of this from forsyth.  From those quarters, we had
perfectly sane responses to the effect that rc is neither old nor
tired and that it can in fact be improved in small ways without
bringing the universe on the verge of collapse.

I think so, too.

++L