I'm seeing strange audit messages like the following from cron jobs on a
couple of systems. Any idea what this might be about? I don't expect grep to
be needing execmem access and when I run a command matching the proctitle at
the shell prompt it doesn't need it.
type=PROCTITLE msg=audit(26/02/19 00:00:07.426:1130782) : proctitle=grep -m 1
-oP pid-file=\K.+$
type=SYSCALL msg=audit(26/02/19 00:00:07.426:1130782) : arch=x86_64
syscall=mmap success=no exit=EACCES(Permission denied) a0=0x0 a1=0x10000
a2=PROT_READ|PROT_WRITE|PROT_EXEC a3=MAP_PRIVATE|MAP_ANONYMOUS items=0
ppid=6557 pid=6559 auid=unset uid=root gid=root euid=root suid=root fsuid=root
egid=root sgid=root fsgid=root tty=(none) ses=unset comm=grep exe=/bin/grep
subj=system_u:system_r:logrotate_t:s0 key=(null)
type=AVC msg=audit(26/02/19 00:00:07.426:1130782) : avc: denied { execmem }
for pid=6559 comm=grep scontext=system_u:system_r:logrotate_t:s0
tcontext=system_u:system_r:logrotate_t:s0 tclass=process permissive=0
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
Russell Coker <[email protected]> writes:
> I'm seeing strange audit messages like the following from cron jobs on a
> couple of systems. Any idea what this might be about? I don't expect grep to
> be needing execmem access and when I run a command matching the proctitle at
> the shell prompt it doesn't need it.
>
> type=PROCTITLE msg=audit(26/02/19 00:00:07.426:1130782) : proctitle=grep -m 1
> -oP pid-file=\K.+$
> type=SYSCALL msg=audit(26/02/19 00:00:07.426:1130782) : arch=x86_64
> syscall=mmap success=no exit=EACCES(Permission denied) a0=0x0 a1=0x10000
> a2=PROT_READ|PROT_WRITE|PROT_EXEC a3=MAP_PRIVATE|MAP_ANONYMOUS items=0
> ppid=6557 pid=6559 auid=unset uid=root gid=root euid=root suid=root fsuid=root
> egid=root sgid=root fsgid=root tty=(none) ses=unset comm=grep exe=/bin/grep
> subj=system_u:system_r:logrotate_t:s0 key=(null)
> type=AVC msg=audit(26/02/19 00:00:07.426:1130782) : avc: denied { execmem }
> for pid=6559 comm=grep scontext=system_u:system_r:logrotate_t:s0
> tcontext=system_u:system_r:logrotate_t:s0 tclass=process permissive=0
I suppose you probably should take that question to the grep community?
[root@brutus ~]# grep -m 1 -oP pid-file=\K.+$
^C
[root@brutus ~]# journalctl -rb | head -n2
-- Logs begin at Thu 2019-02-14 15:07:25 CET, end at Tue 2019-02-26 07:48:05 CET. --
Feb 26 07:48:05 brutus audit[13295]: AVC avc: denied { execmem } for pid=13295 comm="grep" scontext=wheel.id:sysadm.role:sysadm.subj:s0 tcontext=wheel.id:sysadm.role:sysadm.subj:s0 tclass=process permissive=0
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
On Tuesday, 26 February 2019 9:40:44 AM AEDT Russell Coker wrote:
> I'm seeing strange audit messages like the following from cron jobs on a
> couple of systems. Any idea what this might be about? I don't expect grep
> to be needing execmem access and when I run a command matching the
> proctitle at the shell prompt it doesn't need it.
>
> type=PROCTITLE msg=audit(26/02/19 00:00:07.426:1130782) : proctitle=grep -m
> 1 -oP pid-file=\K.+$
> type=SYSCALL msg=audit(26/02/19 00:00:07.426:1130782) : arch=x86_64
> syscall=mmap success=no exit=EACCES(Permission denied) a0=0x0 a1=0x10000
> a2=PROT_READ|PROT_WRITE|PROT_EXEC a3=MAP_PRIVATE|MAP_ANONYMOUS items=0
> ppid=6557 pid=6559 auid=unset uid=root gid=root euid=root suid=root
> fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=grep
> exe=/bin/grep subj=system_u:system_r:logrotate_t:s0 key=(null)
> type=AVC msg=audit(26/02/19 00:00:07.426:1130782) : avc: denied { execmem
> } for pid=6559 comm=grep scontext=system_u:system_r:logrotate_t:s0
> tcontext=system_u:system_r:logrotate_t:s0 tclass=process permissive=0
This turns out to be due to line 226 in grep-2.27/src/pcresearch.c:
extra = pcre_study (cre, PCRE_STUDY_JIT_COMPILE, &ep);
From pcre_study(3):
The only option is PCRE_STUDY_JIT_COMPILE. It requests just-in-time
compilation if possible. If PCRE has been compiled without JIT support,
this option is ignored. See the pcrejit page for further details.
Looks like it works OK even when it can't get write-exec memory.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/