lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Fri, 20 Nov 2020 12:52:00 +0000
From:   Roberto Sassu <>
To:     Linus Torvalds <>,
        Mimi Zohar <>
CC:     Christoph Hellwig <>,
        "" <>,
        "" <>,
        Silviu Vlasceanu <>,
        "" <>,
        "" <>,
        "" <>,
        Paul Moore <>,
        "Casey Schaufler" <>,
        Stephen Smalley <>,
        John Johansen <>,
        Kees Cook <>,
        "James Morris" <>,
        "Serge E. Hallyn" <>,
        "Micah Morton" <>
Subject: RE: [RESEND][PATCH] ima: Set and clear FMODE_CAN_READ in

> From: Linus Torvalds []
> 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 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.
> Another alternative is to change the policy and say "any write-only
> open gets turned into a read-write open".

One issue that would arise from doing it is that security policies need
to be modified to grant the additional read permission. If the open
flag is added early, the LSM hook security_file_open() will see it.

This solution seems not optimal, as we are giving to processes a
permission that they wouldn't really take advantage of, since the
content read remains in kernel space. And an additional permission
is a permission that can be exploited.

As Mimi said, we already have a second open with dentry_open() when
the original file descriptor is not suitable. The only problem, which is
why changing the mode is still there, is that a process still might not
have the privilege to read, and this is a legitimate case.

We could assign a more powerful credential to the process, since
dentry_open() accepts a credential as an argument. We could obtain
such powerful credential from prepare_kernel_cred(). This option
has better chances to work without modifying existing security policies
as likely those policies already assigned the required privilege to the
kernel. However, doing so might not be what LSM people recommend.

Any suggestion?



Managing Director: Li Peng, Li Jian, Shi Yanli

Powered by blists - more mailing lists