Benjamin M. Schwartz
2008-03-07 23:52:54 UTC
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.
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.