IMA hashes in LSM events #2818

anfedotoff · 2024-08-16T13:52:00Z

Adding support for collecting file hashes calculated by Linux integrity subsystem (IMA). IMA hashes will be contained in LSM events. To make it work you need to:

enable LSM BPF
enable IMA

There are limitations on implementation due to the requirement to use bpf_ima_file_hash/bpf_ima_inode_hash helpers. The more information you can get from #2409.

Some design insights:

File hash collection will be triggered by Post Action
Only limited set of lsm hooks is supported

TODO list:

modification of bpf_generic_lsm and do_actions
CRD and lsm sensor updates
tests
docs

netlify · 2024-08-16T15:09:36Z

✅ Deploy Preview for tetragon ready!

Name	Link
🔨 Latest commit	`a85b65e`
🔍 Latest deploy log	https://app.netlify.com/sites/tetragon/deploys/66ec6a6265575f0008335414
😎 Deploy Preview	https://deploy-preview-2818--tetragon.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

anfedotoff · 2024-09-04T08:03:25Z

@kkourt , hi! May I ask you for a code review? Next Monday, on Tetragon community meeting I'll show a demo. I want to talk about some design decisions I made. Also I'm going to speak about problems that I overcame and those are still exists.

kkourt · 2024-09-04T12:52:27Z

@kkourt , hi! May I ask you for a code review? Next Monday, on Tetragon community meeting I'll show a demo. I want to talk about some design decisions I made. Also I'm going to speak about problems that I overcame and those are still exists.

Hello :)

Thanks for the heads up! Will try and have a look before the community meeting. Looking forward to the demo!

kkourt

Thanks @anfedotoff! I had a first look. Please find some comments below.

kkourt · 2024-09-09T12:02:20Z

bpf/process/bpf_generic_lsm.c

+
+	e = map_lookup_elem(&process_call_heap, &zero);
+	if (e && e->common.flags & MSG_COMMON_FLAG_IMA_HASH)
+		tail_call(ctx, &lsm_calls, TAIL_CALL_IMA_HASH);


Isn't there a race with this approach?
That is, what guarantees are there that user-space will do the map lookup before the entry is added?

