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...