strange execmem

strange execmem

[Russell Coker]

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/

Re: strange execmem

[Dominick Grift]

Russell Coker <russell@coker.com.au> 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

Re: strange execmem

[Russell Coker]

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/