Fakeroot destrooting [Was: Re: lldb ...]

[Jeremy Huddleston Sequoia]

> On Sep 10, 2016, at 09:38, Clemens Lang <cal at macports.org> wrote:
> 
> Hi,
> 
> On Sat, Sep 10, 2016 at 09:14:16AM -0700, Jeremy Huddleston Sequoia wrote:
>> No, the DYLD_INSERT_LIBRARIES approach is the right one here.
>> Interested users would need to disable SIP.
> 
> "Interested users" would be everybody who uses MacPorts. I'd vote
> against telling all our users to disable SIP. It's a useful
> security/safety feature and it even helps us because users can no longer
> mess up their /usr/bin.

No.  "Interested users" would be everybody who wants to use this fakeroot implementation instead of sudo.  Users would need to make the tradeoff decision for themselves as to whether they want SIP+sudo or !SIP+fakeroot.

> I don't see why the kernel, dyld, or whoever strips the flags could not
> just behave like running a copy of the binary at hand when it sees a
> DYLD variable, i.e. do the workaround we're doing manually at the
> moment.

Because that'e exactly what the system binary bit is intended to prevent.  The system binary bit on the executables is in place to ensure that binary is not interposed by third party code that can potentially degrade the integrity of the running system.

>> It would be nice if a mechanism were in place to determine trust of
>> certain libraries in DYLD_INSERT_LIBRARIES.
> 
> So you're suggesting DYLD_INSERT_LIBRARIES on SIP-protected binaries
> should only work if the inserted library is signed? How would that
> improve anything? Are you suggesting every open source project out there
> that uses library preloading now pays for a certificate and regularly
> builds and releases binaries for macOS? Frankly, I don't see that
> happening.

IMO, there should be a way to establish a trust model such that certain binaries could be inserted (maybe with a particular entitlement on the dylib).  That isn't possible right now.  Please file radars to vote for this getting addressed in a future release.

OSS projects are free to do what they want for the benefit of their customers.  They can sign their code with an ADC-provided cert, a cert from another CA, or not at all and just instruct users on how to sign the binary themselves.

>> Please file radars and point me to them, so I can make sure they get
>> routed to the right place (likely as dupes, but dupes are very useful
>> "votes" for bugs).
> 
> Those tickets have been filed when SIP was introduced and
> DYLD_INSERT_LIBRARIES stopped working.
> Evidently, it wasn't important
> enough to get fixed, so you'll forgive me if I have better things to do
> with my time.

All the radars that I am aware of are mainly focused around "DYLD_INSERT_LIBRARIES doesn't get passed through system binaries" not "DYLD_INSERT_LIBRARIES doesn't get honored by system binaries".  The latter is what this is about.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4465 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20160910/8a9420b6/attachment.p7s>