lists.openwall.net | 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 linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 25 Nov 2020 13:17:23 +0100 From: Daniel Borkmann <daniel@...earbox.net> To: KP Singh <kpsingh@...omium.org>, Yonghong Song <yhs@...com> Cc: James Morris <jmorris@...ei.org>, open list <linux-kernel@...r.kernel.org>, bpf <bpf@...r.kernel.org>, Linux Security Module list <linux-security-module@...r.kernel.org>, Alexei Starovoitov <ast@...nel.org>, Florent Revest <revest@...omium.org>, Brendan Jackman <jackmanb@...omium.org>, Mimi Zohar <zohar@...ux.ibm.com> Subject: Re: [PATCH bpf-next v3 1/3] ima: Implement ima_inode_hash On 11/25/20 1:04 PM, KP Singh wrote: > On Tue, Nov 24, 2020 at 6:35 PM Yonghong Song <yhs@...com> wrote: >> On 11/24/20 7:12 AM, KP Singh wrote: >>> From: KP Singh <kpsingh@...gle.com> >>> >>> This is in preparation to add a helper for BPF LSM programs to use >>> IMA hashes when attached to LSM hooks. There are LSM hooks like >>> inode_unlink which do not have a struct file * argument and cannot >>> use the existing ima_file_hash API. >>> >>> An inode based API is, therefore, useful in LSM based detections like an >>> executable trying to delete itself which rely on the inode_unlink LSM >>> hook. >>> >>> Moreover, the ima_file_hash function does nothing with the struct file >>> pointer apart from calling file_inode on it and converting it to an >>> inode. >>> >>> Signed-off-by: KP Singh <kpsingh@...gle.com> >> >> There is no change for this patch compared to previous version, >> so you can carry my Ack. >> >> Acked-by: Yonghong Song <yhs@...com> > > I am guessing: > > * We need an Ack from Mimi/James. Yes. > * As regards to which tree, I guess bpf-next would be better since the > BPF helper and the selftest depends on it Yep, bpf-next is my preference as otherwise we're running into unnecessary merge conflicts. Thanks, Daniel
Powered by blists - more mailing lists