linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Berger <stefanb@linux.ibm.com>
To: jejb@linux.ibm.com, linux-integrity@vger.kernel.org
Cc: zohar@linux.ibm.com, serge@hallyn.com,
	christian.brauner@ubuntu.com, containers@lists.linux.dev,
	dmitry.kasatkin@gmail.com, ebiederm@xmission.com,
	krzysztof.struczynski@huawei.com, roberto.sassu@huawei.com,
	mpeters@redhat.com, lhinds@redhat.com, lsturman@redhat.com,
	puiterwi@redhat.com, jamjoom@us.ibm.com,
	linux-kernel@vger.kernel.org, paul@paul-moore.com,
	rgb@redhat.com, linux-security-module@vger.kernel.org,
	jmorris@namei.org
Subject: Re: [RFC 08/20] ima: Move measurement list related variables into ima_namespace
Date: Thu, 2 Dec 2021 08:41:10 -0500	[thread overview]
Message-ID: <c3b99439-1dd6-e204-ad41-5d8bacb54d48@linux.ibm.com> (raw)
In-Reply-To: <141ce433f026b47edb1d9a8f89e4581db253c579.camel@linux.ibm.com>


On 12/2/21 07:46, James Bottomley wrote:
> On Tue, 2021-11-30 at 11:06 -0500, Stefan Berger wrote:
>> Move measurement list related variables into the ima_namespace. This
>> way a
>> front-end like SecurityFS can show the measurement list inside an IMA
>> namespace.
>>
>> Implement ima_free_measurements() to free a list of measurements
>> and call it when an IMA namespace is deleted.
> This one worries me quite a lot.  What seems to be happening in this
> code:
>
>> @@ -107,7 +100,7 @@ static int ima_add_digest_entry(struct
>> ima_namespace *ns,
>>          qe->entry = entry;
>>   
>>          INIT_LIST_HEAD(&qe->later);
>> -       list_add_tail_rcu(&qe->later, &ima_measurements);
>> +       list_add_tail_rcu(&qe->later, &ns->ima_measurements);
>>   
>>          atomic_long_inc(&ns->ima_htable.len);
>>          if (update_htable) {
>>
> is that we now only add the measurements to the namespace list, but
> that list is freed when the namespace dies.  However, the measurement
> is still extended through the PCRs meaning we have incomplete
> information for a replay after the namespace dies?

*Not at all.* The measurement list of the namespace is independent of 
the host.

The cover letter states:

"The following lines added to a suitable IMA policy on the host would
cause the execution of the commands inside the container (by uid 1000)
to be measured and audited as well on the host, thus leading to two
auditing messages for the 'busybox cat' above and log entries in IMA's
system log.

echo -e "measure func=BPRM_CHECK mask=MAY_EXEC uid=1000\n" \
         "audit func=BPRM_CHECK mask=MAY_EXEC uid=1000\n" \
     > /sys/kernel/security/ima/policy   "

So even now, with only auditing support in the namespace, you would get 
measurements in the host log with an appropriately written IMA policy. 
The measurements in the host log won't go away when the namespace dies.

The intention is to provide flexibility that allows for writing the IMA 
policy of the host in such a way

- that file accesses occurring in namespaces get measured on the host

- that file accesses occurring in the namespace do NOT get measured on 
the host and protect the host log from ever growing or actions in 
namespaces intentionally growing the host log

There would be a namespace policy that would allow for logging inside 
the namespace. Combine this with the policy on the host and you can have 
no measurements of the namespace file access, measurements in either the 
host log or the namespace log or both. What I would be worried about is 
if the flexibility wasn't there.


>
> I tend to think the way this should work is that until we have a way of
> attesting inside the namespace, all measurements should go into the
> physical log, so that replay is always complete for the PCRs, so
> effectively the visible log of the namespace would always have to be a
> subset of the physical log.

Per the cover letter description this is already possible today.

    Stefan


>
> James
>
>

  reply	other threads:[~2021-12-02 13:41 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-30 16:06 [RFC 00/20] ima: Namespace IMA with audit support in IMA-ns Stefan Berger
2021-11-30 16:06 ` [RFC 01/20] ima: Add IMA namespace support Stefan Berger
2021-11-30 16:06 ` [RFC 02/20] ima: Define ns_status for storing namespaced iint data Stefan Berger
2021-11-30 16:06 ` [RFC 03/20] ima: Namespace audit status flags Stefan Berger
2021-11-30 16:06 ` [RFC 04/20] ima: Move delayed work queue and variables into ima_namespace Stefan Berger
2021-11-30 16:06 ` [RFC 05/20] ima: Move IMA's keys queue related " Stefan Berger
2021-11-30 16:06 ` [RFC 06/20] ima: Move policy " Stefan Berger
2021-11-30 16:06 ` [RFC 07/20] ima: Move ima_htable " Stefan Berger
2021-11-30 16:06 ` [RFC 08/20] ima: Move measurement list related variables " Stefan Berger
2021-12-02 12:46   ` James Bottomley
2021-12-02 13:41     ` Stefan Berger [this message]
2021-12-02 16:29       ` James Bottomley
2021-12-02 16:45         ` Stefan Berger
2021-12-02 17:44           ` James Bottomley
2021-12-02 18:03             ` Stefan Berger
2021-12-02 20:03               ` James Bottomley
2021-11-30 16:06 ` [RFC 09/20] ima: Only accept AUDIT rules for IMA non-init_ima_ns namespaces for now Stefan Berger
2021-11-30 16:06 ` [RFC 10/20] ima: Implement hierarchical processing of file accesses Stefan Berger
2021-11-30 16:06 ` [RFC 11/20] securityfs: Prefix global variables with securityfs_ Stefan Berger
2021-11-30 16:06 ` [RFC 12/20] securityfs: Pass static variables as parameters from top level functions Stefan Berger
2021-11-30 16:06 ` [RFC 13/20] securityfs: Build securityfs_ns for namespacing support Stefan Berger
2021-12-02 13:35   ` Christian Brauner
2021-12-02 13:47     ` Stefan Berger
2021-11-30 16:06 ` [RFC 14/20] ima: Move some IMA policy and filesystem related variables into ima_namespace Stefan Berger
2021-11-30 16:06 ` [RFC 15/20] capabilities: Introduce CAP_INTEGRITY_ADMIN Stefan Berger
2021-11-30 17:27   ` Casey Schaufler
2021-11-30 17:41     ` Stefan Berger
2021-11-30 17:50       ` Casey Schaufler
2021-11-30 16:06 ` [RFC 16/20] ima: Use ns_capable() for namespace policy access Stefan Berger
2021-11-30 16:06 ` [RFC 17/20] ima: Use integrity_admin_ns_capable() to check corresponding capability Stefan Berger
2021-12-01 16:58   ` James Bottomley
2021-12-01 17:35     ` Stefan Berger
2021-12-01 19:29       ` James Bottomley
2021-12-02  7:16         ` Denis Semakin
2021-12-02 12:33           ` James Bottomley
2021-12-02 17:54           ` Stefan Berger
2021-12-02 12:59         ` Christian Brauner
2021-12-02 13:01           ` Christian Brauner
2021-12-02 15:58             ` Casey Schaufler
2021-11-30 16:06 ` [RFC 18/20] userns: Introduce a refcount variable for calling early teardown function Stefan Berger
2021-11-30 16:06 ` [RFC 19/20] ima/userns: Define early teardown function for IMA namespace Stefan Berger
2021-11-30 16:06 ` [RFC 20/20] ima: Setup securityfs_ns " Stefan Berger
2021-12-01 17:56   ` James Bottomley
2021-12-01 18:11     ` Stefan Berger
2021-12-01 19:21       ` James Bottomley
2021-12-01 20:25         ` Stefan Berger
2021-12-01 21:11           ` James Bottomley
2021-12-01 21:34             ` Stefan Berger
2021-12-01 22:01               ` James Bottomley
2021-12-01 22:09                 ` Stefan Berger
2021-12-01 22:19                   ` James Bottomley
2021-12-02  0:02                     ` Stefan Berger
2021-12-02 13:18   ` Christian Brauner
2021-12-02 13:52     ` Stefan Berger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c3b99439-1dd6-e204-ad41-5d8bacb54d48@linux.ibm.com \
    --to=stefanb@linux.ibm.com \
    --cc=christian.brauner@ubuntu.com \
    --cc=containers@lists.linux.dev \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=ebiederm@xmission.com \
    --cc=jamjoom@us.ibm.com \
    --cc=jejb@linux.ibm.com \
    --cc=jmorris@namei.org \
    --cc=krzysztof.struczynski@huawei.com \
    --cc=lhinds@redhat.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=lsturman@redhat.com \
    --cc=mpeters@redhat.com \
    --cc=paul@paul-moore.com \
    --cc=puiterwi@redhat.com \
    --cc=rgb@redhat.com \
    --cc=roberto.sassu@huawei.com \
    --cc=serge@hallyn.com \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).