RFE: better message for map syscalls on lib with executable stack

[cgzones]

I am testing mariadb-10.4 on Debian. It it shipped erroneously with a library with executable stack. Hence SELinux catches several file:execute and process:execmem permission checks:

type=PROCTITLE msg=audit(02/25/20 00:29:15.732:13133) : proctitle=/usr/sbin/mysqld
type=MMAP msg=audit(02/25/20 00:29:15.732:13133) : fd=162 flags=MAP_SHARED|MAP_NORESERVE
type=SYSCALL msg=audit(02/25/20 00:29:15.732:13133) : arch=x86_64 syscall=mmap per=unknown-personality(0x400000) success=yes exit=140459061235712 a0=0x0 a1=0x7 a2=PROT_READ|PROT_WRITE a3=MAP_SHARED|MAP_NORESERVE items=0 ppid=1 pid=1397327 auid=unset uid=mysql gid=mysql euid=mysql suid=mysql fsuid=mysql egid=mysql sgid=mysql fsgid=mysql tty=(none) ses=unset comm=mysqld exe=/usr/sbin/mysqld subj=system_u:system_r:mysqld_t:s0 key=(null)
type=AVC msg=audit(02/25/20 00:29:15.732:13133) : avc:  denied  { execute } for  pid=1397327 comm=mysqld path=/tmp/#sql_15524f_0.MAD dev="sda1" ino=786732 scontext=system_u:system_r:mysqld_t:s0 tcontext=system_u:object_r:mysqld_tmp_t:s0 tclass=file permissive=1
----
type=PROCTITLE msg=audit(02/25/20 00:29:32.088:13134) : proctitle=/usr/sbin/mysqld
type=SYSCALL msg=audit(02/25/20 00:29:32.088:13134) : arch=x86_64 syscall=mprotect per=unknown-personality(0x400000) success=yes exit=0 a0=0x7fbf1c2be000 a1=0x5000 a2=PROT_READ|PROT_WRITE a3=0x7fbf1c2be000 items=0 ppid=1 pid=1397327 auid=unset uid=mysql gid=mysql euid=mysql suid=mysql fsuid=mysql egid=mysql sgid=mysql fsgid=mysql tty=(none) ses=unset comm=mysqld exe=/usr/sbin/mysqld subj=system_u:system_r:mysqld_t:s0 key=(null)
type=AVC msg=audit(02/25/20 00:29:32.088:13134) : avc:  denied  { execmem } for  pid=1397327 comm=mysqld scontext=system_u:system_r:mysqld_t:s0 tcontext=system_u:system_r:mysqld_t:s0 tclass=process permissive=1
----
type=PROCTITLE msg=audit(02/25/20 00:31:02.198:13135) : proctitle=/usr/sbin/mysqld
type=SYSCALL msg=audit(02/25/20 00:31:02.198:13135) : arch=x86_64 syscall=mprotect per=unknown-personality(0x400000) success=yes exit=0 a0=0x7fbef0032000 a1=0x4000 a2=PROT_READ|PROT_WRITE a3=0x7fbef0032000 items=0 ppid=1 pid=1397327 auid=unset uid=mysql gid=mysql euid=mysql suid=mysql fsuid=mysql egid=mysql sgid=mysql fsgid=mysql tty=(none) ses=unset comm=mysqld exe=/usr/sbin/mysqld subj=system_u:system_r:mysqld_t:s0 key=(null)
type=AVC msg=audit(02/25/20 00:31:02.198:13135) : avc:  denied  { execmem } for  pid=1397327 comm=mysqld scontext=system_u:system_r:mysqld_t:s0 tcontext=system_u:system_r:mysqld_t:s0 tclass=process permissive=1
----
type=PROCTITLE msg=audit(02/25/20 00:50:30.784:13436) : proctitle=/usr/sbin/mysqld
type=MMAP msg=audit(02/25/20 00:50:30.784:13436) : fd=3 flags=MAP_PRIVATE
type=SYSCALL msg=audit(02/25/20 00:50:30.784:13436) : arch=x86_64 syscall=mmap per=unknown-personality(0x400000) success=no exit=EACCES(Permission denied) a0=0x0 a1=0x4d12 a2=PROT_READ a3=MAP_PRIVATE items=0 ppid=1 pid=1400666 auid=unset uid=mysql gid=mysql euid=mysql suid=mysql fsuid=mysql egid=mysql sgid=mysql fsgid=mysql tty=(none) ses=unset comm=mysqld exe=/usr/sbin/mysqld subj=system_u:system_r:mysqld_t:s0 key=(null)
type=AVC msg=audit(02/25/20 00:50:30.784:13436) : avc:  denied  { execute } for  pid=1400666 comm=mysqld path=/etc/ld.so.cache dev="sda1" ino=1048745 scontext=system_u:system_r:mysqld_t:s0 tcontext=root:object_r:ld_so_cache_t:s0 tclass=file permissive=0

Maybe these logs can be improved especially the field per=unknown-personality(0x400000).

[pcmoore]

Generally we try to avoid changing the record format for compatibility reasons.

That said, do you have any specific suggestions?

[cgzones]

I am quite unfamiliar how auditd internally works. That said, auditd apparently adds a personality field with value 0x400000 to the syscall (I do not know why). Maybe the userspace frontend can interpret this value in a more human readable ways.

[pcmoore]

If you are talking only about the output from ausearch -i then you should file an issue with the audit-userspace tool. If you are talking about the raw kernel output then you are in the right place :)

It sounds like this is an issue for the userspace tool so I'm going to close this out (not a kernel issue), but if you disagree feel free to reopen/comment further.