Ask Slashdot: Ubuntu Lockdown Options?

First time accepted submitter clava writes "We have a desktop Java testing application that is going to be administering tests to students on lab computers running Ubuntu 10.x. These computers are used by the students for other purposes and we're not allowed to create special users or change the OS configuration. When the testing app is launched, we need to restrict users from exiting the app so they can't do things like search the internet for answers or use other applications. Is there a good way to put an Ubuntu machine in kiosk mode or something via our application and have exiting kiosk mode be password protected? Any ideas are appreciated."

Comments

Depends how locked-down

[Anonymous Coward]

I'm afraid if you want it actually locked-down, you're pretty screwed. You can't really disable things like switching to a tty with ctrl-alt-f1 without "changing the OS configuration."

Re:Depends how locked-down

[c 0xFF]

Disabling TTY switching is a pretty simple change, though, and won't affect the general use of the system.

In fact, you might as well use this to your advantage: start up a new X server instance, but don't start up the window manager. Run your java app in this server.

Now all a student can do is take the test -- there's no way to do anything besides take the test unless they can switch using ctrl-alt-F*, which has been disabled.

That's as near to a "kiosk mode" as I can figure.

Re:Depends how locked-down

[adamdoyle]

Or if you're feeling extra clever, you could straight up disable the keyboard and rely on the mouse for selecting answers. It would have to be enabled at the beginning for the user to enter his or her credentials, but then you could disable it during the actual test (there's no way to exit fullscreen with only a mouse), and then re-enable it upon completion. The site I linked to explains how to both enable and disable the entire keyboard programmatically. The linked site produces a shell script... In Java, you could run that shell script with: Process.Start(@"./scriptname.sh").

Re:Depends how locked-down

[Culture20]

Problem is, Windows' lockdown depends on Windows users being idiots.

Not true. True kiosk mode exists in Windows world. Do some regedits and gedit.msc foo and you'll have replaced explorer.exe with your choice of program (so it's the only program that can run), auto-logged in your user and disabled most of the ctrl-alt-del functions. Lock the bios, boot only from HDD, and padlock the computer, and the end users will have to bring in a set of lockpicks and a live CD to do anything normal with the computer.

Re:Depends how locked-down

[Windowser]

Not sure about Ubuntu, but this is the way to do it in Debian :
Disable gdm
# update-rc.d -f gdm remove

modify /etc/rc.local, add these lines just before "exit 0"
** rc.local - BEGIN
su - username -c startx
reboot
** rc.local - END

add the file /home/username/.xsession
** .xsession - BEGIN
#!/bin/sh
/path/to/script/that/start/yourapp
** .xsession - END

make the .xsession executable
# chmod u+x /home/username/.xsession

Re:Depends how locked-down

[ksd1337]

Why not just edit the initrc and remove all the geTTYs that aren't for X?

Re:Depends how locked-down

[jrumney]

True kiosk mode exists in the Linux world too, just not with the restrictions that the submitter placed "no special user accounts or changes to the OS configuration" is a pretty big restriction, no matter what OS you are trying to do this on.

Re:Depends how locked-down

[Bert64]

Kiosk mode is actually much easier on Linux...
Instead of a full blown desktop environment, simply supply a minimal window manager (or none at all) and the desired application. Remove all unnecessary packages from the system, and ensure any area the user can write to is mounted noexec and gets automatically cleared each time the machine is used.

Boot from USB or CD-ROM?

[hawguy]

Create your own custom locked down kiosk boot image and require users to boot from that? Keep in mind that users might take the boot media home with them so they'll have a copy of the test app if you store it locally (as opposed to retrieving it from a website)

Here's an example:

http://jacob.steelsmith.org/content/ubuntu-kiosk-based-910

