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

Wed Feb 6 17:47:36 UTC 2013

This whole conversation is really about policy, or the lack there of on 
LINUX desktops/servers.

I am having a discussion about that right now with RedHat's Benjamin Adler.

Nothing so far to report other than the fact there is lack of control.

Although that is not really a bad thing per se, you could write a shell 
to do what you are asking.

But, to the point:

Allow policy group control over a workstations

1) Applications and Desktop/Preferably KDE.
2) Authentication of groups based on two factor authentication 
(Biometric or RSA key).
3) Enforced policy control of network access per workstation such as 
VPN, ports and EGRES/INGRES the group has access to.
4) Enforced policy control of storage access per workstation the group 
has access to.

So policy based on what a login session can and cannot do isn't 
technically a problem if you can write your own shell, it is a problem 
if you can't because a login shell does is at the heart of the policy 
questions here I think, with perhaps a dash of network policy as well.

So even the big guys don't have a real answer to a Linux desktop 
management system that approaches anything like SCCM for example on the 
Microsoft side.

Just in case you are wondering.

-gc

On 02/06/2013 08:02 AM, chris at ccburton.com wrote:
> 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.
>>
>>
>
>
> ________________________________________________________________
>       Were you helped on this list with your FreeNX problem?
>      Then please write up the solution in the FreeNX Wiki/FAQ:
>
> http://openfacts2.berlios.de/wikien/index.php/BerliosProject:FreeNX_-_FAQ
>
>           Don't forget to check the NX Knowledge Base:
>                   http://www.nomachine.com/kb/
>
> ________________________________________________________________
>         FreeNX-kNX mailing list --- FreeNX-kNX at kde.org
>        https://mail.kde.org/mailman/listinfo/freenx-knx
> ________________________________________________________________