Re: [PATCH bpf-next v2 3/3] bpf: Update LSM selftests for bpf_ima_inode_hash
On 11/23/20 10:54 AM, Yonghong Song wrote: On 11/23/20 10:46 AM, KP Singh wrote: On Mon, Nov 23, 2020 at 7:36 PM Yonghong Song wrote: On 11/23/20 10:27 AM, KP Singh wrote: [...] Even if a custom policy has been loaded, potentially additional measurements unrelated to this test would be included the measurement list. One way of limiting a rule to a specific test is by loopback mounting a file system and defining a policy rule based on the loopback mount unique uuid. Thanks Mimi! I wonder if we simply limit this to policy to /tmp and run an executable from /tmp (like test_local_storage.c does). The only side effect would be of extra hashes being calculated on binaries run from /tmp which is not too bad I guess? The builtin measurement policy (ima_policy=tcb") explicitly defines a rule to not measure /tmp files. Measuring /tmp results in a lot of measurements. {.action = DONT_MEASURE, .fsmagic = TMPFS_MAGIC, .flags = IMA_FSMAGIC}, We could do the loop mount too, but I am guessing the most clean way would be to shell out to mount from the test? Are there some other examples of IMA we could look at? LTP loopback mounts a filesystem, since /tmp is not being measured with the builtin "tcb" policy. Defining new policy rules should be limited to the loopback mount. This would pave the way for defining IMA- appraisal signature verification policy rules, without impacting the running system. +Andrii Do you think we can split the IMA test out, have a little shell script that does the loopback mount, gets the FS UUID, updates the IMA policy and then runs a C program? This would also allow "test_progs" to be independent of CONFIG_IMA. I am guessing the structure would be something similar to test_xdp_redirect.sh Look at sk_assign test. sk_assign.c: if (CHECK_FAIL(system("ip link set dev lo up"))) sk_assign.c: if (CHECK_FAIL(system("ip route add local default dev lo"))) sk_assign.c: if (CHECK_FAIL(system("ip -6 route add local default dev lo"))) sk_assign.c: if (CHECK_FAIL(system("tc qdisc add dev lo clsact"))) sk_assign.c: if (CHECK(system(tc_cmd), "BPF load failed;" You can use "system" to invoke some bash commands to simulate a script in the tests. Heh, that's what I was trying to avoid, I need to parse the output to the get the name of which loop device was assigned and then call a command like: # blkid /dev/loop0 /dev/loop0: UUID="607ed7ce-3fad-4236-8faf-8ab744f23e01" TYPE="ext3" Running simple commands with "system" seems okay but parsing output is a bit too much :) I read about: https://man7.org/linux/man-pages/man4/loop.4.html But I still need to create a backing file, format it and then get the UUID. Any simple trick that I may be missing? Maybe you can create a bash script on your prog_test files and do system("./<>.sh"). In the shell script, you can use all the bash magic (sed, awk, etc) to parse and store the needed result in a temp file, and after a successful system(""), you just read that temp file. Does this work? I guess under the current framework, you can also create a .sh file manually and place it into tools/testing/selftests/bpf directory and call it in your prog_tests .c file with system("./<>.sh")... - KP - KP Mimi
Re: [PATCH bpf-next v2 3/3] bpf: Update LSM selftests for bpf_ima_inode_hash
On 11/23/20 10:46 AM, KP Singh wrote: On Mon, Nov 23, 2020 at 7:36 PM Yonghong Song wrote: On 11/23/20 10:27 AM, KP Singh wrote: [...] Even if a custom policy has been loaded, potentially additional measurements unrelated to this test would be included the measurement list. One way of limiting a rule to a specific test is by loopback mounting a file system and defining a policy rule based on the loopback mount unique uuid. Thanks Mimi! I wonder if we simply limit this to policy to /tmp and run an executable from /tmp (like test_local_storage.c does). The only side effect would be of extra hashes being calculated on binaries run from /tmp which is not too bad I guess? The builtin measurement policy (ima_policy=tcb") explicitly defines a rule to not measure /tmp files. Measuring /tmp results in a lot of measurements. {.action = DONT_MEASURE, .fsmagic = TMPFS_MAGIC, .flags = IMA_FSMAGIC}, We could do the loop mount too, but I am guessing the most clean way would be to shell out to mount from the test? Are there some other examples of IMA we could look at? LTP loopback mounts a filesystem, since /tmp is not being measured with the builtin "tcb" policy. Defining new policy rules should be limited to the loopback mount. This would pave the way for defining IMA- appraisal signature verification policy rules, without impacting the running system. +Andrii Do you think we can split the IMA test out, have a little shell script that does the loopback mount, gets the FS UUID, updates the IMA policy and then runs a C program? This would also allow "test_progs" to be independent of CONFIG_IMA. I am guessing the structure would be something similar to test_xdp_redirect.sh Look at sk_assign test. sk_assign.c:if (CHECK_FAIL(system("ip link set dev lo up"))) sk_assign.c:if (CHECK_FAIL(system("ip route add local default dev lo"))) sk_assign.c:if (CHECK_FAIL(system("ip -6 route add local default dev lo"))) sk_assign.c:if (CHECK_FAIL(system("tc qdisc add dev lo clsact"))) sk_assign.c:if (CHECK(system(tc_cmd), "BPF load failed;" You can use "system" to invoke some bash commands to simulate a script in the tests. Heh, that's what I was trying to avoid, I need to parse the output to the get the name of which loop device was assigned and then call a command like: # blkid /dev/loop0 /dev/loop0: UUID="607ed7ce-3fad-4236-8faf-8ab744f23e01" TYPE="ext3" Running simple commands with "system" seems okay but parsing output is a bit too much :) I read about: https://man7.org/linux/man-pages/man4/loop.4.html But I still need to create a backing file, format it and then get the UUID. Any simple trick that I may be missing? Maybe you can create a bash script on your prog_test files and do system("./<>.sh"). In the shell script, you can use all the bash magic (sed, awk, etc) to parse and store the needed result in a temp file, and after a successful system(""), you just read that temp file. Does this work? - KP - KP Mimi
Re: [PATCH bpf-next v2 3/3] bpf: Update LSM selftests for bpf_ima_inode_hash
On Mon, Nov 23, 2020 at 7:36 PM Yonghong Song wrote: > > > > On 11/23/20 10:27 AM, KP Singh wrote: > > [...] > > > > Even if a custom policy has been loaded, potentially additional > measurements unrelated to this test would be included the measurement > list. One way of limiting a rule to a specific test is by loopback > mounting a file system and defining a policy rule based on the loopback > mount unique uuid. > >>> > >>> Thanks Mimi! > >>> > >>> I wonder if we simply limit this to policy to /tmp and run an executable > >>> from /tmp (like test_local_storage.c does). > >>> > >>> The only side effect would be of extra hashes being calculated on > >>> binaries run from /tmp which is not too bad I guess? > >> > >> The builtin measurement policy (ima_policy=tcb") explicitly defines a > >> rule to not measure /tmp files. Measuring /tmp results in a lot of > >> measurements. > >> > >> {.action = DONT_MEASURE, .fsmagic = TMPFS_MAGIC, .flags = IMA_FSMAGIC}, > >> > >>> > >>> We could do the loop mount too, but I am guessing the most clean way > >>> would be to shell out to mount from the test? Are there some other > >>> examples > >>> of IMA we could look at? > >> > >> LTP loopback mounts a filesystem, since /tmp is not being measured with > >> the builtin "tcb" policy. Defining new policy rules should be limited > >> to the loopback mount. This would pave the way for defining IMA- > >> appraisal signature verification policy rules, without impacting the > >> running system. > > > > +Andrii > > > > Do you think we can split the IMA test out, > > have a little shell script that does the loopback mount, gets the > > FS UUID, updates the IMA policy and then runs a C program? > > > > This would also allow "test_progs" to be independent of CONFIG_IMA. > > > > I am guessing the structure would be something similar > > to test_xdp_redirect.sh > > Look at sk_assign test. > > sk_assign.c:if (CHECK_FAIL(system("ip link set dev lo up"))) > sk_assign.c:if (CHECK_FAIL(system("ip route add local default dev lo"))) > sk_assign.c:if (CHECK_FAIL(system("ip -6 route add local default dev > lo"))) > sk_assign.c:if (CHECK_FAIL(system("tc qdisc add dev lo clsact"))) > sk_assign.c:if (CHECK(system(tc_cmd), "BPF load failed;" > > You can use "system" to invoke some bash commands to simulate a script > in the tests. Heh, that's what I was trying to avoid, I need to parse the output to the get the name of which loop device was assigned and then call a command like: # blkid /dev/loop0 /dev/loop0: UUID="607ed7ce-3fad-4236-8faf-8ab744f23e01" TYPE="ext3" Running simple commands with "system" seems okay but parsing output is a bit too much :) I read about: https://man7.org/linux/man-pages/man4/loop.4.html But I still need to create a backing file, format it and then get the UUID. Any simple trick that I may be missing? - KP > > > > > - KP > > > >> > >> Mimi > >>
Re: [PATCH bpf-next v2 3/3] bpf: Update LSM selftests for bpf_ima_inode_hash
On 11/23/20 10:27 AM, KP Singh wrote: [...] Even if a custom policy has been loaded, potentially additional measurements unrelated to this test would be included the measurement list. One way of limiting a rule to a specific test is by loopback mounting a file system and defining a policy rule based on the loopback mount unique uuid. Thanks Mimi! I wonder if we simply limit this to policy to /tmp and run an executable from /tmp (like test_local_storage.c does). The only side effect would be of extra hashes being calculated on binaries run from /tmp which is not too bad I guess? The builtin measurement policy (ima_policy=tcb") explicitly defines a rule to not measure /tmp files. Measuring /tmp results in a lot of measurements. {.action = DONT_MEASURE, .fsmagic = TMPFS_MAGIC, .flags = IMA_FSMAGIC}, We could do the loop mount too, but I am guessing the most clean way would be to shell out to mount from the test? Are there some other examples of IMA we could look at? LTP loopback mounts a filesystem, since /tmp is not being measured with the builtin "tcb" policy. Defining new policy rules should be limited to the loopback mount. This would pave the way for defining IMA- appraisal signature verification policy rules, without impacting the running system. +Andrii Do you think we can split the IMA test out, have a little shell script that does the loopback mount, gets the FS UUID, updates the IMA policy and then runs a C program? This would also allow "test_progs" to be independent of CONFIG_IMA. I am guessing the structure would be something similar to test_xdp_redirect.sh Look at sk_assign test. sk_assign.c:if (CHECK_FAIL(system("ip link set dev lo up"))) sk_assign.c:if (CHECK_FAIL(system("ip route add local default dev lo"))) sk_assign.c:if (CHECK_FAIL(system("ip -6 route add local default dev lo"))) sk_assign.c:if (CHECK_FAIL(system("tc qdisc add dev lo clsact"))) sk_assign.c:if (CHECK(system(tc_cmd), "BPF load failed;" You can use "system" to invoke some bash commands to simulate a script in the tests. - KP Mimi
Re: [PATCH bpf-next v2 3/3] bpf: Update LSM selftests for bpf_ima_inode_hash
[...] > > > > > > Even if a custom policy has been loaded, potentially additional > > > measurements unrelated to this test would be included the measurement > > > list. One way of limiting a rule to a specific test is by loopback > > > mounting a file system and defining a policy rule based on the loopback > > > mount unique uuid. > > > > Thanks Mimi! > > > > I wonder if we simply limit this to policy to /tmp and run an executable > > from /tmp (like test_local_storage.c does). > > > > The only side effect would be of extra hashes being calculated on > > binaries run from /tmp which is not too bad I guess? > > The builtin measurement policy (ima_policy=tcb") explicitly defines a > rule to not measure /tmp files. Measuring /tmp results in a lot of > measurements. > > {.action = DONT_MEASURE, .fsmagic = TMPFS_MAGIC, .flags = IMA_FSMAGIC}, > > > > > We could do the loop mount too, but I am guessing the most clean way > > would be to shell out to mount from the test? Are there some other examples > > of IMA we could look at? > > LTP loopback mounts a filesystem, since /tmp is not being measured with > the builtin "tcb" policy. Defining new policy rules should be limited > to the loopback mount. This would pave the way for defining IMA- > appraisal signature verification policy rules, without impacting the > running system. +Andrii Do you think we can split the IMA test out, have a little shell script that does the loopback mount, gets the FS UUID, updates the IMA policy and then runs a C program? This would also allow "test_progs" to be independent of CONFIG_IMA. I am guessing the structure would be something similar to test_xdp_redirect.sh - KP > > Mimi >
Re: [PATCH bpf-next v2 3/3] bpf: Update LSM selftests for bpf_ima_inode_hash
[Cc'ing Petr Vorel] On Mon, 2020-11-23 at 15:06 +0100, KP Singh wrote: > On Mon, Nov 23, 2020 at 2:24 PM Mimi Zohar wrote: > > > > On Sat, 2020-11-21 at 00:50 +, KP Singh wrote: > > > From: KP Singh > > > > > > - Update the IMA policy before executing the test binary (this is not an > > > override of the policy, just an append that ensures that hashes are > > > calculated on executions). > > > > Assuming the builtin policy has been replaced with a custom policy and > > CONFIG_IMA_WRITE_POLICY is enabled, then yes the rule is appended. If > > a custom policy has not yet been loaded, loading this rule becomes the > > defacto custom policy. > > > > Even if a custom policy has been loaded, potentially additional > > measurements unrelated to this test would be included the measurement > > list. One way of limiting a rule to a specific test is by loopback > > mounting a file system and defining a policy rule based on the loopback > > mount unique uuid. > > Thanks Mimi! > > I wonder if we simply limit this to policy to /tmp and run an executable > from /tmp (like test_local_storage.c does). > > The only side effect would be of extra hashes being calculated on > binaries run from /tmp which is not too bad I guess? The builtin measurement policy (ima_policy=tcb") explicitly defines a rule to not measure /tmp files. Measuring /tmp results in a lot of measurements. {.action = DONT_MEASURE, .fsmagic = TMPFS_MAGIC, .flags = IMA_FSMAGIC}, > > We could do the loop mount too, but I am guessing the most clean way > would be to shell out to mount from the test? Are there some other examples > of IMA we could look at? LTP loopback mounts a filesystem, since /tmp is not being measured with the builtin "tcb" policy. Defining new policy rules should be limited to the loopback mount. This would pave the way for defining IMA- appraisal signature verification policy rules, without impacting the running system. Mimi
Re: [PATCH bpf-next v2 3/3] bpf: Update LSM selftests for bpf_ima_inode_hash
On Mon, Nov 23, 2020 at 2:24 PM Mimi Zohar wrote: > > On Sat, 2020-11-21 at 00:50 +, KP Singh wrote: > > From: KP Singh > > > > - Update the IMA policy before executing the test binary (this is not an > > override of the policy, just an append that ensures that hashes are > > calculated on executions). > > Assuming the builtin policy has been replaced with a custom policy and > CONFIG_IMA_WRITE_POLICY is enabled, then yes the rule is appended. If > a custom policy has not yet been loaded, loading this rule becomes the > defacto custom policy. > > Even if a custom policy has been loaded, potentially additional > measurements unrelated to this test would be included the measurement > list. One way of limiting a rule to a specific test is by loopback > mounting a file system and defining a policy rule based on the loopback > mount unique uuid. Thanks Mimi! I wonder if we simply limit this to policy to /tmp and run an executable from /tmp (like test_local_storage.c does). The only side effect would be of extra hashes being calculated on binaries run from /tmp which is not too bad I guess? We could do the loop mount too, but I am guessing the most clean way would be to shell out to mount from the test? Are there some other examples of IMA we could look at? - KP > > Mimi >
Re: [PATCH bpf-next v2 3/3] bpf: Update LSM selftests for bpf_ima_inode_hash
On Sat, 2020-11-21 at 00:50 +, KP Singh wrote: > From: KP Singh > > - Update the IMA policy before executing the test binary (this is not an > override of the policy, just an append that ensures that hashes are > calculated on executions). Assuming the builtin policy has been replaced with a custom policy and CONFIG_IMA_WRITE_POLICY is enabled, then yes the rule is appended. If a custom policy has not yet been loaded, loading this rule becomes the defacto custom policy. Even if a custom policy has been loaded, potentially additional measurements unrelated to this test would be included the measurement list. One way of limiting a rule to a specific test is by loopback mounting a file system and defining a policy rule based on the loopback mount unique uuid. Mimi