Linux-Security-Module Archive on lore.kernel.org
 help / color / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: Christian Brauner <christian.brauner@ubuntu.com>
Cc: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
	linux-integrity@vger.kernel.org, keyrings@vger.kernel.org,
	linux-security-module@vger.kernel.org
Subject: Re: null-ptr-deref in integrity_inode_free()
Date: Wed, 14 Apr 2021 16:21:05 -0400
Message-ID: <c4fa972d0aa32febee712cd70723a5da12a06ee2.camel@linux.ibm.com> (raw)
In-Reply-To: <20210414181940.fp66fiwkcfoogu44@wittgenstein>

On Wed, 2021-04-14 at 20:19 +0200, Christian Brauner wrote:
> On Wed, Apr 14, 2021 at 01:46:46PM -0400, Mimi Zohar wrote:
> > Hi Christian,
> > 
> > On Wed, 2021-04-14 at 13:50 +0200, Christian Brauner wrote:
> > > Hey,
> > > 
> > > [Resending since the previous mail somehow hasn't made it onto the list.]
> > > 
> > > While working on a patch to port ecryptfs to use clone_private_mount() I
> > > hit the splat in [1] with v5.12-rc6 (Without any of my changes.). To
> > > reproduce this you can use the config in [5]. Then run the scripts [2]
> > > and [3] in two terminals. The kernel command line was [4]:
> > > 
> > > while true; do ./test.sh; done
> > > while true; do ./test2.sh; done
> > > 
> > > and wait for [1] to appear.
> > > 
> > > The two test scripts aren't specifically designed to trigger this issue.
> > > They were stress tests for my ecryptfs clone_private_mount() port. They
> > > just allow to trigger this issue.
> > > 
> > > From a very uninformed position it seemed that:
> > > 
> > > void integrity_inode_free(struct inode *inode)
> > > {
> > >         struct integrity_iint_cache *iint;
> > > 
> > >         if (!IS_IMA(inode))
> > >                 return;
> > 
> > Thank you for all the details.
> > 
> > A builtin IMA policy wasn't specified on the boot command line.  Unless
> > a custom IMA policy is loaded, it shouldn't get beyond this
> > point.   Before looking any farther, I would appreciate your confirming
> > that you've loaded a custom IMA policy.  To see if a policy has been
> > loaded, cat /sys/kernel/security/ima/policy.
> 
> Ah, interesting thank you. Here's the output:
> 
> sudo cat /sys/kernel/security/ima/policy
>   dont_measure fsmagic=0x9fa0
>   dont_measure fsmagic=0x62656572
>   dont_measure fsmagic=0x64626720
>   dont_measure fsmagic=0x1021994
>   dont_measure fsmagic=0x1cd1
>   dont_measure fsmagic=0x42494e4d
>   dont_measure fsmagic=0x73636673
>   dont_measure fsmagic=0xf97cff8c
>   dont_measure fsmagic=0x43415d53
>   dont_measure fsmagic=0x27e0eb
>   dont_measure fsmagic=0x63677270
>   dont_measure fsmagic=0x6e736673
>   dont_measure fsmagic=0xde5e81e4
>   measure func=MMAP_CHECK mask=MAY_EXEC
>   measure func=BPRM_CHECK mask=MAY_EXEC
>   measure func=FILE_CHECK mask=^MAY_READ euid=0
>   measure func=FILE_CHECK mask=^MAY_READ uid=0
>   measure func=MODULE_CHECK
>   measure func=FIRMWARE_CHECK
>   measure func=POLICY_CHECK
> 
> Hm, note that ecryptfs is not in this list so I guess ecryptfs would be
> measured?

That's the "tcb" policy, which can be specified as "policy=tcb" on the
boot command line.  The builtin policy rules are generic and would
normally be replaced with more specific policy rules based on LSM
labels.

Right, ecryptfs files are being measured.

There's somehow a race freeing the inode.  The fix is straight forward.
Did you want to fix it or should I?

thanks,

Mimi


  reply index

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210414115055.mayc4aeonsklgwks@wittgenstein>
2021-04-14 17:46 ` Mimi Zohar
2021-04-14 18:19   ` Christian Brauner
2021-04-14 20:21     ` Mimi Zohar [this message]
     [not found]       ` <CAHrFyr67SkruTdYnRYy+OkrEh6wqz1A=DGHZLKE2b0s-_=Cb8g@mail.gmail.com>
2021-04-14 20:36         ` 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=c4fa972d0aa32febee712cd70723a5da12a06ee2.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --cc=christian.brauner@ubuntu.com \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    /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

Linux-Security-Module Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-security-module/0 linux-security-module/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-security-module linux-security-module/ https://lore.kernel.org/linux-security-module \
		linux-security-module@vger.kernel.org
	public-inbox-index linux-security-module

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-security-module


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git