lldb ...

[Jeremy Huddleston Sequoia]

> On Sep 9, 2016, at 04:38, René J.V. Bertin <rjvbertin at gmail.com> wrote:
> 
> On Friday September 09 2016 12:10:05 Rainer Müller wrote:
> 
> 
>>> different than your case either.  Either way, the debugger and all
>>> its dependencies need to be signed by a valid certificate.
>> 
>> That does not seem to be the case. In my testing on OS X 10.10 Yosemite,
>> it is enough to sign /opt/local/bin/ggdb with a trusted certificate to
>> get it working.

It requires the ggdb executable and all libraries it links against to be signed.  The port is written such that it only links against Apple-provided executables, so that solves that dependency.

> And lldb requires only the debugserver executable to be signed.

Again, because debugserver uses entitlements, all its dependencies need to be signed as well.

$ otool -L  /opt/local/libexec/llvm-devel/bin/debugserver
/opt/local/libexec/llvm-devel/bin/debugserver:
	/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 22.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 307.4.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1348.1.0)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1349.0.0)
	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)

As you can see, all of its dependencies are system libraries, so they're all valid.

>> Did this change with El Capitan or Sierra?
> 
> I'm guessing that would somehow be evident from the lldb-3.9 CMake files and build instructions...
>> At least on OS X 10.10 Yosemite, I can use any path to a keychain with
>> `codesign --keychain`. This keychain does not have to be listed in
>> `security list-keychains`.
> 
> Does `man codesign` still mention the search list  requirement in the documentation for --keychain?

Yes, that is still a requirement.

> 
> On Friday September 09 2016 02:26:19 Jeremy Huddleston Sequoia wrote:
> 
>>>> I'd hate that because I've set things up with macports_user=myself and
>>>> everything under workpath owned by myself, to avoid constant need for
>>>> UID changing. I kind of doubt I'm the only one maintaining lots of
>>>> ports who does that.> > 
>>> I don't understand.  Can you elaborate?  Doesn't post_destroot{} run as
>>> root in order to setup desired permissions in the destroot?  That's a
>>> good place to handle the resigning.
> 
> I do a lot of development on projects for which I also maintain ports; in fact, development that's tightly coupled to the fact the code is available via a port. Doing all that work "as myself" only to transfer it to the port afterwards is a hassle and waste of time as far as I'm concerned. It's not so much that I want to avoid having to put sudo in front of each and every port command (I'd write a `sport` wrapper/alias). I don't want to grow the habit of putting sudo in front of everything I'm doing around those ports' build directories and that I'd also be doing in development that's got nothing to do with MacPorts. I also want to be able to open a port's source tree in an IDE, run incremental builds in subdirs for ${build.dir}, etc. So I've set my macportsuser to my own username, and most of the time I run everything up to and including `port destroot` as myself (and set up symlinks to `port work` for easy access). Typically, for -devel ports that use fetch.git I also replace ${worksrcdir} with a symlink to the working copy under my own home directory (that way I also won't lose local changes if I ever forget to use -o or -k).
> Many of the contributions I've made to KDE over the past few years were developed with this approach. I've used the standard approach (macportsuser = macports) on a VM Bradley gave me access to, and it's definitely a lot less productive.
> Evidently this is not the kind of advanced use we need to consider for regular users, but port developers/maintainers are users too, and I think we *could* consider their needs too.
> 
> As an aside, I'd be in favour of setting up MacPorts such that ${prefix} is owned by a ${macports_operator} who's got admin rights (= myself) and reserve use of actual root privilege to those few ports that require setting up SETUID/GETUID executables or that need to create users or groups.

YES!  We should not be needing to do such things as root.  That is 100% true, and I am in full support of moving away from that and only using root for activate.  We should be able to use fakeroot (https://wiki.debian.org/FakeRoot) for destdir.

> MacPorts installs into a parallel prefix, and there are only few ports that require access to system directories. 
> 
>>> That's because you're using sudo, which doesn't change the bootstrap
>>> session.  You likely want to do something like:
>>> sudo launchctl asuser `id -u joebob` sudo -u joebob codesign ...
>>> which requires launchd2 (OS X 10.10+)
> 
> From what I can tell the Security framework (and the security and codesign execs) work from a remote (SSH) connection too. Indeed, sudo doesn't by default change HOME (there's the -H option for that) ... but that's basically what I'm arguing.
> 
>>>> Isn't that a bit of a special case, with you certainly having Apple's
>>>> benediction to work on that particular product?> > 
>>> XQuartz isn't any more blessed in that respect than MacPorts.
> 
> And the fact you're an Apple's payroll doesn't have anything to do with it either?

