Hello to all,
Published application, nice feature, huge potential...
As I see, the list of published applications, is a link to "/usr/share/applications".
Is there a way to so a published applications per user/group. Each group of users should see different "published applications"
Is the a way to configure x2oserver to accept only "published applications" without any desktop environment ?
Thank you, Vasilica Petcu
Am 19.04.2012 14:33, schrieb Vasilica Petcu:
As I see, the list of published applications, is a link to "/usr/share/applications".
That's the default, you may change it to a directory of your choice.
- Is there a way to so a published applications per user/group. Each group of users should see different "published applications"
I haven't tried it, but it should work by setting file ownership and permissions accordingly and adding the users to different groups.
- Is the a way to configure x2oserver to accept only "published applications" without any desktop environment ?
The easiest way would be to uninstall the DE on the server. ;-) Of course, that may have unwanted side effects for your particular use case.
-Stefan
On 2012 4 19 14:37, "Stefan Baur" <newsgroups.mail2@stefanbaur.de> wrote:
<snip>
- Is the a way to configure x2oserver to accept only "published applications" without any desktop environment ?
The easiest way would be to uninstall the DE on the server. ;-) Of course, that may have unwanted side effects for your particular use case.
Maybe an implementation like the nxacl in FreeNX?
Regards, Terje
Am 19.04.2012 16:16, schrieb Terje Andersen:
On 2012 4 19 14:37, "Stefan Baur" <newsgroups.mail2@stefanbaur.de <mailto:newsgroups.mail2@stefanbaur.de>> wrote:
<snip>
- Is the a way to configure x2oserver to accept only "published applications" without any desktop environment ?
The easiest way would be to uninstall the DE on the server. ;-) Of course, that may have unwanted side effects for your particular use case.
Maybe an implementation like the nxacl in FreeNX?
"Those who don't understand Unix are condemned to reinvent it, poorly." (Henry Spencer)
http://en.wikipedia.org/wiki/Extended_file_attributes#Linux are available on ext2 and newer.
See http://www.techrepublic.com/article/learn-to-use-extended-filesystem-acls/60... or google for <nameofyourfilesystem> extended acl
-Stefan
Hi,
On Do 19 Apr 2012 16:16:09 CEST Terje Andersen wrote:
Maybe an implementation like the nxacl in FreeNX?
Regards, Terje
my vote would rather be using SELinux or AppArmor. I already made an
approach on pseudo-ACLs within X2Go, but this would give
pseudo-security.
Using SELinux/AppArmor is the far more generic approach.
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 2012 4 19 19:54, "Mike Gabriel" <mike.gabriel@das-netzwerkteam.de> wrote:
Hi,
On Do 19 Apr 2012 16:16:09 CEST Terje Andersen wrote:
Maybe an implementation like the nxacl in FreeNX?
Regards, Terje
my vote would rather be using SELinux or AppArmor. I already made an
approach on pseudo-ACLs within X2Go, but this would give pseudo-security.
Using SELinux/AppArmor is the far more generic approach.
Based on the different feedbacks on my proposal, I guess you where mislead by the part 'acl'. The nxacl is a rather misunderstood thing (in my view) that actually are quite great for sysadmins, and others. It's more of a policy tool where one can set policies that are enforced on single users, groups or system as a whole. These policies can also, as an example, enforce settings like which desktop environment a particular group of users should have - regardless of what they set in their clients session configuration. This could also be used to restrict users to only being able to access published applications, if the administrator chooses to.
See here for more information, it's actually a near little feature which is worth a peek: http://openfacts2.berlios.de/wikien/index.php/BerliosProject:FreeNX_-_HowtoA...
This had nothing to do with filesystem permissions, or ACL. For those who have worked with Group Policies in Active Directory, or Policies in Citrix environments, this should be familiar functionality for you. Something like this would be of use in X2go also in my view, hence my suggestion.
Regards, Terje
Am 20.04.2012 01:26, schrieb Terje Andersen:
[...]
Based on the different feedbacks on my proposal, I guess you where mislead by the part 'acl'. The nxacl is a rather misunderstood thing (in my view) that actually are quite great for sysadmins, and others.
[much blah]
This had nothing to do with filesystem permissions, or ACL.
While "everything is a file" isn't as true on Linux as it is on "Plan 9", it is true enough for this case. Please, be so kind and explain to us why simply blocking access to a particular program via file system ACLs isn't good enough for you?
-Stefan
Am 20.04.2012 01:26, Terje Andersen schrieb:
This had nothing to do with filesystem permissions, or ACL. For those who have worked with Group Policies in Active Directory, or Policies in Citrix environments, this should be familiar functionality for you. Something like this would be of use in X2go also in my view, hence my suggestion.
Due to the way x2go works this would install pseudo-security. It was hard work getting rid of that in x2go and significantly improving the overall security in x2go by doing so. Therefore, if you see your suggestion as a way of distributing different configurations to different clients, it might be worth a second thought, as it saves one from having to mess with user rights when distributing. If you want to keep someone from running a certain application, this is the wrong way.
Cheers Morty
Am 20.04.2012 08:26, schrieb Moritz Strübe: [lots of true stuff about kludgy pseudo-security snipped]
Therefore, if you see your suggestion as a way of distributing different configurations to different clients, it might be worth a second thought, as it saves one from having to mess with user rights when distributing.
According to Mike, that's what $HOME/.x2go/applications is for, so we have that covered already.
-Stefan
Am 20.04.2012 08:29, Stefan Baur schrieb:
Therefore, if you see your suggestion as a way of distributing different configurations to different clients, it might be worth a second thought, as it saves one from having to mess with user rights when distributing.
According to Mike, that's what $HOME/.x2go/applications is for, so we have that covered already.
Nope, that folder is supposed to be in the user's power. You don't want to set symlinks in every home.
Cheers Morty
Den 20. april 2012 08:26, skrev Moritz Strübe:
Am 20.04.2012 01:26, Terje Andersen schrieb:
This had nothing to do with filesystem permissions, or ACL. For those who have worked with Group Policies in Active Directory, or Policies in Citrix environments, this should be familiar functionality for you. Something like this would be of use in X2go also in my view, hence my suggestion. Due to the way x2go works this would install pseudo-security. It was hard work getting rid of that in x2go and significantly improving the overall security in x2go by doing so. Therefore, if you see your suggestion as a way of distributing different configurations to different clients, it might be worth a second thought, as it saves one from having to mess with user rights when distributing. If you want to keep someone from running a certain application, this is the wrong way.
Hi Morty and list,
My suggestion was about enforcing configuration, yes.
I'm sorry that I didn't explain my point good enough in my previous email, but if you look at the page I linked to, you will hopefully see the value in something like the (wrongfully named) nxacl.
http://openfacts2.berlios.de/wikien/index.php/BerliosProject:FreeNX_-_HowtoA...
This is similar to what NoMachine calls User Profiles which consists of rules (in their terminology). http://www.nomachine.com/documents/admin-guide.php (chapter 8)
In my view, being able to enforce or restrict
- what kind of session the user(s)/group(s) should be able to access/use
- what kind of bandwidth (LAN/WAN/ADSL/dialup)
- printing for certain user(s)/group(s)/server(s)
- clipboard - only at server or client
- use of shared folders (for the x2go session)
- many more possibilities
... is valuable.
If it should be implemented, that's not for me to say (although I would love it if it was), it was a suggestion on how to solve this question:
"2) Is the a way to configure x2oserver to accept only "published applications" without any desktop environment ?"
Best regards, Terje
Am 20.04.2012 09:49, schrieb Terje Andersen:
- what kind of session the user(s)/group(s) should be able to access/use
And again, this can and should be solved by setting proper access rights in the file system.
- what kind of bandwidth (LAN/WAN/ADSL/dialup)
- printing for certain user(s)/group(s)/server(s)
- clipboard - only at server or client
- use of shared folders (for the x2go session)
These config options would indeed be nice on the server side, though I don't see them as a high priority, except for maybe clipboard and shared folders (by the way, shared folders and printing require the user to be a member of the fuse group, so again this can be managed already using existing mechanisms, though limited in the form that you can only enable/disable both at once). My preferred way of handling this would be using config files in a /etc/x2go/forcedconfig.d/ directory, where seperate files with either names or ownership/permissions matching the group/user you want to cover are stored. That way, it's all in the file system, just like it's supposed to be. ;-)
Also, the client should notify the user if a forced setting overrules something in his local setting. Otherwise, you're going to confuse the heck out of users and first level supporters when the settings don't match.
If you want to discuss this further, I'd suggest changing the title of the thread or creating a new one. :-)
-Stefan
Hi everyone,
Le 20/04/2012 10:06, Stefan Baur a écrit :
Am 20.04.2012 09:49, schrieb Terje Andersen:
- what kind of session the user(s)/group(s) should be able to access/use
And again, this can and should be solved by setting proper access rights in the file system.
one thing I am missing from nx is in fact the nxacl file. It allowed me to setup access rights depending no the source ip and login of users and time of the day. For example I have one group of user that can login from the internal network only, while another group of road warriors that can log both from local or remote location. It is very cumbersome to do at the ssh level, and the nxacl file was very handy to do this. Perhaps there is a way to reproduce this behavior in x2go, and sorry if I missed it.
On the file ACL point of view, I thing the apparmor/selinux/nameyourown framework way to be much more clean. I don't like much the idea to change ACL on programs because of maintainability, for example on software upgrade and all (and IMHO security needs maintainability), and I think a broader framework to be more suitable (no opinion on which one).
my 2 cents,
Cheers,
Denis
- what kind of bandwidth (LAN/WAN/ADSL/dialup)
- printing for certain user(s)/group(s)/server(s)
- clipboard - only at server or client
- use of shared folders (for the x2go session)
These config options would indeed be nice on the server side, though I don't see them as a high priority, except for maybe clipboard and shared folders (by the way, shared folders and printing require the user to be a member of the fuse group, so again this can be managed already using existing mechanisms, though limited in the form that you can only enable/disable both at once). My preferred way of handling this would be using config files in a /etc/x2go/forcedconfig.d/ directory, where seperate files with either names or ownership/permissions matching the group/user you want to cover are stored. That way, it's all in the file system, just like it's supposed to be. ;-)
Also, the client should notify the user if a forced setting overrules something in his local setting. Otherwise, you're going to confuse the heck out of users and first level supporters when the settings don't match.
If you want to discuss this further, I'd suggest changing the title of the thread or creating a new one. :-)
-Stefan
X2Go-Dev mailing list X2Go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
-- Denis Cardon Tranquil IT Systems 44 bvd des pas enchantés 44230 Saint Sébastien sur Loire tel : +33 (0) 2.40.97.57.57 http://www.tranquil-it-systems.fr
On 2012-04-20 10:52, Denis Cardon wrote:
one thing I am missing from nx is in fact the nxacl file. It allowed me to setup access rights depending no the source ip and login of users and time of the day. For example I have one group of user that can login from the internal network only, while another group of road warriors that can log both from local or remote location. It is very cumbersome to do at the ssh level, and the nxacl file was very handy to do this. Perhaps there is a way to reproduce this behavior in x2go, and sorry if I missed it.
On the file ACL point of view, I thing the apparmor/selinux/nameyourown framework way to be much more clean. I don't like much the idea to change ACL on programs because of maintainability, for example on software upgrade and all (and IMHO security needs maintainability), and I think a broader framework to be more suitable (no opinion on which one).
Again, due to the way x2go works it is not possible to enforce this. x2go is just a very efficient way of "ssh -X". If it wasn't for maintainability, we could even get rid of the sqlite database and start the x2go manually.
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
Am 20.04.2012 11:12, schrieb Moritz Struebe:
On 2012-04-20 10:52, Denis Cardon wrote:
one thing I am missing from nx is in fact the nxacl file. It allowed me to setup access rights depending no the source ip and login of users and time of the day. For example I have one group of user that can login from the internal network only, while another group of road warriors that can log both from local or remote location. It is very cumbersome to do at the ssh level, and the nxacl file was very handy to do this. Perhaps there is a way to reproduce this behavior in x2go, and sorry if I missed it.
On the file ACL point of view, I thing the apparmor/selinux/nameyourown framework way to be much more clean. I don't like much the idea to change ACL on programs because of maintainability, for example on software upgrade and all (and IMHO security needs maintainability), and I think a broader framework to be more suitable (no opinion on which one).
Again, due to the way x2go works it is not possible to enforce this. x2go is just a very efficient way of "ssh -X". If it wasn't for maintainability, we could even get rid of the sqlite database and start the x2go manually.
Morty
+1 The main idea of X2Go is to use existing UNIX tools for data transport, authentication, access control, etc. This is why we decided to develop X2Go and not to improve, for example, freenx.
Any Idea to provide something like nxacl will be refused.
Regards, Alex
Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
Hi Terje, hi all,
On Fr 20 Apr 2012 09:49:02 CEST Terje Andersen wrote:
In my view, being able to enforce or restrict
- what kind of session the user(s)/group(s) should be able to access/use
- what kind of bandwidth (LAN/WAN/ADSL/dialup)
- printing for certain user(s)/group(s)/server(s)
- clipboard - only at server or client
- use of shared folders (for the x2go session)
- many more possibilities
... is valuable.
this feature already exists. Unfortunately, not in public. It is
called X2Go Session Broker and only exists in customized site
configurations for paying customers.
I have been nagging Alex recently to join in with me in providing a
generic solution of the X2Go Session Broker, but that is music of the
future, still.
However, the session broker will deliver session configurations to the
X2Go Client. It will not restrict access to the X2Go Server itself. As
Morty says, everything you can do with ssh -X can theoretically done
with X2Go.
Hardening of your system has to be done with SELinux/AppArmor & co.
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,
On Do 19 Apr 2012 14:37:47 CEST Stefan Baur wrote:
Am 19.04.2012 14:33, schrieb Vasilica Petcu:
- Is there a way to so a published applications per user/group. Each group of users should see different "published applications"
It is possible to place .desktop files into $HOME/.x2go/applications.
- Is the a way to configure x2oserver to accept only "published applications" without any desktop environment ?
The easiest way would be to uninstall the DE on the server. ;-) Of course, that may have unwanted side effects for your particular use case.
Install a minimal system. Install X2Go server. Install you favourite applications (iceweasel, libreoffice, terminal).
No desktop environment involved.
Done. 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...
-
Denis Cardon -
Mike Gabriel -
Moritz Struebe -
Moritz Strübe
-
Oleksandr Shneyder -
Stefan Baur -
Terje Andersen -
Vasilica Petcu