Hey folks,
I've been toying around with x2go a bit, and I'm really liking it.
From what I've seen, the overall architecture is cleaner than freenx and even neatx. Certainly none of that insanity of netcat's and fdcopy's.
I was a rather disturbed by the x2goserver package adding a line in my sudoers file to allow anyone in the x2gousers group to run x2gopgwrapper as root. I checked out that script and the three scripts it can potentially call, x2gopgwrapper_{local,net,sqlite}. Other than the _net script I see no reason why root access is required. All these scripts do is access a database and run queries. The _net script as written probably needs root access, but there's no reason why with some permission adjustments on the postgres database server that it can't run unprivileged as well.
As I'm just using sqlite on a single system, I did a little experiment and made some changes to run that script as an unprivileged user.
I created an unprivileged x2go user with no password: (The defaults with this particular invocation of useradd are adequate, but the account can be restricted some more) useradd -r x2go
So the sudoers entry becomes: #### X2GO section %x2gousers ALL=(x2go) NOPASSWD: /usr/bin/x2gopgwrapper
Then permissions on the sqlite database need changing so our x2go user can run its queries: cd /var/db sudo chown -R x2go.x2go x2go
Finally, the scripts in /usr/bin need to be changed so that x2gopgwrapper runs at x2go: for i in x2go*; do sed -ibak -e 's/sudo x2gopgwrapper/sudo -u x2go x2gopgwrapper/' $i; done
I made these changes on my system and have not had any issues connecting. I am only using the x2goserver package at the moment; it's just this one script that gets executed as root, I don't know about any of the other packages.
There's also the matter of the x2gocleansessions cleanup script... There's a couple of sudo calls in there as well, I didn't change that just yet as I've just disabled it altogether to prevent the spam it sends to my syslog.
I apologize if this topic has been brought up before or is discussed in the documentation someplace; I looked around and didn't see anything. I simply bring this up in the interest of system security. The fewer things that run as root the better.
The changes I describe above are my quick hack-n-fix. If I get a chance in the next few days I can throw together a proper fix and submit a patch. (And please add my vote to the yes-please git repository crowd.)
X2go seems to have a lot of possibilities and potential. Thanks to Heinz and Alex for their hard work.
^_^ rob
On Sat, 2010-10-02 at 01:52 -0700, Rob Lemley wrote:
Hey folks,
I've been toying around with x2go a bit, and I'm really liking it. From what I've seen, the overall architecture is cleaner than freenx and even neatx. Certainly none of that insanity of netcat's and fdcopy's.
I was a rather disturbed by the x2goserver package adding a line in my sudoers file to allow anyone in the x2gousers group to run x2gopgwrapper as root. I checked out that script and the three scripts it can potentially call, x2gopgwrapper_{local,net,sqlite}. Other than the _net script I see no reason why root access is required. All these scripts do is access a database and run queries. The _net script as written probably needs root access, but there's no reason why with some permission adjustments on the postgres database server that it can't run unprivileged as well.
As I'm just using sqlite on a single system, I did a little experiment and made some changes to run that script as an unprivileged user.
I created an unprivileged x2go user with no password: (The defaults with this particular invocation of useradd are adequate, but the account can be restricted some more) useradd -r x2go
So the sudoers entry becomes: #### X2GO section %x2gousers ALL=(x2go) NOPASSWD: /usr/bin/x2gopgwrapper
Then permissions on the sqlite database need changing so our x2go user can run its queries: cd /var/db sudo chown -R x2go.x2go x2go
Finally, the scripts in /usr/bin need to be changed so that x2gopgwrapper runs at x2go: for i in x2go*; do sed -ibak -e 's/sudo x2gopgwrapper/sudo -u x2go x2gopgwrapper/' $i; done
I made these changes on my system and have not had any issues connecting. I am only using the x2goserver package at the moment; it's just this one script that gets executed as root, I don't know about any of the other packages.
There's also the matter of the x2gocleansessions cleanup script... There's a couple of sudo calls in there as well, I didn't change that just yet as I've just disabled it altogether to prevent the spam it sends to my syslog.
I apologize if this topic has been brought up before or is discussed in the documentation someplace; I looked around and didn't see anything. I simply bring this up in the interest of system security. The fewer things that run as root the better.
The changes I describe above are my quick hack-n-fix. If I get a chance in the next few days I can throw together a proper fix and submit a patch. (And please add my vote to the yes-please git repository crowd.)
X2go seems to have a lot of possibilities and potential. Thanks to Heinz and Alex for their hard work. <snip> Hi, Rob. I'm on a getaway with the family and "sneaking" this in so I may be remembering the details incorrectly :)
You may want to trace all the other scripts which are invoked as part of the process, especially x2gomount_sessions and x2goumount_sessions. These may need root access - I'm not sure - John
Hey John,
I double-triple checked again, and tried a session myself that mounted my desktop with my changes. No issues.
The only script that gets called with sudo is x2gopgwrapper. It's the only script that can get called as it's the only entry added to the sudoers file.
x2gopgwrapper calls one of x2pgwrapper_local, x2pgwrapper_sqlite, or x2pgwrapper_net. That's all it does. Those scripts are a giant case blocks that only runs sql queries against a database. In the case of sqlite you need to assume the id of the sqlite database file owner. (I thought about making the file group-writable, but chose not to go that direction. With the sudoers entry and the script there's some level of protection from average-joe user mangling the database.) As for postgres, it's the same idea. It can authenticate by userid with the right entry in pg_hba.conf (?? right filename??)
The mounting and unmounting seems to be done through fuse so the only privilege needed is to be a member of the fuse group. The x2gocleansessions process started by init will unmount a fuse mounted directory if it finds a stale session, but that is running as root so there's no issue there.
Enjoy the rest of your getaway!
-rob
<snip> On Sat, Oct 2, 2010 at 9:56 AM, John A. Sullivan III <jsullivan@opensourcedevel.com> wrote:
<snip> Hi, Rob. I'm on a getaway with the family and "sneaking" this in so I may be remembering the details incorrectly :)
You may want to trace all the other scripts which are invoked as part of the process, especially x2gomount_sessions and x2goumount_sessions. These may need root access - I'm not sure - John
Hey John,
Hello Rob, list
In multi-user environment session informations of all users are stored in one data base table. If we granting access to this table for all users, each user will be able to view or change data of other users, that's unacceptable. Using sudo we can give access for user only to his own data. It's simplest way we have found to protect data of other users. In postgresql we could use views, but not all DBMS have such mechanisms. We cannot although create single table for every user, because all users should know which DISPLAYs/ports are currently in use by other users.
Rob you are right. The user which execute sql queries not necessarily should be root. As you can see, in x2gopgwrapper.local all queries are executed with user postgres. We could make same changes in x2gopgwrapper_local and x2gopgwrapper_net, but wee need to add a new user into a system (as user "x2go" in your example). Unfortunately since x2goserver version 3_0.1-9 (http://x2go.obviously-nice.de/deb/pool-heuler/x2goserver/) there is one more reason to run x2gopgwrapper as root. Running with argument "startshadowagent" x2gopgwrapper should start x2gostartagent as user which desktop will be displayed. I don't see the simple way to do this without root privileges.
Rob Lemley schrieb:
Hey John,
I double-triple checked again, and tried a session myself that mounted my desktop with my changes. No issues.
The only script that gets called with sudo is x2gopgwrapper. It's the only script that can get called as it's the only entry added to the sudoers file.
x2gopgwrapper calls one of x2pgwrapper_local, x2pgwrapper_sqlite, or x2pgwrapper_net. That's all it does. Those scripts are a giant case blocks that only runs sql queries against a database. In the case of sqlite you need to assume the id of the sqlite database file owner. (I thought about making the file group-writable, but chose not to go that direction. With the sudoers entry and the script there's some level of protection from average-joe user mangling the database.) As for postgres, it's the same idea. It can authenticate by userid with the right entry in pg_hba.conf (?? right filename??)
The mounting and unmounting seems to be done through fuse so the only privilege needed is to be a member of the fuse group. The x2gocleansessions process started by init will unmount a fuse mounted directory if it finds a stale session, but that is running as root so there's no issue there.
Enjoy the rest of your getaway!
-rob
<snip> On Sat, Oct 2, 2010 at 9:56 AM, John A. Sullivan III <jsullivan@opensourcedevel.com> wrote:
<snip> Hi, Rob. I'm on a getaway with the family and "sneaking" this in so I may be remembering the details incorrectly :)
You may want to trace all the other scripts which are invoked as part of the process, especially x2gomount_sessions and x2goumount_sessions. These may need root access - I'm not sure - John
Hey John,
X2go-dev mailing list X2go-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
-- Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
Hello Oleksandr,
Please understand that I am trying to offer constructive criticism. Any time I see something that runs as root, I try to figure out why, and if possible run it as a non-privileged user. From a sysadmin point of view, I would much prefer that a piece of software that I install create a new user on my system than allow any user to run a script as root.
I see what you mean with the shadow sessions. May I suggest a second wrapper script for cases like this?
User permissions and security are rarely simple, and safeguards can quickly overwhelm the original scope of the situation. Sometimes all we can do is minimize the risk/exposure, and that is all I am looking to do here.
Thank you for your hard work on x2go.
-rob
On Tue, Oct 5, 2010 at 12:37 AM, Oleksandr Shneyder <oleksandr.shneyder@obviously-nice.de> wrote:
Hello Rob, list
In multi-user environment session informations of all users are stored in one data base table. If we granting access to this table for all users, each user will be able to view or change data of other users, that's unacceptable. Using sudo we can give access for user only to his own data. It's simplest way we have found to protect data of other users. In postgresql we could use views, but not all DBMS have such mechanisms. We cannot although create single table for every user, because all users should know which DISPLAYs/ports are currently in use by other users.
Rob you are right. The user which execute sql queries not necessarily should be root. As you can see, in x2gopgwrapper.local all queries are executed with user postgres. We could make same changes in x2gopgwrapper_local and x2gopgwrapper_net, but wee need to add a new user into a system (as user "x2go" in your example). Unfortunately since x2goserver version 3_0.1-9 (http://x2go.obviously-nice.de/deb/pool-heuler/x2goserver/) there is one more reason to run x2gopgwrapper as root. Running with argument "startshadowagent" x2gopgwrapper should start x2gostartagent as user which desktop will be displayed. I don't see the simple way to do this without root privileges.
Rob Lemley schrieb:
Hey John,
I double-triple checked again, and tried a session myself that mounted my desktop with my changes. No issues.
The only script that gets called with sudo is x2gopgwrapper. It's the only script that can get called as it's the only entry added to the sudoers file.
x2gopgwrapper calls one of x2pgwrapper_local, x2pgwrapper_sqlite, or x2pgwrapper_net. That's all it does. Those scripts are a giant case blocks that only runs sql queries against a database. In the case of sqlite you need to assume the id of the sqlite database file owner. (I thought about making the file group-writable, but chose not to go that direction. With the sudoers entry and the script there's some level of protection from average-joe user mangling the database.) As for postgres, it's the same idea. It can authenticate by userid with the right entry in pg_hba.conf (?? right filename??)
The mounting and unmounting seems to be done through fuse so the only privilege needed is to be a member of the fuse group. The x2gocleansessions process started by init will unmount a fuse mounted directory if it finds a stale session, but that is running as root so there's no issue there.
Enjoy the rest of your getaway!
-rob
<snip> On Sat, Oct 2, 2010 at 9:56 AM, John A. Sullivan III <jsullivan@opensourcedevel.com> wrote:
<snip> Hi, Rob. I'm on a getaway with the family and "sneaking" this in so I may be remembering the details incorrectly :)
You may want to trace all the other scripts which are invoked as part of the process, especially x2gomount_sessions and x2goumount_sessions. These may need root access - I'm not sure - John
Hey John,
X2go-dev mailing list X2go-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
-- Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
X2go-dev mailing list X2go-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
Rob Lemley schrieb:
Hello Oleksandr,
Please understand that I am trying to offer constructive criticism. Any time I see something that runs as root, I try to figure out why, and if possible run it as a non-privileged user. From a sysadmin point of view, I would much prefer that a piece of software that I install create a new user on my system than allow any user to run a script as root.
I see what you mean with the shadow sessions. May I suggest a second wrapper script for cases like this?
I understand what you mean. It seems to be a good idea. I'll think about it.
User permissions and security are rarely simple, and safeguards can quickly overwhelm the original scope of the situation. Sometimes all we can do is minimize the risk/exposure, and that is all I am looking to do here.
Thank you for your hard work on x2go.
-rob
-- Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
On Tue, 2010-10-05 at 09:37 +0200, Oleksandr Shneyder wrote:
Hello Rob, list
In multi-user environment session informations of all users are stored in one data base table. If we granting access to this table for all users, each user will be able to view or change data of other users, that's unacceptable. Using sudo we can give access for user only to his own data. It's simplest way we have found to protect data of other users. In postgresql we could use views, but not all DBMS have such mechanisms. We cannot although create single table for every user, because all users should know which DISPLAYs/ports are currently in use by other users.
Rob you are right. The user which execute sql queries not necessarily should be root. As you can see, in x2gopgwrapper.local all queries are executed with user postgres. We could make same changes in x2gopgwrapper_local and x2gopgwrapper_net, but wee need to add a new user into a system (as user "x2go" in your example). Unfortunately since x2goserver version 3_0.1-9 (http://x2go.obviously-nice.de/deb/pool-heuler/x2goserver/) there is one more reason to run x2gopgwrapper as root. Running with argument "startshadowagent" x2gopgwrapper should start x2gostartagent as user which desktop will be displayed. I don't see the simple way to do this without root privileges. <snip> We were quite uncomfortable running as the postgres user in our environment. We altered the scripts so that they used schemas instead. Each user can see only their schema within the single PostgreSQL database. We then created a separate table to sessions with the information needed to be held in common. That was visible to postgres and we used triggers to synchronize the common table with the individual schemas. Finally, we moved all functionality which needed the postgres and root users to the x2gocleansessions daemon so that users have very restricted access to the database and the underling system. I don't know if those changes would be portable to your system - John
-
John A. Sullivan III -
Oleksandr Shneyder -
Rob Lemley