Re: SSH revised

[Lluis]

El Sat, Mar 25, 2006 at 02:42:47AM +0100, Marcus Brinkmann ens deleità amb les 
següents paraules:
> 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.

yes, but capabilities also convey privileges, if you show them to the 
correct entity, it's just that these capabilities should be used only for 
that service, and I see the user identification as a global one, coherent 
between all the system services...

now that I think of it, this makes no sense, if with that ID cap. you could 
access an undesired service, this is that the system is badly designed, or 
that it has more semantics than you envisioned

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

ok, I was thinking on something like:

- event EV_FOO has multiple recipient, but all of them are registered as 
  ID1
- every 'useradd <user> ID1' makes <user> have access to the ID1 cap. user 
  identifier
- anyone wishing to recieve EV_FOO events has to register into the logger 
  with ID1

that's why I was talking about user ids as groups and each event class 
being associated to a single group-as-a-user

And if ID1 is a user identificator cap. it could convey some undesired 
rights on other services, so it should really be ID1::ev_reciever, meaning 
"the capability used to recieve events for ID1"

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

yes yes, I uderstand this, it's just that when I think of directories, I 
hawe to think a little more to associate each contained directory and file 
as a cap., it's only that my mental processing is just a little slower with 
this :)

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

Well, what I was thinking of is like:

evil$ ssh address@hidden
User does not exist [ or connection closed or something similar ]
evil$ ssh address@hidden
Password: 

Now I have more information, I know that bertrand.doe can log into the 
machine, so I could start a dictionary attack, knowing an account to attack 
and, maybe, having some information about Bertrand Doe (google, trashing, 
guessing, social engineering,...)

Is this nonsense? Maybe. Is this paranoid? Sure, but after reading this 
list, the little paranoid on me is growing XD

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: After FOrever (Live At Pinkpop) - 03. Semblance Of Confusion