RE: [RESEND][PATCH] ima: Set and clear FMODE_CAN_READ in ima_calc_file_hash()

[Roberto Sassu]

> From: Linus Torvalds [mailto:torvalds@xxxxxxxxxxxxxxxxxxxx]
> Sent: Wednesday, November 18, 2020 12:37 AM
> On Tue, Nov 17, 2020 at 3:29 PM Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Tue, Nov 17, 2020 at 3:24 PM Mimi Zohar <zohar@xxxxxxxxxxxxx>
> 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?

Thanks

Roberto

HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Li Jian, Shi Yanli