On Mon, 2013-06-17 at 12:06 +0100, Richard Purdie wrote: > The plan (and I believe what this series does) is to have two busybox > binaries, one is suid (as small a subset as we really need) and the > other is not and hence this hopefully goes some way to reassuring people > about that.
Partly, but that's only half the problem. My recollection from when I last looked at this is that it was actually quite straightforward to convince yourself by inspection of the code that busybox is indeed dropping setuid privs almost immediately for applets that don't need it, so the risk of having things like /bin/cat unexpectedly running as setuid is probably fairly low. (However, there are other minor reasons why having the primary busybox binary as setuid is sometimes inconvenient so I agree that splitting the setuid portions out makes sense.) What's harder. given the way that the code is structured, is to get a clear view of which lines of source might end up being invoked by one of the setuid applets and to determine whether this has changed from one busybox release to the next. p. _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core