openat2(2) flags support

[cgzones]

For open(2) and openat(2) one can filter by the flags used (e.g. O_CREAT):

-a always,exit -F -S openat,open_by_handle_at -F a2&0100 -F key=creation
-a always,exit -F -S open -F a1&0100 -F key=creation

Please support filtering on the openat2 how structure flags, e.g.:

-a always,exit -F -S openat2 -F oflags&0100 -F key=creation

Also I noticed the interpretation of the oflag field in the OPENAT2 type is currently wrong: (Probably the field is interpreted as hex value, while it is actual in octal)

struct open_how how = { .flags = O_RDWR | O_CREAT, .mode = 0750 };

type=PROCTITLE msg=audit(22/09/22 14:57:44.045:1528) : proctitle=./openat2 
type=PATH msg=audit(22/09/22 14:57:44.045:1528) : item=0 name=/root/.bashrc nametype=UNKNOWN cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
type=CWD msg=audit(22/09/22 14:57:44.045:1528) : cwd=/home/christian/Downloads 
type=OPENAT2 msg=audit(22/09/22 14:57:44.045:1528) : oflag=O_RDWR|O_NOCTTY mode=000,750 resolve=0x0x0 
type=SYSCALL msg=audit(22/09/22 14:57:44.045:1528) : arch=x86_64 syscall=openat2 success=no exit=EACCES(Permission denied) a0=AT_FDCWD a1=0x5593c5ad3038 a2=0x7ffd1b717900 a3=0x18 items=1 ppid=6055 pid=6754 auid=christian uid=christian gid=christian euid=christian suid=christian fsuid=christian egid=christian sgid=christian fsgid=christian tty=pts4 ses=3 comm=openat2 exe=/home/christian/Downloads/openat2 subj=unconfined key=openat2

struct open_how how = { .flags = O_RDWR | O_CREAT | O_NOCTTY, .mode = 0750 };

type=PROCTITLE msg=audit(22/09/22 14:58:40.248:1530) : proctitle=./openat2 
type=PATH msg=audit(22/09/22 14:58:40.248:1530) : item=0 name=/root/.bashrc nametype=UNKNOWN cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
type=CWD msg=audit(22/09/22 14:58:40.248:1530) : cwd=/home/christian/Downloads 
type=OPENAT2 msg=audit(22/09/22 14:58:40.248:1530) : oflag=O_RDWR|O_NOCTTY|O_APPEND mode=000,750 resolve=0x0x0 
type=SYSCALL msg=audit(22/09/22 14:58:40.248:1530) : arch=x86_64 syscall=openat2 success=no exit=EACCES(Permission denied) a0=AT_FDCWD a1=0x562242b68038 a2=0x7fff537356f0 a3=0x18 items=1 ppid=6055 pid=6785 auid=christian uid=christian gid=christian euid=christian suid=christian fsuid=christian egid=christian sgid=christian fsgid=christian tty=pts4 ses=3 comm=openat2 exe=/home/christian/Downloads/openat2 subj=unconfined key=openat2

struct open_how how = { .flags = O_RDONLY | O_NOCTTY };

type=PROCTITLE msg=audit(22/09/22 15:01:42.546:1536) : proctitle=./openat2 
type=PATH msg=audit(22/09/22 15:01:42.546:1536) : item=0 name=/root/.bashrc nametype=UNKNOWN cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
type=CWD msg=audit(22/09/22 15:01:42.546:1536) : cwd=/home/christian/Downloads 
type=OPENAT2 msg=audit(22/09/22 15:01:42.546:1536) : oflag=O_RDONLY|O_APPEND mode=000,000 resolve=0x0x0 
type=SYSCALL msg=audit(22/09/22 15:01:42.546:1536) : arch=x86_64 syscall=openat2 success=no exit=EACCES(Permission denied) a0=AT_FDCWD a1=0x55a6fa0a0038 a2=0x7ffc5d58fb60 a3=0x18 items=1 ppid=6055 pid=6942 auid=christian uid=christian gid=christian euid=christian suid=christian fsuid=christian egid=christian sgid=christian fsgid=christian tty=pts4 ses=3 comm=openat2 exe=/home/christian/Downloads/openat2 subj=unconfined key=openat2

[stevegrubb]

Filtering is done by the kernel, not user space. I don't know if an issue has been opened with the kernel or it's status, but user space can support it once adopted by the kernel.

[rgbriggs]

On 2022-09-22 06:13, cgzones wrote:

For open(2) and openat(2) one can filter by the flags used (e.g. O_CREAT): -a always,exit -F -S openat,open_by_handle_at -F a2&0100 -F key=creation -a always,exit -F -S open -F a1&0100 -F key=creation

Please support filtering on the openat2 how structure flags, e.g.: -a always,exit -F -S openat2 -F oflags&0100 -F key=creation

We'll need to add a new filter since a2 is a pointer for openat2, say AUDIT_OFLAG and might even be able to generalize it for open()/openat().

Also I noticed the interpretation of the oflag field in the OPENAT2 type is currently wrong: (Probably the field is interpreted as hex value, while it is actual in octal)

It is delivered in the kernel as octal: https://github.com/torvalds/linux/blob/master/kernel/auditsc.c#L1463 case AUDIT_OPENAT2: audit_log_format(ab, "oflag=0%llo mode=0%llo resolve=0x%llx", context->openat2.flags, context->openat2.mode, context->openat2.resolve);

so this interpretation is done in userspace.

Unfortunately, the AUDIT_MQ_OPEN record delivers oflag as hex: https://github.com/torvalds/linux/blob/master/kernel/auditsc.c#L1416 case AUDIT_MQ_OPEN: audit_log_format(ab, "oflag=0x%x mode=%#ho mq_flags=0x%lx mq_maxmsg=%ld " "mq_msgsize=%ld mq_curmsgs=%ld", context->mq_open.oflag, context->mq_open.mode,

So it appears that one or the other will need to be special-cased for interpretation.

struct open_how how = { .flags = O_RDWR | O_CREAT, .mode = 0750 }; type=OPENAT2 msg=audit(22/09/22 14:57:44.045:1528) : oflag=O_RDWR|O_NOCTTY mode=000,750 resolve=0x0x0

struct open_how how = { .flags = O_RDWR | O_CREAT | O_NOCTTY, .mode = 0750 }; type=OPENAT2 msg=audit(22/09/22 14:58:40.248:1530) : oflag=O_RDWR|O_NOCTTY|O_APPEND mode=000,750 resolve=0x0x0

struct open_how how = { .flags = O_RDONLY | O_NOCTTY }; type=OPENAT2 msg=audit(22/09/22 15:01:42.546:1536) : oflag=O_RDONLY|O_APPEND mode=000,000 resolve=0x0x0

[stevegrubb]

Kernel values should always be hex or decimal. Userspace can then present them in any format.

[pcmoore]

The audit record support for openat(2) was added in Linux v5.16 after discussions on-list that spanned multiple months. We are well past the point where we can change the kernel format of the existing OPENAT2 record fields.

[stevegrubb]

Commit 83214d7 should fix interpretation.

[stevegrubb]

Thanks for reporting this. Closing this out. A partial fix has been shipped. If there is still anything left to do, please open a new issue.

[cgzones]

The partial fix only targets the base8-base16 confusion, not the actual support for filtering on openat2() open flags; or did I miss some changes?

[stevegrubb]

Any filtering would be done by the kernel - not user space. User space would provide a way to load the rule. To get any changes to filtering, it would need an issue opened on linux-kernel.