I've changed jobs (within Apple) twice since I worked on X11 officially.  It's not part of my job any more.  I continue to do very very minimal changes to XQuartz in my spare time, mainly to get out version bumps and security fixes.

> Currently Apple doesn't have a say in the admission and upgrade of each and every port in MacPorts, do they?

No, of course not.

> In a way I'd even hope they cannot force the exclusion of a port (other than ones clearly doing unlawful things);

No, or course not.

> signing everything with an official key seems like a way to give them (more) leverage to control over the ports tree.

No, it does not.  We get a say in what we sign, and the certificate is signed by Apple indicating that we have a chain of trust back to Apple.  That gives us the ability to revoke the certificate through ADC if our systems become compromised.  If you want to wear a tin foil hat, we are free to use our own codesignigning certificate, signed by another authority (or none at all), and establishing it as trusted will just require an extra step for our users.  Doing so will make it harder to revoke, though.

>>>> So even you don't know what the ad hoc identity can and won't allow?
>>> 
>>> I'm not sure I understand your question.
> 
> Sorry, I understood that you hadn't realised that signing with the ad hoc identity prevents the persistent firewall popup for internet-enabled applications.
> 
>>>> because everything from before that magic moment will have been signed
>>>> with a different key that *might* break unpredictable things?> > 
>>> Can you elaborate here?  What do you mean by "a different key"?  Adhoc
>>> signing does not use a key.  What do you expect might break or be
>>> unpredictable?
> 
> So a library that's signed ad-hoc won't be rejected when loaded in an application that's signed with a different identity and that requires all its dependencies to be signed with that same identity?

It's quite a bit more complicated than that.  First off, these settings are on by default but can be configured through SIP flags, boot args, etc.  There are also many types of restrictions that have different effects.


If a process uses entitlements, issetugid, is a system binary, has library validation enabled, or has a __RESTRICT/__restrict section, then the process is provleged and has more restrictions than "normal" processes.  I believe (but could be wrong) that all of those conditions force the process to be both CS_HARD and CS_KILL.  Under CS_HARD, mmap() will fail if the mapped image's codesignature is invalid (checksum mismatch, untrusted certificate, amfi invalidation, no codesignature, etc).  Under CS_KILL, any process that is !CS_VALID will be terminated.  Such processes are also restricted from using certain DYLD_ envvars.

Because of the CS_HARD restriction, all libraries that are linked against require a valid code signature.

> What I did notice is that signing lldb with a proper lldb_codesign key didn't have any immediate effect after it had been signed with an ad-hoc key.
> I refused to reboot (that simply ought not be necessary, certainly not multiple times) and it was only after I stumbled upon the suggestion to restart taskgated that I got the re-signed lldb to work. Apparently that trick isn't guaranteed to work, so yeah, I'd call that an aspect of unpredictability.

This is because you likely already launched the executable, so the old signature for that particular inode was already cached.  If you copied debugserver somewhere else and then copied it back, it would have addressed the problem for you.


>>> Have you filed a radar at http://bugreport.apple.com requesting that we
>>> ship those other llvm utilities?  Can you point me to it, so I can
>>> followup internally?
> 
> No, I haven't. Quite frankly I'll leave that to someone who's running the latest OS X and who'd be willing to install my (or the) port:kf5-kdevelop once it should be possible to build that against Xcode's toolchain.
> Of course I could file a generic request to provide the full llvm toolchain containing everything required to build 3rd party llvm utilities and extensions, but I won't be able to test anything that doesn't run on the OS version I'm using.
> 
> No specific questions about ad-hoc code-signing, not anymore at least. Thanks for providing enough answers. 
> 
>>>> And here's to that never changing ...
>>> 
>>> Can you elaborate on why you are concerned about that?  I wonder if it is
>>> just confusion about what adhoc signing is about. It doesn't require a
>>> signing certificate, just a valid (possibly adhoc) signature on the
>>> binaries.
> 
> I'm concerned about every step that takes OS X away from a regular Unix (underneath a nice and truly integrated desktop) and towards a locked-in OS like iOS.'

Well macOS is still UNIX.  We continue to verify that through continual conformance testing.  I don't expect that to ever change.

> Not that it really matters because the OS is already locked into hardware and it seems every new hardware release makes it less likely I'll be replacing my ageing MBP with a newer one...

FWIW, I really love my 2015 rMBP.  I was a holdout staying on the pre-retina ones so I could continue to have a DVD drive and a 2.5" drive bay, but I finally gave that up and am really glad that I did because the newer SSDs are blazing fast.


-------------- 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/20160909/0f9464da/attachment.p7s>