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