Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

macOS Containers v0.0.1

macoscontainers.org

Post reply on HN
Print view View original

221–230 of 374 posts

Re: macOS Containers v0.0.1

#221

Post by avidphantasm »

rafaelmn wrote: post #30
highwaylights wrote: post #21

Earlier quoted context omitted.

This kind of makes me wonder why you'd have a Mac at all (I'm sure there are use cases). Wouldn't a Linux device, or Linux running on a Mac suit you better? For me, the security picture is one of the main features of the eco-system even if it's very restrictive - disabling SIP undermines it more or less completely.

>Wouldn't a Linux device, or Linux running on a Mac suit you better? Maybe they want a unixy desktop with working sound ? Half joking, but that's my use case - homebrew is pretty great, most developers use a Mac in my domains of interest so it's always supported. Linux is just too much work (and I'm using Fedora on my desktop). SIP is just false positives and annoyance. I'm on the fence about M/ARM switch since I sti…

I use AMD64 containers on my M1 Pro under Docker Desktop with zero problems. It’s about 10-20% slower than my AMD64 Linux machine on average, which is usually fast enough.

Re: macOS Containers v0.0.1

#222

Post by tambourine_man »

pjmlp wrote: post #219
tambourine_man wrote: post #216

Earlier quoted context omitted.

Off the top of my head: launchd inspired systemd. Spotlight (real time indexing and notification) is something I miss in Linux today. 64bit Unix layer on consumer hardware (G5). All of that stuff was not a first ever implementation, of course, but it was well executed and led the way. All of that was more than a decade ago.

All of that appeared first in HP-UX, Solaris and Aix. Xenix and Coherent were the first UNIX on consumer hardware.

Which is why I said: “All of that stuff was not a first ever implementation, of course, but it was well executed and led the way.”

Apple is rarely the first at doing something but it's often the first that's good and cheap enough that people care about.

Re: macOS Containers v0.0.1

#223

Post by avidphantasm »

sacnoradhq wrote: post #61
przems wrote: post #18

Earlier quoted context omitted.

Could you elaborate why? I’m new to macOS, I’d love to learn more about it.

Don't disable security features because of random comments from randos. Also, don't install shit anywhere but your home directory as you unless you want to break your system in an irreparably, unmaintainable, or unsupported manner. If you're using sudo, you're already doing it wrong. https://support.apple.com/en-us/102149

Civilized people don’t install things in “/“.

Re: macOS Containers v0.0.1

#224

Post by insanitybit »

kafrofrite wrote: post #138
slonopotamus wrote: post #81

Earlier quoted context omitted.

Original author here. Thanks for spotting the typo, fixed. WRT security implications of disabling SIP - I don't think OS becomes any less vulnerable than usual Linux/Windows installation.

> I don't think OS becomes any less vulnerable than usual Linux/Windows installation. is not a good enough argument. For the story, SIP is Apple's "rootless". Effectively the OS runs with less privileges than root. Disabling SIP significantly increases the attack surface. That being said, I'm grateful that someone decided to do something more native for containers in macOS.

I think it's an OK argument given that most people run (and have been running with no alternative until very recently) docker in such a way that there's a trivial privesc to root. In general it seems like docker users are, overall, willing to take that tradeoff.

Re: macOS Containers v0.0.1

#225

Post by radlad »

slonopotamus wrote: post #175
highwaylights wrote: post #147

Earlier quoted context omitted.

This is not necessarily the case. On Linux, more or less the entire permissions system makes no assumption about SIP existing (as it doesn't there), so other protections are relied upon to secure the system (such as SELinux, granular directory permissions, etc.). On both Linux and Windows, TPM and secure boot provide similar protections to SIP on macOS, but are optional (it's encouraged more forcefully on Windows 11)…

What exactly attack vectors you think are possible against macOS without SIP but not possible against Linux?

I think the argument is that file permissions may not be applied as rigorously, with the assumption that SIP is in effect.

Re: macOS Containers v0.0.1

#226

Post by noveltyaccount »

lloeki wrote: post #70
highwaylights wrote: post #16

Earlier quoted context omitted.

