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

171–180 of 374 posts

Re: macOS Containers v0.0.1

#171

Post by nyanpasu64 »

smcleod wrote: post #157
nyanpasu64 wrote: post #129

Earlier quoted context omitted.

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.

My experience is that I was unable to debug Maestral (a Python program) crashing in native Cocoa bindings in LLDB, because the interpreter did not allow itself to be debugged. Mozilla says Firefox acts the same way at https://firefox-source-docs.mozilla.org/contributing/debuggi.... It's possible there's some workaround I'm not aware of, but I ended up disabling SIP just like every non-macOS computer I own.

Re: macOS Containers v0.0.1

#172

Post by _joel »

baq wrote: post #163
_joel wrote: post #160

Earlier quoted context omitted.

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

I mean, I won't be allowed to install it side by side on my work laptop in a million years. GPU acceleration would be nice in a VM if macOS can pass it through, which I've no idea if it can.

It's not really intended to be run as a standalone distro (there's a fedora version though) and (afaiu) the point is to understand the bootloader process and stuff like GPU support from linux.

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.

Re: macOS Containers v0.0.1

#173

Post by cj »

diogenes4 wrote: post #166
smcleod wrote: post #97

Earlier quoted context omitted.

Oh wow… please do not do that folks!

Sincerely, why is this your recommendation? What does this protect against and why do you consider it a concern?

Help doc: https://support.apple.com/en-us/102149#:~:text=System%20Inte....

TLDR: it restricts even the root user from modifying system files. Like the ones that would otherwise be the target of malware.

Re: macOS Containers v0.0.1

#174

Post by _joel »

slonopotamus wrote: post #167
_joel wrote: post #151

Earlier quoted context omitted.

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

> this doesn't give me anything extra to what using docker would do on macos You're missing the point. This project DOES use docker.

I mean docker machine/desktop (kinda implicit of running docker on macos) not the cli or anything :)

Re: macOS Containers v0.0.1

#175

Post by slonopotamus »

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

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

Re: macOS Containers v0.0.1

#176

Post by lloeki »

e12e wrote: post #155
lloeki wrote: post #70

Earlier quoted context omitted.

> 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.

> running a x86 windows binary - looking for 32bit stuff under SysWOW64 - under x86_64 wine in a x86_64 Linux container AOT translated to aarch64 by Rosetta 2 for Linux that switched the ARM M1 memory model to Total Store Ordering on a aarch64 Linux kernel under Virtualisation.framework on arm64 darwin.

FTFY ;) (and thanks!)

Re: macOS Containers v0.0.1

#177

Post by xmodem »

pohl wrote: post #159
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)…

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

Re: macOS Containers v0.0.1

#178

Post by zitsarethecure »

unsupp0rted wrote: post #54
devsda wrote: post #45

Earlier quoted context omitted.

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

There's only a 1% chance these days on Linux that your sound won't work or your computer won't sleep when you close the lid or your wifi won't work, or your ethernet, or your cooling, or a peripheral, or CPU/memory spikes. And a 90% chance it'll be at least one such thing.

All of those things work fine on every computer in my household that runs Linux. This spans thinkpad, dell and ASUS laptops, Dell desktops, home-built gamer type desktops, a few raspberry pi's, and a SFF PC we use to run Kodi on the main TV.

I 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 ¯\_(ツ)_/¯.

Re: macOS Containers v0.0.1

#179

Post by slonopotamus »

e12e wrote: post #158
slonopotamus wrote: post #101

Earlier quoted context omitted.

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"?

I didn't want to use "jail" term because it is mostly unheard of outside of FreeBSD.

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...

Re: macOS Containers v0.0.1

#180

Post by diogenes4 »

cj wrote: post #173
diogenes4 wrote: post #166

Earlier quoted context omitted.

Sincerely, why is this your recommendation? What does this protect against and why do you consider it a concern?

Help doc: https://support.apple.com/en-us/102149#:~:text=System%20Inte... . TLDR: it restricts even the root user from modifying system files. Like the ones that would otherwise be the target of malware.

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.
Post reply on HN