Ubuntu Wiki

Figure out how to easily manage student's access to applications, printers and files:

Description: As a teacher one of our primary responsibilities is to manage student behavior. This is accomplished through everything we do, not only our curriculum and our choice of classroom activities, but also things like the physical layout of the classroom, what we have posted on the walls, the way we interact and feel about our students, our limit setting procedures i.e. how we handle accountability to classroom rules, and etc. It is this last parameter that management software can support.

Procedure:

• Earning privileges
  • A common way of bringing a new person into a community is by giving them an initial set of limited privileges, and as the person shows themselves to be a responsible member of that community limits are removed i.e. privileges increased. In the classroom this could take the form of managing 4 sets of group privileges and then assigning students to these groups. After a certain amount of time, say a week, that students have demonstrated respect for the classroom computer norms they would move to the next level. However, if they broke that trust, their level number tumbles back to level 1 and they start over...

    • Level 1 group allows a student to login to their account, explore the computer's possibilities in such a way that nothing can be damaged either out of ignorance nor malice. you it also allows for using a limited set of applications such as, Open Office and CmapTools running under local account, not using the Internet CmapServers.

    • Level 2 group allows a student to also access a limited set of interactive sites on the Internet as well as the ability to go to some sites such as Wikipedia. Printing on the network might also be enabled for this group. Allowing students to customize their desktop background image from a limited set of choices would be great, here.
    • Level 3 group would open up the internet to all sites as well as allow students to choose their own image for their desktop background.
    • Level 4 group would allow students to also play any game on the computer (for those community-earned 'fun time' events)

Ideas for group management Several are from this blog post. They are copied from there and so the "I" refers to the noted author.

v1

Sabayon is an excellent candidate but has a few, show-stopper bugs.

v2

Edubuntu-menus is also a great possibility, but their isn't a GUI for it yet, and also a person can right-click and access the ability to open a file with programs that one doesn't want accessed at a certain level.

v3

Andreas Olsson Regarding an application whitelist.--What about doing the same as with devices? Setting the permission on certain binaries in such a way that the user has to be part of a specific group to have permissions to execute them? 14 Jan 09 at 5:44 am

v4

Ciarán 14 Jan 09 at 6:07 am --Implementing the variable-white list, could be as easy as creating different levels of user account. A deamon process keeps track of certain measurable quantities, and when a pupil reaches a certain threshold, their username is added to the user list of the next “user level”. Allowing them access to Firefox. I suppose it’s a more granular version of “sudoers”.

v5

Frank 14 Jan 09 at 5:45 pm--Why not just create a group “firefox” and chown firefox:firefox the firefox binary?

v6

Jordan Mantha 14 Jan 09 at 6:16 pm--@Andreas and Frank: Yes, we could do limited whitelisting by changing the permissions but I don’t like the idea of mass editing system-installed binaries. What about doing it via PATH?

v7

Frank 14 Jan 09 at 7:10 pm--You’re not “mass editing binaries”, you’re just changing ownership. The downside with this method is that it may break when firefox is updated. The upside is that you only have to write a script to set ownership “once”, and rerun the script occasionally.

@changing the $PATH Probably the same amount of work, but it seems like you’re using a flathead for a philipshead problem. The downside of this is that you have to manage the path for each group of students seperately. And the PATH, for a single student, changes as they gain privs. So more repeat work (make a number of template .bashrc files). A student can change their $PATH back to whatever they want, whenever they want, so it probably won’t last to long if they’re over 10yrs old.

If you’re already in the .bashrc, you might as well just alias firefox=ls. It is just as secure as the PATH solution and doesn’t futz with anything important.

Jordan Mantha 14 Jan 09 at 8:25 pm--@Frank: Right, I didn’t mean actually editing the binaries themselves, but the permissions, I should have been more clear there. And I think you’re right with the “flathead for a philipshead problem” comment. I’m just nervous about changing system-wide files.

v8

Vance 14 Jan 09 at 9:21 pm--Speaking on the infrastructure level, this could be done via access control lists (ACLs). I believe these are supported in Ubuntu, although there are difficulties when trying to apply ACLs across networked file systems (this is a generic problem, not a Linux- or Ubuntu-specific problem).

Administering ACLs can get complex, so you’d probably want a friendlier interface to the basic tools. But this might give you a place to start looking…

v9

Andreas Olsson 15 Jan 09 at 12:17 am--If I were to build a solution I guess I’d roughly do something like the following:

First (manually) create a list of the binaries you intend to restrict and which groups to match them against. It might be a good idea to put this information in a database. If you don’t already run a full database server then sqlite might be a good option

Have your script read the list of intended groups, check if they already exist and if not, create them. I guess it’s more fitting to create system groups then user groups.

Scan your list of files for the current/original set of permissions and ownership. This information might be useful to save in your database, for future restores.

Set the new ownerships. I guess $orginaluser:$newgroup and 750 should do fine

(By the way, watch out for setuid binaries and other special cases. Actually it might be best to make sure you leave them alone, just to be on the safe side.)

Bonus: Implement the option to restore restore the original permissions and ownerships. Might just come in handy.

It’s of course possible to do all this manually. That said, in the long run you’ll probably be grateful to yourself if you from the start take the time to write a proper (perl) script.

Actually, this is not necessarily the way I would do it. If I were to actually implement it myself I’d most likely give it some more thought. This is just the first idea which comes to mind. Still, could be a good one

Jordan Mantha 15 Jan 09 at 12:28 am--@Andreas: I was talking with David this evening on IRC about doing just about that. Good tip on suid binaries. I’d personally like to wrap it up into a Python GUI to make it easier for teachers to use.

Andreas Olsson 15 Jan 09 at 12:38 am--@Jordan: Yes, a Python GUI sounds like a good idea if it’s intended for a more general use. Feel free to drop me an e-mail if you’d like any help testing the solution or such.

v10

Edmundo Carmona 15 Jan 09 at 6:09 am--Use a group (like in /etc/group) for each application that needs control access. Say: a firefox group for firefox, another group for amarok (for the sake of the example) and so on. Then, set the applications to belong to that group, set the permissions so that only that group can execute it and then add/remove the users of the students to the groups as they gain/lose that right. That should pull it off.

Bryan 16 Jan 09 at 5:21 am--I think that creating separate groups for controlled applications is the best way to control access to applications. This is completely out of the control of the users, yet simple to administrate after it is set up. You simply go to the user control app and add or remove groups to users’ lists.

v11

James 16 Jan 09 at 11:14 am--I think the following would work for an application whitelist. If you make a firefox group and set the firefox binary to be owned by root and assigned the group firefox, and set the permissions accordingly, a student belonging to the firefox group could use it, and vice versa. E.g. (say /usr/bin/firefox-bin is the binary)

groupadd firefox chmod root:firefox /usr/bin/firefox-bin chmod 0750 /usr/bin/firefox-bin # rwxr-x—

Then you would do usermod -a firefox to allow firefox use.

Disallowing firefox use would be a rather more complicated operation. A command which would work would be

usermod -G id -nG | perl -pe ’s/firefox ?//; s/ /, /g;’

Disclaimer: you might want to check all that.

James 16 Jan 09 at 11:16 am Edit to the above. Should read:

usermod -a firefox username

and

usermod -G id -nG username | perl -pe ’s/firefox ?//; s/ /, /g;’ username

I orginally put username between chevrons.

v12

From response to a question posted on edubuntu-users list: Roger--Edubuntu includes two menu editors (gmenu-simple-editor and alacarte); both need to be locked down. Setting their permissions to 0700 works for me!

v13

v14

v15

Summaries

CategoryEdubuntu