October 2017 - Darwin-dev - lists.apple.com

Re: How to safely kill all processes owned by a user on macOS
by Daniel Peebles 18 Oct '17

18 Oct '17

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b9d+OAjaUuRdEGzloJx5g2oAax2HIKHcFyhmH7WP71I=; b=OwZo2bKqGpCGF/SFZWOnONN46B7srndbHQzufyUH46oDOAxymZaXnEhJVyDCv+hrOa 89++7DnZMvJ1I6w2MLPdvI2n74dbcZZmoIBemnq4UJRiMpRB5uf7gQ9y7zy4I1ucumyI VDHfVfpfZFN57ch7we8yn7d0Z4tSeHXjyEd/5nq4aGy3wIXLrBajeYOVylEH8SASvWiI CBCzs3Nnqx00Edz7L4leqqppjPcRgVqLlMoEpSdAkLOnhA3HZVbHnv4qGzDIT+N2ezAk Ul5NsBH+3gjif0yfvZMQT64q9+NSdGvAA9CcheJuP/SAolfd0nfIzPzeCKavYj421Fcn hROQ== Sorry, I forgot to reply to the second half of your email! The process group thing indeed doesn’t seem to crash the machine but doesn’t quite fit our use case, unfortunately. Nix is a build too and/or package manager and it goes out of its way to isolate package builds, by using Apple’s sandbox (scheme style, since it’s not a GUI app and needs fine-grained control over the sandbox), user isolation, and whichever other mechanisms we have available to us. Imagine a CI system running semi-untrusted (misbehaving or possibly actively malicious) build processes, on macOS. We run each build as a dummy no-privilege user and when the build is done (or cancelled) we want to ensure that there are no processes left lying around on the host. The kill(-1, ...) approach has worked fine for us for this purpose in the past but just recently started crashing systems, so we’re looking into other possible approaches. Thanks, Dan On Wed, Oct 18, 2017 at 06:31 Alastair Houghton < alastair(a)alastairs-place.net> wrote: > > On 18 Oct 2017, at 02:24, Daniel Peebles <pumpkingod(a)gmail.com> wrote: > > > > The obvious thing we tried before was to launch a new process, set(e)uid > to the user in question, then kill(-1, SIGKILL). That will kill all running > processes under that user (including the killer!), but unfortunately in > High Sierra (and possibly earlier), it also crashes the entire system and > I'm unsure how long it'll be until it's fixed: > http://www.openwall.com/lists/oss-security/2017/10/12/1 > > Has this been submitted to <product-security(a)apple.com>? The ability to > take out the system is quite clearly a security issue; there are Macs > installed with guest user access, for instance, where this would be > troublesome. > > > Does anyone have other ideas, possibly informed by obscure macOS > internal behavior, for how to effectively kill all processes owned by a > user? > > You could try killing just those processes in the same process group, if > that’s sufficient for your purposes (i.e. kill(0, SIGKILL)). Of course, > that may also trigger the bug, I don’t know. > > Alternatively, perhaps you can explain what you’re trying to achieve by > killing all the processes belonging to a particular user? Maybe there’s > something else you could do instead? > > Kind regards, > > Alastair. > > -- > http://alastairs-place.net > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap… This email sent to site_archiver(a)lists.apple.com

1 0

Re: How to safely kill all processes owned by a user on macOS
by Daniel Peebles 18 Oct '17

18 Oct '17

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GZUfJHOE/7xW64MAnLMcUqn8v2bM1BqNJWAZ0VXvfAw=; b=aDXm/OU1Fa55UWNlwF1j6sO7pp2awXjaC+uSFyr1ruRLzeGtipw+jp5siVCTfaDkzB C1SYZevi8qIDGnEgBIgJj9wkqOWzJ7JRmcyKbUh7pzFAmg5B3G20R7/yurdp3A+qInQq DCokdQS6kgip14GdUchskF1bMxn0hig19bycs63d5OCPRZP7FcM+A4nWH4VOmrDamsLw cljWvXqxSH9gj59FUOoluTFK9YEDrKQCHf731DXLHIjAbWg+nKaEQkkLnsbvhB8F6zG1 By2Zbl7Z3/F3AtgmoeP1tyD80ElnE2MuQQS2UigW8lk4MGGjp/Z76bxo73Y+dzo2Fxgc f1lw== Hi Alastair, Yes, we did try with them first and they told us they didn’t consider it a security issue, so we posted to oss-security after making sure Apple understood we’d do that unless they asked us not to. Thanks, Dan On Wed, Oct 18, 2017 at 06:31 Alastair Houghton < alastair(a)alastairs-place.net> wrote: > > On 18 Oct 2017, at 02:24, Daniel Peebles <pumpkingod(a)gmail.com> wrote: > > > > The obvious thing we tried before was to launch a new process, set(e)uid > to the user in question, then kill(-1, SIGKILL). That will kill all running > processes under that user (including the killer!), but unfortunately in > High Sierra (and possibly earlier), it also crashes the entire system and > I'm unsure how long it'll be until it's fixed: > http://www.openwall.com/lists/oss-security/2017/10/12/1 > > Has this been submitted to <product-security(a)apple.com>? The ability to > take out the system is quite clearly a security issue; there are Macs > installed with guest user access, for instance, where this would be > troublesome. > > > Does anyone have other ideas, possibly informed by obscure macOS > internal behavior, for how to effectively kill all processes owned by a > user? > > You could try killing just those processes in the same process group, if > that’s sufficient for your purposes (i.e. kill(0, SIGKILL)). Of course, > that may also trigger the bug, I don’t know. > > Alternatively, perhaps you can explain what you’re trying to achieve by > killing all the processes belonging to a particular user? Maybe there’s > something else you could do instead? > > Kind regards, > > Alastair. > > -- > http://alastairs-place.net > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap… This email sent to site_archiver(a)lists.apple.com

