On 02/18/2011 03:02 PM, 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: >>>>> >>>> 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. >
Yes, it's similar but not exactly the same as ssh. You might want to let a vendor/app-support have ssh access but not allow them a desktop. In neither case should the default be 'wide-open' access. > >>>> We don't have any problems with the current mechanism of 'x2gousers' >>>> providing the control. >>>> >>>> And in fact in most OS you see 'groups' are specifically there for the >>>> express purpose of controlling access to functionality. >>>> >>>> >>> Yes, but in large setups, groups become very hard to manage. Large >>> groups with thousands of users tend to be an administration burden, also >>> a large number of additional groups for each user tends to be >>> problematic with many operating systems or setups (NIS, SQL, older >>> unices, etc). >>> >>> >> Well, qualified sysadmins have been managing large installations quite >> successfully for about 50 years now. >> > Yes, success comes from expirience and the right set of tools. And my > expirience tells me that groups are often not the ideal tool for the > job. Again, we wouldn't necessarily need to do away with the 'x2gousers' > group, we just would make the process more flexible to allow for > authorization mechanisms other than by group membership. > > >>> And our approach wouldn't make the >>> 'x2gousers' group go away if you still want to use it: You can simply >>> make the x2gowrapper executable only for that group and not for others. >>> Then you have exactly the same functionality as with 'sudo', but without >>> the hassle of setting up the sudo configuration (wich does never seem to >>> work automatically on installation). That would also be the suggested >>> migration path i guess. Additionally you can of course use database >>> black/whitelists, or you can set x2gowrapper o+rx and only use database >>> black/whitelists. In that sense our approach would also be far more >>> flexible than the current sudo approach. >>> >>> >> It doesn't make the 'x2gousers' group go away. But it removes all the >> 'sudo' functionality which does it's job of auditing and control very well. >> > 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. > That is why there are log-parsing tools. Even 'grep' can get rid of 99% of useless log stuff. > >> I don't get what is complained about here: sudo being difficult. It is >> not difficult at all. Use 'visudo' as you should and it works very well. >> > Yes, but for example the debian package installation does not use > visudo, instead it just tries to edit the sudoers file to the best of > its abilities. Which, if the sudoers file has been altered before, > usually fails. That leads to frustrated first-time users and possibly > screwed up sudo configuration either by the script or the user, which > could be a huge security problem. > > >> If you try direct access to the sudoers file then you have to take extra >> precautions. If you're not doing that then of course you will run into >> problems. >> > Which is, in other words, "sudo configuration is fragile and difficult" > ;) > This is no more difficult than an application having to update any other config file. By your standard every application configuration is 'fragile and difficult'. In the case of configs, you have the install put the 'new' file in place as FILE.new and you provide a message to the user/install-log saying that the sysadmin must MERGE the old config file and new config file. We already do this for a number of applications on upgrades/installations. x2go is no different here. I do think this topic needs quite a bit more thought and study before any change should be undertaken. There is LDAP to consider, local users/groups, John's 1-1 vm scenario, regular 1-M vm scenario. Right now there are no problems with the 'sudo' approach for these scenarios. At least none that anyone is screaming about. So I think we need to be careful before making drastic changes. Regards, Gerry _______________________________________________ X2go-dev mailing list X2go-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
