On May 2, 2019, at 4:19 PM, James Morris [off-list ref] wrote:

quoted

On Thu, 2 May 2019, Matthew Garrett wrote:

quoted

On Thu, May 2, 2019 at 2:07 PM James Morris [off-list ref] wrote:
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.

quoted

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

I’m not convinced this is worthwhile.  As I see it, there really are only two privileges here: root can read kernel memory, and root can corrupt kernel state.  A policy that root can’t corrupt kernel memory except using, say, eBPF is useless — it gives warm fuzzy feelings but nothing else.