Roadmap for finishing the basic implementation of student-control-panel


To control LTSP connections in a school environment, an application that interacts with the ltsp server and the clients is needed. An initial implementation of this application tailored for the Ubuntu LTSP implementation called student-control-panel was uploaded to dapper. It currently implements basic connection control: it shows a list of the users and the ip each client they are using, allows the administrator to cut the connection for one, more or all users, and can show the currently running processes of a single user. The current scope is to control a standalone LTSP server, in case we start to implement clustering and the like, a network aware backend has to be implemented in a future version of student control panel.

More features are needed to provide a full student control application for school environments.

Use cases

Dr. Miller teaches biology in an ltsp equipped class. He has several students he suspects to secretly browse the web while he is not looking. Using student-control-panel he can monitor the students desktops via vnc to see if his suspicion is true.

Miriam teaches about free software in a class that uses a ltsp setup. She wants to demonstrate several free software apps she wants to start up on all students desktops. She hits ctrl-a to select all students in student-control-panel and clicks on the execute button which brings up a dialog to execute a command on all selected desktop simultaneously.

Anselmo has one student he doesn't want to be able to access the commandline from his desktop, since this specific student is known to write harmful scripts. Anselmo right clicks on the student's name in student-control-panel and selects the lock down option there. Pessulus, the gnome lockdown editor pops up and Anselmo checks the "Disable Commandline" checkbox.


Easy handling of student LTSP connections on a single LTSP server.

Design and Implementation

Killing processes

Remote desktop access

Execution of programs in the users session(s)

The GUI of Student Control Panel is started through gksudo and has a check if it runs under UID 0 to be able to manage the ssh sessions, have write access for password creation of vnc passwords in the client chroot etc. This enables usto talk to the system dbus which is only accessible through ACLs in the services file. A Student Control Panel listener service file with the namespace 'com.ubuntu.StudentControlPanel' will be installed in /usr/share/dbus-1/service.d/ which will listen for messages from Student Control Panel. A second listener in the users session will pick up messages from this system service and execute the requested applications in the users sessions if the user is appearing in the com.ubuntu.StudentControlPanel.Comm.List message. DBUS has ACL based security built in to not accept any messages except from SCP via the service namespace and the default AUTH mechanism. explains details about the internally used authentication mechanism and message handling of dbus. See also the system dbus configuration /etc/dbus-1/system.conf (for the system specific settings) and the dbus-daemon(1) manpage for further information on dbus access control.

A services file example with access control:

<!DOCTYPE busconfig PUBLIC
 "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"

  <!-- Only root can own the SCP service -->
  <policy user="root">
    <allow own="com.ubuntu.StudentControlPanel"/>

  <!-- Allow anyone to recieve the messages we send -->
  <policy context="default">
    <allow receive_interface="com.ubuntu.StudentControlPanel.Comm"

  <!-- define who is allowed to send command messages -->
  <policy user="0">
    <allow send_interface="com.ubuntu.StudentControlPanel.Comm.List"/>
    <allow send_interface="com.ubuntu.StudentControlPanel.Comm.Exec"/>
    <allow send_interface="com.ubuntu.StudentControlPanel.Comm.Kill"/>
    <allow send_interface="com.ubuntu.StudentControlPanel.Comm.Notify"/>

The com.ubuntu.StudentControlPanel namespace will know the following messages:

list <list> - the list of users for which the message applies (picked up automatically from the UI selection)
exec <path> - ececutes the given path
kill <PID> - kills the given PID
notify <string> - sends a notification message to the notification daemon in the user session with the attached string

The notification service is ignored for now, but will be helpful in further implementations of the student control panel.

Execution of an application will be done the following way:

* SCP sends list message to the system dbus (the ACL controls only SCP can do that)
* The session script picks it up from there and verifies the message comes from the SCP namespace and verifies $USER is in the list
* SCP sends exec message to the system bus
* The session script, notified through the matching list message, picks up the exec message with the DATA (program to execute)
* The session script executes what it found in the DATA that was trasferred (i.e. /usr/bin/firefox)

This is a simple and elegant solution and security wise way better than the the xhost/DISPLAY variant all other similar tools use nowadays.

Lockdown on the fly


Outstanding issues


StudentControlPanelCompletion (last edited 2008-08-06 16:27:07 by localhost)