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 > > > 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 own > > Ok, 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). > > > 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 <jmorris@xxxxxxxxx>
