lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Thu, 2 May 2019 17:34:51 -0700
From:   Andy Lutomirski <luto@...capital.net>
To:     James Morris <jmorris@...ei.org>
Cc:     Matthew Garrett <mjg59@...gle.com>,
        LSM List <linux-security-module@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        David Howells <dhowells@...hat.com>,
        Linux API <linux-api@...r.kernel.org>,
        Andy Lutomirski <luto@...nel.org>
Subject: Re: [PATCH V32 01/27] Add the ability to lock down access to the running kernel image


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

Powered by blists - more mailing lists