Possible bug or unintended behaviour using bpf_ima_file_hash

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Using bpf_ima_file_hash() from kernel 6.0.

When using bpf_ima_file_hash() with the lsm.s/file_open hook, a hash
of the file is only sometimes returned.  This is because the
FMODE_CAN_READ flag is set after security_file_open() is already
called, and ima_calc_file_hash() only checks for FMODE_READ not
FMODE_CAN_READ in order to decide if a new instance needs to be
opened. Because of this, if a file passes the FMODE_READ check  it
will fail to be hashed as FMODE_CAN_READ has not yet been set.

To demonstrate: if the file is opened for write for example, when
ima_calc_file_hash() is called and the file->f_mode is checked against
FMODE_READ, a new file instance is opened with the correct flags and a
hash is returned. If the file is opened for read, a new file instance
is not returned in ima_calc_file_hash() as (!(file->f_mode &
FMODE_READ)) is now false. When __kernel_read() is called as part of
ima_calc_file_hash_tfm() it will fail on if (!(file->f_mode &
FMODE_CAN_READ)) and so no hash will be returned by
bpf_ima_file_hash().

If possible could someone please advise me as to whether this is
intended behaviour, and is it possible to either modify the flags with
eBPF or to open a new instance with the correct flags set as IMA does
currently?

Alternatively, would a better solution be adding a check for
FMODE_CAN_READ to ima_calc_file_hash()? I noticed in the comment above
the conditional in ima_calc_file_hash() that the conditional should be
checking whether the file can be read, but only checks the FMODE_READ
flag which is not the only requirement for __kernel_read() to be able
to read a file.

Thanks for your help.
Isaac



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux