Re: SSH revised

[Lluis]

El Thu, Mar 23, 2006 at 11:39:01PM +0100, Marcus Brinkmann ens deleità amb les 
següents paraules:
[...]
> This is pretty accurate.  However, we also consider a variation.  In the 
> variation, in step 1 _only_ the username is supplied to the system.  The 
> system does not do authentication.  Then step 2 and 3 happen.  Before 
> step 4, the user code would do the authentication itself.
> 
>> This relies on each user registering some login agent with each 
>> authentication process in the system (i.e. local terminal login, SSH 
>> login, etc.) before logins to the user's account can happen.
> 
> Not really.  First, we do not need to send the capability to the user, 
> the user can ask for it with a blocking fetch operation.  This means 
> that we do not need to register user capabilities, but that we can 
> advocate system capabilities to the user.  Also, there only needs to be 
> one such capability.  There needs to be something that multiplexes the 
> terminals to the users, of course.  I thought about this and came to the 
> conclusion that a system log mechanism could be used for this, if we add 
> capability support to the logger.  Ie, you don't log strings, but you log 
> "capabilities".  Terminal log-ons would be logged in their own category, 
> and be addressed to the user as the recipient.  The capability that the 
> system logs is the directory created in your step 2.  The same mechanism 
> can be used for other events that are generated by the system and 
> reported to the user (software updates, hotplug events on a terminal the 
> user is currently using etc).

so you propose the logger being like a capability board? sorry if I don't 
get the idea, but with this method, everyone looking at the board can see 
its contents. Of course, you can restrict "reads" to the board/stack/list 
by only matching the recipient with the user identity (being able to use 
the group identities for "multi-handlers"). Once your user-side ssh server 
gets to read a log-in message, it can fabricate a new container for the 
capabilities you are configured to recieve as you previously configured.

This works, but, first, each user *must* (al long as I understand) have a 
server running, and, second, this logger board thingie is just a server 
that handles a capability for a network connection (the socket recieveing 
the connection, in fact handled by the system ssh server, posting it to the 
logger).

This logger is a capability croupier, making 1 to N connections, I mean, 
sending the same message to the possible N listeners for that kind of event 
and for that concrete recipient

ok, so:

- an ssh server S listens on socket T
- S recieves a petition to login into Anna's account
- S looks up Anna's associated identificator, A
- S posts (A,E,{T}) to the logger (being E an identificator of the event 
  type)
- the logger sends a message to the registered clients on events for A
- the user logger routes the event to clients registered for type E
- the user side ssh server S' recieves T and starts any sort of 
  authentication mechanism that it is able to handle
- if the remote client successfully authenticates, S' creates a suitable 
  environment for the remote client

and the "login" process for the client to the global logger can be a 
registration of "classes", each class of event associated with an user 
identification (to make all this process administrable through the 
classical ways of user add and remove from groups)

this separation makes each component to be as least privileged as possible 
(meaning by possible "I can think of just now")

and makes it possible for a user to avoid logging through ssh by simply 
disabling the ssh handler

what I don't have clear is if that client-side handlers should be run 
on-demand or started in a udev-like manner (I was thinking of those "funny" 
things like persistence...mmm)

[...]
> The basic mechanism must be the same, as there should only be one 
> mechanism for this.  So, in the end, it will boil down to "one 
> capability" that is provided by the system to the user.  However, I think 

a local login could be handled by another client logger handler, giving a a 
"full powered" environment (if you want it to give it to you)

what I don't like is differentiating on this level between local terminal 
logins and remote ssh logins... both should be just an EV_LOGIN, with some 
properties which differentiate their idiosyncrasies

> for SSH this capability will not represent a transparent pseudo terminal, 
> but something more complex.  The reason is that the SSH protocol is not 
> just for PTY creation.  So, in order to support other functions of SSH, 
> you need to separate the protocol handling into a system layer and a user 
> layer.  The interface between the system and the user needs to reflec 
> this.  Ie, the system needs to pass off the SSH connection, with some of 

well, if the client logger is able to spawn a handler that spawns a new 
environment/shell, then the system has to do nothing but the username 
handling and routing

> its state, to the user.  It was not clear to me that this is possible, 
> although Niels mail told us that it is.  In particular, if we want to do 
> the variation above, the username needs to be received by the system 
> code, but the credential verification needs to be done by the user.  So, 
> the split may happen at an inconvenient place, and certainly long before 
> the pty creation step.

the problem I see in here, is, what happens when an invalid username is 
given? is there a dummy ssh handler to avoid leaking information?

> In other words: Terminals consist of physical or logical devices that 
> the user needs to know how to use.  For SSH, there will be some funny 
> logical device, that is not a PTY, but represents an existing SSH 
> connection, with channels and what not.

I don't completely understand what you try to say here, many things get 
away from me :)

[...]
> "You have to break eggs to make an omelett."

wow! I didn't expect for this... phrase to be used on other languages, I 
see its mundially used, but only with changed words :)

Read you,
  Lluis

PS: sorry if my mail is not much clear, but today has been a long day and 
I'm specially tired, although this doesn't mean that my lines will be more 
understandable another day ;)

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth
 
 Listening: Dram Theater (Six Degrees Of Inner Turbulence - Disc One) - 05.  
Disappear