This introduces a long-standing problem that is really the main issue I have with Docker/Podman/containers on anything other than Linux - you have a dedicated VM that needs memory to be set aside for it exclusively. This is fine if you have a 32/64GB machine, but less so on an 8GB non-upgradeable laptop. I get it - memory is relatively cheap these days - and manufacturers that are building memory-limited devices are…

> If anyone knows of any projects trying to work around that problem I'd love to hear about it. Containers are namespaced processes. These processes exec against the corresponding kernel they require. There is no workaround: if you have an ELF binary calling Linux syscalls it can only run on a Linux kernel†, so to run that you need a VM††. It's not as bad as it appears thanks to memory ballooning†††. Conversely if yo…

> WSL1 was implementing the Linux syscall API on the Windows kernel, which proved to be much more complex than it appears to be.

I've long wondered, and again now that Chat GPT is proving so adept at coding, if this translation layer could be automated. Do humans actually have to hand-code each syscall? Or are there just enough edge conditions that can't be automated?

Re: macOS Containers v0.0.1

#227

Post by slonopotamus »

radlad wrote: post #225
slonopotamus wrote: post #175

Earlier quoted context omitted.

What exactly attack vectors you think are possible against macOS without SIP but not possible against Linux?

I think the argument is that file permissions may not be applied as rigorously, with the assumption that SIP is in effect.

SIP won't save you from wrong file permissions.

And SIP doesn't defend you from editing files in /bin. They are guarded by the fact that root filesystem is mounted read-only.

Re: macOS Containers v0.0.1

#228

Post by pohl »

xmodem wrote: post #177
pohl wrote: post #159

Earlier quoted context omitted.

macOS had granular directory permissions way back when it was NeXTSTEP, long before SIP was introduced. Where are you suggesting they disappeared to?

It still has them, of course, but the concern is that after ~8 years of SIP basically ~everywhere, platform security decisions have been made assuming it is present. This concern is definitely not totally unfounded, back in 2019 Chrome shipped an update that rendered systems with SIP disabled unbootable: https://support.google.com/chrome/thread/15235262?hl=en

The "varsectomy" bug in Chrome isn't the example you think it is, because disabling SIP was not sufficient conditions for it. There were 3 other conditions that had to be met, the most notable of which is that "/" had to be writeable by tho logged-in user, which is not the default.

This is an example of defense-in-depth being present, and defense-in-depth still failing for some users who gave escalated permissions to some installers, allowing them to run roughshod over their filesystem permissions, leaving them vulnerable to a subsequent varsectomy. If one did the same thing to their Linux system, the same thing could happen.

https://arstechnica.com/information-technology/2019/09/no-it...

Re: macOS Containers v0.0.1

#229

Post by kevincox »

AceJohnny2 wrote: post #6

How does this work? Fundamentally, containers are about namespace/isolation of a bunch of OS interfaces, so file system functions, network functions, memory management, process functions, etc, can all pretend like they're the only game in town, but crucially without having to virtualize out the kernel. Does XNU have such namespacing functionality across all its interfaces? Furthermore, the existing container ecosyste…

I am also interested in the API boundary. It seems that there are too options:

1. Rely on system call stability. This is like Linux containers but unlike Linux macOS doesn't provide a stable system call API. So this would break when the system updates with a change that modifies the system call API.

2. Install the host libraries into the container at runtime. This should provide as much stability as macOS apps usually have. It may also be beneficial as you wouldn't be embedding these into every container.

It seems like 2 would be preferable. However it may be a bit weird when building as the libraries you build against would be updated without the container being aware, but this is unlikely to break anything unless they are copying them to new paths which seems unlikely.

Re: macOS Containers v0.0.1

#230

Post by jmbwell »

diogenes4 wrote: post #218
digitalsushi wrote: post #191

Earlier quoted context omitted.

I want that feature on cause I dont want stuff I dont know about looking and changing stuff I dont know about, whether it's running with escalated privileges or not

I doubt you (or any human) is capable of enumerating what you don't want looked at. Frankly, I doubt most of this unknown area is covered by SIP at all, and it would be extremely odd if it did. Perhaps you might consider arguing for actual permissions rather than arbitrarily walling off the OS in a way that tangentially benefits the monopoly Apple holds over their own computers. Wouldn't it be far easier to enumerate…

SIP means not messing with the system files, enumerated thusly: /System.

Enumerating what I do want an app to access is handled by Gatekeeper.

Post reply on HN