[jedieaston]

I wonder how much people are able to publish about the device. I'd expect not much, but it'd be nice to be able to compare a iPhone that was completely unlocked (at least, to whatever that means for Apple) with whatever security they put on the ARM Macs which are supposed to be "open for hobbyists". I'd expect that the ARM Macs have much of the same security stack (by default) that iOS devices have given what they said in the WWDC talks, but maybe that's not the case.

Also, if you found an exploit on a research iPhone because you made use of entitlements that were Apple-only, I wonder if that'd be worth anything bounty wise. Nobody can/should be able to write an that'll get through App Store checks if they asked for PLZ_NO_SANDBOX_ILL_BE_GOOD or something (at least, that's what I thought before the whole Snapchat system call thing happened). But hypothetically the App Store review process is vulnerable to a bad actor inside Apple pushing an update to a big app that included malware, so I'd think that private entitlements shouldn't be available at all to binaries that didn't ship with the device/in a system update (unless some kind of hobbyist flag was flipped by the consumer). So I'd say that would be worth something, even if smaller than a more interesting exploit.

[saagarjha]

We’ll see how the shipping ARM Macs are “fused” when they come out, but my guess is that they will be more locked down than these devices: their OS will be more permissive but you will not have meaningful kernel debugging.

> Nobody can/should be able to write an that'll get through App Store checks if they asked for PLZ_NO_SANDBOX_ILL_BE_GOOD or something (at least, that's what I thought before the whole Snapchat system call thing happened).

Snapchat (on iOS at least) is still subject to the app sandbox, no app has on iOS has been granted an exception there to my knowledge. On macOS there are apps that are “grandfathered in” to not require the sandbox on the App Store, but new apps are supposed to have it. Due to the way the dynamic linker works, until recently it was possible to upload an app that could bypass the sandbox, but Apple has said they have fixed this. Some apps do have an exception to this as well, as the broad way they fixed one of the issues broke legitimate functionality in library loading. You can find those hardcoded in AMFI.kext, theoretically they could turn off the sandbox for themselves if they wanted.

[xenadu02]

The KDK has instructions for loading your own kernel extensions on Apple Silicon. This includes making a new writable root snapshot, modifying it, then blessing it for boot. It also includes kernel debugging.

Booting custom kernels is not supported at the moment but as has been noted "the Mac remains the Mac" and booting a custom kernel is allowed on the Mac.

And of course you can disable SIP.

Developer and hobbyist scenarios are an explicitly supported workflow on the Mac. Default security policies need to be the right thing for the vast majority of users but that doesn't mean anyone wants to take away your ability to do all kinds of interesting things to the system.

[mrpippy]

> you will not have meaningful kernel debugging

Given that kext development is still supported (although highly discouraged), won’t they have to support the same level of kernel debugging as usual?

> On macOS there are apps that are “grandfathered in” to not require the sandbox on the App Store

Can you name any of these apps? Apple’s own apps don’t have to be sandboxed (like Xcode or macOS installers), but I don’t know of anything else that gets an exception. Some apps like Office get special “holes” out of the sandbox (in the form of additional SBPL), but fundamentally they’re still sandboxed.

[GekkePrutser]

> We’ll see how the shipping ARM Macs are “fused” when they come out, but my guess is that they will be more locked down than these devices: their OS will be more permissive but you will not have meaningful kernel debugging.

My big worry is them dropping terminal access altogether like on iOS. That would really make the platform useless to me.

However I don't think they would do this at this point. There's many user groups (like cloud developers) specifically favouring Mac because of the strong terminal access.

[bluesign]

> But hypothetically the App Store review process is vulnerable to a bad actor inside Apple pushing an update to a big app that included malware.

I don’t think this is technically possible.