On Fri, Feb 18, 2011 at 20:34:06 (CET), Gerry Reno wrote:
On 02/18/2011 02:14 PM, Alexander Wuerstlein wrote:
On 11-02-18 19:59, Gerry Reno <greno@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:
On Fri, 2011-02-18 at 17:18 +0100, Reinhard Tartler wrote:
<snip>The question is if there was a legitimate use-case for having users that can login via ssh, but are not in the x2gousers group, i.e., cannot login via x2go.
<snip> It's a bit of a stretch but I could see it in hosted environments like ours. Although we do not do this specifically, let's say there is an application server which is also hosting X2Go desktops. The client may have an external consultant/support person who should not have a billable X2Go desktop but does need console access to support the application via, say, a VPN connection.
Come to think of it, I suppose that is not just a hosting issue. A company using X2Go may not want to give desktop access to consultants who are supporting applications running on the same server. That sounds like poor practice but there may be some legitimate reason to do that which we haven't considered. Is that more in line with what you were asking? Thanks - John
Indeed, that would.
AFAIUI, you also agree that this is a pretty obscure corner case that is not worth to have as default. Therefore, I suggest to drop the sudo stuff completely and install x2gowrapper as 'suid x2gouser' so that no additional configuration is necessary. With this change, the use-case above doesn't work anymore.
In order to restore that functionality, the database schema would need to be extended to implement a blacklist. And in fact, your explanation kindof confirms that a blacklist would be more suited than the current whitelist (i.e., the x2gousers group) approach.
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.
Please elaborate. What security goal is compromised here?
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.
We are talking about a setup with ~100 new and deleted user accounts on a yearly basis, the CS student lab at uni-erlangen.de
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.
It does. My implementation still keeps the x2gousers group, but removes the necessity to add users to that group by default. If you have a valid use case, that's fine, just adjust the permissions of the wrappers and implement your user whitelist by adding them to the group.
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.
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.
No, editing /etc/sudoers is not the problem. Managing the x2gousers group is.
-- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4