From: Mimi Zohar <zohar@linux.ibm.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Fabian Vogt <fvogt@suse.de>, Ignaz Forster <iforster@suse.de>,
overlayfs <linux-unionfs@vger.kernel.org>,
linux-integrity <linux-integrity@vger.kernel.org>
Subject: Re: PROBLEM: IMA xattrs not written on overlayfs
Date: Thu, 04 Oct 2018 11:52:30 -0400 [thread overview]
Message-ID: <1538668350.3702.348.camel@linux.ibm.com> (raw)
In-Reply-To: <CAJfpegt52N==WoSQt_GMwZnOPyoV38j3r8vL95Ds0-NakVFueg@mail.gmail.com>
On Thu, 2018-10-04 at 00:35 +0200, Miklos Szeredi wrote:
> Right, if it's done from last fput() then it's at least not a security hole.
>
> This hack may work for some filesystems, but as you noticed, it won't
> work for overlayfs. And if probably won't work for a number of other
> filesystems as well: the fs can assume that f_mode & FMODE_READ will
> remain off if it was off at open time.
>
> The proper way to handle it generally is to open a separate instance
> of the same file from IMA with O_RDONLY and use that to calculate the
> hash. There's really no point in reusing the same file and hacking
> the f_mode bits.
Is there an appropriate low level kernel call for creating a new file
descriptor that would be appropriate? dentry_open(), like the call in
file_clone_open(), has a lot of overhead, including the LSM calls.
Calculating the file hash always needs to work.
Mimi
WARNING: multiple messages have this Message-ID (diff)
From: Mimi Zohar <zohar@linux.ibm.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Fabian Vogt <fvogt@suse.de>, Ignaz Forster <iforster@suse.de>,
overlayfs <linux-unionfs@vger.kernel.org>,
linux-integrity <linux-integrity@vger.kernel.org>
Subject: Re: PROBLEM: IMA xattrs not written on overlayfs
Date: Thu, 04 Oct 2018 11:52:30 -0400 [thread overview]
Message-ID: <1538668350.3702.348.camel@linux.ibm.com> (raw)
In-Reply-To: <CAJfpegt52N==WoSQt_GMwZnOPyoV38j3r8vL95Ds0-NakVFueg@mail.gmail.com>
On Thu, 2018-10-04 at 00:35 +0200, Miklos Szeredi wrote:
> Right, if it's done from last fput() then it's at least not a security hole.
>
> This hack may work for some filesystems, but as you noticed, it won't
> work for overlayfs. And if probably won't work for a number of other
> filesystems as well: the fs can assume that f_mode & FMODE_READ will
> remain off if it was off at open time.
>
> The proper way to handle it generally is to open a separate instance
> of the same file from IMA with O_RDONLY and use that to calculate the
> hash. There's really no point in reusing the same file and hacking
> the f_mode bits.
Is there an appropriate low level kernel call for creating a new file
descriptor that would be appropriate? dentry_open(), like the call in
file_clone_open(), has a lot of overhead, including the LSM calls.
Calculating the file hash always needs to work.
Mimi
next prev parent reply other threads:[~2018-10-04 22:46 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-07 16:49 PROBLEM: IMA xattrs not written on overlayfs Ignaz Forster
2018-09-07 18:45 ` Mimi Zohar
2018-09-10 9:17 ` Ignaz Forster
2018-09-28 16:54 ` Mimi Zohar
2018-09-28 18:24 ` Ignaz Forster
2018-09-28 18:24 ` Ignaz Forster
2018-09-28 19:06 ` Mimi Zohar
2018-09-28 19:06 ` Mimi Zohar
2018-09-28 19:37 ` Fabian Vogt
2018-10-01 9:05 ` Miklos Szeredi
2018-10-03 21:18 ` Mimi Zohar
2018-10-03 21:18 ` Mimi Zohar
2018-10-03 22:35 ` Miklos Szeredi
2018-10-04 15:52 ` Mimi Zohar [this message]
2018-10-04 15:52 ` Mimi Zohar
2018-10-05 2:57 ` Goldwyn Rodrigues
2018-10-05 10:33 ` Mimi Zohar
2018-10-05 10:33 ` Mimi Zohar
2018-10-05 17:30 ` Goldwyn Rodrigues
2018-10-05 17:30 ` Goldwyn Rodrigues
2018-10-05 17:30 ` Goldwyn Rodrigues
2018-10-07 8:22 ` Amir Goldstein
2018-10-08 12:54 ` 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=1538668350.3702.348.camel@linux.ibm.com \
--to=zohar@linux.ibm.com \
--cc=fvogt@suse.de \
--cc=iforster@suse.de \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
/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.