All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Berger <stefanb@linux.ibm.com>
To: Stefan Berger <stefanb@linux.vnet.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, jejb@linux.ibm.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: [PATCH v8 16/19] ima: Enable re-auditing of modified files
Date: Wed, 5 Jan 2022 10:21:38 -0500	[thread overview]
Message-ID: <be083959-b1ef-9de7-0ea6-71ab36596523@linux.ibm.com> (raw)
In-Reply-To: <20220104170416.1923685-17-stefanb@linux.vnet.ibm.com>


On 1/4/22 12:04, Stefan Berger wrote:
> From: Stefan Berger <stefanb@linux.ibm.com>
>
> Walk the list of ns_status associated with an iint if the file has
> changed and reset the IMA_AUDITED flag, which is part of the
> IMA_DONE_MASK. This causes a new audit message to be emitted when the
> file is again accessed on either the host or in an IMA namespace.
>
> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
> ---
>   security/integrity/ima/ima_main.c | 33 ++++++++++++++++++++++++++++++-
>   1 file changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> index 99dc984b49c9..bc3ab08f39c6 100644
> --- a/security/integrity/ima/ima_main.c
> +++ b/security/integrity/ima/ima_main.c
> @@ -153,6 +153,35 @@ static void ima_rdwr_violation_check(struct ima_namespace *ns,
>   				  "invalid_pcr", "open_writers");
>   }
>   
> +#ifdef CONFIG_IMA_NS
> +
> +static void mask_iint_ns_status_flags(struct integrity_iint_cache *iint,
> +				      unsigned long mask)
> +{
> +	struct ns_status *status;
> +	unsigned long flags;
> +
> +	read_lock(&iint->ns_list_lock);
> +	list_for_each_entry(status, &iint->ns_list, ns_next) {
> +		flags = iint_flags(iint, status) & mask;
> +		set_iint_flags(iint, status, flags);
> +	}
> +	read_unlock(&iint->ns_list_lock);
> +}
> +
> +#else
> +
> +static void mask_iint_ns_status_flags(struct integrity_iint_cache *iint,
> +				      unsigned long mask)
> +{
> +	unsigned long flags;
> +
> +	flags = iint_flags(iint, NULL) & mask;
> +	set_iint_flags(iint, NULL, flags);
> +}
> +
> +#endif
> +

The above two cases are due to this here:

diff --git a/security/integrity/integrity.h b/security/integrity/integrity.h
index 547425c20e11..201a9d46d6e1 100644
--- a/security/integrity/integrity.h
+++ b/security/integrity/integrity.h
@@ -138,6 +138,10 @@ struct integrity_iint_cache {
  	enum integrity_status ima_creds_status:4;
  	enum integrity_status evm_status:4;
  	struct ima_digest_data *ima_hash;
+#ifdef CONFIG_IMA_NS
+	rwlock_t ns_list_lock;
+	struct list_head ns_list;
+#endif
  };

Ideally namespaced and non-namespaced code cases would share the code and to be able to share it the above #ifdef CONFIG_IMA_NS  in integrity.hshouldn't be there but we would have the lock and list in IMA namespacing and non-namespacing case. The above two code cases shown above are just the beginning and as more variables are moved from the iint into the ns_status these types of 'two cases of code' would show up in more places. So I think we should prevent this already now.

To be able to share the code we need an ns_status on a list in the non-namespacing case as well. In the non-namespacing case it would always be a single ns_status on the list. What is worth a decision is how to get the ns_status on the list. One idea would be to conditionally embed it into the integrity_iint_cache like this:

/* integrity data associated with an inode */
struct integrity_iint_cache {
         struct rb_node rb_node; /* rooted in integrity_iint_tree */
         struct mutex mutex;     /* protects: version, flags, digest */
         struct inode *inode;    /* back pointer to inode in question */
         u64 version;            /* track inode changes */
         unsigned long flags;
         unsigned long atomic_flags;
         enum integrity_status ima_file_status:4;
         enum integrity_status ima_mmap_status:4;
         enum integrity_status ima_bprm_status:4;
         enum integrity_status ima_read_status:4;
         enum integrity_status ima_creds_status:4;
         enum integrity_status evm_status:4;
         struct ima_digest_data *ima_hash;
         rwlock_t ns_list_lock;
         struct list_head ns_list;
#ifndef CONFIG_IMA_NS
	struct ns_status status;
#endif
};

This would prevent a 2nd cache just for allocation of ns_status in the 
non-namespacing case and getting the  embedded ns_status onto the list 
would also be like this:

     INIT_LIST_HEAD(&iint->ns_list);

#ifndef CONFIG_IMA_NS

     INIT_LIST_HEAD(&iint->status.ns_next);

     list_add_tail(&iint->status.ns_next, &iint->ns_list);

#endif

The other option is to allocated the ns_status via a minimal 
implementation of ima_ns_status.c for the non-namespaced case using 
kmalloc's from a cache for ns_status structures.


Also, the new 'rwlock_t ns_list_lock' in the iint would really only be 
necessary for locking in the namespacing case. However, to be able to 
share the code we would need to keep this lock around for the 
non-namespacing case as well so that we can call read_lock() in both 
cases. An option would be to introduce a macro for the locking that is a 
no-op in the non-namespacing case and does the actual locking in the 
namespacing case. I am not sure what would be better. I would prefer to 
explicitly see the read_lock()...



