On Thu, Aug 08, 2013 at 09:48:45PM -0700, Greg KH wrote:
On Fri, Aug 09, 2013 at 12:37:45PM +0800, Lee, Chun-Yi wrote:
From: Matthew Garrett
Secure boot adds certain policy requirements, including that root must not be able to do anything that could cause the kernel to execute arbitrary code. The simplest way to handle this would seem to be to add a new capability and gate various functionality on that. We'll then strip it from the initial capability set if required.
Signed-off-by: Matthew Garrett
Acked-by: Lee, Chun-Yi --- include/uapi/linux/capability.h | 6 +++++- I know this has been submitted upstream, do you know what the status of it being accepted it?
It's run into the problem that capabilities are, broadly, unusable. Adding a new capability means adding new capability checks for fairly obvious reasons. But existing capability-aware applications will drop all privileges except the ones they know they need, which means they won't have the new capability and so fail the new capability checks. This means it's effectively impossible to add a new capability outside a small number of corner cases - it's fine adding capabilities to let you do things you can't currently do, but removing privileges just breaks things. So, despite the fact that I'm the one who proposed this originally, I don't think it's a viable approach. So what are the other options? We can add if (secure_boot) guards, but it's been made clear that people want something that has general benefit rather than being special-cased. All I've really been able to come up with is implementing a BSD-like securelevel. I hear the 90s are this decade's 80s. -- Matthew Garrett | mjg59@srcf.ucam.org -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org