Re: [PATCH] Install customization packages left for us by a USB key.
On Mon, Jun 30, 2008 at 10:19 PM, Michael Stone [EMAIL PROTECTED] wrote: On Mon, Jun 30, 2008 at 04:58:33PM -0400, C. Scott Ananian wrote: + yum -yt --nogpgcheck install $pkgs 1. As an earlier commenter hinted, you want localinstall because otherwise yum may try to talk to the network in order to download its header cache and to look for newer versions of packages that satisfy dependencies of the installation set. k, thx. @@ -212,6 +228,11 @@ __EOF__ echo olpc-configure: replaying rainbow spool... /usr/sbin/rainbow-replay-spool fi + + # developer customizations. + if /usr/bin/olpc-test-devkey -q ; then + install_customization_packages 2. Do we need a guard for the existence and executability of olpc-test-devkey? it's in the Requires clause for the package, but also bash does not echo 'yes' given: $ if /asdasd ; then echo yes ; fi 3. Why do we care whether there's a devkey? We would actually be better off checking that all the RPMs we're installing are owned by uid 0, this being the exact privilege that we're attempting to safeguard. because we're also trying to enforce P_SF_RUN and a whole bunch of other random things; all of which everyone seems to agree can be subsumed under you're a developer, you can shoot yourself in the foot if you want to. The loosey-goosey but this is highly likely to break when you upgrade between major releases objection, for instance, is answered by the foot-shooting permission. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] Install customization packages left for us by a USB key.
On Tue, Jul 01, 2008 at 08:05:46AM -0400, C. Scott Ananian wrote: 3. Why do we care whether there's a devkey? We would actually be better off checking that all the RPMs we're installing are owned by uid 0, this being the exact privilege that we're attempting to safeguard. because we're also trying to enforce P_SF_RUN and a whole bunch of other random things; all of which everyone seems to agree can be subsumed under you're a developer, you can shoot yourself in the foot if you want to. And, as you will observe here http://dev.laptop.org/git?p=security;a=blob;f=rainbow.txt;hb=HEAD#l101 in my opinion, the cheapest way to implement P_SF_CORE + P_SF_RUN is by turning the root password into a developer key, then by applying a CoW layer such as we recently discussed. The loosey-goosey but this is highly likely to break when you upgrade between major releases objection, for instance, is answered by the foot-shooting permission. It's also answered by the fact that RPM checks dependencies, no? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] Install customization packages left for us by a USB key.
On Tue, Jul 1, 2008 at 11:36 AM, Michael Stone [EMAIL PROTECTED] wrote: http://dev.laptop.org/git?p=security;a=blob;f=rainbow.txt;hb=HEAD#l101 in my opinion, the cheapest way to implement P_SF_CORE + P_SF_RUN is by turning the root password into a developer key, then by applying a CoW layer such as we recently discussed. Right, we'll revisit this when all that is in place. In particular, that means locking down sudo (and things which use it, like sugar-control-panel) far more than we do currently. The loosey-goosey but this is highly likely to break when you upgrade between major releases objection, for instance, is answered by the foot-shooting permission. It's also answered by the fact that RPM checks dependencies, no? Only if you assume that (a) nothing in the RPM set is going to be considered 'critical', and (b) all RPMs are well-behaved. I don't think we can enforce either. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] Install customization packages left for us by a USB key.
On Fri, Mar 7, 2008 at 3:23 AM, Michael Stone [EMAIL PROTECTED] wrote:
---
olpc-configure | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/olpc-configure b/olpc-configure
Slight variant, which passes my muster (unless someone convinces me it
shouldn't!) attached (and also added to
http://dev.laptop.org/ticket/6432#comment:14 ).
--scott
--
( http://cscott.net/ )
diff --git a/etc/rc.d/init.d/olpc-configure b/etc/rc.d/init.d/olpc-configure
index 17b0f80..c4f0d2d 100755
--- a/etc/rc.d/init.d/olpc-configure
+++ b/etc/rc.d/init.d/olpc-configure
@@ -103,6 +103,22 @@ rebuild_library_index() {
fi
}
+install_customization_packages () {
+ # we'd like to look on USB/SD here, but udev/sugar hasn't mounted
+ # them yet =(
+ for pkgdir in /home/olpc/.custom/rpms ; do # other paths?
+ if [ ! -d $pkgdir ]; then continue; fi
+ pkgs=$(find $pkgdir -name '*.rpm' -a ! -name '*.src.rpm' )
+ if [ -n $pkgs ]; then
+ echo '* olpc-configure: Installing customization packages:'
+ echo $pkgs
+ yum -yt --nogpgcheck install $pkgs
+ fi
+ unset pkgs
+ fi
+ unset pkgdir
+}
+
# configurations which happen in /home
# these don't need to be repeated when we upgrade.
configure_home() {
@@ -212,6 +228,11 @@ __EOF__
echo olpc-configure: replaying rainbow spool...
/usr/sbin/rainbow-replay-spool
fi
+
+ # developer customizations.
+ if /usr/bin/olpc-test-devkey -q ; then
+ install_customization_packages
+ fi
}
#
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [PATCH] Install customization packages left for us by a USB key.
On Mon, Jun 30, 2008 at 04:58:33PM -0400, C. Scott Ananian wrote: + yum -yt --nogpgcheck install $pkgs 1. As an earlier commenter hinted, you want localinstall because otherwise yum may try to talk to the network in order to download its header cache and to look for newer versions of packages that satisfy dependencies of the installation set. @@ -212,6 +228,11 @@ __EOF__ echo olpc-configure: replaying rainbow spool... /usr/sbin/rainbow-replay-spool fi + + # developer customizations. + if /usr/bin/olpc-test-devkey -q ; then + install_customization_packages 2. Do we need a guard for the existence and executability of olpc-test-devkey? 3. Why do we care whether there's a devkey? We would actually be better off checking that all the RPMs we're installing are owned by uid 0, this being the exact privilege that we're attempting to safeguard. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] Install customization packages left for us by a USB key.
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? Why is this being proposed, Michael? I believe that, when used judiciously, it adds valuable flexibility to the customization process that our deployment teams, the individuals who wind up maintaining the laptops' on-site over the course of their lifetimes, and our developers will appreciate. I'll leave it to you to articulate your view of the potential hazards that my 'judicious use' qualification carefully masks. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] Install customization packages left for us by a USB key.
On Fri, Mar 7, 2008 at 12:00 PM, Michael Stone [EMAIL PROTECTED] wrote: On Fri, Mar 07, 2008 at 10:11:06AM -0500, C. Scott Ananian wrote: Why is this being proposed, Michael? I believe that, when used judiciously, it adds valuable flexibility to the customization process that our deployment teams, the individuals who wind up maintaining the laptops' on-site over the course of their lifetimes, and our developers will appreciate. I'll leave it to you to articulate your view of the potential hazards that my 'judicious use' qualification carefully masks. I asked for specific use cases. I'm not interested in supporting risky things that are unnecessary but might be nice somehow. Let's make our support problems *better*, not *worse*. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] Install customization packages left for us by a USB key.
On Fri, Mar 07, 2008 at 12:04:29PM -0500, C. Scott Ananian wrote: I asked for specific use cases. I apologize if I was inadequately specific in my previous email. As I alluded to before, three specific groups who I am confident would benefit from the ability to install RPMs via a USB-based customization process include: a) Walter and the teachers he's training, who would like an easy way to install gnuchess, since Gcompris doesn't yet bundle it. b) Individuals with large numbers of unreliably-networked laptops who would like to install carefully chosen and tested software on them en-masse, e.g. Bryan Berry and OLE Nepal. c) Individuals like me (and you?) who want a convenient way to install a fixed software overlay on top of whatever recent build they are presented with. I'm not interested in supporting risky things that are unnecessary but might be nice somehow. First a disclaimer - I'm going to ask what may be a couple of dumb questions because I really want to better understand your position. My question is simply: were you speaking on behalf of the entire OLPC development community, the OLPC-employed software team, or really, solely, for yourself? If the last (which I'll assume since I take it to be the literal meaning of your statement): a) why would you feel that you, personally, are supporting arbitrary 'risky things' that someone else thought were good ideas? (particularly when they go to the effort of developing, testing, and submitting a patch in order to offer everyone the opportunity to reach their own judgment of the merits of the proposal?) b) given that you currently feel this way, have you considered changing your feelings by letting the role of 'human firewall' fall on some different, perhaps larger set of shoulders, for example, those of the design- and code-review community whose help I solicited by publishing my first email? Sincerely, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] Install customization packages left for us by a USB key.
On Fri, Mar 7, 2008 at 12:56 PM, Michael Stone [EMAIL PROTECTED] wrote: On Fri, Mar 07, 2008 at 12:04:29PM -0500, C. Scott Ananian wrote: I asked for specific use cases. a) Walter and the teachers he's training, who would like an easy way to install gnuchess, since Gcompris doesn't yet bundle it. This is a gnuchess problem. Gnuchess is not properly packaged yet. b) Individuals with large numbers of unreliably-networked laptops who would like to install carefully chosen and tested software on them en-masse, e.g. Bryan Berry and OLE Nepal. This is an inadequate problem description. What software? Why can't they be packaged as activities? What are the risks / benefits compared to the existing approach? c) Individuals like me (and you?) who want a convenient way to install a fixed software overlay on top of whatever recent build they are presented with. I believe we have a general design for such a system: trac #6432. You have provided one part of it; our full design included looking on external media, and mechanisms for making trojan attacks via this mechanism more difficult. The general approach is valid as long as it is not abused for deployment customization (your examples (a) and (b)). Checking for a developer key before invoking this mechanism would be one way of ensuring this, since we have already posited that presence of a developer key means that the user takes all responsibility for updating their machine and protecting it from theft. My question is simply: were you speaking on behalf of the entire OLPC development community, the OLPC-employed software team, or really, solely, for yourself? Of course, I am speaking only on behalf of myself. I have no authority, as you well know. Like gnu, my influence is limited to calling bullshit when I see it and trying to build consensus for sane approaches. I believe that your responsibility is also to build consensus: you must make a best effort to satisfy objectors (including myself) and make compromises. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] Install customization packages left for us by a USB key.
-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- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] Install customization packages left for us by a USB key.
On Fri, Mar 07, 2008 at 03:32:14PM -0500, Benjamin M. Schwartz wrote: First, thanks very much for the constructive criticism. This discussion is ultimately about Bitfrost's P_SF_RUN, We should certainly design a solution compatible with P_SF_RUN. I submit that the tactical part of the discussion contains material that extends beyond the scope of Bitfrost, but it's certainly good to revist the theoretical underpinnings of the enterprise. 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. Certainly true. 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. Agreed. 2. RPM customization from USB sticks will constitute a security hole, rendering P_SF_RUN ineffectual. I would have suggested, instead, that 'once P_SF_RUN is implemented, this RPM installation feature will operate by exercising P_SF_RUN.' In other words, isn't rebooting with a specially formatted USB key (perhaps with fancy signed instructions; perhaps not) a [1] perfectly good way to determine that the human operator of the XO actually intends to modify the system software contained on it? [1]: Clearly, some alternate mechanism is also needed in order to support users who do not possess spare USB keys. Revertibility still needs some work: something like a CoW linking primitive, union mounts, etc. are still needed in order to put a writable layer on top of the read-only base layer. Comments? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] Install customization packages left for us by a USB key.
On Fri, Mar 7, 2008 at 12:00 PM, Michael Stone [EMAIL PROTECTED] 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? Yes. The presence of this hook turns the ability to *write files* as UID 500 into the ability to *execute code* as UID 0. These permissions should not be identical, and where they are (for example, in so far as we source scripts from /home/olpc instead of parsing non-executable configuration files) I believe this to be a flaw in our security. A subtle version of this attack would be to have an attacker write /home/olpc/.bashrc, which would be invoked when the child launched Terminal; we should perhaps consider passing --noprofile to bash in Terminal to mitigate this risk. I am also very concerned about the number of activities running as UID 500, but I think that's off-topic, and on the schedule of things-to-be-fixed at any rate. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
