[PATCH] Install customization packages left for us by a USB key.

[Benjamin M. Schwartz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Stone wrote:
| On Fri, Mar 07, 2008 at 10:11:06AM -0500, C. Scott Ananian wrote:
|> Classic privilege-escalation attack.
|
| /, /home, and /home/olpc, are only writable by uids 0 and 500. Both uids
| 0 and 500 have direct access to uid 0. Therefore, if Mallory can affect
| what files are pointed to by $PKGDIR, then she already had access to uid
| 0. Is there a more subtle privilege escalation attack that I missed? In
| particular, one that was not already present 'a fortiori'? Are you
| instead primarily concerned that too much software is running under uids
| 0 and 500?

This discussion is ultimately about Bitfrost's P_SF_RUN, which when
enabled gives uid 500 access to uid 0.  According to the Bitfrost spec,
the P_SF_RUN permission is required for the user to modify the running
system files.  Installing an RPM clearly constitutes a modification of the
system files.  Moreover, any user who can install an RPM can make
arbitrary modifications to the system, using setuid binaries or other
techniques.

Currently, there is no way to disable P_SF_RUN permission.  However, we
are operating under the assumption that Bitfrost will eventually be
implemented completely.  Once P_SF_RUN is implemented, this RPM
installation feature will be incompatible with P_SF_RUN.  There are then
two options:

1. RPM customization from USB sticks will not work if P_SF_RUN is disabled.
2. RPM customization from USB sticks will constitute a security hole,
rendering P_SF_RUN ineffectual.

I (and I believe also others) oppose this feature because it creates this
inevitable conflict with Bitfrost.  Once P_SF_RUN is implemented, RPM
customization will have to be disabled, causing consternation among those
who are using this feature.  It would be far better to comply with the
constraints of Bitfrost now, even though they may not yet be enforced.

If you would like to argue that P_SF_RUN should always be enabled, and
therefore should not appear as a permission in the Bitfrost spec, you
should make this argument separately.

- --Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH0aZOUJT6e6HFtqQRAkITAJ940x7P4PziHw8OmMvTRDHndO6pnACgkJf4
P8N/BlH530gMb3KTxXDFpTQ=
=3qEq
-----END PGP SIGNATURE-----