[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jKjXqn-1j881vYc1F0POPhPJOPZB1w=W_zfgdXTsiyX6A@mail.gmail.com>
Date: Thu, 16 Nov 2017 17:08:57 -0800
From: Kees Cook <keescook@...omium.org>
To: Roberto Sassu <roberto.sassu@...wei.com>
Cc: Mimi Zohar <zohar@...ux.vnet.ibm.com>,
linux-integrity@...r.kernel.org,
linux-security-module <linux-security-module@...r.kernel.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
linux-doc@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
silviu.vlasceanu@...wei.com
Subject: Re: [PATCH v2 00/15] ima: digest list feature
On Tue, Nov 7, 2017 at 8:45 AM, Roberto Sassu <roberto.sassu@...wei.com> wrote:
> On 11/7/2017 2:37 PM, Mimi Zohar wrote:
>> Normally, the protection of kernel memory is out of scope for IMA.
>> This patch set introduces an in kernel white list, which would be a
>> prime target for attackers looking for ways of by-passing IMA-
>> measurement, IMA-appraisal and IMA-audit. Others might disagree, but
>> from my perspective, this risk is too high.
BTW, which part of the series does the whitelist? I'd agree generally,
though: we don't want to make things writable if they're normally
read-only.
> It would be much easier for an attacker to just set ima_policy_flag to
> zero.
That's a fair point. I wonder if ima_policy_flag could be marked
__ro_after_init? Most of the writes are from __init sections, but I
haven't looked closely at when ima_update_policy() gets called.
-Kees
--
Kees Cook
Pixel Security
Powered by blists - more mailing lists