hoakley June 22, 2019 Macs, Technology

Why Catalina has got a read-only system volume

Since Apple introduced System Integrity Protection (SIP) in El Capitan – in addition to the more regular file-system protections provided to macOS system files – there has been a succession of vulnerabilities reported in it.

In March 2016, Pedro Vilaca revealed a local attack which allowed escalation of privileges and bypass of SIP, which was patched in OS X 10.11.4. Immediately after that, Stefan Esser revealed a group of SIP-related vulnerabilities, some of which were fixed in 10.11.3, others which remained in 10.11.4.

In December 2016, Patrick Wardle explained how to bypass SIP in a local attack using an upgrade Installer app, which affected versions of macOS up to and including 10.12.1.

In August 2018, Adam Chester revealed full details of an exploit which used a kernel extension for VirtualBox to disable SIP.

Most recently, at the second Objective by the Sea conference earlier this month, Jaron Bradley detailed how a crafted Installer package can partially bypass SIP, a vulnerability which was fixed in macOS 10.14.4.

This is a small selection of those reports which have been published to date. They demonstrate that there have been, and almost certainly still are, quite a few vulnerabilities in SIP during its relatively brief existence. This sustained interest in SIP among security experts confirms how important they consider it to be to your Mac: it’s not ‘security theatre’, but a primary defence.

The solution adopted in Catalina has involved considerable engineering investment, including the development of a new type of bi-directional symbolic link named a firmlink, which enables the two boot volumes to integrate and function as one. Apple clearly considers that protecting system integrity is an essential function in macOS 10.15, not an optional extra to be enabled so long as it doesn’t trip your apps up.

13Comments

Add yours

1

EcleX on June 22, 2019 at 8:04 am

“Why Catalina has got a read-only system volume”.

That may be great, but the main danger is for malware to encrypt user data. I guess that protecting against that and preventing that is more difficult, if not impossible (beyond common sense, of course). But macOS could integrate something like Menu Meters
https://member.ipmu.jp/yuji.tachikawa/MenuMetersElCapitan
so that the user may check out if CPU goes too high. But even better would be if macOS prevented encrypting the whole disk with password (beyond FileVault or equivalent macOS), like malware ransomware does. If that is technically possible.

LikeLiked by 1 person
- 2
  
  hoakley on June 22, 2019 at 8:21 am
  
  Ransomware which encrypts user data is, and has been, extremely unusual. Patrick Wardle has an excellent Ransomware detector which I suspect hasn’t been developed a great deal because of very low demand.
  The overwhelming majority of Mac malware may steal your data – the reason for all the new privacy protection – but doesn’t try making it inaccessible to you. There’s greater value in stolen data, and in continuing to be able to steal it.
  Whole-disk encryption isn’t available to malware because of SIP anyway, and I suspect would be far too technically-challenging with APFS too.
  Howard.
  
  LikeLike
3

Joss on June 22, 2019 at 4:15 pm

I still think it’s security theater: the read-only system volume can be mounted as read/write with `mount -uw /` (at least that was the gist from WWDC2019). The only thing you need to do is disable SIP. So that volume is not an additional layer of protection beyond SIP, it’s a subset of SIP, so all you need is yet another SIP exploit—and judging from the hack frauds managing coreOS at Apple, those are bound to rear their ugly head rather sooner than later—, and with a SIP bypass a malware could just mount the system volume as read/write (maybe even silently) and write some nasty stuff to it. The only thing necessary is for the user to enter his admin password, and blammo: you’re toast. Your run-of-the-mill adware won’t do this to you, of course, but those usually don’t target the system anyway. However, more sophisticated tools will eventually be able to. Chances are super-slim that the normal user will ever encounter such a malware, but even a read-only system volume, while surely ingenious, will be hacked some day.

I just know one thing: I’ll make a monitoring daemon so that I will at least be warned when the system volume is being mounted as read/write. Question is: properly codesigned Apple System processes can get around SIP and TCC anyway, e.g. to install security updates (MRT, XProtect, Gatekeeper), so there will probably be a lot of mounting and unmounting going on. I’m already getting lots of those, because I’m using appgineers Mountain with prefs set to show internal & system volumes, and notify on mount & unmount. Maybe Mountain will be sufficient. We’ll see.

