Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

macOS 11’s hidden security improvements

blog.malwarebytes.com

Post reply on HN
Print view View original

11–20 of 152 posts

Re: macOS 11’s hidden security improvements

#11

Post by GekkePrutser »

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 happy leaving my security to a black box and just trusting the supplier implicitly. This is a supplier that introduced a "get root with blank password" bug and the "your password hint is your actual password" one. Sure, everyone makes mistakes, especially for that reason I'd want to have more access than they offer now.

macOS is becoming more and more like iOS, which is also way too closed in my opinion. More locks is always good but the user should have a key, not just the supplier.

Re: macOS 11’s hidden security improvements

#12

Post by gregsadetsky »

sillysaurusx wrote: post #9
gregsadetsky wrote: post #6

Earlier quoted context omitted.

Discussed here: https://news.ycombinator.com/item?id=16082909 cperciva's paper from 2005 (linked above): http://www.daemonology.net/papers/htt.pdf

Hmm. That commenter’s username seems familiar… Thanks. :) > The problems introduced by caches have been further exacerbated by the current trend towards increased parallelism. On recent processors implementing simultaneous multithreading [18], such as Intel’s “Hyper- Threading” processors [11], access to the L1 cache is shared between two independent instruction streams And here we are 16 years later, with NO_SMT. Ne…

https://lkml.org/lkml/2005/5/16/152

Linus: "[...] I'd be really surprised if somebody is actually able to get a real-world attack on a real-world pgp key usage or similar out of it (and as to the covert channel, nobody cares). It's a fairly interesting approach, but it's certainly neither new nor HT-specific, or necessarily seem all that worrying in real life. [...]"

Re: macOS 11’s hidden security improvements

#13

Post by azinman2 »

GekkePrutser wrote: post #11

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…

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.

Re: macOS 11’s hidden security improvements

#15

Post by mzs »

sillysaurusx wrote: post #4

> NO_SMT disables Simultaneous multithreading (SMT), the CPU feature better known under Intel’s trade name of “Hyper-Threading”. SMT allows a CPU core to execute two or more threads at the same time, for improved performance at the cost of contention for per-core resources, such as caches, TLBs etc. > Letting multiple threads share invisible resources carries the risk of letting a malicious thread steal secrets from…

How many years until this from last year is regretted?

introduce memfd_secret system call to create "secret" memory areas

v11: * Drop support for uncached mappings

https://lwn.net/ml/linux-kernel/20201124092556.12009-1-rppt@...

Re: macOS 11’s hidden security improvements

#16

Post by comex »

uniqueuid wrote: post #8

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 to both approaches.

As for the other one, forcing VERW to be executed on every return from the kernel, both Linux and OpenBSD chose the brute-force approach of doing this for all processes by default; both added this feature in 2019 as part of the coordinated disclosure of the MDS vulnerability class. Apple is instead doing it on a per-thread basis. Again, pros and cons.

[1] https://lwn.net/Articles/861251/

Re: macOS 11’s hidden security improvements

#17

Post by upbeat_general »

azinman2 wrote: post #13
GekkePrutser wrote: post #11

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…

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

Re: macOS 11’s hidden security improvements

#19

Post by jchw »

azinman2 wrote: post #13
GekkePrutser wrote: post #11

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…

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.

If one mentions Android’s “openness” as a plus, people (rightly) point out that sure, it is technically open source and you can often sideload, but that doesn’t mean it is friendly towards those things necessarily. A lot of downsides come with rooting and bootloader unlocking after all. That is when comparing to iOS, which is more restrictive than macOS, as you point out.

I mention this because I think that it’s good Apple lets you use some of the hardware you own with relatively little restriction if you so choose, but it is a lot less practical than the previous status quo and other systems. You definitely lose some functionality (on M1, I believe you lose at least iOS application support.) If we’re going to be frank about it with Android, I think it’s fair to be frank about it with macOS/M1.

I would guess things could be better if user choice was as much of a focus as vendor control.

Re: macOS 11’s hidden security improvements

#20

Post by kccqzy »

Interesting tidbit about Chrome using POSIX_SPAWN_NP_CSM_ALL now. But I would point out that according to the open-source Chromium code base, these CPU security mitigation APIs offer process-wide protection rather than thread-based protection (commit message at https://source.chromium.org/chromium/chromium/src/+/46e23c81... )

Some more digging shows that Chrome started using a weaker version of CSM, TCSM (thread CSM I assume) two years ago in NaCl: https://source.chromium.org/chromium/_/chromium/native_clien...

Firefox of course uses TCSM too: https://hg.mozilla.org/mozilla-central/rev/cd1ccb74af7c And so does Safari: https://trac.webkit.org/changeset/244233/webkit

I hope this at least somewhat assuages the fears of people who prefer Firefox or Safari over Chrome.

Post reply on HN