Re: SSH revised

[Marcus Brinkmann]

At Fri, 24 Mar 2006 16:49:07 +0100,
Lluis <address@hidden> wrote:
> 
> 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)

I agree it makes no difference here.  The only difference is in
maintenance.  For example, if you use plain identifiers, they must not
be reused.  That's easy enough to guarantee in this case if you use a
lot of bits.  Capabilities do not have this problem, but they are more
expensive to compare.

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

I was thinking that the event recipient should be either "everybody"
or a particular user, and the event class is just a data payload and
does not convey any semantics to the log server.

Group notifications can be handled if we consider a group to be just
another "user", and if the actual dispatch of the event happens in the
group itself (this would require that the user log daemon listens not
only on the system log server, but also on the log servers of the
groups the user is in).  It seems to me that the system code does not
need to be burdened with this.

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

I'm with you.
 
> 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.)

This "just one cap" is the directory :) What is a directory?  A
directory is a vector of pairs (string, cap).  The only simpler object
I can imagine is a cap vector without strings, and cap sets.  Cap
vectors without string have inefficient sparse representations, and
cap sets do not allow to distinguish the capabilities in the set.  So,
it seems to me that what you want is what I call a directory.

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

Do you really use a username like "p6.#wwQz"?

I am not sure what type of directed attacks you mean.  Maybe you can
follow up to clarify?

However, the username _by definition_ is not a secret, in the same
sense that my name "Marcus Brinkmann" is not a secret.  I believe that
any attack that is possible due to knowledge of the username indicates
a flaw in a different aspect of the system (I accept challenges to
this belief :)

Thanks,
Marcus