Full Disk Access just gives an application the same filesystem powers that your user account has. For most users that means it has administrator level access, which is the 3rd highest tier.
There are two levels above an administrator-level account: 1) the root user can access files that an administrator can't (e.g. the files of
other users and certain system configuration files), and 2) the kernel and system processes can access "system" files that even root cannot - this is enforced by SIP.
Apple is quite liberal in what they hide away with SIP. It's possible for disk space to leak whereby the OS has decided to store some file that it doesn't need and there is no way to even list such files without following the above instructions - the only indication will be a mysteriously large amount of space taken up by the system.
It goes without saying that if you're going to delete system files you should make sure you know what you're doing.
The HN crowd in particular absolutely has a say in this, given the amount of engineering leads, managers, and even just regular programmers/admins/etc that frequent here - all of whom contribute to making these decisions.
You have the power to not host your own infrastructure on aws and behind cloudflare, or in the case of an employer you have the power to fight against the voices arguing for the unsustainable status quo.
If you need DDoS mitigation then you essentially need to rely on a third party. Every third party will have inevitable downtime. For many it’s just whether you’d prefer to be down while everyone else is down or not.
After that, have a look at pcpartpicker.com, motherboards section. They have feature selectors, like number of usb ports, power connector type and so on. Very useful to find boards.
That's Windows doing that, which they've just compromised and then configured to display only the normal login prompt but send your credentials to the attacker.
They can also decrypt your hard drive by doing the same thing without modifying the original machine by just stealing it and leaving you a compromised one of the same model to also steal your password.
No, GP is misinterpreting Windows's message. It prompts for a recovery key because the TPM is bound to, among other things, Secure Boot == enabled. When Secure Boot is disabled, the TPM notices that and refuses to release the key, that's how you know to reënable Secure Boot or throw away your device.
The fact that Windows is compromised does not make it capable of extracting secrets from the TPM, though maybe a naïve user can be convinced to enter the recovery key anyway...
> When Secure Boot is disabled, the TPM notices that and refuses to release the key, that's how you know to reënable Secure Boot or throw away your device.
But the attacker isn't trying to get the key from the TPM right now, they're trying to get the credentials from the user. It's the same thing that happens with full disk encryption and no TPM. They can't read what's on the device without the secret but they can alter it.
So they alter it to boot a compromised Windows install -- not the original one -- and prompt for your credentials, which they then capture and use to unlock the original install.
They don't need secure boot to be turned on in order to do that, the original Windows install is never booted with it turned off and they can turn it back on later after they've captured your password. Or even leave it turned on but have it boot the second, compromised Windows install to capture your credentials with secure boot enabled.
How suspicious are you going to be if you enter your credentials and the next thing that happens is that Windows reboots "for updates" (into the original install instead of the compromised one)?
So this attack is to steal my Windows password or Windows Hello credentials, but doesn't get my encryption key...? That's...not ideal, but I think you'll see it's an improvement over unencrypted disks (again, TPMs are for people who can't be bothered to set a strong password).
And again this presupposes that you can disable Secure Boot, boot a malicious OS from another drive, fool the user into entering their password, automatically reboot, enable Secure Boot, boot into the legit OS, then come back later and have the ability to boot the OS yourself and log in as the user (because again, you don't have the decryption key, you have the user's login credentials).
You are also presupposing what the TPM is bound to. I don't use Windows, but using systemd-cryptsetup I could configure a TPM to bind to the drives in the system; in this way, it will refuse to boot my legit OS while your malicious disk is installed (well, it will demand a recovery key). Again, setting off alarm bells, and if I discover the disk with my recorded credentials before you can physically access it, I can just destroy it.
> And again this presupposes that you can disable Secure Boot, boot a malicious OS from another drive, fool the user into entering their password, automatically reboot, enable Secure Boot, boot into the legit OS, then come back later and have the ability to boot the OS yourself and log in as the user (because again, you don't have the decryption key, you have the user's login credentials).
But that's the same thing that happens with full disk encryption. They come get physical access to the machine but don't have the decryption key yet so they compromise the unencrypted part of the machine which is what prompts you for it, have that capture the key when you enter it, and now they have the key when they come back to use it.
If anything allowing the short password is even worse, because if you leave your machine in suspend you expect it to prompt for your unlock password but not the full disk encryption key when you come back, so the latter would be suspicious but the former doesn't let them unlock the disk, and now you're using the short password for both.
> You are also presupposing what the TPM is bound to. I don't use Windows, but using systemd-cryptsetup I could configure a TPM to bind to the drives in the system; in this way, it will refuse to boot my legit OS while your malicious disk is installed (well, it will demand a recovery key). Again, setting off alarm bells, and if I discover the disk with my recorded credentials before you can physically access it, I can just destroy it.
Except that it doesn't need to be installed once you're at that point. By then it has already captured your credentials and stored them or sent them to the attacker over the network, so it can disable that device right before it goes to boot into the original operating system.
Also notice that the original premise was to make it easy for ordinary users and now the workaround is to install Linux and change a setting that will confuse people as soon as they leave their own USB stick plugged into their computer.
reply