Messages in this thread | | | Subject | Re: [PATCH bpf-next v2 3/3] bpf: Update LSM selftests for bpf_ima_inode_hash | From | Yonghong Song <> | Date | Mon, 23 Nov 2020 11:00:22 -0800 |
| |
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 <yhs@fb.com> 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 >>>>>
| |