(I'm not vouching for this particular implementation, I just found it through a quick google search).

Re:Boot from USB or CD-ROM?

[phoenix_rizzen]

That's what we do. All our Linux stations boot off the network and use NFS mounts for everything. For government exams, teachers reboot the stations into "Exam Mode" which disables everything possible, launches a bare-bones X11 session with Firefox as the "WM", with all settings locked in, including an add-on that let's you specify a list of sites that are accessible, blocking access to everything else.

Took a few iterations to get the configuration locked down completely, but there's really no better way to find the holes than watch a class of students try to break it. :)

It's not bullet-proof, but we've made it hard enough that it's very obvious when a student is trying to break out of the box that anyone watching the lab will notice. :)

If you can't change the OS config, you can't lock it down.

LiveCD?

[grahamsaa]

Not sure how hard this would be to do, but it seems like it would be fairly easy to boot from a livecd/usb key. If you remove packages you don't want the end user to have access to (it's hard to browse the web for test answers if there's no browser installed) that should address at least some of your concerns. An added bonus is that if you need to repurpose the machine, or if it doesn't need to be in test mode all the time, a simple reboot could restore it to a vanilla version of the OS.

Google???

[muphin]

did you even google your question?
http://lmgtfy.com/?q=ubuntu+lockdown

maybe this will help you
http://ubuntuforums.org/showthread.php?t=456549
http://users.telenet.be/mydotcom/howto/linuxkiosk/ubuntu01.htm
http://library.gnome.org/admin/system-admin-guide/stable/menustructure-13.html.en

Re:Chortle!

[wierd_w]

Or simply don't expose it to the internet.

Or, if it really needs to talk to the internet for some very special reason, put it behind a very configurable gateway.

Block all traffic types except port 80 http, and then restrict which ip addresses inbound packets can come from. Tada. Can't use google. Instant 404 error.

This won't stop them from playing uhrkan masters using the .deb they smuggled in, assuming they have the user rights to install. (Failing that they could smuggle in a binary blob version) but it would help prevent cheating.

What I had always considered to be ideal for a kiosk system where you don't want users pwning your workstations is to use a minimalist boot kernel on a usb stick, have the workstation tftp a system image to ram, then boot that.

This would make maintenance as easy as turning the system off, and on again, and would centralize maintenance of the system image.

Initial bootup network activity would spike with all the clients pulling the ramdisk volumes, but you could make the actual kiosk as naked as you wanted that way. No internal hdd to hide stuff on, no optical drive, and only 1 usb port that needs the key inserted because it is the boot volume.

If you go a bit further, and make sure the ctrl alt f1 seq can't be pressed at the hardware level from the kiosk, even better.

Re:Why?

[Anonymous Coward]

As an EMT, it's rarely the "patching up" that requires reference - after all, cardiology can be explained thusly - "air goes in and out; blood goes round and round; variations are bad."

The trickier aspect is typically pharmacology - drugs people have been prescribed, known toxicity manifestations, drug interactions (polypharmacy and drug potentiation are a crapshoot when most of the public fails to understand that "diabetes" and "the sugar" are the same disorder and that, no, you cannot double a dose to make up for a missed dose...). Resources like Epocrates and others are utterly invaluable for assisting in patient care. Common drugs or those with recognizable etymologies are readily identifiable; it's typically niche drugs and worrying about interactions that create the biggest problem.

Does that mean the EMT is dependent upon the cellular connection? Negative. However, the EMT - and therefore the patient - substantially benefits when additional information is readily available in a portable, user-friendly package.

Someone asked this on StackOverflow a while back

[KeithIrwin]

Someone asked a very similar question on Stack Overflow. It's here. The short version is: if you're running KDE and can change the window manager configuration, no problem. If you can change which window manager, then sure. (Also, the previous "yank the ethernet cable" or "boot off of live CD/USB" suggestions are quite reasonable. However, it is possible to handle most of it in the application using JNI to write X-Windows code which will capture most all keystrokes. It doesn't get ctrl-alt-backspace, but it appears to get prevent most of the rest.

Re:Requires things he said he couldn't do

[jrumney]

Furthermore in Ubuntu, you can't just kill the current X session and start a new one from the command line with the application as the window manager.

Why not?

sudo service gdm stop; Xorg -sp security.policy & kiosk-mode-test-program

Probably if you spend more than the two seconds I did thinking about this you can find a more robust version perhaps involving a custom gdm configuration that can restart the X server if the user logs out prematurely etc.