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 10:54:42 -0800 |
| |
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?
> - KP > >> >>> >>> - KP >>> >>>> >>>> Mimi >>>>
| |