Re: [PATCH V32 01/27] Add the ability to lock down access to the running kernel image
From: James Morris <jmorris@namei.org>
Date: 2019-05-02 23:19:57
Also in:
linux-api, lkml
On Thu, 2 May 2019, Matthew Garrett wrote:
On Thu, May 2, 2019 at 2:07 PM James Morris [off-list ref] wrote:quoted
One possible direction is to (as previously mentioned) assign IDs to each callsite and be able to check this ID against a simple policy array (allow/deny). The default policy choices could be reduced to 'all' or 'none' during kconfig, and allow a custom policy to be loaded later if desired.Ok. My primary concern around this is that it's very difficult to use correctly in anything other than the "all" or "none" modes. If a new kernel feature is added with integrated lockdown support, if an admin is simply setting the flags of things they wish to block then this will be left enabled - and may violate the admin's expectations around integrity. On the other hand, if an admin is simply setting the flags of things they wish to permit, then adding lockdown support to an existing kernel feature may result in that feature suddenly being disabled, which may also violate the admin's expectations around the flags providing a stable set of behaviour.
Understood. Most uses will likely be either a distro or an embedded system, who I'm assuming would provide a useful policy by default, and perhaps a high-level abstraction for modification.
Given that, would you prefer such a policy expression to look like?
Perhaps a write-once policy, injected from userspace during early boot? The policy could be simply a list of: lockdown_feature true|false
quoted
Within the policy check hook, we could add a new LSM hook, which would allow an LSM to restrictively override the lockdown policy with its ownOk, that makes sense. If we take this approach, does there need to be a separate policy mechanism at all? Users who want fine-grained control would be able to set the behaviour to "None" and then use their choice of LSM to express more fine-grained control.
Right, and there could be a stackable LSM which just does fine-grained policy (per above).
quoted
This doesn't really address the completeness / maintenance issue (i.e. "do we have everything covered and how do we ensure this on an ongoing basis?", and "what will this new lockdown feature break?"), although it should make it easier to add new lockdown callsites as they don't have to be enabled by the user.I can start on this.
Cool! -- James Morris [off-list ref]