Live data from Hacker News

macOS 11’s hidden security improvements

blog.malwarebytes.com

21–30 of 152 posts

Re: macOS 11’s hidden security improvements

#21

Sounds good but a problem with Apple's latest releases are that a lot of its security features listen only to Apple and not to the user. This doesn't concern most of the improvements mentioned in the article, those are purely technical improvements at a very low level. But the signed system volume for example (also mentioned), while a good idea, lacks a convenient way for the user to make changes to it. I'm not very…

On the other hand, Linux is getting better and better. And with the prevalence of web apps, the main obstacle to running non (MS | Apple) systems is getting smaller. With Linux, you can adjust the level of security you need and you keep the key. Security improvements appear also in BSDs, especially OpenBSD, but honestly I wouldn't recommend people used to macOS to switch to OpenBSD (yet).

Re: macOS 11’s hidden security improvements

#23

Earlier quoted context omitted.

You can always disable CSR/SIP generally. macOS is unlike iOS in that many security mitigations can be disabled. The fact that new M1 Macs let you side load a diff non-Apple in iOS should be the ultimate proof you need of this motivation to allow user control on Macs.

Except doing so doesn’t let you run iOS apps and not to mention is a pain to do so after every update (I believe SSV requires that). The list of things to disable seems to grow every year. Even with Gatekeeper, CSR/SIP disabled I’ll still have issues opening applications which may (or may not) be fixed by taking it out of quarantine, changing the signature, etc

You can disable SIP once and it will stay off (although maybe not if you do a full system update).

Re: macOS 11’s hidden security improvements

#24

I'd be interested to hear from someone with deep security knowledge: Some people have dismissed OpenBSD's mitigations as overhyped (i.e. - things like W^X are not the main problem, linux has long caught up, etc). But now we see Apple adding precisely some of these mitigations. Where does this leave such architectural countermeasures? Are there real gains from investing in such low-level things? Are they irrelevant in…

It’s clear that W^X isn’t “solving security”, but it’s not a bad idea just because it’s a low-hanging fruit. On Apple platforms, I think that it came to be as a natural consequence of the ability to toggle RX mappings to be RW without a syscall.

Almost all DMA-capable peripherals on Apple Silicon (including iDevices) are gated behind an IOMMU.

Re: macOS 11’s hidden security improvements

#25

Sounds good but a problem with Apple's latest releases are that a lot of its security features listen only to Apple and not to the user. This doesn't concern most of the improvements mentioned in the article, those are purely technical improvements at a very low level. But the signed system volume for example (also mentioned), while a good idea, lacks a convenient way for the user to make changes to it. I'm not very…

On the other hand, Linux is getting better and better. And with the prevalence of web apps, the main obstacle to running non (MS | Apple) systems is getting smaller. With Linux, you can adjust the level of security you need and you keep the key. Security improvements appear also in BSDs, especially OpenBSD, but honestly I wouldn't recommend people used to macOS to switch to OpenBSD (yet).

It's the year of the Linux desktop!

Re: macOS 11’s hidden security improvements

#26

I'd be interested to hear from someone with deep security knowledge: Some people have dismissed OpenBSD's mitigations as overhyped (i.e. - things like W^X are not the main problem, linux has long caught up, etc). But now we see Apple adding precisely some of these mitigations. Where does this leave such architectural countermeasures? Are there real gains from investing in such low-level things? Are they irrelevant in…

W^X is a good mitigation to prevent attackers from just spraying shellcode into a RWX heap. This is how most JIT engines used to be attacked, and many exploits continue to include WebAssembly just because Chrome will create a RWX arena for this. Many of the OpenBSD mitigations are actually a good idea, but some are fanciful junk. The posture that the team has towards pushing those latter ones is what generally makes people unhappy.

Also, do note that Apple silicon puts everything behind a DART (essentially an IOMMU). This is noted in the article:

> Device isolation was another M1-only feature, that uses the more powerful IOMMU of that platform to make sure hardware devices can only share memory with the operating system and not with each other. Cross-device memory sharing is a historical custom, based on a blind, unfounded trust in hardware.

Re: macOS 11’s hidden security improvements

#27

Earlier quoted context omitted.

On the other hand, Linux is getting better and better. And with the prevalence of web apps, the main obstacle to running non (MS | Apple) systems is getting smaller. With Linux, you can adjust the level of security you need and you keep the key. Security improvements appear also in BSDs, especially OpenBSD, but honestly I wouldn't recommend people used to macOS to switch to OpenBSD (yet).

It's the year of the Linux desktop!

It always is! (in a good and bad way)

Re: macOS 11’s hidden security improvements

#28

Sounds good but a problem with Apple's latest releases are that a lot of its security features listen only to Apple and not to the user. This doesn't concern most of the improvements mentioned in the article, those are purely technical improvements at a very low level. But the signed system volume for example (also mentioned), while a good idea, lacks a convenient way for the user to make changes to it. I'm not very…

On the other hand, Linux is getting better and better. And with the prevalence of web apps, the main obstacle to running non (MS | Apple) systems is getting smaller. With Linux, you can adjust the level of security you need and you keep the key. Security improvements appear also in BSDs, especially OpenBSD, but honestly I wouldn't recommend people used to macOS to switch to OpenBSD (yet).

Indeed. I switched to FreeBSD myself.

Reasons were the excellent jails system, the ports collection, the ZFS on root (though Ubuntu is starting to offer that) and the great documentation. I also don't like the scale of corporate involvement in Linux development. In the end that leads to companies trying to insert their own IP with a view to monetisation (like Ubuntu with Mir, Upstart, now snaps). It's also the most suitable for a desktop system of all the BSDs I think.

But it's not for everyone. For one the hardware support is limited. I didn't even bother trying to get the WiFi or bluetooth going (I run this on a pure desktop). For laptop use I'd use a flavour of Linux, though I'm not entirely sure which I'd use :) It also doesn't hold your hand as much as most Linux distros, though it's not nearly as barebones as arch either! I'd consider it something a bit in the middle like Manjaro. Overall I'm really happy with it though.

I still use Macs for work though and I administered them for a long time. It's always a struggle if you need to do something that Apple doesn't really want you to do. You may get it working, but there's a good chance it'll get broken in whatever minor patch that's coming along without warning :) Unfortunately in a business with less than 1% Macs you can't always do things the Apple way.

Re: macOS 11’s hidden security improvements

#29
post #16

I'd be interested to hear from someone with deep security knowledge: Some people have dismissed OpenBSD's mitigations as overhyped (i.e. - things like W^X are not the main problem, linux has long caught up, etc). But now we see Apple adding precisely some of these mitigations. Where does this leave such architectural countermeasures? Are there real gains from investing in such low-level things? Are they irrelevant in…

Which mitigations exactly? macOS has enforced W^X in most cases for many years. As for the two mitigations mentioned in the article: NO_SMT seems to be equivalent to Linux's "core scheduling" feature, which landed recently [1]. This approach, involving disabling SMT (aka hyperthreading) for specific processes, is different from OpenBSD's more brute-force approach of disabling SMT systemwide; there are pros and cons t…

(To provide more context, before the new APIs Apple used to flip actual page memory protections, which required going through the kernel. The new SPRR APIs allow for essentially the same thing, except they work per-thread and just set a register accessible from userspace that essentially applies an extra mask on the permission bits, which is much faster.)
Post reply on HN