>   static void ima_check_last_writer(struct integrity_iint_cache *iint,
>   				  struct inode *inode, struct file *file)
>   {
> @@ -169,8 +198,10 @@ static void ima_check_last_writer(struct integrity_iint_cache *iint,
>   		if (!IS_I_VERSION(inode) ||
>   		    !inode_eq_iversion(inode, iint->version) ||
>   		    (iint->flags & IMA_NEW_FILE)) {
> -			iint->flags &= ~(IMA_DONE_MASK | IMA_NEW_FILE);
> +			mask_iint_ns_status_flags(iint,
> +					~(IMA_DONE_MASK | IMA_NEW_FILE));
>   			iint->measured_pcrs = 0;
> +
>   			if (update)
>   				ima_update_xattr(iint, file);
>   		}

  reply	other threads:[~2022-01-05 15:21 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-04 17:03 [PATCH v8 00/19] ima: Namespace IMA with audit support in IMA-ns Stefan Berger
2022-01-04 17:03 ` [PATCH v8 01/19] securityfs: Extend securityfs with namespacing support Stefan Berger
2022-01-05  3:58   ` Al Viro
2022-01-05 10:18     ` Christian Brauner
2022-01-11 12:16       ` Mimi Zohar
2022-01-11 14:12         ` Christian Brauner
2022-01-04 17:03 ` [PATCH v8 02/19] ima: Define ima_namespace structure and implement basic functions Stefan Berger
2022-01-04 17:04 ` [PATCH v8 03/19] ima: Move policy related variables into ima_namespace Stefan Berger
2022-01-13 20:26   ` Mimi Zohar
2022-01-14 10:48     ` Christian Brauner
2022-01-19 13:32     ` Stefan Berger
2022-01-04 17:04 ` [PATCH v8 04/19] ima: Move ima_htable " Stefan Berger
2022-01-04 17:04 ` [PATCH v8 05/19] ima: Move measurement list related variables " Stefan Berger
2022-01-13 20:27   ` Mimi Zohar
2022-01-19 12:23     ` Stefan Berger
2022-01-04 17:04 ` [PATCH v8 06/19] ima: Move some IMA policy and filesystem " Stefan Berger
2022-01-04 17:04 ` [PATCH v8 07/19] ima: Move dentry into ima_namespace and others onto stack Stefan Berger
2022-01-13 20:28   ` Mimi Zohar
2022-01-18 20:12     ` Stefan Berger
2022-01-18 20:42       ` Mimi Zohar
2022-01-18 20:54         ` Stefan Berger
2022-01-04 17:04 ` [PATCH v8 08/19] ima: Use mac_admin_ns_capable() to check corresponding capability Stefan Berger
2022-01-05 20:55   ` kernel test robot
2022-01-05 20:55     ` kernel test robot
2022-01-13 20:28   ` Mimi Zohar
2022-01-04 17:04 ` [PATCH v8 09/19] ima: Only accept AUDIT rules for non-init_ima_ns namespaces for now Stefan Berger
2022-01-04 17:04 ` [PATCH v8 10/19] ima: Implement hierarchical processing of file accesses Stefan Berger
2022-01-14 11:21   ` Christian Brauner
2022-01-18 18:25     ` Stefan Berger
2022-01-04 17:04 ` [PATCH v8 11/19] ima: Implement ima_free_policy_rules() for freeing of an ima_namespace Stefan Berger
2022-01-04 17:04 ` [PATCH v8 12/19] userns: Add pointer to ima_namespace to user_namespace Stefan Berger
2022-01-04 17:04 ` [PATCH v8 13/19] ima: Add functions for creation and freeing of an ima_namespace Stefan Berger
2022-01-14 11:43   ` Christian Brauner
2022-01-04 17:04 ` [PATCH v8 14/19] integrity/ima: Define ns_status for storing namespaced iint data Stefan Berger
2022-01-04 17:04 ` [PATCH v8 15/19] ima: Namespace audit status flags Stefan Berger
2022-01-04 17:04 ` [PATCH v8 16/19] ima: Enable re-auditing of modified files Stefan Berger
2022-01-05 15:21   ` Stefan Berger [this message]
2022-01-04 17:04 ` [PATCH v8 17/19] ima: Setup securityfs for IMA namespace Stefan Berger
2022-01-04 17:04 ` [PATCH v8 18/19] ima: Show owning user namespace's uid and gid when displaying policy Stefan Berger
2022-01-14 13:45   ` Christian Brauner
2022-01-18 16:31     ` Stefan Berger
2022-01-19  9:23       ` Christian Brauner
2022-01-04 17:04 ` [PATCH v8 19/19] ima: Enable IMA namespaces Stefan Berger
2022-01-14 12:05   ` Christian Brauner
2022-01-18 17:53     ` Stefan Berger
2022-01-14 14:45   ` Christian Brauner
2022-01-18 18:09     ` Stefan Berger
2022-01-19  9:46       ` Christian Brauner
2022-01-19 12:45         ` Stefan Berger
2022-01-19 13:03           ` Christian Brauner

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=be083959-b1ef-9de7-0ea6-71ab36596523@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=stefanb@linux.vnet.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.