undefined | Better HN

0 pointshighwaylights2y ago0 comments

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

Removing SIP from a system that relies on it as a basis for platform security is different than using a system that wasn't relying on it in the first place.

0 comments

slonopotamus2y ago

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

johnmaguire2y ago

I think the argument is that file permissions may not be applied as rigorously, with the assumption that SIP is in effect.

slonopotamus2y ago

SIP won't save you from wrong file permissions.

And SIP doesn't defend you from editing files in /bin. They are guarded by the fact that root filesystem is mounted read-only.

Klonoar2y ago

With SIP enabled it’s not possible to load arbitrary kernel extensions, for one - they must be signed.

saagarjha2y ago

Entitlement stealing, for example.

pohl2y ago

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

xmodem2y ago

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

pohl2y ago

The "varsectomy" bug in Chrome isn't the example you think it is, because disabling SIP was not sufficient conditions for it. There were 3 other conditions that had to be met, the most notable of which is that "/" had to be writeable by tho logged-in user, which is not the default.

This is an example of defense-in-depth being present, and defense-in-depth still failing for some users who gave escalated permissions to some installers, allowing them to run roughshod over their filesystem permissions, leaving them vulnerable to a subsequent varsectomy. If one did the same thing to their Linux system, the same thing could happen.

https://arstechnica.com/information-technology/2019/09/no-it...

xmodem2y ago

The two other conditions listed in the page you link basically amount to "the buggy code has to run". Related, I think SSV [1], introduced last year, would also have blocked this bug even with SIP disabled. But none of that invalidates concern that areas of the OS we don't know about might not have the level of defence in depth that we would like - it's not like Apple has never cut corners or shipped bugs to hit a date.

1: https://support.apple.com/en-gb/guide/security/secd698747c9/...

1 more reply

saagarjha2y ago

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

zare_st2y ago

I'd like to digress to your "Encouraged more forcefully" phrasing which is quite interesting if you think about it. In my view, it would mean something like pervasive dialog box ala EULA, some UI hoops you need to resolve, alike going with local account on installation.

In reality they done basically everything to force users to use secure boot. If they disabled normal boot altogether, OS adoption would suffer heavily. They could've obscured that option, but it would be found out, and enterprise users would be pissed at them because they didn't gave them a provisionable way while the way exists. So it came down to normal variables in installer registry.

However modifying, e.g making users "hack" the ISO is really as forceful as it gets without market loss.

Note: There may be more normal way today than modifying the registry of ISO, I installed 11 once when it came out.

j / k navigate · click thread line to collapse

0 comments

slonopotamus2y ago

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

johnmaguire2y ago

I think the argument is that file permissions may not be applied as rigorously, with the assumption that SIP is in effect.

slonopotamus2y ago

SIP won't save you from wrong file permissions.

And SIP doesn't defend you from editing files in /bin. They are guarded by the fact that root filesystem is mounted read-only.

Klonoar2y ago

With SIP enabled it’s not possible to load arbitrary kernel extensions, for one - they must be signed.

saagarjha2y ago

Entitlement stealing, for example.

pohl2y ago

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

xmodem2y ago

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

pohl2y ago

https://arstechnica.com/information-technology/2019/09/no-it...

xmodem2y ago

1: https://support.apple.com/en-gb/guide/security/secd698747c9/...

1 more reply

saagarjha2y ago

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

zare_st2y ago

However modifying, e.g making users "hack" the ISO is really as forceful as it gets without market loss.

Note: There may be more normal way today than modifying the registry of ISO, I installed 11 once when it came out.

j / k navigate · click thread line to collapse