All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Moore <paul@paul-moore.com>
To: Roberto Sassu <roberto.sassu@huaweicloud.com>, zohar@linux.ibm.com
Cc: jmorris@namei.org, serge@hallyn.com,
	linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk,
	Roberto Sassu <roberto.sassu@huawei.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH v2] security: Restore passing final prot to ima_file_mmap()
Date: Fri, 6 Jan 2023 16:14:47 -0500	[thread overview]
Message-ID: <CAHC9VhQUAuF-Fan72j7BOqOdLE=B=mJpJ_GpR5p5cUmXruYT=Q@mail.gmail.com> (raw)
In-Reply-To: <20221221141007.2579770-1-roberto.sassu@huaweicloud.com>

On Wed, Dec 21, 2022 at 9:10 AM Roberto Sassu
<roberto.sassu@huaweicloud.com> wrote:
>
> From: Roberto Sassu <roberto.sassu@huawei.com>
>
> Commit 98de59bfe4b2f ("take calculation of final prot in
> security_mmap_file() into a helper") moved the code to update prot with the
> actual protection flags to be granted to the requestor by the kernel to a
> helper called mmap_prot(). However, the patch didn't update the argument
> passed to ima_file_mmap(), making it receive the requested prot instead of
> the final computed prot.
>
> A possible consequence is that files mmapped as executable might not be
> measured/appraised if PROT_EXEC is not requested but subsequently added in
> the final prot.
>
> Replace prot with mmap_prot(file, prot) as the second argument of
> ima_file_mmap() to restore the original behavior.
>
> Cc: stable@vger.kernel.org
> Fixes: 98de59bfe4b2 ("take calculation of final prot in security_mmap_file() into a helper")
> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
> ---
>  security/security.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/security/security.c b/security/security.c
> index d1571900a8c7..0d2359d588a1 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -1666,7 +1666,7 @@ int security_mmap_file(struct file *file, unsigned long prot,
>                                         mmap_prot(file, prot), flags);
>         if (ret)
>                 return ret;
> -       return ima_file_mmap(file, prot);
> +       return ima_file_mmap(file, mmap_prot(file, prot));
>  }

This seems like a reasonable fix, although as the original commit is
~10 years old at this point I am a little concerned about the impact
this might have on IMA.  Mimi, what do you think?

Beyond that, my only other comment would be to only call mmap_prot()
once and cache the results in a local variable.  You could also fix up
some of the ugly indentation crimes in security_mmap_file() while you
are at it, e.g. something like this:

diff --git a/security/security.c b/security/security.c
index d1571900a8c7..2f9cad9ecac8 100644
--- a/security/security.c
+++ b/security/security.c
@@ -1662,11 +1662,12 @@ int security_mmap_file(struct file *file, unsigned long
prot,
                       unsigned long flags)
{
       int ret;
-       ret = call_int_hook(mmap_file, 0, file, prot,
-                                       mmap_prot(file, prot), flags);
+       unsigned long prot_adj = mmap_prot(file, prot);
+
+       ret = call_int_hook(mmap_file, 0, file, prot, prot_adj, flags);
       if (ret)
               return ret;
-       return ima_file_mmap(file, prot);
+       return ima_file_mmap(file, prot_adj);
}

--
paul-moore.com

  reply	other threads:[~2023-01-06 21:15 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-21 14:10 [PATCH v2] security: Restore passing final prot to ima_file_mmap() Roberto Sassu
2023-01-06 21:14 ` Paul Moore [this message]
2023-01-11  9:30   ` Roberto Sassu
2023-01-11 14:25     ` Paul Moore
2023-01-12 12:36       ` Roberto Sassu
2023-01-12 17:45         ` Mimi Zohar
2023-01-13 10:52           ` Roberto Sassu
2023-01-20 21:04             ` Paul Moore
2023-01-23  8:30               ` Roberto Sassu
2023-01-23 21:03                 ` Paul Moore
2023-01-22 20:29             ` Mimi Zohar

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='CAHC9VhQUAuF-Fan72j7BOqOdLE=B=mJpJ_GpR5p5cUmXruYT=Q@mail.gmail.com' \
    --to=paul@paul-moore.com \
    --cc=jmorris@namei.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=roberto.sassu@huawei.com \
    --cc=roberto.sassu@huaweicloud.com \
    --cc=serge@hallyn.com \
    --cc=stable@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --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.