[FreeNX-kNX] preventing data transfers over SSH, yet still allow NX sessions.

[chris at ccburton.com]

freenx-knx-bounces at kde.org wrote on 06/02/2013 06:49:35:

> Hello,
> 
> I have searched something to do that and i find !!
> 
> I use lshell to prevent all actions over ssh and in a shell, but allow 
> NX sessions.

Hmmmm

Sounds like a lot of work . . .
and
in the end not very well pinned down because lshell is
rather basic and not so difficult to get round 
unless
you very heavily restrict what the users can launch . . .


 
> If you want more informations, you're welcome.


Well . . . I'm interested anyway !!


What did you have to permit (in /etc/lshell.conf) 
to get it all to run??

. . . how did you get it to run:-

                 /usr/bin/nxnode

as a user . . . cos lshell doesn't much like paths-to-executables . . . 


You can just permit startkde/gnome and they run fine
but
when kde etc are running, how can you then stop
users launching /bin/bash ftp email etc (from within kde)

Lots of configuring there . . . 



lshell is a bit basic in operation.

It only filters on "command name"
        not the command's binary signature
                 like apparmor and SElinux . . .
eg,
Have you tried copying

        cp /bin/bash ~/bin/ls

then running ls from lshell ???


So without extra configuration
You have to
permenantly stop the users from
doing just about everything, including copying.


(NOTE
actually I don't allow any users write access
to any filesystem mounted with exec, so /home and
/var  ( /tmp -> /var/tmp ) are noexec here, which
stops a lot of that sort of thing . . . )






It is better not to run the combination:-

        sshd    with
        passwordauthentication yes
        port 22      (or any other port too preferably)
        ListenAddress "on a globally acessible IP"
                         127.0.0.1 only would be good


unless
        you restrict incoming ssh on originating IP
        you don't bother logging attempted connections
                else you don't mind huge log files full
                        of password brute force attacks,
                        one every 15 mins typical here
        you don't mind weak passwords being guessed.


So IMNSHO you really ought to fix that as a matter of
course,
by having only rsa/dsa visible from outside





Then looking at the OP's requrements

to stop people getting stuff off the server you have to
stop all outgoing sessions, regardless of how well you
think your restricted shell is doing, and even that doesn't
stop client screen prints.




And, as a point of policy

it is much better to properly configure the software you
are already running so it is as secure as you can
reasonably make it
 i.e.   no passwordauthentication

and
        no email, ftp etc out in this case
than
install more software, particularly
 e.g. lshell   which doesn't quite do it all

 


I'd be interested to see what you have done tho'
not being a restricted shell expert . . . 

> 
> Sincerely,
> 
> Jean
> 
> Jean Milot  - jmilot at dotriver.eu - www.dotriver.eu<
http://www.dotriver.eu/>
> 5 passage de l'avenir, F-69200 Vénissieux
> Fixe: +33 (0)4 27 46 39 80 Hotline: # 89  Fax: # 81
> 
> Renouvellement du label LVED pour DotRiver ( http://bit.ly/Rwv5F9 )
> Le BYOD est mort ! vive le KYED ( http://bit.ly/Qelwtz )
> DotRiver, membre du consortium "nuage-France" ( http://bit.ly/LNIfMr )
> 
> Pas à pas, agissons au quotidien pour préserver notre environnement.
> N'imprimez que si nécessaire, réduisez les déchets informatiques et 
> économisez l'énergie en utilisant les solutions DotRiver.
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/freenx-knx/attachments/20130206/9e40a589/attachment.html>