https://github.com/macOScontainers/homebrew-formula "macOS native containers" Cool, this sounds interesting. "Disable System Identity Protection." Eesh.
macOS Containers v0.0.1
51–60 of 374 posts
Re: macOS Containers v0.0.1
#52https://github.com/macOScontainers/homebrew-formula "macOS native containers" Cool, this sounds interesting. "Disable System Identity Protection." Eesh.
> "Disable System Identity Protection." This is the first thing I do on any Mac OS system before I start using it.
Re: macOS Containers v0.0.1
#53Why should anyone trust this website and download the software? There's no indication who made it. Could be malware for all I know.
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
Re: macOS Containers v0.0.1
#54Earlier quoted context omitted.
>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…
> Maybe they want a unixy desktop with working sound ? 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…
And a 90% chance it'll be at least one such thing.
Re: macOS Containers v0.0.1
#55Can anyone speak to how the macOS runners on GitHub actions work? It would seem from this post that containers of any kind for macOS are a brand new thing..
Re: macOS Containers v0.0.1
#56Earlier quoted context omitted.
>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…
> homebrew is pretty great I hear this said a lot in passing, and I'm really curious what people mean when they say this.
[1] https://brew.sh
Re: macOS Containers v0.0.1
#57Earlier quoted context omitted.
I imagine because if an adversary can a chroot environment, then they can trick anything using that chroot to use different binaries.
I have these thoughts about Homebrew also. 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/check…
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.
Re: macOS Containers v0.0.1
#58How 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…
The transitively linked docs have some answers: 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…
Re: macOS Containers v0.0.1
#59Re: macOS Containers v0.0.1
#60Earlier quoted context omitted.
The transitively linked docs have some answers: 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…
So essentially a chroot with a bit of make-up and a lot of marketing? Except 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)
- 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.