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

281–290 of 374 posts

Re: macOS Containers v0.0.1

#281

Post by saagarjha »

slonopotamus wrote: post #175
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)…

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

Entitlement stealing, for example.

Re: macOS Containers v0.0.1

#282

Post by crabbone »

slonopotamus wrote: post #210
crabbone wrote: post #203

Unrelated to containers themselves: how do you make a patch when no version was released? I mean, people call this "semantic" versioning, but then spit in the face of those semantics...

Original author here. I wanted to clearly indicate early-prealpha-unstable-not-for-production-yet state of this software. Using "1.0.0" and even "1.0.0-alpha" would give false expectations about maturity of this project.

This was more of a stab at "semantic" part of the semantic versioning (which similar to in semantic Web... found its own semantics that don't follow from its definitions). You are definitely not the only one using it like this.

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

Re: macOS Containers v0.0.1

#283

Post by saagarjha »

xmodem wrote: post #177
pohl wrote: post #159

Earlier quoted context omitted.

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

Here's a better one: https://gist.github.com/ChiChou/e3a50f00853b2fbfb1debad46e50...

Re: macOS Containers v0.0.1

#284

Post by saagarjha »

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.

You can't debug system processes or anything with the hardened runtime enabled.

Re: macOS Containers v0.0.1

#285

Post by crabbone »

timcobb wrote: post #204
crabbone wrote: post #203

Unrelated to containers themselves: how do you make a patch when no version was released? I mean, people call this "semantic" versioning, but then spit in the face of those semantics...

Version 0?

Oh, it was easier than I thought: https://semver.org/#spec-item-2

    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.
So, no leading zeros, ta-da!

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.
So... my reading of this "definition" is that there's really no need for three digits, if major is zero... Then why on earth would you have two digits? Also, if no pubic API at this point, then why have versions at all? I mean, you clearly shouldn't be specifying anything with zero major version as a dependency because it should be illegal to depend on a library w/o public API... Then, again, why have versions in this situation? And if the argument is that its for internal use, then why standardize it for external use?

Just two paragraphs below. How lovely.

Re: macOS Containers v0.0.1

#286

Post by saagarjha »

jmbwell wrote: post #230
diogenes4 wrote: post #218

Earlier quoted context omitted.

I doubt you (or any human) is capable of enumerating what you don't want looked at. Frankly, I doubt most of this unknown area is covered by SIP at all, and it would be extremely odd if it did. Perhaps you might consider arguing for actual permissions rather than arbitrarily walling off the OS in a way that tangentially benefits the monopoly Apple holds over their own computers. Wouldn't it be far easier to enumerate…

SIP means not messing with the system files, enumerated thusly: /System. Enumerating what I do want an app to access is handled by Gatekeeper.

It's actually a larger list available in /System/Library/Sandbox/rootless.conf

Re: macOS Containers v0.0.1

#287

Post by diogenes4 »

jmbwell wrote: post #230
diogenes4 wrote: post #218

Earlier quoted context omitted.

I doubt you (or any human) is capable of enumerating what you don't want looked at. Frankly, I doubt most of this unknown area is covered by SIP at all, and it would be extremely odd if it did. Perhaps you might consider arguing for actual permissions rather than arbitrarily walling off the OS in a way that tangentially benefits the monopoly Apple holds over their own computers. Wouldn't it be far easier to enumerate…

SIP means not messing with the system files, enumerated thusly: /System. Enumerating what I do want an app to access is handled by Gatekeeper.

> SIP means not messing with the system files, enumerated thusly: /System.

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

Re: macOS Containers v0.0.1

#288

Post by saagarjha »

jppittma wrote: post #110
highwaylights wrote: post #21

Earlier quoted context omitted.

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.

SIP on consumer laptops/desktops is security theater. It only really makes sense on web-servers. For people for whom this is a deal breaker, can you describe a concrete scenario where SIP would actually protect you?

SIP protects you from an app accidentally rendering your system unbootable, for example.

Re: macOS Containers v0.0.1

#289

Post by saagarjha »

Klonoar wrote: post #42
perryizgr8 wrote: post #15

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.

So I take it you don't use Apple Pay or anything...? Edit: to be clear for the people who may not know, Apple Pay does not work with SIP disabled. ;P

You can forward Apple Pay requests to your other devices.

Re: macOS Containers v0.0.1

#290

Post by satvikpendem »

highwaylights wrote: post #7

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

I always disable SIP on every Mac I own. It's not very useful and I can run whatever I want on my hardware.
Post reply on HN