Provide parity with Linux Audit system for logging real user identity in case sudo/sudo su is used (%user.auid property is needed)

[alukyan]

When Falco is configured to log EXECVE calls it is not possible to track ID of actual executing user - %user.name returns root and %user.uid return 0.

But Linux auditing system always provides an identity of actual executing user via auid field.

So if user with ID = 1002 runs

$ sudo su
$ touch /bin/myfile12

the Falco log with rule

 - rule: All the commands executed by users
   desc: an attempt to run interactive commands by any user
   condition: spawned_process
   output: "User ran an interactive command (user=%user.name uid=%user.uid command=%proc.cmdline)"
   priority: INFO
   tags: [users]

looks like this

01:54:28.826846427: Informational User ran an interactive command (user=root uid=0 command=touch /bin/myfile12)

while audit record looks like this (note auid=1002 there) which makes it easy to correlate which user run this command as sudo and provide automated response if suspicious activity is spotted

type=SYSCALL msg=audit(1516672468.826:127058): arch=c000003e syscall=59 success=yes exit=0 a0=bea588 a1=be06c8 a2=bde008 a3=598 items=2 ppid=15394 pid=15407 auid=1002 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1811 comm="touch" exe="/bin/touch" key=(null)
type=EXECVE msg=audit(1516672468.826:127058): argc=2 a0="touch" a1="/bin/myfile12"
type=PATH msg=audit(1516672468.826:127058): item=0 name="/usr/bin/touch" inode=46 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00

[jaguasch]

related?

added loginuid on execve event by @arossert

draios/sysdig#1008

[mfdii]

@mstemm are we pulling in the changes from draios/sysdig#1008 to address this issue?

[mebezac]

This would be great to have!

[mstemm]

draios/sysdig#1189 is an updated version of the changes that will address this feature.

[mstemm]

The PR is merged. I'm going to keep this falco issue open until I also update the ruleset to take advantage of user.loginuid and user.loginname.

[leodido]

Hey @mstemm what's the state of this?

[mstemm]

We haven't updated the rules yet to take advantage of the changes in draios/sysdig#1189, so we should keep it open.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[mstemm]

We should keep this on the roadmap.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[leodido]

Absolutely keep!

…

On Fri, Oct 11, 2019, 6:39 PM stale[bot] ***@***.***> wrote: This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#318?email_source=notifications&email_token=AAA5J42QEE72KN3VXK2COX3QOCT25A5CNFSM4END57C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBARRAY#issuecomment-541137027>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA5J4ZEU5CHLO45GXPMSLLQOCT25ANCNFSM4END57CQ> .

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[xaocon]

I don't want to tell you guys to work on but I think it's a pretty important issue to be closed automatically so I'm going to bump.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[csschwe]

I think this issue is important.

Looks like the simplest solution would be to find any user=%user.name and replace with user=%user.name user_loginuid=%user.loginuid

I can should be able to provide a pull request if this is ok?

[drewblas]

Agreed. This is still important and a pretty naive oversight for a security product. Would love to see it fixed