[HN Gopher] Enable hibernation when Lockdown is enabled
___________________________________________________________________
Enable hibernation when Lockdown is enabled
Author : doener
Score : 78 points
Date : 2021-02-22 08:36 UTC (14 hours ago)
(HTM) web link (lore.kernel.org)
(TXT) w3m dump (lore.kernel.org)
| 1996 wrote:
| Very interesting work, but I see 2 major weakness: (hinted at the
| bottom of the introduction)
|
| > So. During hibernation we freeze userland. We then reset PCR 23
| and
|
| > extend it to a known value. We generate a key, use it and then
| encrypt
|
| > it with the TPM. When we encrypt it, we define a policy which
| states
|
| > that the TPM must have the same PCR 23 value as it presently
| does. We
|
| > also store the current PCR 23 value in the key metadata. On
| resume, we
|
| > again freeze userland, reset PCR 23 and extend it to the same
| value. We
|
| > decrypt the key, and verify from the metadata that it was
| created when
|
| > PCR 23 had the expected value.
|
| First weakness: kexec. It's not clear how the extension of PCR23
| will be compatible with different kernel versions. What if you
| want to upgrade in place and kexec your new kernel, to avoid too
| much time spend in the bios (as is often the case on systems with
| multiple disks and specific peripherals)? What if an attacker use
| kexec for more evil purposes?
|
| Second weakness: kernel image attack. This work is interesting in
| that in provide a nice way to prevent a specific kind of evil
| maid attack (replacing the content of your swap by something
| evil), but the job of protecting the swap falls in the kernel.
|
| If the extension of PCR23 is done with a common key (to help with
| the kexec - for example the UUID) or anything that can easily be
| guessed/recovered, it will be possible to cook an "evil" kernel
| that 1) extend PCR23 with it to get access 2) inject content into
| the swap before resume. It just moves the problems.
|
| As most systems use a shimx64 followed by grub, it won't be
| detectable by the user.
|
| The best solution I see:
|
| 1) secureboot with your own keys, using a fat EFI (kernel +
| initrd + cmdline in one EFI file) that you sign (cf
| https://wiki.archlinux.org/index.php/EFISTUB ; and to
| automatically deploy new kernel on apt upgrade, use a systemd
| monitor:
| https://wiki.archlinux.org/index.php/EFI_system_partition#Us... )
| : the computer won't boot if this is altered
|
| 2) place what's used to extend the PCR23 in a luks partitions
| with 2 keys: a plain text one for recovery or transfer of the
| disk to another computer (or rescue operations etc), one stored
| in the TPM
|
| You could also store in that protected partition the keys for
| other boot related task - just let the kernel key manager expire
| the key and have the final step of the boot unmount this
| partition. Even if it's 0700 and the file inside are readable
| only by root, you don't want a zero day to expose your keys
| mjg59 wrote:
| There's a more detailed background on this here:
| https://mjg59.dreamwidth.org/55845.html
| mtzet wrote:
| > In 2012 Microsoft started requiring vendors ship systems with
| UEFI Secure Boot, a firmware feature that allowed[5] systems to
| refuse to boot anything without an appropriate signature. This
| not only enabled the creation of a system that drew a strong
| boundary between root and kernel, it arguably required one -
| what's the point of restricting what the firmware will stick in
| ring 0 if root can just throw more code in there afterwards?
|
| I still think there's plenty of point. I usually don't care
| about what ring0 can do; I care about what the system can do.
| Root can steal or destroy my data, or make my system do bad
| things.
|
| The reason for restricting what kernel will be loaded, is to
| restrict what will happen at userspace.
|
| A common use-case is bitlocker-style encryption. The system
| decrypts my harddrive using keys from the TPM. My own userspace
| is secured at the userspace-level using a login prompt. To
| defend against an attacker sideloading a different OS, I rely
| on secure boot to only load my kernel and hence my userspace.
|
| I'm actually having a bit of a hard time finding really good
| usecases for this lockdown feature. On embedded systems the
| secure boot keys are often fused in, but I suppose the kernel,
| but potentially not root, could be able to change the tpm keys
| on an x86 system?
| baybal2 wrote:
| > but potentially not root, could be able to change the tpm
| keys on an x86 system?
|
| A non-root can change the entire TPM chip on an x86 system...
| Boulth6 wrote:
| > To defend against an attacker sideloading a different OS, I
| rely on secure boot to only load my kernel and hence my
| userspace.
|
| You could additionally seal the TPM key to specific PCR
| values so that only booting your kernel would allow using
| that TPM key.
|
| > kernel, but potentially not root, could be able to change
| the tpm keys on an x86 system?
|
| Depends on what do you mean by "change". They can't extract
| private bits but they can remove and add new ones. But if the
| data is encrypted using the old key it would become bit
| recoverable.
| TargetedVictim wrote:
| Dutch police and mainstream media is trying to kill me over
| bitcoin and ethereum, for over 3 years now.
| https://pastebin.com/btAfNf3T
| dash2 wrote:
| I wish someone would enable me to hibernate in lockdown :-/
| dstick wrote:
| Hehe I thought the exact same thing. Thanks for articulating
| stuaxo wrote:
| It's the waking up from hibernation that always seems to be
| iffy.
| saagarjha wrote:
| Have you tried checking if you have the necessary FAT drivers?
| You may also want to try looking into dropping your core
| temperatures a bit.
| dash2 wrote:
| The FAT driver is definitely not a problem....
| toyg wrote:
| Mine is now abundantly ExFAT
| altcognito wrote:
| Man, it would be legit amazing if we could just sleep off
| extra fat. If that would include a proper rebuilding of
| damaged tissues, just wow. Sleep will have to suffice for
| now.
| bobthepanda wrote:
| To a degree this is what happens already. Just not
| generally fast enough to avoid putting in the hard work of
| exercising and diet. (In fact, muscle growth is you
| damaging your muscles with strenuous exercise and then the
| body repairing itself to a better state during your sleep.)
|
| Fix your sleep is pretty good baseline advice for people
| starting fitness.
| gostsamo wrote:
| The biggest issue are gut bacteria, a.k.a user space devices
| with their own energy supply that are not managed by the
| kernel.
| no_no_no_no wrote:
| You need to Add support for in-kernel resetting of PCRs
| Negative or positive...
| bayindirh wrote:
| From "SecureBoot is hindering Linux" to "How we can exploit its
| feature set further, so we can make things even more secure".
| Wow.
|
| I'm actually glad that Linux has found a way to use SecureBoot
| and build upon it. This is really impressive.
|
| I still don't like the idea of being Microsoft is the only key
| authority, but well...
| DyslexicAtheist wrote:
| > I still don't like the idea of being Microsoft is the only
| key authority, but well...
|
| anyone aware of companies building alternatives to this? If I'd
| be China, Russia or Iran I'd have a keen interest in avoiding
| letting my adversary manage attestation at all cost.
| jgowdy wrote:
| Isn't this moot given that with many BIOS interfaces you can
| choose your own root authority and not use theirs?
| eloeffler wrote:
| First thing I expected from the title was a nerdy article about
| sleeping through winter during a Covid curfew, hah!
| xxs wrote:
| It says: "kernel.org". The context is there.
| paganel wrote:
| Has anyone ever carried out a sociological study about the
| "anthropomorphism" (for lack of a better word) present in
| computer science/the IT industry?
| marcosdumay wrote:
| Yes, the context is there to correct you right after you make
| the wrong conclusion.
|
| That's not a complaint, by the way, I found it hilarious.
| londons_explore wrote:
| Why not simply require the hibernation image is stored on a LUKS
| partition?
|
| Then nobody can tamper with the image, since the LUKS key is
| derived from the TPM...
|
| Then you get to reuse all the existing kernel infrastructure
| rather than reinventing the encryption wheel...
| lmm wrote:
| > Then nobody can tamper with the image, since the LUKS key is
| derived from the TPM...
|
| How do you avoid root having access to it?
| londons_explore wrote:
| Simply don't allow root to write to partitions that would be
| eligible for resume?
|
| Ie. if it's swap on LUKS, writes are disallowed and resume
| can happen. In all other situations, writes are allowed, but
| resume cannot.
|
| There isn't a thread safe way for root to write to a swap
| partition while it's in use anyway, and I'm not even sure if
| the current kernel allows that.
| lorenzhs wrote:
| How do you suggest enforcing that root can't write to a
| LUKS swap partition? Root knows the key, root can write to
| block devices, what's stopping me from disabling swap and
| writing a backdoored image to the partition with a user-
| space implementation of LUKS?
| hkt wrote:
| Sound life advice
| londons_explore wrote:
| I don't really agree with this separation of privileges between
| root and kernel... (and by extension, lockdown mode)
|
| It seems to add a lot of complexity, and offers no real world
| usecases.
|
| If you want a secure system, don't run untrusted code as root! If
| your evil code only runs as a regular user, there is no issue
| trusting hibernation, because a non-root user will never be able
| to touch the hibernation image. Even if you assume the non-root
| user has physical access to the disk between boots, you can use
| disk encryption and TPM to ensure they can't mess with it.
| TheRealPomax wrote:
| And how do you propose to effect that? Because can you trust
| apt? Not really, but we just do. Can you trust that you're
| talking to the DNS server you think you're talking to? Again,
| not really, but we do. Can you trust that your admin won't
| violate their contract, and the law, for personal gain (or to
| prevent personal loss)? Still no, but again we typically do
| anyway.
|
| The real world includes things like large infrastructure,
| hospitals, defence, etc. Separating root from kernel in those
| settings adds complexity because just having "be root" be your
| access pass to the everything has already been proven to not be
| good enough time and time again.
| mschuster91 wrote:
| > It seems to add a lot of complexity, and offers no real world
| usecases.
|
| As sad as it is, there is one use case: DRM and other forms of
| device integrity attestations.
| userbinator wrote:
| Exactly. Its main goal is to appease the authoritarian
| corporatocracy.
|
| This is one of the biggest signs that open source does not
| mean freedom.
| bayindirh wrote:
| > It seems to add a lot of complexity, and offers no real world
| usecases.
|
| I'd love to be able to lock my system in a trusted state and
| try some dangerous things, having another level of isolation
| between kernel and root, as long as I have the keys to
| revert/modify the state.
|
| This irks the old timers (incl. me) as "It's already secure
| when process doesn't have root, eh?", but containers, cloud,
| virtualization and other stuff makes these further enhancements
| useful. I'm not adding high security installations to this set
| of scenarios.
|
| Linux is already pretty secure by most counts, but more
| security won't hurt IMHO.
| sildur wrote:
| > I'd love to be able to lock my system in a trusted state
| and try some dangerous things, having another level of
| isolation between kernel and root, as long as I have the keys
| to revert/modify the state.
|
| You should take a look to QubesOS. It gives me peace of mind.
| seniorivn wrote:
| there is a of privilege association
| seniorivn wrote:
| *a risk
| Jasper_ wrote:
| setuid breaks this thinking. For nearly 15 years, "beep" on
| Debian could be exploited to get root. "Don't write
| unexploitable code that runs as root" is not a solid defense
| mechanism for today's world.
| pilif wrote:
| _> If you want a secure system, don 't run untrusted code as
| root!_
|
| This pretty much means: don't run any untrusted code as any
| user (because privilege escalation) and that also pretty much
| includes visiting any web page.
|
| Security flaws exist and they are in-fact being abused.
|
| Not having to completely wipe a machine (if that even helps.
| Who knows what kind of tricks malware elevating its privileges
| to root can pull) after every day of web browsing is a nice
| convenience to have.
| Nullabillity wrote:
| Malware running as root doesn't need kernel access to wreak
| plenty of havoc. Hell, your own user has access to almost all
| of the data that both you and the malware author are likely
| to care about.
| gruez wrote:
| Relevant xkcd: https://xkcd.com/1200/
| user-the-name wrote:
| Yes, the security model based around users in Unix is very
| outdated at this point. It doesn't really represent the
| kind of threats a modern computer faces.
| pilif wrote:
| Malware running as a normal user can't put itself in a
| position where it's hidden from software running as root.
|
| Preserving system integrity was my point.
|
| The patch in the original article is about preserving
| system integrity in the face of a compromised root account
| and the only way of doing that is by limiting the
| capabilities of the root user.
|
| It adds one more and hopefully final level of defense in
| order to guarantee system integrity.
| NullPrefix wrote:
| >This pretty much means: don't run any untrusted code as any
| user
|
| Wasn't this a recommendation from Intel when spectre/meltdown
| happened?
| yjftsjthsd-h wrote:
| > because privilege escalation
|
| If we're assuming a vulnerable kernel, why not assume
| vulnerable firmware and throw the whole thing out?
| zozbot234 wrote:
| > It seems to add a lot of complexity, and offers no real world
| usecases.
|
| The use case for kernel lockdown has to do with being a good
| player in the Secure Boot ecosystem so that kernel images can
| be signed by default. If a malicious user can boot the kernel
| in secure boot mode and then get it to execute code in ring0
| that chainloads a different OS while staying in secure boot
| mode and with the user being none the wiser, this subverts the
| ecosystem since the other OS will lose its pre-existing
| guarantees about system state. Note that the EFI "shim"
| executable does allow for chainloading an OS in secure mode but
| only after prompting the user to that effect.
| lima wrote:
| Isn't that kind of a lost fight? So many signed bootloaders
| and no way to revoke in-the-wild.
| londons_explore wrote:
| Just make the linux kernel modify the TPM state in some way
| on startup? Then any chainloaded OS would be able to see it
| isn't running on bare metal.
| est31 wrote:
| Due to namespacing, anybody can appear as root to the kernel,
| at least if unprivileged namespacing is allowed. So you kinda
| need the separation.
| londons_explore wrote:
| Is this true? While you can appear root to other userspace
| apps, I don't think any amount of namespacing will let you
| get capabilities to load kernel drivers...
| breton wrote:
| > an attacker with root (but not kernel) privileges could disable
| swap, write a valid hibernation image containing code of their
| own choosing to the swap partition, and then reboot. On reboot,
| the kernel would happily resume the provided code.
|
| Could someone please explain why an attacker with root would do
| that, and not just use their root privileges? Shouldn't SELinux
| prevent this kind of attack?
| saagarjha wrote:
| Finally, a practical use for TPMs that isn't DRM! One thing I'm
| curious about is if encryption is dependent on the current boot-
| if not, could an attacker steal the hibernation state, reboot
| into a kernel of its choosing with the right PCR state, decrypt
| and then re-encrypt an altered restore?
| Kwpolska wrote:
| TPM is also used by BitLocker drive encryption, it enables
| passwordless encryption.
| Kubuxu wrote:
| The solution for that is Secure Boot. As far as I know TPM is
| aware of Secure Boot status being changed and will disable/wipe
| secrets when it happens.
| Kubuxu wrote:
| Downgrade is an issue as previously signed kernels (before
| this patch) would be happy with userspace using that TPM
| config to decrypt the hibernation imagine.
|
| As the previous kernels are already signed, downgrading to
| them is allowed under the Secure Boot, but booting a new
| version of unsigned kernel on that machine is not.
| sanxiyn wrote:
| That's what "downgrade kernel" means in the mail. This patchset
| does not address that issue, but apparently there is a way to
| make it work.
| bestouff wrote:
| At last ! Glad to see this incoming. Now if it could work also
| for LineageOS phones, that would be perfect.
___________________________________________________________________
(page generated 2021-02-22 23:01 UTC)