1 0

Re: How to safely kill all processes owned by a user on macOS
by Alastair Houghton 18 Oct '17

18 Oct '17

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com > On 18 Oct 2017, at 02:24, Daniel Peebles <pumpkingod(a)gmail.com> wrote: > > The obvious thing we tried before was to launch a new process, set(e)uid to > the user in question, then kill(-1, SIGKILL). That will kill all running > processes under that user (including the killer!), but unfortunately in High > Sierra (and possibly earlier), it also crashes the entire system and I'm > unsure how long it'll be until it's fixed: > http://www.openwall.com/lists/oss-security/2017/10/12/1 Has this been submitted to <product-security(a)apple.com>? The ability to take out the system is quite clearly a security issue; there are Macs installed with guest user access, for instance, where this would be troublesome. > Does anyone have other ideas, possibly informed by obscure macOS internal > behavior, for how to effectively kill all processes owned by a user? You could try killing just those processes in the same process group, if that’s sufficient for your purposes (i.e. kill(0, SIGKILL)). Of course, that may also trigger the bug, I don’t know. Alternatively, perhaps you can explain what you’re trying to achieve by killing all the processes belonging to a particular user? Maybe there’s something else you could do instead? Kind regards, Alastair. -- http://alastairs-place.net _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap… This email sent to site_archiver(a)lists.apple.com

1 0

How to safely kill all processes owned by a user on macOS
by Daniel Peebles 18 Oct '17

18 Oct '17

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=J9Lf3xhM6CZTfe7SxTED19ZDxy8OH8KQCiAxWlxOYAM=; b=lzVI61cu5u0SEYbeHn2GwsUqlaqe1TnEpRBi4lxVFHpoEq9fbwEvRrhhlRr7zu5Gcp hJCgkV0Dj5Bd8yJs02hRheAmIECB21m1jCqnp6eEP86IYUCJ2wjIFGF74HRyPTfrZC3c sgsGUyg7DqnKn5vSvYiiTgoLP2YfbmFsCsmf+WcW4kDFQF/3XMvQAWmSztTPuO/kdGDu VCe1fVcD3TkvFdqh8fr/HYMOoxXJ9Ee9bWC7WnRbVZitvIYadDddOQJ2cviAzMVZYWv6 BiSjD7XB0SUyciiIiHkD30uyjAH1Aiz5r2cZW1EnfkqVKDkj0YGBbqUqbTym8F5XjTRJ 2omw== Hi all, I'm looking for less obvious ways to kill all processes running as a UID in macOS, because the obvious ways are failing me right now. The obvious thing we tried before was to launch a new process, set(e)uid to the user in question, then kill(-1, SIGKILL). That will kill all running processes under that user (including the killer!), but unfortunately in High Sierra (and possibly earlier), it also crashes the entire system and I'm unsure how long it'll be until it's fixed: http://www.openwall.com/lists/oss-security/2017/10/12/1 To get better exit codes, we've also tried kill(-1, SIGKILL, 0); That's right, the kill syscall in XNU actually takes a secret third argument (not available via C API) that indicates whether you want POSIX behavior or not. Non-POSIX behavior in this case just means not killing the caller process but killing everyone else. This worked up until 10.13 but was also thwarted by the bug I linked above. So given that the obvious things don't work, what's a good approach here? I'm operating under the assumption that processes can misbehave, so listing processes and then killing them, being non-atomic, has issues: I can list processes while a process is forking and miss stuff. I could run that in a loop but there's no guarantee the loop will ever terminate (e.g., during fork-bomb-like behavior or even more innocent stuff). Does anyone have other ideas, possibly informed by obscure macOS internal behavior, for how to effectively kill all processes owned by a user? Thanks, Dan P.S: if this question looks familiar I also posted it to the newosxbook forum, but I'm eager for as many ideas as possible so I thought I'd cross-post it here. P.P.S: if you're an Apple XNU dev and would like to fix 10.13's XNU to stop crashing on kill(-1, SIGKILL), you'd make lots of us very happy :) :) :) _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap… This email sent to site_archiver(a)lists.apple.com

