macOS Containers v0.0.1(macoscontainers.org) |
macOS Containers v0.0.1(macoscontainers.org) |
Yep, this is primary goal of this project.
I would be very curious as to how you already run darwin containers.
The only alternative is spinning a macOS VM (including relying on macOS CI machines as a remote job executor)
Something like namespaces or proper jails on darwin would be super cool, but not at the expense of other security measures and chroot-ish outcome imho. Maybe this works for some, but not me :)
They’re not even trying, now.
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.
macbook is the best laptop there is but macos...
can't wait for a stable release of Asahi and permission from corporate to install it even in a VM somehow. probably won't happen, but one can dream.
I know company policy moves glacially with these things (been there, got the faded t-shirt!) so yea, you're probably right there. Technically you could probably still use linux MDM instead of MacOS for mgmt, but getting that past IT is nigh on impossible imho also.
Ah, I understand your angel, in that your use case is to run namespaced processes that achieve some functional purpose irrespective of the underlying kernel/platform, which is totally fair.
> not at the expense of other security measures
Not for me either... that is, not in a host OS, maybe a dedicated VM; I consider this to be as it says on the tin, 0.0.1, a thing that would help bootstrap an ecosystem of containers, which would push towards Apple adding namespaces or jails (oh, hell yeah, JailKit!) to darwin.
You're missing the point. This project DOES use docker.
Xenix and Coherent were the first UNIX on consumer hardware.
Apple is rarely the first at doing something but it's often the first that's good and cheap enough that people care about.
Please cite a USENIX research paper from Apple.
Amiga, Atari, BeOS, OS/2, Windows, classical Mac OS,...
But it was after they released their implementations that those ideas caught on.
I hope you can see the point I’m making.
The Hollywood studios that now use Apple, would be using SGI previously.
On iDevices, UNIX APIs aren't even that relevant for app development, even basic stuff like networking has been superceeded by Objective-C specific APIs.
So no, I don't see anything UNIX related where Apple has helped to caught on.
Moving beyond UNIX, now that is a thing NeXT and Apple have done a lot.
Perhaps if you read “Rethinking PID 1”, from Lennart Poettering in 2010, who originally wrote systemd along with Kay Sievers
http://0pointer.de/blog/projects/systemd.html
“But first, let's clear a few things up: is this kind of logic new? No, it certainly is not. The most prominent system that works like this is Apple's launchd system: on MacOS the listening of the sockets is pulled out of all daemons and done by launchd. The services themselves hence can all start up in parallel and dependencies need not to be configured for them. And that is actually a really ingenious design, and the primary reason why MacOS manages to provide the fantastic boot-up times it provides. I can highly recommend this video where the launchd folks explain what they are doing. Unfortunately this idea never really took on outside of the Apple camp.”
Other than that, your answer has nothing to do with what I wrote.
It’s just that influence is not all about being first.
"macOS native containers"
Cool, this sounds interesting.
"Disable System Identity Protection."
Eesh.
(More details here: https://support.apple.com/en-us/102149 )
WRT security implications of disabling SIP - I don't think OS becomes any less vulnerable than usual Linux/Windows installation.
Not every workload is running on an endpoint connected to a human via keyboard and screen.
Isn't this especially dangerous on a build worker? All your source code goes in and you (presumably) use the binaries that come out across the rest of your infrastructure. Compromising a build worker in a persistent fashion due to lack of SIP seems like it could do some serious[1] harm...
There's probably a hundred things that are not right just yet and they know it, let's not be overly negative
(although the discussion on what it is and what it does definitely is interesting)
This is the first thing I do on any Mac OS system before I start using it.
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.
Edit: to be clear for the people who may not know, Apple Pay does not work with SIP disabled. ;P
Aaand, it's stillborn. Not happening.
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 ecosystem assumes a Linux syscall interface. [1]. Does macOS provide that? I expect not.
The way Docker Desktop (and podman.io) implement "containers on macOS" is a bit of a cop-out: they actually run a Linux virtual machine (using Hypervisor.framework/hvf), and have that just provide the container environment.
Is that what this project is doing? But then, how could it run a macOS container?
[1] based on the foundation that Linux, unlike BSDs, has a stable syscall interface!
I get the point of isolation for build/test situations. But Apple provides a neat virtualization framework, and you get security + isolation + reproducibility + decent performance.
It seems like if you feel the need to containerize the userspace on MacOS you're using MacOS wrong. It's not the same thing as the Linux userspace, and doesn't have the same kernel features that would let you do so cleanly or performantly.
Orbstack is moving mountains to provide Linux-native perf and support for containers and it still makes me beg the question: why are devs allergic to just using Linux natively? At least I understand why Orbstack is useful, I don't know why containerizing MacOS itself is.
You also get limits on how many VMs your machine can run, each VM needs gobs of storage and locked-out RAM blocks, and sharing directories between the host and guest, compared to bind mounts, is something that makes me remember for my root canal dental jobs wistfully.
I can see how you'd need a crap ton of disk for MacOS virtualization, but again, why do you need it?
If it's isolation for builds, fix your build. If it's isolation for tests, live with it. If it's for running your app, write your app to properly run in the app sandbox.
Or is this just the fully open source Darwin core? That wouldn't likely be super compatible with a ton of production software? I need more explanation of what is actually going on here because it sounds like a good way to get sued.
1. This project didn't take explicit permission from Apple to redistribute binaries
2. There are multiple jurisdictions where you don't need to explicitly have such permission, it is implied by law
3. Usage of this software implies you already have macOS system. I'm not a lawyer, but it looks to be covered by section 3 of macOS EULA.
4. There are existing precedents of redistribution of macOS binaries for multiple years aready:
- https://github.com/cirruslabs/macos-image-templates/pkgs/con...
- https://hub.docker.com/r/sickcodes/docker-osx
- https://app.vagrantup.com/jhcook/boxes/macos-sierra
And so on.
Unless you're producing fully static binaries (or static enough that they don't bind to non-redistributable things) it'd be a yes (it would not be much of a container if it needed non-packaged things)
The screenshot points out a ghcr.io URL that lands on these packages: https://github.com/orgs/macOScontainers/packages?repo_name=m...
Edit: There's a note here†, so at least there is some consideration for licensing. No idea if it holds ground.
† https://github.com/macOScontainers/macos-jail/blob/9b1d5b141...
Note: I work at Earthly, but I'm not wrong about this being a good, free, arm64-native workflow for GitHub Actions.
https://github.com/macOScontainers/rund - new code
https://github.com/macOScontainers/moby - fork, 6 commits
https://github.com/macOScontainers/buildkit - fork, 4 commits
https://github.com/macOScontainers/containerd - fork, 5 commits
Would be interesting to see if they can get moby/buildkit/containerd changes upstreamed
Other part of containerd changes waits for gods-know-what: https://github.com/containerd/containerd/pull/9054
But I haven't gave up yet.
Sorry for that we had to revert #8789, but we are looking forward to seeing that PR submitted again with an alternative abstraction interface.
It's intended to prevent malware from changing system files due to rogue permissions or escalation. With SIP enabled, even the root/sudo user doesn't have rights to change these files.
It also refuses to boot a system with drivers that are not signed by Apple, so as to deter malware from using drivers as an attack vector.
Not really. «Secure Boot» is intended to secure the boot process through signature verification. However the security model is completely broken, https://arstechnica.com/information-technology/2023/03/unkil...
SIP is a protection layer which protects system files from modification also after the system is booted.
It clearly links to the GitHub where you can click to see all contributors
I suppose the answer to your question is “people who want macOS containers”, whoever they are. As far as malware, I’d employ whatever your standard practices are for installing GitHub projects
I bought an Apple Silicon machine after their presentation claiming that they would have first class docker support, but the reality has been that while the first docker worked well as it was translated, now it wants to default to arm containers and it has become very difficult to use because it doesn't want to use Rosetta 2 containers.
The whole point of using docker is to use the same containers in production as you use in development, so having docker default to these random arm containers means that my containers aren't exactly production, because they are arm based and the servers are not.
I understand that docker is the developer of docker software, but I really wish I could just click a button and force intel based containers in docker as the default and have to opt-in to arm.
If anyone has an easy solution to this let me know. I don't want to spend hours and hours figuring out docker on my mac.
macOS apps have to be signed and notarised to run without a warning, which is a pretty big part of the defence picture for this software - the certificates can be revoked at any time to block the software if malicious behaviour is identified.
However, if I install Homebrew, then install python, then install a pip package, there's really no kind of scanning/notarization/checking happening at all. I wonder if this is something Apple has ever looked into - it seems like the exact scenario where you'd want to sandbox it away from the rest of the system.
At the same time, I don't truly understand why anyone would need to use it. If your preference is to totally work with macOS, then I'm sure this would be perfect for that. Otherwise, what's the advantage?
VMs have really come a long way. Every major OS today has a virtualization framework that makes running another OS extremely performant. Docker on macOS uses a virtual machine, but so what? Performance of individual containers, in my experience, isn't really a problem unless you're doing something with the GPU, and even then there are ways to deal with that. Even a fully-emulated VM using QEMU (without hypervisor or KVM) won't have any noticeable performance penalties in many cases.
IMO, there's a much greater advantage to sticking with Linux. Even if the host isn't Linux, developing and deploying with Linux guests provides a tremendous level of consistency and portability.
But maybe I'll be proven wrong by this project someday soon!
Of course the drawback would be that the host would see just a fat Linux process and its child processes, much like you can see qemu, but it could be an interesting thing nonetheless, if even for shits and giggles of it.
linux is great. macos is great. windows is great too. for their intended purposes.
it’s horseless carriages all the way down.
Trying to break out of that is an exercise in futility.
Can you come up with situations where I would run a container instead of just running an app or sys service?
rund is an experimental containerd shim for running macOS containers on macOS.
rund doesn’t offer the usual level of container isolation that is achievable on other OSes due to limited macOS kernel API.
What rund provides:
Filesystem isolation via chroot(2)
Cleanup of container processes using process group
OCI Runtime Specification compatibility (to the extent it is possible on macOS)
Host-network mode only
bind mountsI believe this is the problem with the format of semantic version which seem to assume that releases only happen to software ready to be... released :)
My preferred course of action in such situations is not specify a version at all.
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 really only doing it to fleece you on obscene upgrade fees at the time of purchase - but it would be nice if there was a more elegant solution to this on Windows and macOS.
WSL 1 had a solution to this that clearly took a lot of work to put together, wherein they'd have a Linux kernel running side-by-side as a Windows sub-process so that the memory pool was shared. Unfortunately it might have been too much work as they scrapped it entirely for WSL 2 and just used essentially the same VM route.
If anyone knows of any projects trying to work around that problem I'd love to hear about it. If Apple really wanted to bring the development community back on board, focusing on these kind of use cases would be great, sadly it seems someone over there has taken the view that scrapping butterfly keys and the touchbar is "enough".
Say what you will about Microsoft, but they've focused really hard on developer use cases for decades, and it shows.
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 you want to exec a Windows binary in a container, the Windows kernel needs to provide process namespacing features (which it does). And if you want to exec a Darwin binary in a container, then the Darwin kernel needs to provide process namespacing features (which it doesn't).
† WSL1 was implementing the Linux syscall API on the Windows kernel, which proved to be much more complex than it appears to be.
†† Or colinux (https://en.wikipedia.org/wiki/Cooperative_Linux), or user-mode Linux (https://en.wikipedia.org/wiki/User-mode_Linux).
autoMemoryReclaim – Makes the WSL VM shrink in memory
as you use it by reclaiming cached memory
Obviously that limits the options, but I'll still be taking one last shot at using creative workarounds to tackle the memory problem in OrbStack (another containers-on-macOS product).
I imagine over time it will get smarter too. Right now it waits for no containers to be running for 30 seconds and enables resource saving mode but who knows what could happen in the future. Maybe it can internally profile and estimate load based on evaluating runtime stats of your contains and dynamically change the VM's resources on the fly and then expose a +% over provision threshold option or a way to turn off dynamic resource saver mode.
Edit: It has been a while since I last looked at this. Looks like containerd is, perhaps, a native option
When Windows containers are being used, it is just there to keep the docker daemon happy.
rund is an experimental containerd shim for running macOS containers on macOS.
rund doesn’t offer the usual level of container isolation that is achievable on other OSes due to limited macOS kernel API.
What rund provides:
- Filesystem isolation via chroot(2)
- Cleanup of container processes using process group
- OCI Runtime Specification compatibility (to the extent it is possible on macOS)
- Host-network mode only
- bind mountsExcept for bind mounts (not even overlayfs...) there isn't much interesting.
> - Host-network mode only
Yeah expect a lot of things to break in subtle ways... most containers are developed kinda expecting you have your own network namespace (and that no one else is using ports)
Essentially, like this:
https://ericchiang.github.io/post/containers-from-scratch/
https://earthly.dev/blog/chroot/
> The way Docker Desktop (and podman.io) implement "containers on macOS" is a bit of a cop-out
It's not, it's a requirement for running Linux containers: https://news.ycombinator.com/item?id=37656401
DfM is more like running the CLI locally to a remote Linux machine, and all it does is conveniently expose /Users in the same place through the VM folder share so that you have the convenient illusion that it happens locally.
If Darwin had process namespacing features it would not make it magically able to run Linux processes.
I don't think so, but some Docker features could be implemented using XNU sandboxing AFAIK
> Furthermore, the existing container ecosystem assumes a Linux syscall interface. [1]. Does macOS provide that? I expect not.
This project is about running macOS containers on macOS. It's not about running Linux containers.
> I don't think so, but some Docker features could be implemented using XNU sandboxing AFAIK
Theoretically, probably, for coarse-grained yes/no things? I don't think it's able to go much further than "you can use the local network and/or internet" and "you can read/write to the filesystem location corresponding to you bundle identifier `com.foo.bar`" but not "hey let me present you with a namespaced view of loopback or process list".
Also not sure if it can be dynamically set by a parent process for a child? Seems like it's very bundle oriented (except maybe for Apple processes) so not very practical.
There is more to the container ecosystem than Linux containers; Windows native containers function much the same way (well, in two ways, with VM-backing or the traditional kernel syscall interface, but with Windows syscalls).
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.
I'm really wondering, do you have any links about macOS syscall stability over versions?
A normal version number MUST take the form X.Y.Z where X, Y, and Z are
non-negative integers, and MUST NOT contain leading zeroes. X is the
major version, Y is the minor version, and Z is the patch
version. Each element MUST increase numerically. For instance: 1.9.0
-> 1.10.0 -> 1.11.0.
Oh, wait. The spec was written by some... big brain:
Major version zero (0.y.z) is for initial development. Anything MAY
change at any time. The public API SHOULD NOT be considered stable.
Just two paragraphs below. How lovely.
- there has been images like that circulating on well-known platforms† for a long time.
- I never heard of a single DMCA on any of these, even though they were on much clearer violation of the license.
Apple might be pulling a Hackintosh manoeuvre here.
† an example, there are many others: https://app.vagrantup.com/jhcook/boxes/macos-sierra
is this that much different?
* The most obvious is the commonly mentioned fact that syscalls may change. Here is an example where golang program broke because they were directly using the `gettimeofday()` syscalls[2].
* The interface between the kernel and the dynamic linker (which is required since ABI stability for statically linked executables is not guaranteed) is private and may change between versions. That means if your chroot contains a `dyld` from an OS version that is not the same as the host kernel it may not work.
* The format of the dyld shared cache changes most releases, which means you can't just use the old dyld that matches the host kernel in your chroot because it may not work with the dyld shared cache for the OS you are trying to run in the chroot.
* The system maintains a number of security policies around platform binaries, and those binaries are enumerated as part of the static trust cache[3]. Depending on what you are doing and what permissions it needs you may not be able to even run the system binaries from another release of macOS.
In practice you can often get away with a slight skew (~1 year), but you can rarely get away with skews of more than 2-3 years.
[1]: https://developer.apple.com/library/archive/qa/qa1118/_index...
[2]: https://github.com/golang/go/issues/16606
[3]: https://support.apple.com/guide/security/trust-caches-sec7d3...
It’s a core part of how macOS is prevents unauthorised modifications to the operating system and file system by malicious software.
TLDR: it restricts even the root user from modifying system files. Like the ones that would otherwise be the target of malware.
If the latter, it's definitely a footgun but you shouldn't be using it for applications. It's a legacy binary for scripts.
Yes, it can. See sandbox-exec tool. And I actually plan to use it: https://github.com/macOScontainers/rund/issues/15
I played with it some time ago, can't recall the context but it was about build systems / packaging (maybe nix?), doing the configure/make/make install with reduced privileges.
https://github.com/koekeishiya/yabai
For instance requires SIP to be disabled.
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.
I guess you don't use Homebrew or MacPorts?
There is: you are running that pip package in a chain of processes: Terminal (or iTerm, or whatever) - your shell - python - pip package. In this chain, Terminal has "Developer Tools" privilege, which allows you to run software, that does not meet the system's security policy.
You can disable this privilege in System settings, Privacy and Security panel.
This is my point, Terminal with Developer Tools privilege is essentially granting carte blanche privilege to every sub-process running there, which is not really necessary.
If I could pop a Terminal with a restrictive scope, allowing read and write access only within that directory tree it would be a much better situation than we have now. macOS' permission system isn't really that far away anyway - I can already disable Terminal's permissions to access anything else same as other apps.
Essentially a basic and very limited not-even-a-chroot would be a vast improvement and would still offer an adequate sandbox.
We don’t even have certainty that the human running the account is who they say they are (anyone can make a GitHub account and make it look like a real person).
Not everyone who wants to use a container system understands the underlying code of that container system. If I’m a web developer using Docker Desktop or podman to build my PHP app, I’m not necessarily going to understand the code written in Go when my specialty is PHP.
With the source code available and the primary contributor clear, what more could anyone want? Certainly it’s a bit much for one to ask for a security audit they themselves won’t do
Reproducible builds. :)
If I am a developer using podman/Docker to build my PHP images, am I expected to understand code written in Go?
These are all acceptable risks until someone is asking me to disable SIP.
Isolation fixes the problem for free and is more similar to how I build for Linux. Why would I want another solution?
Further you can sandbox processes just fine on MacOS without needing to mock the whole userspace, like you do on Linux. This will give you the same degree of isolation that a container does.
But still not "as fast as it gets". And I want it to be as fast as it gets.
My point is "as fast as it gets" is using MacOS how MacOS is designed: ie, through sandboxing and not containerization that pretends the MacOS userspace is Linux. It's not Linux.
There is a fundamental trade off between isolation and performance. You cannot securely share resources without overhead.
[1] https://capitaloneshopping.com/research/apple-pay-statistics...
This doesn't work because, well, I do make releases and they need some numbers)
If you release it, it has to start with version one. Zero is for non-released versions.
I think the only true solutions are (a) OS vendors develop their own native container platforms with UX similar or better than Docker (b) OS vendors agree on some common ABI standard
FTFY ;) (and thanks!)
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?
So, I won't preclude the idea of AI helping, but I think human effort is still the bottleneck for projects like this. Even if AI could write perfect code 100% of the time, testing and troubleshooting would probably still be the larger timesink.
> So essentially a chroot with a bit of make-up
Well.
1. It is not trivial to properly set up a chroot on macOS. If you try to find a working guide/tool that works with modern macOS, I doubt you'll find anything (at least, I failed, even though tried very hard) 2. I believe that ability to package stuff into a Docker image distributable via already existing infrastructure and compatible with already existing tools maybe "a bit of make-up", but it is an important makeup. 3. Kubernetes recently got HostProcesses for Windows: https://kubernetes.io/blog/2022/12/13/windows-host-process-c.... They are even less isolated from host than chroot and still, people find them useful for certain scenarios.
> and a lot of marketing?
Thanks for "a lot of marketing", that made me chuckle. My own submission got buried yesterday with humble 8 points: https://news.ycombinator.com/item?id=37640688
Container definition is very stretched nowadays. Look at Windows HostProcesses in Kubernetes [1]. They don't have neither process, network nor device isolation from the host.
I also plan to try macOS sandbox-exec tool, which should offer additional isolation from the host.
[1]: https://kubernetes.io/blog/2022/12/13/windows-host-process-c...
- bind mounting solves the exposition of filesystem within the root pivot.
- overlayfs solves the persistence efficiency issue using a layered union fs.
> most containers are developed
Most Linux (and Windows) containers. Since these are macOS containers there are no containers developed yet so by definition there is nothing to break.
Wouldn't it be far easier to enumerate what you want an app to access?
Enumerating what I do want an app to access is handled by Gatekeeper.
...and all its children, which is effectively the entire operating system
> Enumerating what I do want an app to access is handled by Gatekeeper.
Gatekeeper is not capable of this.
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 still see a lot of friction with containers so I might be looking at framework for my next device. Or just go all in on client/server development model.
I hear this said a lot in passing, and I'm really curious what people mean when they say this.
Beats all the package management experiences I've had on Windows, admittedly I have not tried to use Windows for work for >1 year.
[1] https://brew.sh
Is there a way to make a separate partition of MacOS and have one copy with SIP and one without?
I'd say that the whole containerization topic is niche
> Is there a way to make a separate partition of MacOS and have one copy with SIP and one without?
I think you can install macOS VM on your macOS host and disable SIP _inside VM_.
i haven't found any issues with it that i could not get over in the past 2+ years of m1. most of the containers are available on both architectures anyway. the performance improvement was totally worth it, i won't even talk about the heating issue with intel.
I'm currently running a Journal of Open Source Software x86 container on aarch64 and it's terribly slow. Takes 12GB of RAM and 3 minutes to build a LaTeX document, see https://github.com/openjournals/inara/issues/30. Any tips?
In my experience, this has not been an issue for the past 10-15 years atleast. Before that there were some problems with few (external) soundcards or random cpu spikes with the mixers.
However, the UX can still improve. Switching audio outputs with multiple outputs like external displays etc is not very smooth or intuitive.
Some bluetooth headsets have issues but I've had those with a mac as well.
There is great audio software coming to Linux (Bitwig, Reaper, etc) which is great but the underlying infrastructure is a mess.
There are like 3-4 audio subsystems running, I never know which one is it, setting latency is wizardry and sometimes it doesn't run at all. It's usually fine when I run stuff like Spotify, VLC, or Youtube in Firefox, so for user-level audio, Linux is fine IMO. But when I run something where I care about latency and multichannel output, it's hit or miss. It runs fine one day and then I get no sound on another or distorted sound or sound playing at wrong speed and wrong pitch (yay, 44,1 vs 48).
Maybe it's the distros I'm using, maybe there are some that work better, but the UX isn't as great as with macOS. On Manjaro, update sometimes get audio notification removed from tray and I can't change volume using mouse or dedicated keys. Then I have to look for few hours for a solution only to have the same thing happen again three months later (same with brightness keys on laptop). On Ubuntu Studio with an external soundcard, I get randomly distorted sound or no sound at all. So it's easier to use some shitty onboard sound, great.
I like Linux, I use Linux daily, but sound on Linux is terrible. It's much better than it was, yes, but still terrible. For anything more than "play a song here", macOS is much better.
I moved from Linux to M1 MacBook recently. I know my greps and vims, but I was tired of audio glitches during high CPU usage, system not waking up from sleep, total OS freezes, super loud fans, and so on.
Now I get none of that. I don't think I've ever heard the fans. Audio just works, everything is super snappy. It always wakes up. I'm no longer afraid of bluetooth.
And on top of that, setting my $DAYJOB VPN took three minutes and it just works, where on Linux I had constant problems with DNS breaking, and setting it up was always an hour of work, praying I got the config files right this time.
It really seems to be "unixy desktop with working sound", the best of both worlds.
And a 90% chance it'll be at least one such thing.
On my desktop I couldn't even boot installer without running with safe mode, otherwise I'd just get stuck on a blank screen (ancient 1050 TI GPU and standard desktop components otherwise, so not exotic/new stuff).
I've used linux desktop for >decade and Gnome shell feels like home but these days I feel like I don't have the time for linux adventures. Maybe I'll mix it up with my next device, but I'm not reading great things about AMD power modes and Linux.
May be some confusion. To run linux on a newer Mac with "Apple Silicon" (ARM based), you need to go through a lot of hoops and much work needs to be done still for a stable environment. Check out https://asahilinux.org/about/
Or maybe you thought they meant running linux in general on a PC (Intel x86 32/64 bit)? In that case I agree - driver issues like that have been mostly ironed out by now.
I would expect a very small number people making this choice over security concerns.
No? Maybe you're preferring Mac OS for getting stuff done, exchange work with the outside world and/or use non-historic software (like any commercial desktop app such as idk Photoshop, Sketch, Audio, 3D, CAD s/w, etc., etc.) and still are a developer?
Or even doing something esoteric such as using office software without wanting to throw your notebook out of the window?
Connecting to a Mac Agent with Visual Studio on Windows gave me nothing but headaches.
I only ever really had one goofy driver/deep OS bug in Mac - something with the location daemon would cause the wireless internet connection to cut out repeatedly. That bug was left behind with that machine when I left that company, and didn't appear in my next macbook pro.
Linux is just always a struggle with drivers, subtle bugs, and other misc friction. It's not a dealbreaker - ubuntu 22.04 is still my daily driver, but it's very much enough that I would prefer a mac for most development.
For example, if I run a software update, it quietly breaks the fn keys to change screen brightness, and when the machine wakes from sleep, the screen stays black. I figured out after much trial that running ubuntu-drivers fixes it, but it's a pain. I'd rather just turn off auto-updates.
Also the Command key for keyboard shortcuts is brilliant and just works across the whole system. On linux I have to use ctrl-shift to copy/paste and I haven't found a good workaround yet.
Conversely, macOS is broadly 'production grade'. It mostly 'just works' (with a number of tweaks - including SIP -, hacks etc on initial config, most power users automate with dotfiles). It has a drastically better UI, first class terminals and unixy support, and most code built for it has a higher level of shine.
I am confident enough to deploy alternate security implementations for the convenience of full FS control, as I know many power users are. Disabling SIP is a bad idea for those who don't understand it, the same as disabling Windows Defender or forwarding NAT on your router.
My work provides it. Everyone else uses it and I don't want to be the one with a different setup.
I would not consider Linux sound Terrible, but to be fair, I only use it every day for regular development tasks for the last 10 years. Maybe I've become accustomed to whatever problem you see that I don't.
Hmmm once every full moon MS Teams running on ungoogled chrome do not seem to realize my Bose BT Headset is paired and available (and in that case I just use the internal soundcard) but I have seen people having sound issues on MS teams and needing to reboot regardless of the OS they were using. Windows, Linux, even some MacOS users so I wouldn't use that as a generalization.
There's your issue. Use an aarch64 image.
[0] https://formulae.brew.sh/formula/coreutils
[1] https://apple.stackexchange.com/questions/69223/how-to-replace-mac-os-x-utilities-with-gnu-core-utilitiesI do find it amusing in a thread about how you have to turn off a core security feature to be able to use containers properly on a Mac that the discussion immediately turns to how bad Linux sound drivers supposedly are. Honestly, I went in the other direction (Mac to Linux) and I've found the waters to be just fine. I don't know if I just have the magic touch or something, but ¯\_(ツ)_/¯.
But this isn't bashing on linux desktop (I would use it if Mac wasn't an option) as much as giving a reason why people would use MacOS despite being annoyed by SIP.
Things like macports and pkgsrc do things in an arguably much simpler, more unixy way, without the contortions that so often seem to leave homebrew in a bind after routine operations like updating.
Also, assuming a downstream distro like Debian or Ubuntu, what's in Homebrew is likely a more up to date package. You could fiddle with adding/using Debian testing or some PPA, or... you could just use Homebrew.
(FWIW: I use Arch and the AUR on my desktop Linux installs these days, and it's essentially the same process. But still using Homebrew on the Mac, and occasionally in Linux when I'm not on a desktop)
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.
Is there anything else I should be doing security wise?
I’ve been hearing podman is more secure, but I think it’s still containerd under the hood, so idk how true that is.
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).
Removing SIP from a system that relies on it as a basis for platform security is different than using a system that wasn't relying on it in the first place.
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
In reality they done basically everything to force users to use secure boot. If they disabled normal boot altogether, OS adoption would suffer heavily. They could've obscured that option, but it would be found out, and enterprise users would be pissed at them because they didn't gave them a provisionable way while the way exists. So it came down to normal variables in installer registry.
However modifying, e.g making users "hack" the ISO is really as forceful as it gets without market loss.
Note: There may be more normal way today than modifying the registry of ISO, I installed 11 once when it came out.
Is this related to the code you tried to have merged here: https://github.com/containerd/containerd/pull/8789 ?
Vanilla containerd cannot mount anything on macos.
> If you really want good adoption, you’ll have to figure out a way for devs to try it out without first having to disable SIP.
I can't stress enough how I also would like it to work with SIP enabled!
No matter what you or I think about what's needed for adoption, technical problems get in the way of the tool working with SIP, so seems it's in Apple's ball court really.
Think places where security is a big deal, like finance, military, aerospace, critical infrastructure etc.
This is not an alternative to remotely connecting to a VM to control Linux containers (which DfM is)
They did not have such success on windows, despite Windows also having a container subsystem, as windows servers already did this with IIS web app containerization.
On MacOS desktop software distribution is largely a solved problem since ages. On MacOS/Darwin servers... are there such in industrial use apart from some research installations?
Maybe for an automated test CI/CD running system (which is probably the main use-case), but not on anything that users would interact with.
That's a technical limitation.
If it really isn’t technically possible (which I think you might be able to do in a Darwin VM), then maybe this approach isn’t a good idea.
A modern Linux with SELinux enabled (the default in e.g. Fedora) running apps inside rootless containers (Podman doesn’t even need a daemon) is likely much more secure than your default MacOS or Windows.
Where SELinux really shines is in server installs.
A decade ago SIP didn't exist at all. I thought disabling SIP just put us back to how things were in Yosemite. What changed?
Sure it does not attempt to map fsevents<->inotify 1:1 but honestly I can live with that limitation given that it's a 10x performance increase compared to the DfM kitchensink.
I do go native darwin when I can / it makes sense.
Can you say anything more about what you did instead, and how it ended up working out?
And SIP doesn't defend you from editing files in /bin. They are guarded by the fact that root filesystem is mounted read-only.
The way that podman and newer versions of docker get around this is using unprivileged user namespaces. Unprivileged user namespaces are not a free lunch - in fact, they're a bit of a security disaster in their own right.
Thankfully there is rootless mode for some time now: https://docs.docker.com/engine/security/rootless/.
Podman, too, can run in rootful and rootless mode. Rootless in podman still feels to me to be more like first class citizen, as opposed to docker case.
In both cases it's important to keep in mind in which mode you operate. Both from the perspective of security and day to day operations, as some aspects of behavior will differ between those modes.
Of course, if you are using Go or some other language with a fast, static cross-compilation step, you don't need to mount a source code volume into your container, you can just rebuild the whole container image or rebuild on the host and `docker cp` the new binary onto the target container.
I believe this project can be useful for CI and testing scenarios.
> On MacOS desktop software distribution is largely a solved problem since ages
Are you talking about App Store? Or Homebrew? Or MacPorts? Or... Wait, isn't this too many tools for a problem that was solved?
Tomorrow Apple might decide it is safe to chroot with SIP enabled (I actually do not understand why they restrict it, chroot is a tool to increase security). Does that suddenly convert bad design into a good design? But this is exactly the same design.
Does this current design require disabling SIP? Then I don’t think it is worth my effort to use (for my use case). If Apple changes the system in the future, my opinion might change.
But a design cannot be judged as good or bad outside of the context for which it was designed.
If you feel this is a better way to tackle the problem, then talk to Apple about it.
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...
1: https://support.apple.com/en-gb/guide/security/secd698747c9/...
No
> or are you saying you sort of roll your own DfM alternative?
Yes, I set up a NixOS VM and use DOCKER_HOST=ssh://docker@<ip>
If you want to have it easy you can roll with lima/colima (but I found the fs sharing slower than vmhgfs)
> Also, what does "VM isolation" mean here?
The host/guest boundary. The guest is just like any another, remote machine. DsM adds smoke and mirrors to make it look like guest and host are one.
> How is NFS or VMware Fusion more "isolated" than DfM?
It's not, both are VMs and need a way to expose the host fs to the guest, NFS or vmhgfs are a means to that.