Live data from Hacker News

macOS Containers v0.0.1

macoscontainers.org

291–300 of 374 posts

Re: macOS Containers v0.0.1

#291

Earlier quoted context omitted.

> "Disable System Identity Protection." This is the first thing I do on any Mac OS system before I start using it.

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.

The hardware is what's good in Macs, with Apple Silicon, not the software, which I use begrudgingly.

Re: macOS Containers v0.0.1

#292

https://github.com/macOScontainers/homebrew-formula "macOS native containers" Cool, this sounds interesting. "Disable System Identity Protection." Eesh.

"v0.0.1"

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)

Re: macOS Containers v0.0.1

#293

https://github.com/macOScontainers/homebrew-formula "macOS native containers" Cool, this sounds interesting. "Disable System Identity Protection." Eesh.

I'm sure they'll overcome this! Rootless containers are a thing after all!

Re: macOS Containers v0.0.1

#294

Earlier quoted context omitted.

I understand that of course, I'm much more curious why you think this is a concern for people, and/or why you consider this an effective protection against said unknown actors.

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

Why would it be running with escalated privileges if you don't know what it is ?

Re: macOS Containers v0.0.1

#295
post #267

Earlier quoted context omitted.

> But Apple provides a neat virtualization framework, and you get security + isolation + reproducibility + decent performance. 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've only used it with Linux kernels, but that has not been my experience with the new Virtualization.framework. The perf of virtio shares is reasonably fast. 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…

> If it's isolation for builds, fix your build

Isolation fixes the problem for free and is more similar to how I build for Linux. Why would I want another solution?

Re: macOS Containers v0.0.1

#296
post #266

Earlier quoted context omitted.

> I don't think OS becomes any less vulnerable than usual Linux/Windows installation. 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.

I think you're probably @totallywrong

Well Linux powers just about all the most important systems in the world and SELinux was originally developed by the NSA, but I'd love to get your insights.

Re: macOS Containers v0.0.1

#297
post #245

Earlier quoted context omitted.

As long as the architecture satisfies Popeck and Goldberg, why shouldn't it?

The point of Asahi is to provide linux drivers for Apple hardware. What would be the point? You can already run Linux in a VM on arm macOS today with good performances. You don't even need to disable SIP.

Passing through a device and using it in a VM.

Re: macOS Containers v0.0.1

#298
post #268

Earlier quoted context omitted.

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.

How so? I use docker pretty frequently, but I’m sure that my user is part of the docker group before I do, so I don’t sudo anything. 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.

In a typical installation, being in a docker group gives you access to a socket that controls docker daemon and that daemon runs as root. `sudo` is not important in this context.

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.

Re: macOS Containers v0.0.1

#299

https://github.com/macOScontainers/homebrew-formula "macOS native containers" Cool, this sounds interesting. "Disable System Identity Protection." Eesh.

OrbStack doesn’t require breaking security: https://orbstack.dev/

Does OrbStack allow you to create MacOS Containers? It doesn't seem like it from their website. It seems like it just runs on MacOS to let you create Linux containers.

Re: macOS Containers v0.0.1

#300
post #294

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

Why would it be running with escalated privileges if you don't know what it is ?

I feel like you're assuming that applications have to be honest about what they are when they request a user-prompted permission. SIP makes that irrelevant.
Post reply on HN