At Sat, 25 Mar 2006 19:55:48 +0100, Lluis <[EMAIL PROTECTED]> wrote: > 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
I think I said something similar, if you look into the discussion of how to implement groups. > 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" I think that the system should not really care about this. The only thing the system needs to ensure is that the user and the group ID1 can communicate _at all_. Further capability exchange can be used to negotiate specific authorizations, without the system needing to be involved. > Well, what I was thinking of is like: > > evil$ ssh [EMAIL PROTECTED] > User does not exist [ or connection closed or something similar ] > evil$ ssh [EMAIL PROTECTED] > 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 It's not nonsense. Although it is security through obscurity, there is nothing wrong with making it harder even for only some attackers. Practical security also means to add some obstacles to thwart or delay attacks. However, your security model should not depend on this. So, I think that the lack of something like this is not a fatal flaw. There are other ways you can make attacks harder, for example by using stronger/longer passwords, or by not using passwords at all but public key authentication. Thanks, Marcus _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
