-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Note: I do not know enough about UNIX permissions to be sure that this document makes sense.
It is easy to implement the P_SF_CORE permission: simply add the user "olpc" to the group "wheel". This allows the user to work as "root" using the "su" and "sudo" commands. The root user may do absolutely anything, including write arbitrary bytes to almost anywhere in memory. This is good, because this is the intent of P_SF_CORE. (P_SF_CORE also grants permissions regarding the firmware; this may be treated independently.) One of the key difficulties of Bitfrost, however, is implementing the P_SF_RUN permission. P_SF_RUN grants the student permission to modify system files in an arbitrary way. However: 1. The student must not be able to stop the anti-theft daemon from functioning. 2. If there is a clean backup copy of the system files, the student must not be able to damage them. Abstractly, the goal of P_SF_RUN is to provide the student with the feeling of root access, without enabling theft of the machines, and without enabling students to render the machine inoperative, accidentally or otherwise. I use the phrase "feeling of root access" because it is important that P_SF_RUN provide the student the ability to modify the software system as freely as possible, and because it is not important that the student actually have uid 0. Currently, the OLPC OS includes two main users: root (uid 0) and olpc (uid 500). I believe P_SF_RUN may be safely implemented by introducing a third user: sfrun (uid 100). (The name "sfrun" is not intended to be final.) When running as sfrun, the student should feel as though they are running as root, but they should not be able to mess with things that will break the system irrevocably. Things sfrun can do: 1. Create a directory anywhere 2. Delete any file 3. Read any file 4. Run any executable. 5. Install RPMs. ~ a. use yum to install RPMs Things sfrun cannot do: 1. Add users to the "wheel" group (this would be a root exploit) 2. Mess with the internals of the running kernel 3. Mess with the network stack (could be used to disable anti-theft) 4. Mount the backup partition, if it exists, or modify it if it is already mounted. 5. Create or modify executables that are setuid root. I suspect that these "can" and "cannot" lists can be implemented using nothing more than standard POSIX permissions. However, the desired precision might exceed the expressivity of standard POSIX permissions, in which case an ACL system would be required. Allowing sfrun to do things: Most of the things sfrun needs to do can be accomplished by changing the ownership of system files from "root:root" to "sfrun:rootlike". Both root and sfrun should be members of rootlike. This arrangement does not reduce the capabilities of root, since root can chmod any file. For example, almost every file in /bin, /boot, /etc, /lib, /ofw, /opt, /sbin, /usr, and /var should have its ownership set in this fashion, as well as the directories themselves. Most devices in /dev should also be created with similar permissions. To ensure that sfrun can also read the files created by the olpc user, the /home directory should be setgid rootlike. The same may be true of /tmp. Matching the "cannot" list, there are some exceptions to this pattern: 1. /etc/group must not be writable by sfrun. It may be that /etc/passwd should also not be writable by sfrun. 2. /dev/mem, /dev/kmem, and other highly sensitive devices should be left with their current ownership (root:kmem) 3. /dev/net, and any other networking-related devices should be left with root:root permissions 4. The device in /dev representing the backup partition should not be writable by sfrun. If the partition is mounted, it should not be unmountable by sfrun. If the partition is mounted using /etc/fstab, /etc/fstab should not be writable by sfrun. If the device is mounted by udev, then the appropriate udev config file may need to be read-only. 5. Any executables that are setuid root should not be writable by sfrun. However, it may be that some of these executables can be changed to be setuid sfrun. Matching the "can" list, there are some clarifications: 1. All directories in / except /dev, /sys, /proc, and potentially /security and /versions, should be owned by sfrun:rootlike. This includes "/", if possible, so that sfrun may create new files and directories in / 5. The "rpm" tool may or may not be entirely compatible with this approach. The sfrun user has write access to all the required directories, so rpm and yum should be fully able to install files. However, they should never install setuid root executables, or take any other action that requires permissions beyond sfrun's. The rpm tools must also know to install new executables as sfrun:rootlike, not root:root. It is not clear to me whether rpm and yum currently satisfy these criteria. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH0dVWUJT6e6HFtqQRAtMfAKCduSzmRtdXRW2WTVRVoxn/+oejeACfd+Bu HBEzFzodHnnlTNkQmau4bJ8= =95yh -----END PGP SIGNATURE----- _______________________________________________ Security mailing list [email protected] http://lists.laptop.org/listinfo/security