Yes, you are right... It might be that user-space will do map lookup before entry is added. For now, I have only one idea how to overcome this problem. Do not use hash_map, use ring buffer to send event from lsm.s program.
But ring buffers are not supported in tetragon (#208). Do you have any ideas how to to this with out ring buffer?

Can we tailcall to a program that does the generic_output from an lsm.s program?

Can we tailcall to a program that does the generic_output from an lsm.s program?

Unfortunately, no(. Becase we can't use BPF_MAP_TYPE_PROG_ARRAY maps in lsm.s programs. We can tail call in, but we can't taill call out :).

kkourt · 2024-09-09T12:03:08Z

pkg/sensors/program/loader.go

@@ -423,6 +423,9 @@ func TracingAttach() AttachFunc {

 func LSMOpen(load *Program) OpenFunc {
 	return func(coll *ebpf.CollectionSpec) error {
+		delete(coll.Programs, "ima_file_open")
+		delete(coll.Programs, "ima_mmap_file")
+		delete(coll.Programs, "ima_bprm_check_security")


Why do we remove the programs here?

Because, we can't load them all (they are not generic). We need to load one of them only if imaHash: true in the policy. I load ima_* programs on demand, after all lsm generic programs are loaded.

olsajiri · 2024-09-10T08:01:05Z

I refreshed on LSM programs and I think we can do this differently

so LSM programs are attached through trampolines on specific bpf_lsm_XXX
function which is invoked as part of the lsm modules call chain on particular
lsm call back

and trampoline allows to attach and invoke multiple bpf programs to
specific function (or lsm hook)

so I think we could have the sleepable lsm hooks invoked first to get the
hash and update the map and then we will have generic lsm invoked that
would run the hash action, which would get the hash from the map and
send the event

  bpf_lsm_XXX
    -> trampoline
         run lsm.s/file_open
               map_update_elem(&ima_hash_map, &e->current, &hash, BPF_ANY);
         run lsm/generic_lsm
               map_lookup_elem(&ima_hash_map, &e->current, ...)

to ensure the generic lsm is invoked AFTER lsm.s/XXX hook we can rely
on kernel using standard lists when queuing programs for trampoline,
so you should just attach lsm.s hook first and then generic lsm

I guess there might be some hiccups when you'll implement that
(there always are) but so far it seems straightforward

WDYT?

olsajiri · 2024-09-10T08:16:28Z

pkg/sensors/tracing/genericlsm.go

+					return fmt.Errorf("opening BTF file '%s' failed: %w", btfFilePath, err)
+				}
+			}
+			spec, err := ebpf.LoadCollectionSpec(args.Load.Name)


whatever solution we pick for this I think the IMA lsm hooks should go in separate object and we should be able to load it through normal LoadLSMProgram interface

anfedotoff · 2024-09-10T15:17:47Z

I refreshed on LSM programs and I think we can do this differently

so LSM programs are attached through trampolines on specific bpf_lsm_XXX function which is invoked as part of the lsm modules call chain on particular lsm call back

and trampoline allows to attach and invoke multiple bpf programs to specific function (or lsm hook)

so I think we could have the sleepable lsm hooks invoked first to get the hash and update the map and then we will have generic lsm invoked that would run the hash action, which would get the hash from the map and send the event
  bpf_lsm_XXX
    -> trampoline
         run lsm.s/file_open
               map_update_elem(&ima_hash_map, &e->current, &hash, BPF_ANY);
         run lsm/generic_lsm
               map_lookup_elem(&ima_hash_map, &e->current, ...)
to ensure the generic lsm is invoked AFTER lsm.s/XXX hook we can rely on kernel using standard lists when queuing programs for trampoline, so you should just attach lsm.s hook first and then generic lsm

I guess there might be some hiccups when you'll implement that (there always are) but so far it seems straightforward

WDYT?

Thanks for making it clear!
IIUC, we will calculate hash on every triggered hook. It might cause some performance issues. Now our calls of bpf_ima_file_hash are filtered by tracing policy. When we move lsm.s/ima_* programe to the top, we will call helper no matter if tracing policy is satisfied or not. I think, it will be OK, if ima_policy is satisfied. Let's consider the following example:

We have a default ima_policy=tcb:

measure func=MMAP_CHECK mask=MAY_EXEC
measure func=BPRM_CHECK mask=MAY_EXEC # binary executed
measure func=FILE_CHECK mask=^MAY_READ euid=0
measure func=FILE_CHECK mask=^MAY_READ uid=0 # root opened r/o, r/w
measure func=MODULE_CHECK
measure func=FIRMWARE_CHECK
measure func=POLICY_CHECK

In particular, this ima_policy will measure hashes when files owned by root are opened for reading. So, in solution that you proposed will call bpf_ima_file_hash on every hook. The question is what helper will return, if ima_policy is not satisfied? If error, than it is OK, I think. But if it calculates hash despite the ima_policy it is not OK. I think, I can check this.

To sum up, I think, you solution is a nice compromise if ima_policy is taking to account during bpf_ima_file_hash call. What do you think about this?

olsajiri · 2024-09-11T16:47:30Z

Hmm, maybe we can split sensor into three parts. If we can use the same percpu heap map this scheme might work. It seems to me, that your first solution is much easier to implement:).

yea, it might be better to do the initial solution first as a base and split to 3 parts lsm sensor as a follow up.. we might learn other things that could shape up the final solution when doing that ;-)

anfedotoff · 2024-09-12T16:28:24Z

Hmm, maybe we can split sensor into three parts. If we can use the same percpu heap map this scheme might work. It seems to me, that your first solution is much easier to implement:).

yea, it might be better to do the initial solution first as a base and split to 3 parts lsm sensor as a follow up.. we might learn other things that could shape up the final solution when doing that ;-)

