Nicolas Williams wrote: > On Tue, Mar 04, 2008 at 10:20:50AM +0000, Darren J Moffat wrote: > > Roland Mainz wrote: > > > Would be there any (technical) objections to modify "useradd" to add > > > entries to /etc/publickey by default (and assign a default host key for > > > the machines, too) ? > > > The idea is to get SecureRPC working by default on a plain Solaris > > > installation to allow users to use X11's SUN-DES-1 authentification > > > scheme instead of MIT-MAGIC-COOKIE-1 stuff (e.g. use $ xhost +username@ > > > # instead of shuffeling cookies around which should be much more > > > user-friendly) and/or use SecureRPC for NFS... > > > > Sounds like a great idea to me. > > Is it? > > The files and NIS backends for publickey(4) only supports 192-bit keys, > which are too weak,
Which is (AFAIK) fixable (isn't there even a RFE for that already ?) ... > and without NIS/NIS+/LDAP then you get no non-local > benefit from having any entries in /etc/publickey unless you manually > maintain it. Right... but it's still easier to handle than setting-up Kerberos5 (and the matching X11 MIT-KERBEROS-5 auth. is currently broken (which is on my ToDo list), leaving SUN-DES-1 as the only functional user2user authentification scheme in X11) or NIS+ (which Sun tries to remove at some point (which is IMO a pitty since once it has become mature Sun wants to get rid of it... ;-( )) and better than the current defaults (for NFS users it's MUCH better than the uid+gid auth and works around the "number of groups per user"-limit and for X11 it's much more user-friendly to give an "user" access to the display then explain your users how the abstract concept of cookies should work (and most of them don't understand it anyway and use $ xhost + # (= disable access control completely) instead. From my experience the $ xhost +username@ # thing solved at least this problem ((non-IT) users falling back to $ xhost + #) nicely... :-) )). > Network security requires the deployment of authentication > infrastructure or ad-hoc, SSH publickey-like leap-of-faith > authentication. The files backend of publickey(4) != either. > > Also, I'm not sure that any method of X11 display authentication other > than cookies makes sense unless we want users to be able to share their > displays with *other* users. The need to share displays is quite common at least on universities and/or if you want to do something like a presentation or demo in such an environment. From my experience the syntax of $ xhost +username@ # is MUCH more user-friendly. > Consider: if the only reason to forward krb5 creds to a remote server is > so I can use them to open my local display then I've given that server > the ability to impersonate me to all others just so I could access my > display from that server -- how odd! I could just use cookies, and then > I need not give that server anything too valuable. X11 cookies works > *fine* for SSH. I disagree for the "fine" - it just works very poorly. The ssh port forwarding+encryption+decryption needs giant amounts of CPU time and adds lots of latency and even defeats all the fine-grained buffer flushes in the X11 code by just copying the data without caring about things like X11 packet boundaries. Just try a simple experiment and run quake2 remotely, one time via normal X11 and one time via ssh forwarding. The ssh forwarding makes such an application unuseable (or the more real-world experiment would be X11 over a high-latency (satellite) link - if you use ssh the applications will become unuseable...). (There are other issues like that last time I checked their code OpenSSH doesn't use the SECRUITY extension to make new MIT-MAGIC-COOKIEs and just shares the original one (which is a serious security issue, something which ssh.com's version of ssh fixed long ago by trying to use the SECURITY extension first) or that the obsolete cookies aren't removes properly either) ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
