Raspian Jessie - how to lock down the desktop

[kristiaan_d]

Hi Everyone, I have a requirement to lock down the user desktop of a vanilla Jessie image so that users cannot right click, add / customise menus etc and set the system so that only one app runs when launched into the desktop. and the user in question is not able to have root access.

However whilst I am fairly confident in a CLI based interface, I've never delved into GUI work (99% of things I've done are server based so no GUI).

I've found that its using LDXE for the desktop interface, but can't seem to find any useful info on how to customise this interface to stop certain things being shown, or how I can get it to launch my own app etc. I can switch bits off by removing them in the right click menu etc, but this is not suitable as the user could just add them back if they wished.

also what is startx and how can I configure it to only run an app that I specify?

any advice on this would be really useful as I am starting to feel a little lost here.

[peterlite]

Are you setting up a separate user? Guest? There is info about creating a locked down guest user in:
http://raspberrypi.stackexchange.com/qu ... d-features

[gkreidl]

You don't have to use the desktop at all. You just need XORG and a window manager. Create a small file in the root of your user directory:

Code: Select all

#!/bin/sh
openbox --config-file ~/.config/openbox/rc.xml --startup myapp

Save it as mystarter and make it executable. From the command line start it with

Code: Select all

xinit ./mystarter

[kristiaan_d]

Are you setting up a separate user? Guest? There is info about creating a locked down guest user in:<br abp="646">http://raspberrypi.stackexchange.com/qu ... d-features

Hi Peter thank you for the information on locking down the Pi, I'm going to have a look at this to see what I can apply to my installation and how far I can go locking it down.

You don't have to use the desktop at all. You just need XORG and a window manager. Create a small file in the root of your user directory:<br abp="624">

Code: Select all

#!/bin/sh<br abp="625">openbox --config-file ~/.config/openbox/rc.xml --startup myapp<br abp="626">

<br abp="627">Save it as mystarter and make it executable. From the command line start it with<br abp="628">

Code: Select all

xinit ./mystarter

This is pretty much perfect for what I am looking to-do, the only minor change I had to make is the reference to the rc.xml file.

I could not find a file with the rc.xml name in the referenced location rather the only file I could find was lxde-pi-rc.xml so opted to try this configuration file instead. I've not had any specific errors when running with the config file mentioned so can only presume its either ignoring the file and taking defaults or its had no issue and is using it quite happily.

Thank you both very much for your input its been very useful and fixed my problem perfectly.

[gkreidl]

Maybe the rc.xml file is missing on new installations. It has been the settings file for openbox with default LXDE before the Foundation added its modifications.

I prefer a settings file which does not depend on the settings used by the modifications.
obconf has also been removed from the latest Raspbian image which can be used to create your own settings for OpenBox.

[peterlite]

@gkreidl, in your configuration, how does the administrator access the system to apply security updates?

[gkreidl]

@gkreidl, in your configuration, how does the administrator access the system to apply security updates?

What do you mean by "my configuration"?

You can always run
sudo apt-get update && upgrade, either from a terminal or connected via SSH.

[peterlite]

Oops, I misread the setup as automatically starting when you boot the system. I was thinking of kiosks where a power outage leads to an automatic boot into the locked down system so that visitors cannot bypass security by switching the power off then on.

[gkreidl]

Oops, I misread the setup as automatically starting when you boot the system. I was thinking of kiosks where a power outage leads to an automatic boot into the locked down system so that visitors cannot bypass security by switching the power off then on.

This is possible, of course. I have helped in the past to set up such kiosk systems, in a German school, for example, where pupils can use 3 kiosks to order their meals for lunch. It had to be prevented from being used to surf the web, play games etc. by all means.

[kristiaan_d]

Oops, I misread the setup as automatically starting when you boot the system. I was thinking of kiosks where a power outage leads to an automatic boot into the locked down system so that visitors cannot bypass security by switching the power off then on.

In our situation we have control of the images and look at keeping one master image that boots to the command prompt, this allows us to test / update the image etc. before its pushed to the general user population we reconfigure the image so that it automatically boots into the xinit interface.

Testing is then carried out to make sure the image does what we expect and users cannot get a root prompt, at this point the SD card is duplicated and rolled out to our users.

you can still get ssh access to each system remotely but we only really use this to debug crashes, reboot stuck systems etc.

[hello world :-)]

Maybe the rc.xml file is missing on new installations. It has been the settings file for openbox with default LXDE before the Foundation added its modifications.

I prefer a settings file which does not depend on the settings used by the modifications.
obconf has also been removed from the latest Raspbian image which can be used to create your own settings for OpenBox.

Code: Select all

apt-get install obconf

(slow clap).

[peterlite]

@ kristiaan_d, thank you for the explanation of what you do. It is similar to what I do for some projects before updating the system just in case the update breaks the configuration. With the low cost of an SD card, it makes sense to keep multiple copies.

[peterlite]

Thinking about a slightly different use case. Give the user a computer they can use to browse the Internet, Skype, whatever. Also allow the administrator full access via remote desktop. I would do this with multiple users.

Give the local user an automatic login to the restricted guest user. Start vnc for one admin session and another session to view the user's session. I followed some tutorials that ended up not working unless you logged in locally. Then I found a tutorial that put start up info in /etc/rc.local. rc.local appears to run before a user is started. Using x11vnc and rc.local, I could start vnc for administrator remote access without waiting for a user session.

I suspect this could be used to start a second session for the guest login. You could then watch what they do and work out ways to stop them doing whatever you do not want them doing. Or you could just watch them log in to their bank account.

rc.local looks like a useful script.

[vunthao]

Thank you for your great post, I'm looking to setup something similar. I'm a newbie when it comes to raspberry pi and was wondering if you could share the steps to set it up?