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.