1 0

XNU/CoreStorage Question
by Clifford Sekel 15 Oct '17

15 Oct '17

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pd-devs-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=BUD6cwUQuduDDOxRZdRLXHWOVm96ZoVvTNKhYquEgBU=; b=JAlKGgemMukqiUFKCrftz09bZaWW/x13SFIoB5ZchD3wE1ONK62YXLrMlPRt10WKpX 3/5duYFTmNBPWL8cTtEyVIT+tAVZ8wXtr18wPGrQME1O9+yGvLoU8Zs/3ISpe0xYgxvz SUE+Qqc6iu0OEXyM//yk5XJ5/bAizjqqKFpHoOSjNPm78InPHUCH2bjxRrfVwQ3R1NbQ mCNb3K/oTAQ0PGQaYl2UbiqNv/nMii/nsE3Vo2qydlNp/7wlhPk8GxeBkP0hsxCT7WRZ RilQx72SKBMubIaGoRcSAssVs17s4prXhLUrsTblnkGDQRbpABKVLCrp2VvDtuGFEokB FHFQ== All, The PureDarwin group I work with have hit a bit of a snag, We understand that Apple has removed HFS and VFS Journal from XNU since 10.12. Since we don't have access to CoreStorage for HFS we created this patch to compile HFS without AppleKeyStore which results in there happening http://www.puredarwin.org/Screen%20Shot%202017-07-20%20at%208.05.16%20PM.png We believe that the issue is that HFS is not being loaded into the kernel correctly and we're thinking about patching back in vfs_journal init into the Kernel and seeing what happens with the system. Does anyone else have an idea about these filesystems or a direction we should look in? Thanks Cliff Sekel InSaneDarwin _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap… This email sent to site_archiver(a)lists.apple.com

1 0

Re: XNU's EXTERNAL_HEADERS folder and seemingly outdated headers in it
by Daniel Peebles 12 Oct '17

12 Oct '17

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jQPFYXzxOKUBZAtPaHVr6nQqf+meUSB5qMAZaBM8fN4=; b=cHufQkSQ9ypm5CXiKxnnKbUneCAtNe5mw5THxqMXVilM+B0I3YmtjDM017wRio9c37 i82u+sTSJCHtB3mTsBKbF596Om3ebJWJ0fTFAAq880IsPIIschCG1Ucl3csvP6lBrxIc PZY7t/lLPN0aVKKUqi0T2e85k9qLuYU0rzNghKUa2a8yjLDcGdEpJRxg5XZC9xAnKjcl 9FICCdD1EiMQzoa8uUvGALrjPxLIq8ueFjl6fbXkTfJV2v68juznWMRlFp/OoCDq0hAA ZOEFffrgT537MnO1+zhcmts1Brvq9jJFBXeGjIHUfhTgYrrwnffnIw0DSaiwsLKddtVU 6QcQ== Yeah, my build breaks if I don't ensure that the architecture project's include dir is earlier in the import precedence than EXTERNAL_HEADERS. The stuff in EXTERNAL_HEADERS still seems to make its way into the generated System/Kernel.framework though, so even on the latest Xcode, I see that this path: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk//System/Library/Frameworks/Kernel.framework/Versions/A/Headers/architecture/i386/asm_help.h contains an outdated macro for PICIFY (and presumably other parts of the file are similarly outdated). Not sure whether the best fix is to just update the contents of the EXTERNAL_HEADERS folder or rearrange how the build works, but I figured I'd point it out to the broader community (and maintainers) since I wasted a good few hours figuring out how anything was supposed to work at all with a header that seemingly hadn't been updated since the 32-bit days. Thanks, Dan On Wed, Oct 11, 2017 at 3:25 PM, Greg Parker <gparker(a)apple.com> wrote: > > On Oct 10, 2017, at 9:08 PM, Daniel Peebles <pumpkingod(a)gmail.com> wrote: > > Hi all, > > I'm trying to understand the purpose of the EXTERNAL_HEADERS folder in the > XNU releases. I'm currently struggling to compile XNU 3248.60.10's > libsyscall and my build is getting thrown off by the asm_help.h inside > EXTERNAL_HEADERS, which tries to inject i386 code into my x86_64 syscall > wrappers. > > As an example, see https://opensource.apple.com/source/xnu/xnu-3248.60.10/ > EXTERNAL_HEADERS/architecture/i386/asm_help.h.auto.html, which defines a > PICIFY macro near the bottom. The one in there unconditionally runs popl > %edx, which isn't valid in 64-bit mode. > > If instead we compare the same asm_help.h from https://opensource.apple. > com/source/architecture/architecture-268/i386/asm_help.h.auto.html (which > comes from the same macOS release, 10.11.6), the same PICIFY macro > correctly branches based on architecture and runs a far more appropriate movq > var@GOTPCREL(%rip),%r11 on 64-bit intel. > > This doesn't seem to affect most builds of XNU (such as those Shantonu Sen > so helpfully explains on his blog) because the standard macOS SDKs include > the more moderbn asm_help.h in the standard headers. > > That leaves me wondering why EXTERNAL_HEADERS is provided in the first > place, since it feels very confusing to those of us compiling in > non-standard environments. It never seems to change (even the new > darwin-xnu project on GitHub with the 10.13 kernel sources still has the > old 32-bit file: https://github.com/apple/darwin-xnu/blob/master/ > EXTERNAL_HEADERS/architecture/i386/asm_help.h#L270-L275). > > Can anyone shed light on these apparent discrepancies? > > > The old copy of asm_help.h in xnu's EXTERNAL_HEADERS is probably leftover > historical cruft. I bet libsyscall is expecting the more recent asm_help.h > file from Darwin's 'architecture' project. > https://opensource.apple.com/source/architecture/architecture-268/ > > > -- > Greg Parker gparker(a)apple.com Runtime Wrangler > > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap… This email sent to site_archiver(a)lists.apple.com

