Hu Administrator
Joined: 06 Mar 2007 Posts: 22893
|
Posted: Sun Nov 10, 2024 5:34 pm Post subject: |
|
|
That depends on what you mean by "safe." Kernel lockdown must disable hibernation, because it is presumed to be unsafe to resume from a kernel image that might have been modified in ways that violate the lockdown policies. The two paths you cite are both overrides of this policy, implemented through different means. Neither adds any security of its own, so whether it is "safe" depends on whether your threat model handles offline modification of the hibernation image. Broadly, I would say threat models here fit one of a few categories:- Kernel lockdown is not wanted, so any negative effects from it are unwanted. You would prefer to enable hibernation despite the risks.
- Offline attacks are assumed to be impossible due to physical security of the computer. Therefore, offline modification of the hibernation image is likewise assumed to be impossible, and you can "safely" enable hibernation.
- Offline attacks are theoretically possible, but you as the operator assume that none will occur in practice, so again, you can "safely" enable hibernation. This can be appropriate for a home user, where every person in the home is trusted.
- Offline attacks are a serious concern (such as for a computer in an office where multiple people have physical access to it, and at least one such person is not trusted with full administrator privilege on the system). You should not enable hibernation here.
If I needed to bypass the restriction, I would use the second patch, on the basis that it was simple enough for me to do a quick visual review and find nothing malicious or complicated in it.
If you want more specific advice, please explain your threat model and why kernel lockdown is enabled at all. What, if any, value do you hope to get from other kernel lockdown features? |
|