tetragon icon indicating copy to clipboard operation
tetragon copied to clipboard

`auid` always unset in event outputs, not showing the actual login user Id

Open ycaoT opened this issue 2 years ago • 5 comments

What happened?

It's interesting that after I found the issue, I did a search 4294967295 in this repo, I found many results in the event outputs. Looks like I don't even need to provide more proofs. JK 😄

Back to the issue, auid should be supposed to my login/real user Id. Somehow it's always 4294967295. uid is my current user Id, as I switched to root, this is correct. auid should be my user's Id, so I know the action is actually done by who. uid=1002(ycao) gid=1003(ycao) groups=1003(ycao)

{
	"process_exec": {
		"process": {
			"exec_id": "Ojg3MTQ5NTY3NTg0OTkzOjExMzQzMTU=",
			"pid": 1134315,
			"uid": 0,
			"cwd": "/",
			"binary": "/bin/cat",
			"arguments": "/etc/shadow",
			"flags": "execve rootcwd clone",
			"start_time": "2023-12-13T21:27:45.849484339Z",
			"auid": 4294967295,
			"docker": "4cdb2f230e5ba4cb183c170888b686c",
			"parent_exec_id": "Ojg3MDAxOTM1MTg1NzQ4OjExMzIzODU=",
			"tid": 1134315
		},
		"parent": {
			"exec_id": "Ojg3MDAxOTM1MTg1NzQ4OjExMzIzODU=",
			"pid": 1132385,
			"uid": 0,
			"cwd": "/",
			"binary": "/bin/bash",
			"flags": "execve rootcwd clone",
			"start_time": "2023-12-13T21:25:18.217084929Z",
			"auid": 4294967295,
			"docker": "4cdb2f230e5ba4cb183c170888b686c",
			"parent_exec_id": "Ojg3MDAxODQwOTA0ODgzOjExMzIzNzE=",
			"tid": 1132385
		}
	},
	"time": "2023-12-13T21:27:45.849483813Z"
}

Tetragon Version

Latest

Kernel Version

6.1.72-96.166.amzn2023.x86_64, on Amazon Linux 2023 hosts

Kubernetes Version

No response

Bugtool

No response

Relevant log output

No response

Anything else?

No response

ycaoT avatar Feb 08 '24 21:02 ycaoT

According to here https://www.reddit.com/r/redhat/s/OyQGjPd4PF, that means the auid is unset if it's 4294967295. So the real problem is that why auid is unset?

ycaoT avatar Feb 08 '24 23:02 ycaoT

According to here https://www.reddit.com/r/redhat/s/OyQGjPd4PF, that means the auid is unset if it's 4294967295. So the real problem is that why auid is unset?

yes indeed, usually you initialize the ids to something not zero otherwise in the case they are not correctly set, you end up assuming root which might have security implications. As an illustration, see this kind of issue in Microsoft omi.

Now why this thing is unset should be indeed investigated to understand, thanks for the report!

mtardy avatar Feb 09 '24 08:02 mtardy

Back to the issue, auid should be supposed to my login/real user Id. Somehow it's always 4294967295. uid is my current user Id, as I switched to root, this is correct. auid should be my user's Id, so I know the action is actually done by who.

If it is 4294967295, then that's what the kernel returns, and we just print it, if there was a bug in Tetragon then we may return garbage data and not specific value that indicates loginuid (auid) is not set.

Some reading first: https://linux.die.net/man/8/pam_loginuid . The loginuid is to track user sessions, and it is set from user space, so you should check your workload, how did you spawn this session and see why the loginduid is not set?

Then the fix is have in the software that spawned this session in the first place is either to use pam_loginuid or audit_setloginuid() helpers to set it correctly before spawning anything, where it will be inherited by the session. An alternative way is that software could write directly to /proc/self/loginuid the uid assuming it has CAP_AUDIT_CONTROL.

Hope this helps

tixxdz avatar Feb 09 '24 09:02 tixxdz

Hey @tixxdz, thanks for sharing!

Quick question, does the auid ever work for you? Was it able to correctly show the real login users in some cases?

ycaoT avatar Feb 13 '24 22:02 ycaoT

Hey @tixxdz, thanks for sharing!

Quick question, does the auid ever work for you? Was it able to correctly show the real login users in some cases?

Yes it works, when running Tetragon in k8s, docker or standalone just login into the machine through ssh or normal login then inspect the tetragon events. Or to simply test it as root inside the session with the CAP_AUDIT_CONTROL capability enabled

# echo -n "99999" > /proc/self/loginuid
# id
uid=0(root) gid=0(root) groups=0(root)

Will produce:

{
  "process_exec": {
    "process": {
      "exec_id": "OjgyMTAxNDUyNzQzNTozMTQ0NQ==",
      "pid": 31445,
      "uid": 0,
      "cwd": "/root",
      "binary": "/usr/bin/id",
      "flags": "execve clone",
      "start_time": "2024-02-14T07:15:32.466738422Z",
      "auid": 99999,

tixxdz avatar Feb 14 '24 07:02 tixxdz