Re: [X2go-dev] concept for X2go session lock-down to kiosk-mode (was Re: X2go is insecure)
Hi list,
Reading all comments on my stone in the pond I still think it is not really clear what the problem is (and my proposed solution)
I do not want to secure the entire server. I only want a door that can be locked. So I allow a user to use the terminal. Okay he is allowed to use the terminal and so he can do anything he likes. No problem.
Or I say on the server the user may only use program XYZ. XYZ starts and that is all. If XYZ deletes my system that is Okay by me. The user had access to that program and that is it.
This can be enforced by my simple solution. From the client a command is sent, say "Start terminal". Then in the wrapper, the user is matched with the command and if the match exists, the command is allowed and is executed. If not, the request is rejected.
Maybe this can be achieved also by apparmor, but it looks to me that apparmor is intended to secure the entire system which is really not what I want. (Or maybe I am mistaken because of lack of knowledge of apparmor)
Dick Kniep
-----Oorspronkelijk bericht----- Van: Mike Gabriel <mike.gabriel@das-netzwerkteam.de> Verzonden: wo 30-03-11 20:22:45 Aan: x2go-dev@lists.berlios.de; Dick Kniep <dick.kniep@lindix.nl>; Onderwerp: Re: [X2go-dev] concept for X2go session lock-down to kiosk-mode (was Re: X2go is insecure)
Hi Dick,
On Mi 30 Mär 2011 18:46:49 CEST Dick Kniep wrote:
We have developed the wrapper that does exactly what I describe here. Currently it is lacking a screen where an authorized user can change the authorization db, but that will come on short notice.
I hope it is a little clearer now what the problem is and how it can be solved.
What I have been thinking the last day is that it might be much more generic and by far more effective to use the apparmor tool for this kind of lock-down. However, I have never played with apparmor, only in cases when the rules package maintainers had included in their packages were too strict...
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...
Hi list,
Reading all comments on my stone in the pond I still think it is not really clear what the problem is (and my proposed solution)
I do not want to secure the entire server. I only want a door that can be locked. So I allow a user to use the terminal. Okay he is allowed to use the terminal and so he can do anything he likes. No problem.
Or I say on the server the user may only use program XYZ. XYZ starts and that is all. If XYZ deletes my system that is Okay by me. The user had access to that program and that is it.
This can be enforced by my simple solution. From the client a command is sent, say "Start terminal". Then in the wrapper, the user is matched with the command and if the match exists, the command is allowed and is executed. If not, the request is rejected.
Maybe this can be achieved also by apparmor, but it looks to me that apparmor is intended to secure the entire system which is really not what I want. (Or maybe I am mistaken because of lack of knowledge of apparmor) <snip> Again I confess that I've not taken a lot of time to digest this issue but, I wonder if the back and forth is cause because for some users,
On Fri, 2011-04-01 at 02:44 +0200, Dick Kniep wrote: this would be a highly desirable feature whereas, for others, it not only makes no sense but would be a significant obstacle. Can it be built as a configurable option that can be enabled with a setting in x2go.conf (or whatever file we are using for configuration)? - John
Hi,
On Thu, Mar 31, 2011 at 08:55:40PM -0400, John A. Sullivan III wrote:
On Fri, 2011-04-01 at 02:44 +0200, Dick Kniep wrote:
I do not want to secure the entire server. I only want a door that can be locked. So I allow a user to use the terminal. Okay he is allowed to use the terminal and so he can do anything he likes. No problem. [...] This can be enforced by my simple solution. From the client a command is sent, say "Start terminal". Then in the wrapper, the user is matched with the command and if the match exists, the command is allowed and is executed. If not, the request is rejected.
X2Go uses SSH for remote connections, as a result SSH needs to be restricted [on a per user basis] to allow [some subcommands of] X2Go only. In this case X2Go must not allow opening a shell.
Maybe this can be achieved also by apparmor, but it looks to me that apparmor is intended to secure the entire system which is really not what I want. (Or maybe I am mistaken because of lack of knowledge of apparmor)
I don't see how apparmor can be used to do this, but then I have not yet tried it. AFAIUI apparmor is used to confine a single application. Confining sshd this way for every user would remove the usual remote administration access.
Again I confess that I've not taken a lot of time to digest this issue but, I wonder if the back and forth is cause because for some users, this would be a highly desirable feature whereas, for others, it not only makes no sense but would be a significant obstacle. Can it be built as a configurable option that can be enabled with a setting in x2go.conf (or whatever file we are using for configuration)? - John
The application confined by apparmor must not be allowed to have any influence on apparmor, because apparmor shall confine cracked applications. So X2Go must not be allowed any say in the applicability of an apparmor profile.
On Thu, Mar 31, 2011 at 09:57:18PM -0400, Gerry Reno wrote:
It looks like you want an "authorization" solution. And that is what functionality like "sudo" is meant for. You make your users members of a certain group and then give that group rights to only specific executables. If they try to execute anything else, the command will fail.
AFAIUI Dick does not want to elevate access rights, which can be done using sudo, but further restrict the SSH (secure shell) access. The latter can be done by allowing just one (or a few) command(s) via the authorized_keys file of SSH. If some wrapper script shall be used, care must be taken to introduce no new holes.
It could be worth to investigate giving the x2go users a restricted shell (e.g. rbash).
Regards, Erik
Dipl.-Inform. Erik Auerswald http://www.fg-networking.de/ auerswald@fg-networking.de Tel: +49-631-4149988-0 Fax: +49-631-4149988-9
Gesellschaft für Fundamental Generic Networking mbH Geschäftsführung: Volker Bauer, Jörg Mayer Gerichtsstand: Amtsgericht Kaiserslautern - HRB: 3630
On 03/31/2011 08:44 PM, Dick Kniep wrote:
Hi list,
Reading all comments on my stone in the pond I still think it is not really clear what the problem is (and my proposed solution)
I do not want to secure the entire server. I only want a door that can be locked. So I allow a user to use the terminal. Okay he is allowed to use the terminal and so he can do anything he likes. No problem.
Or I say on the server the user may only use program XYZ. XYZ starts and that is all. If XYZ deletes my system that is Okay by me. The user had access to that program and that is it.
This can be enforced by my simple solution. From the client a command is sent, say "Start terminal". Then in the wrapper, the user is matched with the command and if the match exists, the command is allowed and is executed. If not, the request is rejected.
Maybe this can be achieved also by apparmor, but it looks to me that apparmor is intended to secure the entire system which is really not what I want. (Or maybe I am mistaken because of lack of knowledge of apparmor)
Dick Kniep
It looks like you want an "authorization" solution. And that is what functionality like "sudo" is meant for. You make your users members of a certain group and then give that group rights to only specific executables. If they try to execute anything else, the command will fail.
Regards, Gerry
On 11-04-01 04:58, Gerry Reno <greno@verizon.net> wrote:
On 03/31/2011 08:44 PM, Dick Kniep wrote:
Hi list,
Reading all comments on my stone in the pond I still think it is not really clear what the problem is (and my proposed solution)
I do not want to secure the entire server. I only want a door that can be locked. So I allow a user to use the terminal. Okay he is allowed to use the terminal and so he can do anything he likes. No problem.
What you want and need is something similar to scponly[0] as a shell for all users that should be restricted in that way. That way you ensure security by starting with a restricted set of commands and allowing stuff instead of starting with an "allow all" policy that a normal shell is, applying some usually broken kind of filtering and then allowing stuff again.
Or I say on the server the user may only use program XYZ. XYZ starts and that is all. If XYZ deletes my system that is Okay by me. The user had access to that program and that is it.
This can be enforced by my simple solution. From the client a command is sent, say "Start terminal". Then in the wrapper, the user is matched with the command and if the match exists, the command is allowed and is executed. If not, the request is rejected.
Maybe this can be achieved also by apparmor, but it looks to me that apparmor is intended to secure the entire system which is really not what I want. (Or maybe I am mistaken because of lack of knowledge of apparmor)
I don't think this could be achieved by apparmor. You could try SELinux and I'm sure something working and secure will come out, but its very complex. Imagine the original SSH process (i think you can configure that with pam_selinux) setting a restricted security context that only allows to execute a very restricted set of commands to set up an x2go session (i.e. label all those commands executable for that security context, but not anything else). That x2go session setup then needs the capability to elevate its security context to something more permissive such that a normal application could do its job. But since quite a handful of x2go is written in shell or perl, you will also need to allow those for the restricted security context while ensuring that the user can't do anything out of line. Could work, but its very hard and complex to achieve.
It looks like you want an "authorization" solution. And that is what functionality like "sudo" is meant for. You make your users members of a certain group and then give that group rights to only specific executables. If they try to execute anything else, the command will fail.
How would you do that? sudo is not a generic authorization solution that magically forbids you from executing anything, sudo allows you to change your uid or gid in special circumstances. That may be used as an authorization solution in case that user has some special rights. But last I checked, a system where the contents of /usr/bin is not a+rx doesn't really work without a major amount of pain...
Ciao,
Alexander Wuerstlein.
Hi Alex, hi Dick,
On Fr 01 Apr 2011 10:07:15 CEST Alexander Wuerstlein wrote:
Maybe this can be achieved also by apparmor, but it looks to me that apparmor is intended to secure the entire system which is really not what I want. (Or maybe I am mistaken because of lack of knowledge of apparmor)
I don't think this could be achieved by apparmor. You could try SELinux and I'm sure something working and secure will come out, but its very complex. Imagine the original SSH process (i think you can configure that with pam_selinux) setting a restricted security context that only allows to execute a very restricted set of commands to set up an x2go session (i.e. label all those commands executable for that security context, but not anything else). That x2go session setup then needs the capability to elevate its security context to something more permissive such that a normal application could do its job. But since quite a handful of x2go is written in shell or perl, you will also need to allow those for the restricted security context while ensuring that the user can't do anything out of line. Could work, but its very hard and complex to achieve.
Sorry, I mixed both systems up. I want to refer to SELinux... I
haven't work with any of them, and only know them from reading.
However, I think the time being invested by someone in a wrapper
script (->Dick...) it could be an alternative option to invest time
into SELinux investigation and a generic configuration that hardens
the security of an X2go server...
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...
Hi Mike,
On Fri, Apr 01, 2011 at 10:31:51AM +0200, Mike Gabriel wrote:
Sorry, I mixed both systems up. I want to refer to SELinux... I haven't work with any of them, and only know them from reading. However, I think the time being invested by someone in a wrapper script (->Dick...) it could be an alternative option to invest time into SELinux investigation and a generic configuration that hardens the security of an X2go server...
Well, a generic SELinux (or apparmor) config should allow user level access to the whole system, it might constrain root access. If root access is not allowed through X2Go, some other remote management solution needs to be used. If only X2Go sessions are affected, SSH will still work. Anyway, using something like X2Go for remote management (e.g. to access some GUI configuration tools) seems to me to be a valid use case of X2Go.
Mike, I don't want to discourage you from investigating the SELinux/apparmor/SMACK/TOMOYO/... way of increasing X2Go security, I just don't think it is the right approach for Dick's use case. Dedicated X2Go user accounts with a forced (wrapper) command (via authorized_keys) seems to be a better fit IMHO.
Regards, Erik
Dipl.-Inform. Erik Auerswald http://www.fg-networking.de/ auerswald@fg-networking.de Tel: +49-631-4149988-0 Fax: +49-631-4149988-9
Gesellschaft für Fundamental Generic Networking mbH Geschäftsführung: Volker Bauer, Jörg Mayer Gerichtsstand: Amtsgericht Kaiserslautern - HRB: 3630
-
Alexander Wuerstlein -
Dick Kniep -
Erik Auerswald -
Gerry Reno -
John A. Sullivan III -
Mike Gabriel