1 0

Re: XNU's EXTERNAL_HEADERS folder and seemingly outdated headers in it
by Greg Parker 11 Oct '17

11 Oct '17

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com > On Oct 10, 2017, at 9:08 PM, Daniel Peebles <pumpkingod(a)gmail.com> wrote: > > Hi all, > > I'm trying to understand the purpose of the EXTERNAL_HEADERS folder in the > XNU releases. I'm currently struggling to compile XNU 3248.60.10's libsyscall > and my build is getting thrown off by the asm_help.h inside EXTERNAL_HEADERS, > which tries to inject i386 code into my x86_64 syscall wrappers. > > As an example, see > https://opensource.apple.com/source/xnu/xnu-3248.60.10/EXTERNAL_HEADERS/arc… > > <https://opensource.apple.com/source/xnu/xnu-3248.60.10/EXTERNAL_HEADERS/arc…>, > which defines a PICIFY macro near the bottom. The one in there > unconditionally runs popl %edx, which isn't valid in 64-bit mode. > > If instead we compare the same asm_help.h from > https://opensource.apple.com/source/architecture/architecture-268/i386/asm_… > > <https://opensource.apple.com/source/architecture/architecture-268/i386/asm_…> > (which comes from the same macOS release, 10.11.6), the same PICIFY macro > correctly branches based on architecture and runs a far more appropriate movq > var@GOTPCREL(%rip),%r11 on 64-bit intel. > > This doesn't seem to affect most builds of XNU (such as those Shantonu Sen so > helpfully explains on his blog) because the standard macOS SDKs include the > more moderbn asm_help.h in the standard headers. > > That leaves me wondering why EXTERNAL_HEADERS is provided in the first place, > since it feels very confusing to those of us compiling in non-standard > environments. It never seems to change (even the new darwin-xnu project on > GitHub with the 10.13 kernel sources still has the old 32-bit file: > https://github.com/apple/darwin-xnu/blob/master/EXTERNAL_HEADERS/architectu… > > <https://github.com/apple/darwin-xnu/blob/master/EXTERNAL_HEADERS/architectu…>). > > Can anyone shed light on these apparent discrepancies? The old copy of asm_help.h in xnu's EXTERNAL_HEADERS is probably leftover historical cruft. I bet libsyscall is expecting the more recent asm_help.h file from Darwin's 'architecture' project. https://opensource.apple.com/source/architecture/architecture-268/ <https://opensource.apple.com/source/architecture/architecture-268/> -- Greg Parker gparker(a)apple.com <mailto:gparker@apple.com> Runtime Wrangler _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap… This email sent to site_archiver(a)lists.apple.com

1 0