Do you have any reference to the Rust community “not allowing” something? This seems more like a case of a relatively niche tool doing what it needed to do to work, but not (yet) some broader effort to upstream or integrate this into cargo or rustup. I couldn’t find any RFCs or anything, for instance.
How about the boy who called nonsense security vulnerabilities. This is the same author who posts with incredulity that the ability to change a config file with a shell command in it gives you the ability to run the shell command you posted and wants it treated as some big CVE. Absolutely inconceivable that you might already have your harness in a sandbox where this is okay, and inconceivable that anyone might have a threat model that says that someone who can edit configuration of a tool can make that tool do arbitrary things allowed by its config.
MDMs on macOS are permissioned via AccessRights, and you can verify that their permission set is fairly minimal and does not allow what you've described here (bits 0, 4, 10).
That said, their privacy posture at the cornerstone of their claims is snake oil and has gaping holes in it, so I still wouldn't trust it, but it's worth being accurate about how exactly they're messing up.
You are right - the "nonce binding" the paper uses doesn't seem convincing. The missing link is that Apple's attestation doesn't bind app generated keys to a designated requirement, which would be required to create a full remote attestation.
> If you can prove a public key is generated by the SEP of a machine running with all Apple's security systems enabled, then you can trivially extend that to confidential computing because the macOS security architecture allows apps to block external inspection even by the root user.
It only effectively allows this for applications that are in the set of things covered by SIP, but not for any third-party application. There's nothing that will allow you to attest that arbitrary third-party code is running some specific version without being tampered with, you can only attest that the base OS/kernel have not been tampered with. In their specific case, they attempt to patch over that by taking the hash of the binary, but you can simply patch it before it starts.
To do this properly requires a TEE to be available to third-party code for attestation. That's not a thing on macOS today.
I wiped my post because you are right. I don't think it needs a full SGX-style TEE. What's missing is a link to designated requirements. Abusing a nonce field doesn't seem to work, or if it does I can't figure out how. The MDM/MDA infrastructure would need to be able to include:
public key from SEP -> designated requirement of owning app binary
The macOS KeyStore infrastructure does track this which is why I thought it'd work. But the paper doesn't mention being able to get this data server side anywhere. Instead there's this nonce hack.
It's odd that the paper considers so many angles including things like RDMA over Thunderbolt, but not the binding between platform key and app key.
Reading the paper again carefully I get the feeling the author knows or believes something that isn't fully elaborated in the text. He recognizes that this linkage problem exists, proposes a solution and offers a security argument for it. I just can't understand the argument. It appears APNS plays a role (apple push notification service) and maybe this is where app binding happens but the author seems to assume a fluency in Apple infrastructure that I currently lack.
I can buy the idea that if you can have the MDM infrastructure attest the code signing identity through the designated requirements, that you can probably come pretty close, but I'm still not quite sure you get there with root on macOS (and I suspect that this is part of why DCAppAttest hasn't made it to macOS yet).
Certainly, it still doesn't get you there with their current implementation, as the attempts at blocking the debugger like PT_DENY_ATTACH are runtime syscalls, so you've got a race window where you can attach still. Maybe it gets you there with hardened runtime? I'd have to think a bit harder on that.
Yeah I didn't quite understand the need for PT_DENY_ATTACH. Hardened runtime apps that don't include get-task-allow are already protected from debugger attach from the start of the process, unless I misunderstood something.
I'm not quite sure why Apple haven't enabled DCAppAttest on macOS. From my understanding of the architecture, they have every piece needed. It's possible that they just don't trust the Mac platform enough to sign off on assertions about it, because it's a lot more open so it's harder to defend. And perhaps they feel the reputational risk isn't worth it, as people would generalize from a break of App Attest on macOS to App Attest on iOS where the money is. Hard to say.
Looking at their paper at [1], there's a gaping hole: there's no actual way to verify the contents of the running binaries. The binary hash they include in their signatures is self-reported, and can be modified. That's simply game over.
A note, as others have posted on this thread: I mention this as a concrete and trivial flaw in their whole strategy, but the issue is fundamental: there's no hardware enclave for third-party code available to do the type of attestation that would be necessary. Any software approach they develop will ultimately fall to that hole.
That idea was not expressed in the article, only the fact that the ads were removed. This is worth covering, especially when coupled with the context for what ads Meta regularly does allow. One does not have to believe that they're obligated to do so while also believing that it's incredibly scummy behavior that consumers should be aware of and question.
They have, but they also just announced this week that for business and enterprise plans, they’re switching from quotas for codex to token use based pricing, and I would expect that to eventually propagate to all their plans for all the same reasons.
I’d be surprised if that propagated to personal subscription plans, simply because it would put them at a huge competitive disadvantage against Anthropic, which they’ve already signaled they care about by saying they allow third-party harnesses. But I wouldn’t be surprised if they required third-party harnesses to use per-token billing, since that’d put them on par with Anthropic.
You're not looking at the albedo of the solar panels in isolation though, you're comparing it to asphalt and cars. Typical solar panels have an albedo of ~0.3. Asphalt around ~0.05.
Using a release less than two months is hardly “so far behind”. The 1.24 series had considerable regressions that have taken a number of patch releases to fix, it stands to reason that the same would be true of newer releases. Given there's still miscompilations getting fixed as late as 1.25.8, and 1.25 brought in large changesets for the new experimental GC, sticking it out while 1.24 is still getting patches a mere handful of weeks ago is not unreasonable.
Ubuntu isn’t too big to target, if anything, its dominance makes it the obvious target. When you look at the trajectory over the years and some of Canonical’s decisions, it’s hard not to raise an eyebrow. Major distros like Ubuntu and Fedora didn’t scale globally without taking big tech money and money rarely comes with no strings attached. At some point, players like Microsoft are going to expect a return on that investment.
What fearmongering has the anti-systemd crowd been selling you? Genuinely curious because I wish I wasn't running systemd. My perspective is that the things they (we?) are saying are basically correct. But the service manager works well enough that most distros have accepted the downsides.
> it is really fearmongering when the systemd people literally founded a company to develop attestation for linux?
Considering it changes nothing on what they actually work on on systemd I would give this a yes. Every time I hear "they will do this or that" it just never really happened. So far it feels more like "the boy who cried wolf" than "slippery slope" to me. But maybe I am missing something?
A lot of the devs have always here and there added features for secure/measured boot and image based OSes and things that make them more usable to daily drive (hermetic /usr/, UKIs, sysext, portable services, mkosi, DDIs, ...). A lot of the things make image based systems more modifiable/user accessible without compromising on the general security aspect.
If they really wanted to lock in Linux users to a single blessed image from them they would have had a better chance when Lennart was working at Microsoft (which generally is the only preinstalled CA) instead of starting a "competing" company (they are targeting a different niche from what I understand).
This, and locking down everyone to a single blessed Linux distro would be... Rather difficult given how widespread Linux is and just how many distros exist. It is one thing for each distro to decide "Hey, let's use systemd". Gnome requires it but that's Gnome; there is nothing stopping you from using XFCE, or I3, or KDE, or... It is a totally different thing to make every Linux distro stop working (and have said distro go along with that) because that distro isn't the "blessed" one. Microsoft can pull this off because they're Microsoft and they have total control over one of the most dominant operating systems. Apple can pull this off because they're Apple and control everything from the hardware upwards. Linux is neither of these. I would go so far as to argue that the BSDs have a better chance of pulling off something like this than Lennart does. RedHat may have a lot of influence in the Linux world, but it certainly doesn't have some secret god mode switch it can flip and universally make every distro conform to it's wants and desires.
> it is really fearmongering when the systemd people literally founded a company to develop attestation for linux?
Can you prove beyond a reasonable doubt that they intend to force this on you without any way of disabling it, or that they have already done so? Because unless they plan to do this (and you have concrete proof of such and not just "well they could do this" claims) or they have already done it across a significant portion of the Linux distribution ecosystem (and no, distros voluntarily switching to systemd is not forcing anyone to do anything), this is fearmongering. Simple as that.
reply