| Message ID | 20220302111404.193900-1-roberto.sassu@huawei.com |
|---|---|
| Headers | show |
| Series | bpf-lsm: Extend interoperability with IMA | expand |
On Wed, 2022-03-02 at 12:13 +0100, Roberto Sassu wrote: > Extend the interoperability with IMA, to give wider flexibility for the > implementation of integrity-focused LSMs based on eBPF. > > Patch 1 fixes some style issues. > > Patches 2-6 give the ability to eBPF-based LSMs to take advantage of the > measurement capability of IMA without needing to setup a policy in IMA > (those LSMs might implement the policy capability themselves). > > Patches 7-9 allow eBPF-based LSMs to evaluate files read by the kernel. The tests seem to only work when neither a builtin IMA policy or a custom policy is previously loaded. thanks, Mimi
On Thu, 2022-03-03 at 14:39 -0800, Alexei Starovoitov wrote: > . There is no such thing as "eBPF modules". There are BPF programs. > They cannot be signed the same way as kernel modules. > We've been working on providing a way to sign them for more > than a year now. That work is still ongoing. > > . IMA cannot be used for integrity check of BPF programs for the same > reasons why kernel module like signing cannot be used. I assume the issue isn't where the signature is stored (e.g. appended, xattr), but of calculating the hash. Where is the discussion taking place? Are there any summaries of what has been discussed? FYI, IMA isn't limited to measuring files. Support was added for buffer measurements (e.g kexec boot command line, certificates) and measuring kernel critical data (e.g. SELinux in memory policy & state, device mapper). thanks, Mimi
> From: Mimi Zohar [mailto:zohar@linux.ibm.com] > Sent: Sunday, March 6, 2022 8:24 PM > On Wed, 2022-03-02 at 12:13 +0100, Roberto Sassu wrote: > > Extend the interoperability with IMA, to give wider flexibility for the > > implementation of integrity-focused LSMs based on eBPF. > > > > Patch 1 fixes some style issues. > > > > Patches 2-6 give the ability to eBPF-based LSMs to take advantage of the > > measurement capability of IMA without needing to setup a policy in IMA > > (those LSMs might implement the policy capability themselves). > > > > Patches 7-9 allow eBPF-based LSMs to evaluate files read by the kernel. > > The tests seem to only work when neither a builtin IMA policy or a > custom policy is previously loaded. Hi Mimi unfortunately yes. If there are more generic rules, the number of samples differs from that expected. For example, if you have an existing rule like: measure func=BPRM_CHECK mask=MAY_EXEC you will have: test_test_ima:PASS:run_measured_process #1 0 nsec test_test_ima:FAIL:num_samples_or_err unexpected num_samples_or_err: actual 2 != expected 1 Test #1 fails because also ima_setup.sh is measured. Thanks Roberto HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua
On Mon, Mar 7, 2022 at 3:57 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > > On Thu, 2022-03-03 at 14:39 -0800, Alexei Starovoitov wrote: > > > . There is no such thing as "eBPF modules". There are BPF programs. > > They cannot be signed the same way as kernel modules. > > We've been working on providing a way to sign them for more > > than a year now. That work is still ongoing. > > > > . IMA cannot be used for integrity check of BPF programs for the same > > reasons why kernel module like signing cannot be used. > > I assume the issue isn't where the signature is stored (e.g. appended, > xattr), but of calculating the hash. Where is the discussion taking This has the relevant background: https://lwn.net/Articles/853489/ We had some more discussions in one of our BSC meeting: https://github.com/ebpf-io/bsc/blob/master/minutes.md and we expect the discussions to continue over conferences this year (e.g. LSF/MM/BPF, Linux Plumbers). As I mentioned on another thread we don't have to wait for conferences and we can discuss this in the BPF office hours. Please feel free to add an agenda at: https://docs.google.com/spreadsheets/d/1LfrDXZ9-fdhvPEp_LHkxAMYyxxpwBXjywWa0AejEveU/edit#gid=0 (best is to give some notice so that interested folks can join). > place? Are there any summaries of what has been discussed? > > FYI, IMA isn't limited to measuring files. Support was added for > buffer measurements (e.g kexec boot command line, certificates) and > measuring kernel critical data (e.g. SELinux in memory policy & state, > device mapper). Nice. I need to look at how this is implemented. - KP > > thanks, > > Mimi >
On Mon, 2022-03-07 at 14:17 +0100, KP Singh wrote: > On Mon, Mar 7, 2022 at 3:57 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > > > > On Thu, 2022-03-03 at 14:39 -0800, Alexei Starovoitov wrote: > > > > > . There is no such thing as "eBPF modules". There are BPF programs. > > > They cannot be signed the same way as kernel modules. > > > We've been working on providing a way to sign them for more > > > than a year now. That work is still ongoing. > > > > > > . IMA cannot be used for integrity check of BPF programs for the same > > > reasons why kernel module like signing cannot be used. > > > > I assume the issue isn't where the signature is stored (e.g. appended, > > xattr), but of calculating the hash. Where is the discussion taking > > This has the relevant background: https://lwn.net/Articles/853489/ Thanks, Jon! > > We had some more discussions in one of our BSC meeting: > > https://github.com/ebpf-io/bsc/blob/master/minutes.md > > and we expect the discussions to continue over conferences this year > (e.g. LSF/MM/BPF, Linux Plumbers). As I mentioned on another thread > we don't have to wait for conferences and we can discuss this in the BPF > office hours. Please feel free to add an agenda at: > > https://docs.google.com/spreadsheets/d/1LfrDXZ9-fdhvPEp_LHkxAMYyxxpwBXjywWa0AejEveU/edit#gid=0 > > (best is to give some notice so that interested folks can join). Right, but probably a good idea to understand the issues at least at a high level, before a meeting. > > > place? Are there any summaries of what has been discussed? > > > > FYI, IMA isn't limited to measuring files. Support was added for > > buffer measurements (e.g kexec boot command line, certificates) and > > measuring kernel critical data (e.g. SELinux in memory policy & state, > > device mapper). > > Nice. I need to look at how this is implemented. ima_measure_critical_data() is of kernel state info, so signature verification is currently not needed or supported, only measurement. thanks, Mimi
Hello: This series was applied to bpf/bpf-next.git (master) by Alexei Starovoitov <ast@kernel.org>: On Wed, 2 Mar 2022 12:13:55 +0100 you wrote: > Extend the interoperability with IMA, to give wider flexibility for the > implementation of integrity-focused LSMs based on eBPF. > > Patch 1 fixes some style issues. > > Patches 2-6 give the ability to eBPF-based LSMs to take advantage of the > measurement capability of IMA without needing to setup a policy in IMA > (those LSMs might implement the policy capability themselves). > > [...] Here is the summary with links: - [v3,1/9] ima: Fix documentation-related warnings in ima_main.c https://git.kernel.org/bpf/bpf-next/c/bae60eefb95c - [v3,2/9] ima: Always return a file measurement in ima_file_hash() https://git.kernel.org/bpf/bpf-next/c/280fe8367b0d - [v3,3/9] bpf-lsm: Introduce new helper bpf_ima_file_hash() https://git.kernel.org/bpf/bpf-next/c/174b16946e39 - [v3,4/9] selftests/bpf: Move sample generation code to ima_test_common() https://git.kernel.org/bpf/bpf-next/c/2746de3c53d6 - [v3,5/9] selftests/bpf: Add test for bpf_ima_file_hash() https://git.kernel.org/bpf/bpf-next/c/27a77d0d460c - [v3,6/9] selftests/bpf: Check if the digest is refreshed after a file write https://git.kernel.org/bpf/bpf-next/c/91e8fa254dbd - [v3,7/9] bpf-lsm: Make bpf_lsm_kernel_read_file() as sleepable https://git.kernel.org/bpf/bpf-next/c/df6b3039fa11 - [v3,8/9] selftests/bpf: Add test for bpf_lsm_kernel_read_file() https://git.kernel.org/bpf/bpf-next/c/e6dcf7bbf37c - [v3,9/9] selftests/bpf: Check that bpf_kernel_read_file() denies reading IMA policy https://git.kernel.org/bpf/bpf-next/c/7bae42b68d7f You are awesome, thank you!
Extend the interoperability with IMA, to give wider flexibility for the implementation of integrity-focused LSMs based on eBPF. Patch 1 fixes some style issues. Patches 2-6 give the ability to eBPF-based LSMs to take advantage of the measurement capability of IMA without needing to setup a policy in IMA (those LSMs might implement the policy capability themselves). Patches 7-9 allow eBPF-based LSMs to evaluate files read by the kernel. Changelog v2: - Add better description to patch 1 (suggested by Shuah) - Recalculate digest if it is not fresh (when IMA_COLLECTED flag not set) - Move declaration of bpf_ima_file_hash() at the end (suggested by Yonghong) - Add tests to check if the digest has been recalculated - Add deny test for bpf_kernel_read_file() - Add description to tests v1: - Modify ima_file_hash() only and allow the usage of the function with the modified behavior by eBPF-based LSMs through the new function bpf_ima_file_hash() (suggested by Mimi) - Make bpf_lsm_kernel_read_file() sleepable so that bpf_ima_inode_hash() and bpf_ima_file_hash() can be called inside the implementation of eBPF-based LSMs for this hook Roberto Sassu (9): ima: Fix documentation-related warnings in ima_main.c ima: Always return a file measurement in ima_file_hash() bpf-lsm: Introduce new helper bpf_ima_file_hash() selftests/bpf: Move sample generation code to ima_test_common() selftests/bpf: Add test for bpf_ima_file_hash() selftests/bpf: Check if the digest is refreshed after a file write bpf-lsm: Make bpf_lsm_kernel_read_file() as sleepable selftests/bpf: Add test for bpf_lsm_kernel_read_file() selftests/bpf: Check that bpf_kernel_read_file() denies reading IMA policy include/uapi/linux/bpf.h | 11 ++ kernel/bpf/bpf_lsm.c | 21 +++ security/integrity/ima/ima_main.c | 57 ++++--- tools/include/uapi/linux/bpf.h | 11 ++ tools/testing/selftests/bpf/ima_setup.sh | 35 +++- .../selftests/bpf/prog_tests/test_ima.c | 149 +++++++++++++++++- tools/testing/selftests/bpf/progs/ima.c | 66 +++++++- 7 files changed, 321 insertions(+), 29 deletions(-)