Hi there,
we already talked to Alex, but maybe it's a good idea to ask a broader audience: Has anybody got an use case where someone who has ssh access is not allowed to start x2go? In short: We want to get rid of the sudo-entry and use suidperl instead.
Cheers Morty
-- Dipl.-Ing. Moritz 'Morty' Struebe (Wissenschaftlicher Mitarbeiter) Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme) Friedrich-Alexander-Universität Erlangen-Nürnberg Martensstr. 1 91058 Erlangen
Tel : +49 9131 85-25419 Fax : +49 9131 85-28732 eMail : struebe@informatik.uni-erlangen.de WWW : http://www4.informatik.uni-erlangen.de/~morty
On Fri, 2011-02-18 at 12:32 +0100, Moritz Struebe wrote:
Hi there,
we already talked to Alex, but maybe it's a good idea to ask a broader audience: Has anybody got an use case where someone who has ssh access is not allowed to start x2go? In short: We want to get rid of the sudo-entry and use suidperl instead. <snip> Thanks for asking. I'm not sure what the issues are. Our environment is probably one of the most unusual because there is no root access from within the virtual machine - only from the host entering the VM. Users cannot su. That does not sound like what you are asking, though.
They also have significantly restricted access to kernel functions which is why the call to fusemount (I forget the exact command) fails in our environment and we have to move much of the functionality to the VServer host (which is much more efficient than running 400 instances of x2gocleansessions) - John
On Fri, Feb 18, 2011 at 16:55:56 (CET), John A. Sullivan III wrote:
On Fri, 2011-02-18 at 12:32 +0100, Moritz Struebe wrote:
Hi there,
we already talked to Alex, but maybe it's a good idea to ask a broader audience: Has anybody got an use case where someone who has ssh access is not allowed to start x2go? In short: We want to get rid of the sudo-entry and use suidperl instead. <snip> Thanks for asking. I'm not sure what the issues are. Our environment is probably one of the most unusual because there is no root access from within the virtual machine - only from the host entering the VM. Users cannot su. That does not sound like what you are asking, though.
No. 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.
They also have significantly restricted access to kernel functions which is why the call to fusemount (I forget the exact command) fails in our environment and we have to move much of the functionality to the VServer host (which is much more efficient than running 400 instances of x2gocleansessions) - John
What you describe seems like a reasonably restricted Linux vserver system to me, but doesn't really relate to the original question.
-- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4
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
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.
-- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4
On Fri, 2011-02-18 at 19:18 +0100, 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.
I'm ambivalent. In the little development I've done, unless I'm protecting my users from doing really, really dangerous things, I tend to err on the side of not restricting them because of the countless ways they can think of using my application that never occurred to me. Of course, we are not preventing them - just making it harder. I am somewhat ignorant of the motivation to make the change (I'm sure it is valid) so I'm not in a position to weigh the advantages and disadvantages. I would be quite curious to see what others say and really appreciate your asking before simply implementing it - John
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?
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.
In many companies only certain employees such as field personnel or sales are permitted remote desktop access. And the 'x2gousers' group suits this purpose well.
I would not want to see the existing mechanism changed in the way being proposed.
Regards, Gerry
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.
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).
In many companies only certain employees such as field personnel or sales are permitted remote desktop access. And the 'x2gousers' group suits this purpose well.
Yes, it does on small scales. 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.
Ciao,
Alexander Wuerstlein.
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.
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.
In many companies only certain employees such as field personnel or sales are permitted remote desktop access. And the 'x2gousers' group suits this purpose well.
Yes, it does on small scales.
No, on any scale.
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.
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.
Regards, Gerry
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
On 11-02-18 20:34, Gerry Reno <greno@verizon.net> 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: 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.
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.
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" ;)
Ciao,
Alexander Wuerstlein.
On 02/18/2011 03:02 PM, Alexander Wuerstlein wrote:
On 11-02-18 20:34, Gerry Reno <greno@verizon.net> 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:
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
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 <greno@verizon.net> 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: 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
On 11-02-18 22:24, John A. Sullivan III <jsullivan@opensourcedevel.com> wrote:
On Fri, 2011-02-18 at 21:02 +0100, Alexander Wuerstlein wrote:
On 11-02-18 20:34, Gerry Reno <greno@verizon.net> 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: Hey - that wasn't me - that was Gerry :)
Oh, I'm sorry, that was an accident when deleting stuff...
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'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.
Sounds like a good idea.
Ciao,
Alexander Wuerstlein.
Hi John, hi list,
Am Freitag, 18. Februar 2011, 22:24:00 schrieb John A. Sullivan III:
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.
Thanks for the time you all put into this!!! I agree with John and also think that the upstream development should be as generic as possible and tweaking code such as the proposed change should be either done in the distribution package or possibly even better by the site administrator.
However, if people have patches that are generic and dedicated to upstream X2go and also ease a usage scenario like the one requested by Uni Erlangen, I guess there is a good chance of code inclusion into upstream.
Greets, Mike
Thanks, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0x1943CA5B mail: m.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Hi all,
May I suggest the following: First of all: This is only about the SQLite wrapper! Let's get rid of sudo and use suid instead. Add a commented line to the wrapper that checks whether the current user is in the appropriate group.
Rationale: x2goserver-one, which is responsible for the automatic use of the SQLite wrapper, had exactly this behaviour: It gives all users access to x2go (Worse: A while ago it gave all users root-access). Therefore for the naive user there is no change in behaviour: It gives them more efficient access then using X-forwarding. Administrators who administer a large user base, who should have got nervous with the root-sudo anyway, sould be able to uncomment that one line within the wrapper and change it to a group or groups of there favour.
After all x2go is yet another application. There is no way that you may compromise the system because of this - except using resources, but there are better ways to do so. It you want, you can even adjust the client work around the wrapper-script and start the agent manually (No, I won't discuss how). Therefore there is no real additional security won by disallowing users to run the wrapper.
Cheers Morty
P.s.: IMO the final decision must be made by Alex and Heinz anyway.
On 2011-02-18 22:24, John A. Sullivan III wrote:
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.
-- Dipl.-Ing. Moritz 'Morty' Struebe (Wissenschaftlicher Mitarbeiter) Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme) Friedrich-Alexander-Universität Erlangen-Nürnberg Martensstr. 1 91058 Erlangen
Tel : +49 9131 85-25419 Fax : +49 9131 85-28732 eMail : struebe@informatik.uni-erlangen.de WWW : http://www4.informatik.uni-erlangen.de/~morty
On Sat, 2011-02-19 at 15:43 +0100, Moritz Struebe wrote:
Hi all,
May I suggest the following: First of all: This is only about the SQLite wrapper! <Snip> Oops! I didn't realize that. Sorry if I raised a fuss about nothing - John
HI Morty,
On Sa 19 Feb 2011 15:43:11 CET Moritz Struebe wrote:
P.s.: IMO the final decision must be made by Alex and Heinz anyway.
This is the main point with this thread. To my view it doesn't work
that neither Heinz nor Alex contribute to this discussion...
So, @Heinz and/or Alex: Could you please give your opinion on this
discussion rather sooner than later?
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Hello Mike, hello list,
Am 20.02.2011 10:48, schrieb Mike Gabriel:
So, @Heinz and/or Alex: Could you please give your opinion on this discussion rather sooner than later?
The x2go usergroup was used to restrict the access to "x2gopgwrapper". This main use case is no longer existant, because of the changes made to the postgres database handling.
If you want to deny users access to a server, it is a better idea to think about a more complete solution, as users outside this group still can have access via ssh (-X).
As the main purpose of this construction is no longer needed, we should not keep it alive. Allowing users to run applications as another user is always a great security issue.
As Alex and I have discussed this topic, we've come to the conclusion to drop the need of the group and sudo at all.
This leads to the following suggestions:
You should use pgsql backend in all cases except home, (very) small office network or VM pools where each user has his own VM.
So in future there will be:
- no need to have sudo entry.
- no need to have 'x2gousers' group
- no need to insert users in 'x2gousers' group
This will also solve a Bug on debian edu:
http://www.mail-archive.com/debian-edu@lists.debian.org/msg19665.html
Best Regards,
Alex & Heinz
On Fri, 2011-02-18 at 20:14 +0100, Alexander Wuerstlein wrote:
<snip>>
Are you implying that every user on any x2go server would be able to launch a remote x2go desktop by default?
Yes.
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). Hmm . . . I can see that backfiring in our scenario. Of course, our scenario shouldn't drive the overall development but I'll share my concerns in case others have them, too.
Because we envision a very large environment, we are an LDAP shop (CentOS Directory Server). There are very, very few local accounts. We are not using N-to-1 X2GoServer but rather 1-to-1 - each X2Go user has their own VM. We use a local x2gousers group on the VM. We create it and add the user to it (in fact, the VM hostname is the same as the globally unique user uid) as part of the VM creation. This locks each user to a VM which is handy for both billing and non-repudiation. Because we fix each IP, all activity is known to come from that user and only that user (handy for schools or any other organization sensitive to IT abuse). In the proposed scenario, any valid LDAP user from any client in our multi-tenant environment could conceivably start an X2Go session on any VM thus destroying the control and accountability we implemented exactly because we anticipate a large environment.
However, we do appreciate that you have given us options which I'll address below.
In many companies only certain employees such as field personnel or sales are permitted remote desktop access. And the 'x2gousers' group suits this purpose well.
Yes, it does on small scales. 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.
<snip>
I suppose this is true and appreciate the flexibility. Just as we automate the creation of the group, we could simply change the group ownership of x2gowrapper to the user's personal group and remove world access. Is that a correct understanding of how we could use what you are proposing? I do hope those ownership and permissions changes wold be preserved across an update. Otherwise, I could see a security nightmare.
Again, our use shouldn't drive this decision but I wonder how many others have variations on our theme for issues like billing, security, and non-repudiation. Thanks again for opening the discussion; I hope it is proving helpful rather than burdensome! - John
On 11-02-18 20:55, John A. Sullivan III <jsullivan@opensourcedevel.com> wrote:
On Fri, 2011-02-18 at 20:14 +0100, Alexander Wuerstlein wrote: We use a local x2gousers group on the VM. We create it and add the user to it (in fact, the VM hostname is the same as the globally unique user uid) as part of the VM creation.
So I assume e.g. on host 'mike' the user named 'mike' is a local (only on that host) member of group 'x2gousers'? If thats the case, just install all x2gowrappers executable to the 'x2gousers' group only and you are done. So its just a minimal change to your standard VM image that would be needed. But for non-repudiation you will also need to prevent any other user than 'mike' from logging in to the host 'mike' by ssh, so if your setup works as intended, the permisions on the wrapper will be your second line of defense, not your first.
Yes, it does on small scales. 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. <snip>
I suppose this is true and appreciate the flexibility. Just as we automate the creation of the group, we could simply change the group ownership of x2gowrapper to the user's personal group and remove world access. Is that a correct understanding of how we could use what you are proposing? I do hope those ownership and permissions changes wold be preserved across an update. Otherwise, I could see a security nightmare.
You could also change the group to the user's private group, but I guess that would be much more complicated than the approach described above. And I agree that perhaps the postinstall script should take care not to mess up the permissions of the wrapper if they have been changed (Or perhaps a debconf question would be useful?).
Again, our use shouldn't drive this decision but I wonder how many others have variations on our theme for issues like billing, security, and non-repudiation. Thanks again for opening the discussion; I hope it is proving helpful rather than burdensome! - John
Yes, its very helpful, exploring all the things people would like to do really carves out the corner cases we need to think about. In that sense, I'm very grateful for the active discussion since it prevents nasty surprises that would happen if those corner cases were discovered too late.
Ciao,
Alexander Wuerstlein.
Hi Alexander,
On Fr 18 Feb 2011 20:14:19 CET Alexander Wuerstlein wrote:
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).
???? How do you get to this conclusion. My experience is totally on
the opposite side... Groups help to organize functionality of a system
in a sensible way. I always bind functionality to a group and then add
users to these groups. Such a pity, that posix does not offer a role
model, as well. This would make user und functionality management more
elegant even. This paragraph above makes me a little confused...
Yes, it does on small scales. 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.
You are not really suggesting that an X2go site administrator should
customize/tweak permissions on X2go /usr/bin files. This is really
dirty stuff and not an option to me...
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
On Sat, Feb 19, 2011 at 11:04:48 (CET), Mike Gabriel wrote:
You are not really suggesting that an X2go site administrator should customize/tweak permissions on X2go /usr/bin files. This is really dirty stuff and not an option to me...
Mike, meet dpkg-statoverride, dpkg-statoverride, meet mike:
http://debiananwenderhandbuch.de/stato.html http://man.he.net/man8/dpkg-statoverride http://www.debian.org/doc/debian-policy/ch-files.html
The 'whitelist' approach can be (properly!) restored with a one-line command, after all.
-- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4
Hi Moritz,
On Fr 18 Feb 2011 12:32:20 CET Moritz Struebe wrote:
Hi there,
we already talked to Alex, but maybe it's a good idea to ask a broader audience: Has anybody got an use case where someone who has ssh access is not allowed to start x2go?
Yes, I have such use cases. I use X2go for site administration mostly.
Thus, only the site admin is allowed to X2go to a machine. Other
people may use SSH, SFTP etc., but are not able to obtain a graphical
X2go session.
In short: We want to get rid of the sudo-entry and use suidperl instead.
This is for sqlite? With the new postgresql implementation there
should be not sudo any more, should it?
Greets, mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
-
Alexander Wuerstlein -
Gerry Reno -
Heinz-M. Graesing -
John A. Sullivan III -
Mike Gabriel -
Moritz Struebe -
Reinhard Tartler