Thanks for taking the time to clarify the issues. It is helping me achieve more balance in deciding if this is a good or bad move. I'll respond in the text below - John
On Fri, 2011-02-18 at 21:02 +0100, Alexander Wuerstlein wrote: > On 11-02-18 20:34, Gerry Reno <gr...@verizon.net> wrote: > > On 02/18/2011 02:14 PM, Alexander Wuerstlein wrote: > > > On 11-02-18 19:59, Gerry Reno <gr...@verizon.net> wrote: > > > > > >> On 02/18/2011 01:18 PM, Reinhard Tartler wrote: > > >> > > >>> On Fri, Feb 18, 2011 at 18:52:28 (CET), John A. Sullivan III wrote: Hey - that wasn't me - that was Gerry :) > > >> Are you implying that every user on any x2go server would be able to > > >> launch a remote x2go desktop by default? > > >> > > > Yes. > > > > > > > That would be a security hole. > > In what sense? That would only be a security hole if x2go were less > secure than simple ssh logins. If that is the case, those security > problems should of course be fixed. But I don't see the risk in allowing > x2go usage to users who can use ssh anyways. I suppose that is true. There are differences that we, as more experienced computers users might overlook. Someone using ssh probably knows what they are doing (and are thus probably more dangerous!). I would expect my engineers to be able to ssh to test, troubleshoot, configure these systems. That's different than casual users causing havoc by pointing their x2go clients to other systems (in our case, easily identifiable as other user names). Again, not arguing - just discussing. As I mentioned, I am a bit ambivalent about it all - seeing reasons for and against. Hmm . . . honestly, as I think through the security implications, I'm starting to lean against. Please indulge me by hearing me through a fairly complex thought. I do understand that we are not removing the security but rather giving options. If an admin wants to crank down the security more than the defaults, they can. However, we are creating a potentially less secure environment by default and asking people to tighten rather than a more secure environment and allowing people to loosen - the worldwide lack of patched systems shows that doesn't work too well! So let's consider the following not so corner case. Picture a moderately secure environment where users are not given command line access and applications such as ssh (of course, they can always download a browser based java application to do ssh which is why we implement micro-perimeter security using the ISCS project at http://iscs.sourceforge.net - shameless plug). Regular users thus do not have ssh but they do have X2Go clients. Authentication is centralized via something like AD or LDAP. An admin sets up X2Go on a server for ease of remote administration and is sloppy by not isolating it on a separate network with network access controls between it and the user or using local firewall rules or locking down the x2gopgwrapper script. In their sloppy assumption that users can't fiddle with it because they don't have ssh, command line access, or the ability to install applications, they've given their entire X2Go community who can authenticate against LDAP/AD access to their server. I'm thinking we should err on the side of security and make it secure by default with the option to loosen. That said, is there a way to achieve all goals? We do need to stop the sudo log spam. We do need to prevent misfired installations that required great expertise to sort out. What if, instead of using sudo, we did lock down the x2go scripts by default with restricted ownership as suggested to those who responded to this thread concerned about security. That leaves us with maintaining local groups but that is not the end of the world. It eliminates the sudo problem and makes us secure by default rather than exception. > > <snip>> > Adding appropriate syslog functionality to x2go could of course easily > be done. But the sudo-logspam x2go causes is in on way any viable means > of auditing and control, its much too easy to hide an attack in such a > huge amount of logged lines. I do agree with you there! > <snip> Thanks - John _______________________________________________ X2go-dev mailing list X2go-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
