On Mon, 2022-10-31 at 16:25 +0000, Isaac Matthews wrote: > 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? Hi Isaac I think this is the intended behavior, as IMA is supposed to be called when the file descriptor is ready to use. If we need to call ima_file_hash() from lsm.s/file_open, I think it should not be a problem to create a new fd just for eBPF, in __ima_inode_hash(). Mimi, what do you think? Thanks Roberto > 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