I thought, I can implement some example of our idea using ebpf-go, before coding in tetragon. Here is the repo:
https://github.com/anfedotoff/ima-ebpfgo-example, please have a look.

I have 3 bpf programs: three parts of LSM sensor. In the first program I emulate filtering and enforcing. Second program is used to get hash and the last one to send event via perf buffer. What I noticed.

we need to save information is event filtered or not in test_msg struct (msg_generic_kprobe in case of tetragon). Don't forget about NoPost Action
enforcing, filtering works fine.
it seems to me, that send can be earlier the hash calculation. (race condition now resides here).

Also, I'm not sure, that it is enough just to attach programs this way to preserve the order when hook is triggered.

So far it seems that approach is not working for us, but I may be wrong.

olsajiri · 2024-09-15T21:03:10Z

So far it seems that approach is not working for us, but I may be wrong.

nice, but I'm not sure I understand what's wrong, could you please elaborate? I'll try it anyway

anfedotoff · 2024-09-16T07:18:54Z

So far it seems that approach is not working for us, but I may be wrong.

nice, but I'm not sure I understand what's wrong, could you please elaborate? I'll try it anyway

Yes, sure, I'll try to explain.
I attach three bpf programs using standard Atach interface for LSM programs in the following order:

init_bprm_check (create event, store filename of executed binary in the map, do filtering + blocking);
ima_bprm_check (lsm.s program, that calculates hashes and store it in the map);
send_bprm_check (send stored event in map using perfbuffer);

The question is can we rely on the order of execution when bprm_check_security is triggered?

Here is some logs:

024/09/16 10:01:22 Waiting for events..
2024/09/16 10:01:44 Error file: ./tetragon. Code:0
2024/09/16 10:01:51 Error file: ./tetragon. Code:0
2024/09/16 10:01:57 Error file: ./tetragon. Code:0
2024/09/16 10:01:57 File: ./tetragon
2024/09/16 10:01:57 SHA256: 9c20c4a712cd95766b64bcddc1094b619092944b592be43d75c3f4b3fb1434d40000000000000000000000000000000000000000000000000000000000000000
2024/09/16 10:01:57 <=============>
2024/09/16 10:01:58 File: ./tetragon
2024/09/16 10:01:58 SHA256: 9c20c4a712cd95766b64bcddc1094b619092944b592be43d75c3f4b3fb1434d40000000000000000000000000000000000000000000000000000000000000000
2024/09/16 10:01:58 <=============>
2024/09/16 10:01:59 File: ./tetragon
2024/09/16 10:01:59 SHA256: 29aa689f38158d2e8941fa54e436f0260890af31cecad1e8799e5c2df7bc1ecc0000000000000000000000000000000000000000000000000000000000000000
2024/09/16 10:01:59 <=============>
2024/09/16 10:02:20 Error file: ./tetragon. Code:0
2024/09/16 10:02:22 File: ./tetragon
2024/09/16 10:02:22 SHA256: 4f291296e89b784cd35479fca606f228126e3641f5bcaee68dee36583d7c94830000000000000000000000000000000000000000000000000000000000000000
2024/09/16 10:02:22 <=============>
^C2024/09/16 10:02:31 Received signal, exiting..

According this logs we see, that the 1st program always starts and finishes first. Some times the third program starts before second is finished. 2024/09/16 10:02:20 Error file: ./tetragon. Code:0 this line means that there is no hash in event. It seems to me this because sleepable program sleeps and another bpf program is being executed (this is a send program in our case).

olsajiri · 2024-09-16T11:07:26Z

The question is can we rely on the order of execution when bprm_check_security is triggered?

I think we can, it's hardcoded in kernel.. and if it changes we could actually detect the way it's added
and use proper order attach

however it's the other way round (check https://pastebin.com/Y8EGQ0fg for the trampoline dump),
so when I reverse attach in your example I get proper order of executed programs

could you plz try the change below?

thanks,
jirka

