Hi there,
Here is a feature request proposal for the post-Baikal release (Rebun):
The handshake on session start should be extended in the following way:
o login as user o call a script x2gofeatures (or similar) o this script replies with some file format that states - user may / must not start an X2go session - user may / must not start in rootless/desktop mode - available commands to execute (KDE, TERMINAL, /usr/bin/xterm...) - user may / must not print - user may / must not use audio - ... o the client should obey to this returned list of features o if the user tries to hack some feature that he/she is not allowed to use, the server of course also has to deny this feature (and maybe even the whole session)
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,
to make this reasonable there must be ways to actually enforce this. Currently a little tweaking of the client will allow you to circumvent any of these rules: Start x2goagent "manually" - the db is only convenience, desktop-mode is client-related only, you can patch the client to start any command you wish, audio is only a matter of setting the right environment variables, etc. Basically x2go is just an optimized x-forwarding. So doing rights-control on this level would be to block the main road and leave the side roads open. While this might be enough for a lot of scenarios it might also let administrators think, that there rules are actually enforced. All in all it would be just as safe as doing all the rights-management in the client.... The right way of doing this, would be to the learn about Linux system administration and use the sufficient tools already provided to you (e.g. ACLs). Everything else creates false feeling of security.
Cheers Morty
Am 19.03.2011 17:11, Mike Gabriel schrieb:
Hi there,
Here is a feature request proposal for the post-Baikal release (Rebun):
The handshake on session start should be extended in the following way:
o login as user o call a script x2gofeatures (or similar) o this script replies with some file format that states - user may / must not start an X2go session - user may / must not start in rootless/desktop mode - available commands to execute (KDE, TERMINAL, /usr/bin/xterm...) - user may / must not print - user may / must not use audio - ... o the client should obey to this returned list of features o if the user tries to hack some feature that he/she is not allowed to use, the server of course also has to deny this feature (and maybe even the whole session)
Greets, Mike
X2go-dev mailing list X2go-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
Hi Morty,
On Sa 19 Mär 2011 19:09:52 CET Moritz Strübe wrote:
Hi Mike,
to make this reasonable there must be ways to actually enforce this. Currently a little tweaking of the client will allow you to circumvent any of these rules: Start x2goagent "manually" - the db is only convenience, desktop-mode is client-related only, you can patch the client to start any command you wish, audio is only a matter of setting the right environment variables, etc. Basically x2go is just an optimized x-forwarding. So doing rights-control on this level would be to block the main road and leave the side roads open. While this might be enough for a lot of scenarios it might also let administrators think, that there rules are actually enforced. All in all it would be just as safe as doing all the rights-management in the client.... The right way of doing this, would be to the learn about Linux system administration and use the sufficient tools already provided to you (e.g. ACLs). Everything else creates false feeling of security.
What exactly are you aiming at? Best way to control apps on a Linux
host (X2go server) is the apparmor framework. Are you thinking of this?
BTW: I am also looking forward to the gsecurity patch that will be
part some way ahead future Debian kernels:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605090
(With grsecurity amongst others you can hide processes from the ps aux
list and restrict the list of processes to those owned by the user...)
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 2011-03-20 16:01, Mike Gabriel wrote:
The right way of doing this, would be to the learn about Linux system administration and use the sufficient tools already provided to you (e.g. ACLs). Everything else creates false feeling of security.
What exactly are you aiming at?
I am aiming at x2go-client/server being the wrong place to do rights management. IMO if someone tires to start an x2go session, who is not allowed to do so, should fail starting the server and get a notice of this. I don't see any reason for handshaking, unless this has something to do with x2go. And IMO rights management isn't.
But that's my opinion.
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
Hi Morty,
On Mo 21 Mär 2011 08:52:04 CET Moritz Struebe wrote:
On 2011-03-20 16:01, Mike Gabriel wrote:
The right way of doing this, would be to the learn about Linux system administration and use the sufficient tools already provided to you (e.g. ACLs). Everything else creates false feeling of security.
What exactly are you aiming at?
I am aiming at x2go-client/server being the wrong place to do rights management. IMO if someone tires to start an x2go session, who is not allowed to do so, should fail starting the server and get a notice of this. I don't see any reason for handshaking, unless this has something to do with x2go. And IMO rights management isn't.
But that's my opinion.
I share your opinion. So there are two parts of such a feature...
- control management through the available posix etc. mechanisms
- a script x2gofeatures, that can tell the client what is allowed and what not: if the server can tell the client what's possible and what not the session start up will be much faster compared to stumbling over a couple of session errors during session handshakes
Would apparmor be one way to go? Do you already have a clearer idea
how you would tighten up a system?
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 2011-03-21 09:44, Mike Gabriel wrote:
I share your opinion. So there are two parts of such a feature...
- control management through the available posix etc. mechanisms
- a script x2gofeatures, that can tell the client what is allowed and what not: if the server can tell the client what's possible and what not the session start up will be much faster compared to stumbling over a couple of session errors during session handshakes
Would apparmor be one way to go? Do you already have a clearer idea how you would tighten up a system?
I personally don't see a reason why I shouldn't give some ssh-access and disallow him to run x2go / sound, etc. For most of the stuff ACLs seem the way to go. For sound I have no idea how you want to keep someone from connecting to a server of his choosing - unless you jump through some hoops. Again I don't see why you want to keep someone from using sound anyway..... I also don't see why this should speed things up. If someone connects according to the "rules" there should be no delay and if he doesn't - we'll then only the one who is trying to use those features is to blame.... If again you want a preconfigured client which give the user a certain number of preconfigured options (e.g. start App1, App4 or App8) this is something completely different. But this is a matter of usability not security..... (Or security by convenience.... )
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
Hi Morty,
On Mo 21 Mär 2011 10:31:58 CET Moritz Struebe wrote:
On 2011-03-21 09:44, Mike Gabriel wrote:
I share your opinion. So there are two parts of such a feature...
- control management through the available posix etc. mechanisms
- a script x2gofeatures, that can tell the client what is allowed and what not: if the server can tell the client what's possible and what not the session start up will be much faster compared to stumbling over a couple of session errors during session handshakes
Would apparmor be one way to go? Do you already have a clearer idea how you would tighten up a system?
I personally don't see a reason why I shouldn't give some ssh-access and disallow him to run x2go / sound, etc.
This was discussed before on this list and there are use cases that
demand SSH access, but no x2go startup permission. So we should try to
be compliant to these wishes within the community, I think.
For most of the stuff ACLs seem the way to go.
You mean filesystem ACLs here? The normal user, group, others triple
or the extACL feature? I am still not clear about this.
For sound I have no idea how you want to keep someone from connecting to a server of his choosing - unless you jump through some hoops. Again I don't see why you want to keep someone from using sound anyway.....
I guess you cannot really forbid audio, you could only try to make it
as hard as possible to get sound from the server (refuse copying the
pulse-cookie, not setting the PULSE_CLIENTCONFIG variable etc.).
A use case for no-audio could for performance reasons...
I also don't see why this should speed things up. If someone connects according to the "rules" there should be no delay and if he doesn't - we'll then only the one who is trying to use those features is to blame....
Ok, I partially agree on this... However, an x2gofeatures call could
help the client to sort out proper errors/warnings that could be send
to the user as GUI message boxes etc. So this would not be for
security, but for an enhancement of usability...
If again you want a preconfigured client which give the user a certain number of preconfigured options (e.g. start App1, App4 or App8) this is something completely different. But this is a matter of usability not security..... (Or security by convenience.... )
For PyHoca-GUI I plan something I will call embedded menus. The menus
will be generated on the server and shown with the menu structure of
PyHoca-GUI. For this I need to be able to query the server about
applications to offer to the user. This will not be for security (with
an xterm the user could startup any command available on the server),
but for usability.
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 2011-03-21 09:44, Mike Gabriel wrote:
I share your opinion. So there are two parts of such a feature...
- control management through the available posix etc. mechanisms
- a script x2gofeatures, that can tell the client what is allowed and what not: if the server can tell the client what's possible and what not the session start up will be much faster compared to stumbling over a couple of session errors during session handshakes
Would apparmor be one way to go? Do you already have a clearer idea how you would tighten up a system?
I personally don't see a reason why I shouldn't give some ssh-access and disallow him to run x2go / sound, etc. For most of the stuff ACLs seem the way to go. For sound I have no idea how you want to keep someone from connecting to a server of his choosing - unless you jump through some hoops. Again I don't see why you want to keep someone from using sound anyway..... Performance in a WAN environment comes immediately to mind. One may also have restrictions about noise in the work place but, if that were
On Mon, 2011-03-21 at 10:31 +0100, Moritz Struebe wrote: the case, one would probably disable the sound devices on the physical computer - then again, some other user may have a use case where it legitimately makes sense to conform to noise restrictions by configuring the X2Go server - John <snip>
On 2011-03-21 14:27, John A. Sullivan III wrote:
Performance in a WAN environment comes immediately to mind.
Seriously? You must disable flash, vlc or any other video-support, too. Oh and don't forget Opera, Chrome, etc, which repaint the screen every time you scroll..... (BTW: FF is doing it right....) You can easily limit bandwidth per user. Then the user can decide between responsibility and sound.
One may also have restrictions about noise in the work place but, if that were the case, one would probably disable the sound devices on the physical computer
ACK!
- then again, some other user may have a use case where it legitimately makes sense to conform to noise restrictions by configuring the X2Go server - John
No you are generating absurd use-cases. One shouldn't have to use x2go to enforce this. And then again the right way of doing this is to forbid remote pulse-audio connections locally!
I have the feeling that these requests are not to support x2go, but to be able to enforce a business-model (For sound you have to pay 10 bucks extra). But what do I care, as long as this is optional and having such a handshake is optional......
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 2011-03-21 14:27, John A. Sullivan III wrote:
Performance in a WAN environment comes immediately to mind.
Seriously? You must disable flash, vlc or any other video-support, too. Oh and don't forget Opera, Chrome, etc, which repaint the screen every time you scroll..... (BTW: FF is doing it right....) You can easily limit bandwidth per user. Then the user can decide between responsibility and sound.
One may also have restrictions about noise in the work place but, if that were the case, one would probably disable the sound devices on the physical computer
ACK!
- then again, some other user may have a use case where it legitimately makes sense to conform to noise restrictions by configuring the X2Go server - John
No you are generating absurd use-cases. One shouldn't have to use x2go to enforce this. And then again the right way of doing this is to forbid remote pulse-audio connections locally!
I have the feeling that these requests are not to support x2go, but to be able to enforce a business-model (For sound you have to pay 10 bucks extra). But what do I care, as long as this is optional and having such a handshake is optional...... <snip> Sorry, I disagree but that is a choice of development paradigm. Take my advice from whence it comes - I know very little about development and
On Mon, 2011-03-21 at 14:38 +0100, Moritz Struebe wrote: the costs associated with it but I do know about managing the end user side. To say the user can decide assumes it is a user decision on one-off installations for savvy users with no central administration. Now, there may be better ways to disable the transmission of sound than via X2Go but, in my limited development experience, I've always tried to admit that I may not be able to foresee every possible plausible user case and thus try to provide more rather than fewer options.
These are not absurd user cases and they are not fostered by a business model (in fact, I really didn't appreciate that comment but I may have taken it the wrong way). They are fostered by real world working experiences where sound may be undesirable. Again, there are probably better ways to do this than via X2Go as I mentioned in my original comment but I cannot foresee all cases and there may be a time when it is better to handle it from X2Go. Thanks - John
----- Original Message -----
On 2011-03-21 14:27, John A. Sullivan III wrote:
Performance in a WAN environment comes immediately to mind.
Seriously? You must disable flash, vlc or any other video-support, too. Oh and don't forget Opera, Chrome, etc, which repaint the screen every time you scroll..... (BTW: FF is doing it right....) You can easily limit bandwidth per user. Then the user can decide between responsibility and sound.
One may also have restrictions about noise in the work place but, if that were the case, one would probably disable the sound devices on the physical computer
ACK!
- then again, some other user may have a use case where it legitimately makes sense to conform to noise restrictions by configuring the X2Go server - John
No you are generating absurd use-cases. One shouldn't have to use x2go to enforce this. And then again the right way of doing this is to forbid remote pulse-audio connections locally!
I have the feeling that these requests are not to support x2go, but to be able to enforce a business-model (For sound you have to pay 10 bucks extra). But what do I care, as long as this is optional and having such a handshake is optional...... <snip> Sorry, I disagree but that is a choice of development paradigm. Take my advice from whence it comes - I know very little about development and
On Mon, 2011-03-21 at 14:38 +0100, Moritz Struebe wrote: the costs associated with it but I do know about managing the end user side. To say the user can decide assumes it is a user decision on one-off installations for savvy users with no central administration. Now, there may be better ways to disable the transmission of sound than via X2Go but, in my limited development experience, I've always tried to admit that I may not be able to foresee every possible plausible user case and thus try to provide more rather than fewer options.
These are not absurd user cases and they are not fostered by a business model (in fact, I really didn't appreciate that comment but I may have taken it the wrong way). They are fostered by real world working experiences where sound may be undesirable. Again, there are probably better ways to do this than via X2Go as I mentioned in my original comment but I cannot foresee all cases and there may be a time when it is better to handle it from X2Go. Thanks - John
IIRC Citrix is able to define by policy whether a user signing is allowed sound or not ... Perhaps they have got their user cases wrong as-well ;)
Hi John, hi Morty,
On Mo 21 Mär 2011 15:30:55 CET "John A. Sullivan III" wrote:
On Mon, 2011-03-21 at 14:38 +0100, Moritz Struebe wrote:
On 2011-03-21 14:27, John A. Sullivan III wrote:
Performance in a WAN environment comes immediately to mind.
Seriously? You must disable flash, vlc or any other video-support, too. Oh and don't forget Opera, Chrome, etc, which repaint the screen every time you scroll..... (BTW: FF is doing it right....) You can easily limit bandwidth per user. Then the user can decide between responsibility and sound.
One may also have restrictions about noise in the work place but, if that were the case, one would probably disable the sound devices on the physical computer
ACK!
- then again, some other user may have a use case where it legitimately makes sense to conform to noise restrictions by configuring the X2Go server - John
No you are generating absurd use-cases. One shouldn't have to use x2go to enforce this. And then again the right way of doing this is to forbid remote pulse-audio connections locally!
I have the feeling that these requests are not to support x2go, but to be able to enforce a business-model (For sound you have to pay 10 bucks extra). But what do I care, as long as this is optional and having such a handshake is optional......
<snip> Sorry, I disagree but that is a choice of development paradigm. Take my advice from whence it comes - I know very little about development and the costs associated with it but I do know about managing the end user side. To say the user can decide assumes it is a user decision on one-off installations for savvy users with no central administration. Now, there may be better ways to disable the transmission of sound than via X2Go but, in my limited development experience, I've always tried to admit that I may not be able to foresee every possible plausible user case and thus try to provide more rather than fewer options.
These are not absurd user cases and they are not fostered by a business model (in fact, I really didn't appreciate that comment but I may have taken it the wrong way). They are fostered by real world working experiences where sound may be undesirable. Again, there are probably better ways to do this than via X2Go as I mentioned in my original comment but I cannot foresee all cases and there may be a time when it is better to handle it from X2Go. Thanks - John
I'd also like to see rather more than less features and quite an
amount of flexibility in X2go.
I think X2go is a piece of software that can have many different use
cases and none is less worth than another. We should make sure that we
- as developers - work in such a generic way that we meet requirements
of a broad mass of people. If we need a very special feature for our
own use case, let's find abstraction layers to make the code as
generic and flexible as possible...
That is: A ,,No - we (personally) do not need this feature'' should
not end up in: ,,No - we will not include this feature''.
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 2011-03-21 22:27, Mike Gabriel wrote:
That is: A ,,No - we (personally) do not need this feature'' should not end up in: ,,No - we will not include this feature''.
I do agree here. None the less the sudo-discussion taught me, that pseudo-security-features seem to preferred over real security.... :) - And the features listed seemed to target that way. But someone has to code them first, before they can be added, I I don't care as long as they don't do harm.
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
Hi Morty,
On Di 22 Mär 2011 08:29:22 CET Moritz Struebe wrote:
On 2011-03-21 22:27, Mike Gabriel wrote:
That is: A ,,No - we (personally) do not need this feature'' should not end up in: ,,No - we will not include this feature''.
I do agree here. None the less the sudo-discussion taught me, that pseudo-security-features seem to preferred over real security.... :) - And the features listed seemed to target that way. But someone has to code them first, before they can be added, I I don't care as long as they don't do harm.
Ah, now I start getting your worries. Of course, real security comes
first, then usability.
An x2gofeatures script will also be useful once X2go has evolved and
found an alternative to NX. Then an x2gofeatures script could also let
the client know which technology to use etc. Furthermore it should
also tell the client quickly, what server version is running.
I will keep this in the back of my mind and might come up with a code
proposal 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...
-
--[ UxBoD ]-- -
John A. Sullivan III -
Mike Gabriel -
Moritz Struebe -
Moritz Strübe