[X2go-dev] concept for X2go session lock-down to kiosk-mode (was Re: X2go is insecure)

[Alexander Wuerstlein]

On 11-04-01 04:58, Gerry Reno <greno at 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.

[0] http://sublimation.org/scponly/wiki/index.php/Main_Page