Re: Re: SSH revised

[Lluis]

El Fri, Mar 24, 2006 at 03:44:32PM +0100, Marcus Brinkmann ens deleità amb les 
següents paraules:
[...]
>> 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
> 
> Yeah.  I am not sure if A should be a globally unique ID or a 
> capability itself.

when talking about identificator, I was really thinking about a capability, 
but there must be a "hashed table" of capabilities (or identificators), 
mapping them through their string identificator

whether it should really be a single number or a capability, in fact is not 
really important for the outlined steps I listed, as it should make no 
difference on the logger, it's up to it how to handle this details (in fact 
I would use a plain identificator, as it conveys no special or implicit 
privileges, and a capability could be "shared" to get acces to other 
services)

>> - S posts (A,E,{T}) to the logger (being E an identificator of the event 
>>   type)
> 
> Yes.
> 
>> - the logger sends a message to the registered clients on events for A
> 
> As a reply message to a "Get next event" operation initiated by A.

right, as I said later, a was thinking in a udev-like way, where there are 
callbacks to external non-running processes (script spawning)

>> - 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
> 
> Yes.
>  
>> 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)
> 
> I don't understand this.  What do you want to administrate?

I think I meant that you could give a user access to some class of events 
just through a 'useradd <user> <group>', as every event-class is associated 
with a valid group of recieve-waiting users (and having a "special" 
capability related to a user is like being part of the group that user 
stands for, if I understood your last mails about groups)

[...]
>> [...]
>>> 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
> 
> The same logion event type can be used.  The difference is in the 
> content of the "directory" that contains the information about the 
> terminal, ie the terminal type (set of logical and physical devices). 
> The user will need drivers for any interesting combination (the system 
> can provide default drivers).

right, and one of the things that should be there is a capability to the 
socket through which the connection is going on (or maybe a cap. to a 
wrapper for the connection, as it could be mirrored)

what confuses me is when you talk about directories... I know it's the 
same, but I better understand it like a cap. bundle (that, in the end, is 
probably all accessible through just one cap.)

[...]
>> 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
> 
> Well, and host authentication and transport layer management.

yes, I just "obviated" (is it correct?) this (this is why I talked about a 
socket wrapper a few lines upwards)

>> 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?
> 
> The list of user names is not secret.  If you really want, you could 
> make a dummy user that rejects all authentication attempts.

isn't it? for me it should be, the knowledge about a username being 
available or not on a system can give me information enough to try a 
directed attack to that account... that's related to why finger disappeared 
as a publicly available service on many of the systems out there... (yes, 
finger gives us much more information than just a username)

>>> 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 :)
> 
> A terminal is a directory which contains capabilities to physical and 
> logical devices, and information about these devices.  The SSH 
> terminal would ocntain different devices than a physical terminal with 
> a video card and keyboard etc.

right! this is a more generalised way of talking about it than what I 
pointed out on the pseudo-something that I wrote at the beginning of my 
last mail (the "S posts (A,E,{T}) to the logger", where {T} tries to 
indicate an array of caps. that will be available to the client logger, who 
will rearrange with, probably, some more caps. from itself)

Read you,
  Lluis

-- 
 "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: Lacrimosa (Echos) - 08. Die Schreie Sind Verstummt