> On May 2, 2019, at 4:19 PM, James Morris <jmorris@xxxxxxxxx> wrote: > >> On Thu, 2 May 2019, Matthew Garrett wrote: >> >>> On Thu, May 2, 2019 at 2:07 PM James Morris <jmorris@xxxxxxxxx> 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. > >> 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.
