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

151–160 of 374 posts

Re: macOS Containers v0.0.1

#151

Post by _joel »

lloeki wrote: post #113
_joel wrote: post #32

Sorry, not disabling SIP for something that I can already do without needing to nobble security policies (and have them reset/impossible due to MDM). If there was user/networking space in Darwin then maybe I'd be interested but...

> something that I can already do 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)

I mean in terms of functionality, this doesn't give me anything extra to what using docker would do on macos (granted it's via a linux based VM). From an end user perspective there's no real difference, but I don't have to entirely disable SIP just to use it.

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 :)

Re: macOS Containers v0.0.1

#152

Post by slonopotamus »

donatj wrote: post #127

What's the licensing situation on this? Would I be distributing parts of macOS in my containers? I don't think Apple is OK with that. 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.

> What's the licensing situation on this?

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.

Re: macOS Containers v0.0.1

#153

Post by _joel »

nyanpasu64 wrote: post #129
smcleod wrote: post #97

Earlier quoted context omitted.

Oh wow… please do not do that folks!

I disable SIP because I don't want to use an OS where I cannot debug programs which did not consent to be debugged. macOS makes it impossible to inspect failure states I encounter in normal usage (like I can on Linux with debuginfod enabled, or Windows with .pdb files) without first rebuilding the program in debug mode.

Surely you can do this with xattr?

Re: macOS Containers v0.0.1

#154

Post by abujazar »

highwaylights wrote: post #31
skibz wrote: post #3

System Integrity Protection sounds really important. What does it do normally, and why does this tool require it to be disabled?

SIP is secure boot for macOS. 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. https://en.wikipedia.org/wiki/System_Integrity_Protection

> SIP is secure boot for macOS.

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.

Re: macOS Containers v0.0.1

#155

Post by e12e »

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…

I suppose running a windows binary under wine in a Linux container also belong somewhere on this excellent summary.

Re: macOS Containers v0.0.1

#157

Post by smcleod »

nyanpasu64 wrote: post #129
smcleod wrote: post #97

Earlier quoted context omitted.

Oh wow… please do not do that folks!

I disable SIP because I don't want to use an OS where I cannot debug programs which did not consent to be debugged. macOS makes it impossible to inspect failure states I encounter in normal usage (like I can on Linux with debuginfod enabled, or Windows with .pdb files) without first rebuilding the program in debug mode.

I’ve never had problems debugging anything with SIP on.

Re: macOS Containers v0.0.1

#158

Post by e12e »

slonopotamus wrote: post #101
znpy wrote: post #43

Earlier quoted context omitted.

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)

Original author here. > 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 alr…

Great effort. I get why you call it container - but sounds more like jail or cheroot would give more appropriate expectations; like "tooling to build and run Darwin containers in a macOS chroot"?

Re: macOS Containers v0.0.1

#159

Post by pohl »

highwaylights wrote: post #147
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.

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)…

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

Re: macOS Containers v0.0.1

#160

Post by _joel »

baq wrote: post #111

cries in Asahi Linux 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.

You're missing the point of Asahi, by the looks of it. It's not intended to be run in a VM.
Post reply on HN