LikeLike
- 4
  
  Alberic Muller on June 23, 2019 at 4:14 pm
  
  I agree with you that a software lock on a Catalina’s system volume could eventually be bypassed. Maybe the T2 in so equipped Mac’s could get the new task of limiting access to the system partition. I would not be surprised if a firmware lock like this would only work with Apple supplied SSD’s.
  
  LikeLike
- 5
  
  hoakley on June 23, 2019 at 5:17 pm
  
  To date, as far as I can see, no ‘bypass’ of SIP has completely disabled it, but worked around its intended protection instead. To be able to mount a read-only system volume would therefore appear to require discovering a vulnerability which enabled the disabling of SIP from the whole volume, much as the user can achieve with spctl in Recovery mode. That is a much higher barrier to malware than anything currently in SIP, therefore there is no theatrical element to the change at all.
  Every security protection can, in theory at least, eventually be worked around. It’s a question of how hard that is, and how long it takes before that. Clearly Apple’s security engineers think this raises the bar significantly higher, and I’ve seen nothing to contradict that.
  I’m puzzled that you claim to have seen Catalina repeatedly mounting the volume for installing security updates. I monitor updates very closely, and there hasn’t been a single security update pushed since the read-only volume was enabled in beta 2. Not only that, but updates are very infrequent: Gatekeeper updates occur every 1-2 weeks, XProtect much less frequently, and rumours are that Catalina doesn’t do MRT at all.
  Apple may also intend handling those updates by firmlinks rather than by mounting the whole volume read-write. As I don’t think anyone outside Apple understands firmlinks yet, and Mountain may not even grok Mojave’s APFS properly (it hasn’t been updated for nearly a year), your observations may be based entirely on artefacts in the file system.
  I think it’s probably wiser not to dismiss Apple’s security engineers as either fools or hoaxers until we have a more stable beta, and better evidence from research.
  Howard.
  
  LikeLike
  - 6
    
    Joss on June 23, 2019 at 5:36 pm
    
    I agree that the barrier is now a lot higher, and I think that a read-only volume is a great feature, unlike locking down Documents and Desktop. If I’m not mistaken, there were some ideas years ago of bringing a read-only system volume to OpenBSD (or another BSD release?). But I might be mistaken.
    
    As for mounting/unmounting, I’m still on Mojave, but Mountain is registering it every time Apple does something remotely on my system. So I assume that it will be the same with Catalina. And one should also note that every time the Mac boots, the T2 will emulate the firmware on that T2 chip, and while I don’t know if those two things are related, the Recovery volume will have a different cryptographic signature every after every new boot, which tools like XFENCE will also notice. Not sure though, how this behavior will translate to Catalina’s read-only volume.
    
    LikeLike
7

Florian on June 24, 2019 at 8:44 pm

Does this mean one has to disable SIP in Recovery-Mode before being able to upgrade to a custom hosts file?

LikeLiked by 1 person
- 8
  
  hoakley on June 24, 2019 at 9:22 pm
  
  No one knows at present. The read-only system volume has only been implemented for a week or so, and I suspect issues like this will determine what it locks away.
  Howard.
  
  LikeLike
9

Joe on June 26, 2019 at 5:53 am

Something new related to Wardle MonitorKit and compatibility with Catalina?

LikeLiked by 1 person
- 10
  
  hoakley on June 26, 2019 at 5:56 am
  
  Sorry, I’m not sure I understand. Could you explain, please?
  Howard.
  
  LikeLike
11

Weekly News Summary for Admins — 2019-06-28 – Cebu Scripts on June 28, 2019 at 2:35 pm

[…] Why Catalina has got a read-only system volume – Howard Oakley […]

LikeLike
12

Valdo on July 22, 2019 at 1:18 pm

I think Joe is referring to this:

Click to access OBTS_v1_Malm_Stein.pdf

LikeLiked by 1 person
- 13
  
  hoakley on July 22, 2019 at 8:31 pm
  
  Maybe: that’s for enterprise systems, and I doubt whether you or I could afford it, or have the network which justifies it. I don’t know how that fits in with the read-only system volume in Catalina either, I’m afraid – you’d need to contact Digita Security.
  Howard.
  
  LikeLike

·Comments are closed.

Share this:

Related