Question on using seccomp to identify malicious syscall

Kubernetes
#1

Hi,

If I have a pod hosting a running process that is making malicious syscall such as "kill", is it possible to identify the pod using seccomp?

Here is how I approached the above scenario:

  1. Create the following seccomp directory on the node that is hosting the pod
/var/lib/kubelet/seccomp/profiles/
  1. Create the following custom audit seccomp profile (e.g. audit.json) under the above directory
{
    "defaultAction": "SCMP_ACT_LOG"
}
  1. Edit my deployment to include my seccomp profile under the pod definition
spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: profiles/audit.json
  1. View syscall generated by the process on the host via the following command
grep syscall /var/log/syslog | grep <deployment_name>

Jan  3 22:02:28 cluster1-node1 kernel: [20466.105995] audit: type=1326 audit(1704319348.959:75804): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=105848 comm="collector1-proc" exe="/collector1-process" sig=0 arch=c000003e syscall=281 compat=0 ip=0x45da80 code=0x7ffc0000
Jan  3 22:02:28 cluster1-node1 kernel: [20466.105999] audit: type=1326 audit(1704319348.959:75805): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=105848 comm="collector1-proc" exe="/collector1-process" sig=0 arch=c000003e syscall=35 compat=0 ip=0x45d1bd code=0x7ffc0000
Jan  3 22:02:28 cluster1-node1 kernel: [20466.106903] audit: type=1326 audit(1704319348.963:75806): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=105848 comm="collector1-proc" exe="/collector1-process" sig=0 arch=c000003e syscall=202 compat=0 ip=0x45d863 code=0x7ffc0000
Jan  3 22:02:28 cluster1-node1 kernel: [20466.106906] audit: type=1326 audit(1704319348.963:75807): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=106062 comm="collector1-proc" exe="/collector1-process" sig=0 arch=c000003e syscall=202 compat=0 ip=0x45d863 code=0x7ffc0000

As you can see, I do see various syscall represented by number. However, when I cross reference the syscall number against

grep -w <syscall_number> /usr/include/asm-generic/unistd.h

I don’t see anything related to "kill" syscall.

Does the above approach make sense? Am I doing something wrong here?

Just for the record, when I review the syscalls made by the process using "strace", I do see "kill" syscall made by the process running on the pod:

strace -p <process_id>

epoll_pwait(3, [], 128, 999, NULL, 1)   = 0
kill(666, SIGTERM)                      = -1 ESRCH (No such process)
#2

My sense is that it’s harder than the typical way to solve this class of problem. Assuming you could map the syscall number of kill to something you see in the log, and you have all of your target pods modified to use your auditing profile, it might work. I looked at a different file (arch/x86/entry/syscalls/syscall_64.tbl), and if I’m reading it right, the code would be 62, although I’m not familiar enough with low level Linux code to be sure I’m reading that right.

That said, it would be nice to be able to use a logging or auditing facility to get at which pods were running containers that made a specific syscall, such as kill. I’m not sure if seccomp is the best tool for this purpose. You’d think there’d be a way to make falco do this, but I haven’t found a rule that does this.

Looking at the name of your pods, this looks like a problem I’ve worked before. If you know the universe of pods you’re trying to check, this problem is solved by using crictl to get the container’s ID, using crictl inspect to get the process ID, and using strace -p to see what syscalls are detected.

That approach is used in a couple of mock exam problems I’ve worked; it might suffice for the exam. I’m not sure if there’s a good general solution for your problem that would be practical on a real system, but it would certainly be a good thing to know.

1 Like
#3

Thank you @rob_kodekloud for your detailed response. Yes, this problem is from the CKS simulator and the official solution solved it with CRICTL.