diff --git a/main.go b/main.go
index 1d1fa138660d..0be26120a55f 100644
--- a/main.go
+++ b/main.go
@@ -40,11 +40,11 @@ func main() {
        }
        defer objs.Close()
 
-       initBprmHook, err := link.AttachLSM(link.LSMOptions{Program: objs.imaPrograms.InitBprmCheck})
+       sendBprmHook, err := link.AttachLSM(link.LSMOptions{Program: objs.imaPrograms.SendBprmCheck})
        if err != nil {
                log.Fatalf("linking LSM failed: %s", err)
        }
-       defer initBprmHook.Close()
+       defer sendBprmHook.Close()
 
        imaBprmHook, err := link.AttachLSM(link.LSMOptions{Program: objs.imaPrograms.ImaBprmCheck})
        if err != nil {
@@ -52,11 +52,11 @@ func main() {
        }
        defer imaBprmHook.Close()
 
-       sendBprmHook, err := link.AttachLSM(link.LSMOptions{Program: objs.imaPrograms.SendBprmCheck})
+       initBprmHook, err := link.AttachLSM(link.LSMOptions{Program: objs.imaPrograms.InitBprmCheck})
        if err != nil {
                log.Fatalf("linking LSM failed: %s", err)
        }
-       defer sendBprmHook.Close()
+       defer initBprmHook.Close()
 
        rd, err := perf.NewReader(objs.TcpmonMap, 65535)
        if err != nil {

anfedotoff · 2024-09-16T11:48:18Z

The question is can we rely on the order of execution when bprm_check_security is triggered?

I think we can, it's hardcoded in kernel.. and if it changes we could actually detect the way it's added and use proper order attach

however it's the other way round (check https://pastebin.com/Y8EGQ0fg for the trampoline dump), so when I reverse attach in your example I get proper order of executed programs

could you plz try the change below?

thanks, jirka

diff --git a/main.go b/main.go
index 1d1fa138660d..0be26120a55f 100644
--- a/main.go
+++ b/main.go
@@ -40,11 +40,11 @@ func main() {
        }
        defer objs.Close()
 
-       initBprmHook, err := link.AttachLSM(link.LSMOptions{Program: objs.imaPrograms.InitBprmCheck})
+       sendBprmHook, err := link.AttachLSM(link.LSMOptions{Program: objs.imaPrograms.SendBprmCheck})
        if err != nil {
                log.Fatalf("linking LSM failed: %s", err)
        }
-       defer initBprmHook.Close()
+       defer sendBprmHook.Close()
 
        imaBprmHook, err := link.AttachLSM(link.LSMOptions{Program: objs.imaPrograms.ImaBprmCheck})
        if err != nil {
@@ -52,11 +52,11 @@ func main() {
        }
        defer imaBprmHook.Close()
 
-       sendBprmHook, err := link.AttachLSM(link.LSMOptions{Program: objs.imaPrograms.SendBprmCheck})
+       initBprmHook, err := link.AttachLSM(link.LSMOptions{Program: objs.imaPrograms.InitBprmCheck})
        if err != nil {
                log.Fatalf("linking LSM failed: %s", err)
        }
-       defer sendBprmHook.Close()
+       defer initBprmHook.Close()
 
        rd, err := perf.NewReader(objs.TcpmonMap, 65535)
        if err != nil {

Hmm, I changed the order (swap init and send programs) as you suggest. I got no events collected, but execution is blocked. Are you sure that the order is really proper? It seems to me, that send program is now executed before init program. (send -> ima -> init).
Anyway, the good news is that order is preserved. But other question is that sometimes we miss the hash in event. Does it mean that send program is started before ima program is finished?

olsajiri · 2024-09-16T11:49:10Z

also I think we need to use hash for the data shared by the program, it looks like cpu migration is not actually disabled,
so we can't use per-cpu heap map in here

olsajiri · 2024-09-16T12:07:21Z

hum, when I remove the 'filter' from init function, I get all executed files output:
(I'm still using the per-cpu heap, but I don't think we should rely on that)

root@amd:/home/jolsa/ima-ebpfgo-example# ./ima-test 
2024/09/16 12:04:42 Waiting for events..
2024/09/16 12:04:43 File: /usr/bin/ls
2024/09/16 12:04:43 SHA256: 12a6d908a68ccf6f9f3d799705577c28763f5deef6eddcff7643d6d8a6de543d0000000000000000000000000000000000000000000000000000000000000000
2024/09/16 12:04:43 <=============>
2024/09/16 12:04:45 File: /usr/bin/ls
2024/09/16 12:04:45 SHA256: 12a6d908a68ccf6f9f3d799705577c28763f5deef6eddcff7643d6d8a6de543d0000000000000000000000000000000000000000000000000000000000000000
2024/09/16 12:04:45 <=============>
2024/09/16 12:04:47 File: /usr/bin/ls
2024/09/16 12:04:47 SHA256: 12a6d908a68ccf6f9f3d799705577c28763f5deef6eddcff7643d6d8a6de543d0000000000000000000000000000000000000000000000000000000000000000
2024/09/16 12:04:47 <=============>
2024/09/16 12:04:49 File: /usr/bin/ls
2024/09/16 12:04:49 SHA256: 12a6d908a68ccf6f9f3d799705577c28763f5deef6eddcff7643d6d8a6de543d0000000000000000000000000000000000000000000000000000000000000000
2024/09/16 12:04:49 <=============>
2024/09/16 12:04:50 File: /usr/bin/w
2024/09/16 12:04:50 SHA256: ae49096b42cebab2f3a2557e32b0f3e3e5139fd7e22201c9dc5bcfab9701946c0000000000000000000000000000000000000000000000000000000000000000
2024/09/16 12:04:50 <=============>
2024/09/16 12:05:33 File: /usr/bin/git
2024/09/16 12:05:33 SHA256: 29aa689f38158d2e8941fa54e436f0260890af31cecad1e8799e5c2df7bc1ecc0000000000000000000000000000000000000000000000000000000000000000
2024/09/16 12:05:33 <=============>
2024/09/16 12:05:33 File: /usr/bin/pager
2024/09/16 12:05:33 SHA256: f95851f468afe5c6e287d741153bde008ef26844916f5dfcb916e849ef3ae8bb0000000000000000000000000000000000000000000000000000000000000000
2024/09/16 12:05:33 <=============>
2024/09/16 12:05:47 File: /usr/bin/vim
2024/09/16 12:05:47 SHA256: dfc4b48f9b7976f0b64f6e99702ad8b1e4fb1929958fe07da98dfeb88f0a23fb0000000000000000000000000000000000000000000000000000000000000000
2024/09/16 12:05:47 <=============>

anfedotoff · 2024-09-16T12:35:34Z

hum, when I remove the 'filter' from init function, I get all executed files output: (I'm still using the per-cpu heap, but I don't think we should rely on that)

root@amd:/home/jolsa/ima-ebpfgo-example# ./ima-test 
2024/09/16 12:04:42 Waiting for events..
2024/09/16 12:04:43 File: /usr/bin/ls
2024/09/16 12:04:43 SHA256: 12a6d908a68ccf6f9f3d799705577c28763f5deef6eddcff7643d6d8a6de543d0000000000000000000000000000000000000000000000000000000000000000
2024/09/16 12:04:43 <=============>
2024/09/16 12:04:45 File: /usr/bin/ls
2024/09/16 12:04:45 SHA256: 12a6d908a68ccf6f9f3d799705577c28763f5deef6eddcff7643d6d8a6de543d0000000000000000000000000000000000000000000000000000000000000000
2024/09/16 12:04:45 <=============>
2024/09/16 12:04:47 File: /usr/bin/ls
2024/09/16 12:04:47 SHA256: 12a6d908a68ccf6f9f3d799705577c28763f5deef6eddcff7643d6d8a6de543d0000000000000000000000000000000000000000000000000000000000000000
2024/09/16 12:04:47 <=============>
2024/09/16 12:04:49 File: /usr/bin/ls
2024/09/16 12:04:49 SHA256: 12a6d908a68ccf6f9f3d799705577c28763f5deef6eddcff7643d6d8a6de543d0000000000000000000000000000000000000000000000000000000000000000
2024/09/16 12:04:49 <=============>
2024/09/16 12:04:50 File: /usr/bin/w
2024/09/16 12:04:50 SHA256: ae49096b42cebab2f3a2557e32b0f3e3e5139fd7e22201c9dc5bcfab9701946c0000000000000000000000000000000000000000000000000000000000000000
2024/09/16 12:04:50 <=============>
2024/09/16 12:05:33 File: /usr/bin/git
2024/09/16 12:05:33 SHA256: 29aa689f38158d2e8941fa54e436f0260890af31cecad1e8799e5c2df7bc1ecc0000000000000000000000000000000000000000000000000000000000000000
2024/09/16 12:05:33 <=============>
2024/09/16 12:05:33 File: /usr/bin/pager
2024/09/16 12:05:33 SHA256: f95851f468afe5c6e287d741153bde008ef26844916f5dfcb916e849ef3ae8bb0000000000000000000000000000000000000000000000000000000000000000
2024/09/16 12:05:33 <=============>
2024/09/16 12:05:47 File: /usr/bin/vim
2024/09/16 12:05:47 SHA256: dfc4b48f9b7976f0b64f6e99702ad8b1e4fb1929958fe07da98dfeb88f0a23fb0000000000000000000000000000000000000000000000000000000000000000
2024/09/16 12:05:47 <=============>

Yes, that works for me too, no hashes are missed. I remove filter with out changing order of execution, some hashes were missed.

Now I'm looking at __bpf_prog_enter_sleepable and __bpf_prog_enter

I think we need to use hash for the data shared by the program, it looks like cpu migration is not actually disabled,
so we can't use per-cpu heap map in here

It looks so... To use hash map is a good idea, but for now I don't know how to share key for this map. If we can't use per-cpu heap.

olsajiri · 2024-09-16T12:38:13Z

It looks so... To use hash map is a good idea, but for now I don't know how to share key for this map. If we can't use per-cpu heap.

I think just bpf_get_current_pid_tgid() should be ok? it's always under same task (but maybe not same cpu)

anfedotoff · 2024-09-16T13:02:02Z

It looks so... To use hash map is a good idea, but for now I don't know how to share key for this map. If we can't use per-cpu heap.

I think just bpf_get_current_pid_tgid() should be ok? it's always under same task (but maybe not same cpu)

This Is the first thing that came up to my mind. But what if we have file_open hook and the same process opens several files will it be OK? I think I can try to check this, nevertheless.

olsajiri · 2024-09-16T13:38:20Z

This Is the first thing that came up to my mind. But what if we have file_open hook and the same process opens several files will it be OK? I think I can try to check this, nevertheless.

hum, so if the key is thread id then single thread could have just one active file_open call and we should be fine, right?

anfedotoff · 2024-09-16T13:51:12Z

This Is the first thing that came up to my mind. But what if we have file_open hook and the same process opens several files will it be OK? I think I can try to check this, nevertheless.

hum, so if the key is thread id then single thread could have just one active file_open call and we should be fine, right?

Ahh, yes, we have tid. You are right! It seems to be fine than. I'll try to fix my example. If every thing is fine, I'll start to refactor code in th PR.
Thank you for helping me to find the solution!

anfedotoff · 2024-09-16T14:30:23Z

This Is the first thing that came up to my mind. But what if we have file_open hook and the same process opens several files will it be OK? I think I can try to check this, nevertheless.

hum, so if the key is thread id then single thread could have just one active file_open call and we should be fine, right?

Ahh, yes, we have tid. You are right! It seems to be fine than. I'll try to fix my example. If every thing is fine, I'll start to refactor code in th PR. Thank you for helping me to find the solution!

Everything is fine! I can start refactoring 🎆

Due to restrictions of bpf sleepable programs (no tailcalls, no perf buffer and per_cpu maps, etc.), we need to split generic LSM sensor into three parts (collections) and load them in this order: - bpf_generic_output sends event using perf buffer - bpf_generic_lsm_ima_* calculates hash using IMA helpers - bpf_generic_lsm_core does everything else Signed-off-by: Andrei Fedotov <[email protected]>

Adding support for IMA hash collection in Post Action. Adding IMA hashes in LSM events. Hash is represented by a string algorithm:value. Support loading lsm.s/generic_lsm_ima_* programs. Signed-off-by: Andrei Fedotov <[email protected]>

Signed-off-by: Andrei Fedotov <[email protected]>

Adding test for ImaHash Post action. Signed-off-by: Andrei Fedotov <[email protected]>

Add imaHash post action to lsm_bprm_check.yaml Signed-off-by: Andrei Fedotov <[email protected]>

Signed-off-by: Andrei Fedotov <[email protected]>

anfedotoff · 2024-09-19T19:16:47Z

It works! No race condition! ✨

anfedotoff requested a review from a team as a code owner August 16, 2024 13:52

anfedotoff requested a review from tixxdz August 16, 2024 13:52

anfedotoff marked this pull request as draft August 16, 2024 13:52

anfedotoff force-pushed the ima-hash-action branch 2 times, most recently from 15d918b to 758ec7e Compare August 16, 2024 15:08

anfedotoff force-pushed the ima-hash-action branch 2 times, most recently from 3ec1c3d to 7525121 Compare August 20, 2024 11:17

anfedotoff mentioned this pull request Aug 20, 2024

Tetragon based file integrity monitoring (FIM) #2409

Open

2 tasks

anfedotoff force-pushed the ima-hash-action branch 6 times, most recently from f9e5ac0 to 20a3c09 Compare August 29, 2024 10:23

anfedotoff force-pushed the ima-hash-action branch 2 times, most recently from b84e2bd to ef33031 Compare September 3, 2024 12:29

anfedotoff changed the title ~~WIP: IMA hashes in LSM events~~ IMA hashes in LSM events Sep 3, 2024

anfedotoff marked this pull request as ready for review September 3, 2024 12:30

anfedotoff requested a review from mtardy as a code owner September 3, 2024 12:30

kkourt self-requested a review September 4, 2024 12:51

anfedotoff force-pushed the ima-hash-action branch 2 times, most recently from 2ef75a3 to 58c2771 Compare September 6, 2024 13:56

kkourt added the release-note/major This PR introduces major new functionality label Sep 9, 2024

kkourt reviewed Sep 9, 2024

View reviewed changes

olsajiri reviewed Sep 10, 2024

View reviewed changes

anfedotoff force-pushed the ima-hash-action branch from 58c2771 to 2561d5a Compare September 12, 2024 09:07

anfedotoff force-pushed the ima-hash-action branch 2 times, most recently from 3e8bb67 to 3fc4ac4 Compare September 16, 2024 10:48

anfedotoff force-pushed the ima-hash-action branch from 3fc4ac4 to 9981b69 Compare September 19, 2024 15:03

anfedotoff added 3 commits September 19, 2024 18:07

tetra: Add IMA hashes in compact printing

ccc1c90

Signed-off-by: Andrei Fedotov <[email protected]>

anfedotoff force-pushed the ima-hash-action branch from 9981b69 to e3b21d8 Compare September 19, 2024 15:07

anfedotoff added 2 commits September 19, 2024 21:11

tetragon: Add TestLSMIMAHash

dd40a5d

Adding test for ImaHash Post action. Signed-off-by: Andrei Fedotov <[email protected]>

Update LSM tracingPolicy examples

9aad938

Add imaHash post action to lsm_bprm_check.yaml Signed-off-by: Andrei Fedotov <[email protected]>

anfedotoff force-pushed the ima-hash-action branch from e3b21d8 to 64374c4 Compare September 19, 2024 18:12

docs: imaHash flag for Post Action selector

a85b65e

Signed-off-by: Andrei Fedotov <[email protected]>

anfedotoff force-pushed the ima-hash-action branch from 64374c4 to a85b65e Compare September 19, 2024 18:16

anfedotoff requested review from kkourt and olsajiri September 19, 2024 18:41

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

IMA hashes in LSM events #2818

IMA hashes in LSM events #2818

anfedotoff commented Aug 16, 2024 •

edited

Loading

netlify bot commented Aug 16, 2024 •

edited

Loading

anfedotoff commented Sep 4, 2024 •

edited

Loading

kkourt commented Sep 4, 2024

kkourt left a comment •

edited

Loading

kkourt Sep 9, 2024

anfedotoff Sep 9, 2024

kkourt Sep 9, 2024

anfedotoff Sep 9, 2024

kkourt Sep 9, 2024

anfedotoff Sep 9, 2024

olsajiri commented Sep 10, 2024

olsajiri Sep 10, 2024

anfedotoff commented Sep 10, 2024

olsajiri commented Sep 11, 2024

anfedotoff commented Sep 12, 2024

olsajiri commented Sep 15, 2024

anfedotoff commented Sep 16, 2024 •

edited

Loading

olsajiri commented Sep 16, 2024

anfedotoff commented Sep 16, 2024

olsajiri commented Sep 16, 2024

olsajiri commented Sep 16, 2024

anfedotoff commented Sep 16, 2024

olsajiri commented Sep 16, 2024 •

edited

Loading

anfedotoff commented Sep 16, 2024

olsajiri commented Sep 16, 2024

anfedotoff commented Sep 16, 2024

anfedotoff commented Sep 16, 2024

anfedotoff commented Sep 19, 2024

IMA hashes in LSM events #2818

Are you sure you want to change the base?

IMA hashes in LSM events #2818

Conversation

anfedotoff commented Aug 16, 2024 • edited Loading

netlify bot commented Aug 16, 2024 • edited Loading

✅ Deploy Preview for tetragon ready!

anfedotoff commented Sep 4, 2024 • edited Loading

kkourt commented Sep 4, 2024

kkourt left a comment • edited Loading

Choose a reason for hiding this comment

kkourt Sep 9, 2024

Choose a reason for hiding this comment

anfedotoff Sep 9, 2024

Choose a reason for hiding this comment

kkourt Sep 9, 2024

Choose a reason for hiding this comment

anfedotoff Sep 9, 2024

Choose a reason for hiding this comment

kkourt Sep 9, 2024

Choose a reason for hiding this comment

anfedotoff Sep 9, 2024

Choose a reason for hiding this comment

olsajiri commented Sep 10, 2024

olsajiri Sep 10, 2024

Choose a reason for hiding this comment

anfedotoff commented Sep 10, 2024

olsajiri commented Sep 11, 2024

anfedotoff commented Sep 12, 2024

olsajiri commented Sep 15, 2024

anfedotoff commented Sep 16, 2024 • edited Loading

olsajiri commented Sep 16, 2024

anfedotoff commented Sep 16, 2024

olsajiri commented Sep 16, 2024

olsajiri commented Sep 16, 2024

anfedotoff commented Sep 16, 2024

olsajiri commented Sep 16, 2024 • edited Loading

anfedotoff commented Sep 16, 2024

olsajiri commented Sep 16, 2024

anfedotoff commented Sep 16, 2024

anfedotoff commented Sep 16, 2024

anfedotoff commented Sep 19, 2024

anfedotoff commented Aug 16, 2024 •

edited

Loading

netlify bot commented Aug 16, 2024 •

edited

Loading

anfedotoff commented Sep 4, 2024 •

edited

Loading

kkourt left a comment •

edited

Loading

anfedotoff commented Sep 16, 2024 •

edited

Loading

olsajiri commented Sep 16, 2024 •

edited

Loading