> From: Linus Torvalds [mailto:torva...@linux-foundation.org]
> Sent: Wednesday, November 18, 2020 12:37 AM
> On Tue, Nov 17, 2020 at 3:29 PM Linus Torvalds
> wrote:
> >
> > On Tue, Nov 17, 2020 at 3:24 PM Mimi Zohar
> wrote:
> > >
> > > I really wish it wasn't needed.
> >
> > Seriously, I get th
On Tue, 2020-11-17 at 15:36 -0800, Linus Torvalds wrote:
> Another alternative is to change the policy and say "any write-only
> open gets turned into a read-write open".
>
> But it needs to be done at *OPEN* time, not randomly afterwards by
> just lying to the 'struct file'.
The ima_file_check h
On Tue, Nov 17, 2020 at 3:29 PM Linus Torvalds
wrote:
>
> On Tue, Nov 17, 2020 at 3:24 PM Mimi Zohar wrote:
> >
> > I really wish it wasn't needed.
>
> Seriously, I get the feeling that IMA is completely mis-designed, and
> is doing actively bad things.
>
> Who uses this "feature", and who cares?
On Tue, Nov 17, 2020 at 3:24 PM Mimi Zohar wrote:
>
> I really wish it wasn't needed.
Seriously, I get the feeling that IMA is completely mis-designed, and
is doing actively bad things.
Who uses this "feature", and who cares? Because I would suggest you
just change the policy and be done with it
On Tue, 2020-11-17 at 10:23 -0800, Linus Torvalds wrote:
> On Mon, Nov 16, 2020 at 10:35 AM Mimi Zohar wrote:
> >
> > We need to differentiate between signed files, which by definition are
> > immutable, and those that are mutable. Appending to a mutable file,
> > for example, would result in the
On Tue, Nov 17, 2020 at 10:23:58AM -0800, Linus Torvalds wrote:
> On Mon, Nov 16, 2020 at 10:35 AM Mimi Zohar wrote:
> >
> > We need to differentiate between signed files, which by definition are
> > immutable, and those that are mutable. Appending to a mutable file,
> > for example, would result
On Mon, Nov 16, 2020 at 10:35 AM Mimi Zohar wrote:
>
> We need to differentiate between signed files, which by definition are
> immutable, and those that are mutable. Appending to a mutable file,
> for example, would result in the file hash not being updated.
> Subsequent reads would fail.
Why w
> From: Al Viro [mailto:v...@ftp.linux.org.uk] On Behalf Of Al Viro
> Sent: Monday, November 16, 2020 7:09 PM
> On Mon, Nov 16, 2020 at 09:37:32AM -0800, Linus Torvalds wrote:
> > On Mon, Nov 16, 2020 at 8:47 AM Mimi Zohar
> wrote:
> > >
> > > This discussion seems to be going down the path of req
On Mon, 2020-11-16 at 18:08 +, Al Viro wrote:
> On Mon, Nov 16, 2020 at 09:37:32AM -0800, Linus Torvalds wrote:
> > On Mon, Nov 16, 2020 at 8:47 AM Mimi Zohar wrote:
> > >
> > > This discussion seems to be going down the path of requiring an IMA
> > > filesystem hook for reading the file, agai
On Mon, 2020-11-16 at 10:09 -0800, Linus Torvalds wrote:
> On Mon, Nov 16, 2020 at 9:41 AM Christoph Hellwig wrote:
> >
> > The "issue" with IMA is that it uses security hooks to hook into the
> > VFS and then wants to read every file that gets opened on a real file
> > system to "measure" the con
On Mon, 2020-11-16 at 17:41 +, Christoph Hellwig wrote:
> On Mon, Nov 16, 2020 at 09:37:32AM -0800, Linus Torvalds wrote:
> > > This discussion seems to be going down the path of requiring an IMA
> > > filesystem hook for reading the file, again. That solution was
> > > rejected, not by me. W
On Mon, Nov 16, 2020 at 9:41 AM Christoph Hellwig wrote:
>
> The "issue" with IMA is that it uses security hooks to hook into the
> VFS and then wants to read every file that gets opened on a real file
> system to "measure" the contents vs a hash stashed away somewhere.
Well, but that's easy enou
On Mon, Nov 16, 2020 at 09:37:32AM -0800, Linus Torvalds wrote:
> On Mon, Nov 16, 2020 at 8:47 AM Mimi Zohar wrote:
> >
> > This discussion seems to be going down the path of requiring an IMA
> > filesystem hook for reading the file, again. That solution was
> > rejected, not by me. What is new
On Mon, Nov 16, 2020 at 09:37:32AM -0800, Linus Torvalds wrote:
> > This discussion seems to be going down the path of requiring an IMA
> > filesystem hook for reading the file, again. That solution was
> > rejected, not by me. What is new this time?
>
> You can't read a non-read-opened file. No
On Mon, Nov 16, 2020 at 8:47 AM Mimi Zohar wrote:
>
> This discussion seems to be going down the path of requiring an IMA
> filesystem hook for reading the file, again. That solution was
> rejected, not by me. What is new this time?
You can't read a non-read-opened file. Not even IMA can.
So d
On Mon, 2020-11-16 at 16:22 +, Christoph Hellwig wrote:
> On Mon, Nov 16, 2020 at 08:52:19AM +, Roberto Sassu wrote:
> > FMODE_CAN_READ was not set because f_mode does not have
> > FMODE_READ. In the patch, I check if the former can be set
> > similarly to the way it is done in file_table.c
On Mon, Nov 16, 2020 at 08:52:19AM +, Roberto Sassu wrote:
> FMODE_CAN_READ was not set because f_mode does not have
> FMODE_READ. In the patch, I check if the former can be set
> similarly to the way it is done in file_table.c and open.c.
>
> Is there a better way to read a file when the file
> From: Christoph Hellwig [mailto:h...@infradead.org]
> Sent: Saturday, November 14, 2020 12:11 PM
> On Fri, Nov 13, 2020 at 09:01:32AM +0100, Roberto Sassu wrote:
> > Commit a1f9b1c0439db ("integrity/ima: switch to using __kernel_read")
> > replaced the __vfs_read() call in integrity_kernel_read()
On Fri, Nov 13, 2020 at 09:01:32AM +0100, Roberto Sassu wrote:
> Commit a1f9b1c0439db ("integrity/ima: switch to using __kernel_read")
> replaced the __vfs_read() call in integrity_kernel_read() with
> __kernel_read(), a new helper introduced by commit 61a707c543e2a ("fs: add
> a __kernel_read help
Hi Roberto,
On Fri, 2020-11-13 at 09:01 +0100, Roberto Sassu wrote:
> Commit a1f9b1c0439db ("integrity/ima: switch to using __kernel_read")
> replaced the __vfs_read() call in integrity_kernel_read() with
> __kernel_read(), a new helper introduced by commit 61a707c543e2a ("fs: add
> a __kernel_rea
Commit a1f9b1c0439db ("integrity/ima: switch to using __kernel_read")
replaced the __vfs_read() call in integrity_kernel_read() with
__kernel_read(), a new helper introduced by commit 61a707c543e2a ("fs: add
a __kernel_read helper").
Since the new helper requires that also the FMODE_CAN_READ flag
21 matches
Mail list logo