[9fans] factotum/802.1x catch 22? - Plan9

This is a discussion on [9fans] factotum/802.1x catch 22? - Plan9 ; 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 ...

+ Reply to Thread
Results 1 to 19 of 19

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

  1. [9fans] factotum/802.1x catch 22?

    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.

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

    - erik

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

    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.

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

    > 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


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

    > *** 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

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

    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 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
    >


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

    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


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

    On 3/22/07, erik quanstrom 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

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

    > > 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.

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

    > 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

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

    > 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


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

    > 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 /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


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

    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


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

    > 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


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

    > 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.

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

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

    what? i seem to have missed something.

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

    >>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


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

    >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.

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

    > 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


+ Reply to Thread