Message ID | 20220302111404.193900-1-roberto.sassu@huawei.com (mailing list archive) |
---|---|
Headers | show |
Series | bpf-lsm: Extend interoperability with IMA | expand |
On Wed, Mar 02, 2022 at 12:13:55PM +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. > > 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 We have to land this set through bpf-next. Please get the Acks for patches 1 and 2, so we can proceed.
> From: Alexei Starovoitov [mailto:alexei.starovoitov@gmail.com] > Sent: Wednesday, March 2, 2022 11:21 PM > On Wed, Mar 02, 2022 at 12:13:55PM +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. > > > > 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 > > We have to land this set through bpf-next. > Please get the Acks for patches 1 and 2, so we can proceed. Ok. Mimi, do you have time to have a look at those patches? Thanks Roberto HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua
[Cc'ing Florent, Kees] Hi Alexei, On Wed, 2022-03-02 at 14:20 -0800, Alexei Starovoitov wrote: > On Wed, Mar 02, 2022 at 12:13:55PM +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. > > > > 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 > > We have to land this set through bpf-next. > Please get the Acks for patches 1 and 2, so we can proceed. Each year in the LSS integrity status update talk, I've mentioned the eBPF integrity gaps. I finally reached out to KP, Florent Revest, Kees and others, letting them know that I'm concerned about the eBPF module integrity gaps. True there is a difference between signing the eBPF source modules versus the eBPF generated output, but IMA could at least verify the integrity of the source eBPF modules making sure they are measured, the module hash audited, and are properly signed. Before expanding the ima_file_hash() or ima_inode_hash() usage, I'd appreciate someone adding the IMA support to measure, appraise, and audit eBPF modules. I realize that closing the eBPF integrity gaps is orthogonal to this patch set, but this patch set is not only extending the ima_file_hash()/ima_inode_hash() usage, but will be used to circumvent IMA. As per usual, IMA is policy based, allowing those interested in eBPF module integrity to define IMA policy rules. thanks, Mimi
On Thu, Mar 3, 2022 at 5:05 PM Mimi Zohar <zohar@linux.ibm.com> wrote: > > [Cc'ing Florent, Kees] > > Hi Alexei, > > On Wed, 2022-03-02 at 14:20 -0800, Alexei Starovoitov wrote: > > On Wed, Mar 02, 2022 at 12:13:55PM +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. > > > > > > 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 > > > > We have to land this set through bpf-next. > > Please get the Acks for patches 1 and 2, so we can proceed. > Hi Mimi, > Each year in the LSS integrity status update talk, I've mentioned the > eBPF integrity gaps. I finally reached out to KP, Florent Revest, Kees Thanks for bringing this up and it's very timely because we have been having discussion around eBPF program signing and delineating that from eBPF program integrity use-cases. My plan is to travel to LSS (travel and visa permitting) and we can discuss it more there. If you prefer we can also discuss it before in one of the BPF office hours: https://docs.google.com/spreadsheets/d/1LfrDXZ9-fdhvPEp_LHkxAMYyxxpwBXjywWa0AejEveU/edit#gid=0 > and others, letting them know that I'm concerned about the eBPF module > integrity gaps. True there is a difference between signing the eBPF > source modules versus the eBPF generated output, but IMA could at least > verify the integrity of the source eBPF modules making sure they are > measured, the module hash audited, and are properly signed. > > Before expanding the ima_file_hash() or ima_inode_hash() usage, I'd > appreciate someone adding the IMA support to measure, appraise, and > audit eBPF modules. I realize that closing the eBPF integrity gaps is > orthogonal to this patch set, but this patch set is not only extending This really is orthogonal and IMHO it does not seem rational to block this patchset on it. > the ima_file_hash()/ima_inode_hash() usage, but will be used to > circumvent IMA. As per usual, IMA is policy based, allowing those I don't think they are being used to circumvent IMA but for totally different use-cases (e.g. as a data point for detecting attacks). - KP > interested in eBPF module integrity to define IMA policy rules. > > thanks, > > Mimi >
On Thu, 2022-03-03 at 17:17 +0100, KP Singh wrote: > On Thu, Mar 3, 2022 at 5:05 PM Mimi Zohar <zohar@linux.ibm.com> wrote: > > > > [Cc'ing Florent, Kees] > > > > Hi Alexei, > > > > On Wed, 2022-03-02 at 14:20 -0800, Alexei Starovoitov wrote: > > > On Wed, Mar 02, 2022 at 12:13:55PM +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. > > > > > > > > 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 > > > > > > We have to land this set through bpf-next. > > > Please get the Acks for patches 1 and 2, so we can proceed. > > > > Hi Mimi, > > > Each year in the LSS integrity status update talk, I've mentioned the > > eBPF integrity gaps. I finally reached out to KP, Florent Revest, Kees > > Thanks for bringing this up and it's very timely because we have been > having discussion around eBPF program signing and delineating that > from eBPF program integrity use-cases. > > My plan is to travel to LSS (travel and visa permitting) and we can discuss > it more there. > > If you prefer we can also discuss it before in one of the BPF office hours: > > https://docs.google.com/spreadsheets/d/1LfrDXZ9-fdhvPEp_LHkxAMYyxxpwBXjywWa0AejEveU/edit#gid=0 Sounds good. > > > and others, letting them know that I'm concerned about the eBPF module > > integrity gaps. True there is a difference between signing the eBPF > > source modules versus the eBPF generated output, but IMA could at least > > verify the integrity of the source eBPF modules making sure they are > > measured, the module hash audited, and are properly signed. > > > > Before expanding the ima_file_hash() or ima_inode_hash() usage, I'd > > appreciate someone adding the IMA support to measure, appraise, and > > audit eBPF modules. I realize that closing the eBPF integrity gaps is > > orthogonal to this patch set, but this patch set is not only extending > > This really is orthogonal and IMHO it does not seem rational to block this > patchset on it. > > > the ima_file_hash()/ima_inode_hash() usage, but will be used to > > circumvent IMA. As per usual, IMA is policy based, allowing those > > I don't think they are being used to circumvent IMA but for totally > different use-cases (e.g. as a data point for detecting attacks). > > > > interested in eBPF module integrity to define IMA policy rules. That might be true for your usecase, but not Roberto's. From the cover letter above, Roberto was honest in saying: 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).
On Thu, Mar 3, 2022 at 5:30 PM Mimi Zohar <zohar@linux.ibm.com> wrote: > > On Thu, 2022-03-03 at 17:17 +0100, KP Singh wrote: > > On Thu, Mar 3, 2022 at 5:05 PM Mimi Zohar <zohar@linux.ibm.com> wrote: > > > > > > [Cc'ing Florent, Kees] > > > > > > Hi Alexei, > > > > > > On Wed, 2022-03-02 at 14:20 -0800, Alexei Starovoitov wrote: > > > > On Wed, Mar 02, 2022 at 12:13:55PM +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. > > > > > > > > > > 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 > > > > > > > > We have to land this set through bpf-next. > > > > Please get the Acks for patches 1 and 2, so we can proceed. > > > > > > > Hi Mimi, > > > > > Each year in the LSS integrity status update talk, I've mentioned the > > > eBPF integrity gaps. I finally reached out to KP, Florent Revest, Kees > > > > Thanks for bringing this up and it's very timely because we have been > > having discussion around eBPF program signing and delineating that > > from eBPF program integrity use-cases. > > > > My plan is to travel to LSS (travel and visa permitting) and we can discuss > > it more there. > > > > If you prefer we can also discuss it before in one of the BPF office hours: > > > > https://docs.google.com/spreadsheets/d/1LfrDXZ9-fdhvPEp_LHkxAMYyxxpwBXjywWa0AejEveU/edit#gid=0 > > Sounds good. > > > > > > and others, letting them know that I'm concerned about the eBPF module > > > integrity gaps. True there is a difference between signing the eBPF > > > source modules versus the eBPF generated output, but IMA could at least > > > verify the integrity of the source eBPF modules making sure they are > > > measured, the module hash audited, and are properly signed. > > > > > > Before expanding the ima_file_hash() or ima_inode_hash() usage, I'd > > > appreciate someone adding the IMA support to measure, appraise, and > > > audit eBPF modules. I realize that closing the eBPF integrity gaps is > > > orthogonal to this patch set, but this patch set is not only extending > > > > This really is orthogonal and IMHO it does not seem rational to block this > > patchset on it. > > > > > the ima_file_hash()/ima_inode_hash() usage, but will be used to > > > circumvent IMA. As per usual, IMA is policy based, allowing those > > > > I don't think they are being used to circumvent IMA but for totally > > different use-cases (e.g. as a data point for detecting attacks). > > > > > > > interested in eBPF module integrity to define IMA policy rules. > > That might be true for your usecase, but not Roberto's. From the cover > letter above, Roberto was honest in saying: > > 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). Currently to use the helper bpf_ima_inode_hash in LSM progs one needs to have a basic IMA policy in place just to get a hash, even if one does not need to use the whole feature-set provided by IMA. These patches would be quite beneficial for this user-journey. Even Robert's use case is to implement IMA policies in BPF this is still fundamentally different from IMA doing integrity measurement for BPF and blocking this patch-set on the latter does not seem rational and I don't see how implementing integrity for BPF would avoid your concerns. > > -- > thanks, > > Mimi >
On Thu, 2022-03-03 at 19:14 +0100, KP Singh wrote: > > Even Robert's use case is to implement IMA policies in BPF this is still > fundamentally different from IMA doing integrity measurement for BPF > and blocking this patch-set on the latter does not seem rational and > I don't see how implementing integrity for BPF would avoid your > concerns. eBPF modules are an entire class of files currently not being measured, audited, or appraised. This is an integrity gap that needs to be closed. The purpose would be to at least measure and verify the integrity of the eBPF module that is going to be used in lieu of traditional IMA.
On Thu, Mar 3, 2022 at 11:13 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > > On Thu, 2022-03-03 at 19:14 +0100, KP Singh wrote: > > > > Even Robert's use case is to implement IMA policies in BPF this is still > > fundamentally different from IMA doing integrity measurement for BPF > > and blocking this patch-set on the latter does not seem rational and > > I don't see how implementing integrity for BPF would avoid your > > concerns. > > eBPF modules are an entire class of files currently not being measured, > audited, or appraised. This is an integrity gap that needs to be > closed. The purpose would be to at least measure and verify the > integrity of the eBPF module that is going to be used in lieu of > traditional IMA. Mimi, . 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. . This patch set is orthogonal.
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!