Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B2CE1C43381 for ; Thu, 28 Feb 2019 05:37:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 73CD921850 for ; Thu, 28 Feb 2019 05:37:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=coker.com.au header.i=@coker.com.au header.b="rd6mcs3K" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730778AbfB1FhY (ORCPT ); Thu, 28 Feb 2019 00:37:24 -0500 Received: from smtp.sws.net.au ([46.4.88.250]:47950 "EHLO smtp.sws.net.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725862AbfB1FhX (ORCPT ); Thu, 28 Feb 2019 00:37:23 -0500 Received: from liv.localnet (localhost [127.0.0.1]) by smtp.sws.net.au (Postfix) with ESMTP id 39C0AF676; Thu, 28 Feb 2019 16:37:19 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coker.com.au; s=2008; t=1551332241; bh=B4mjw6/6SM2oIKCvg0jaw0N4wRWKwXYBoY5sMl4YO0Y=; l=1624; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rd6mcs3Kg48vxFDQWK/iuEsH87q6o6ZP83b6ERCXfO8sY9AZvEpp35/RU+4HxzOlO tHFZC12iHcgd33xmZDrcFNbt0NFtyLO5VkgYS2/IGmTLNO6ABX8jKGRyhMg91w0pNz +kQ8uEX5Ia2gAFuLWrXoYtHsFDauEzCDDNZpyS3I= From: Russell Coker To: Russell Coker Cc: "selinux-refpolicy@vger.kernel.org" Subject: Re: strange execmem Date: Thu, 28 Feb 2019 16:37:12 +1100 Message-ID: <14372220.i1gRE7gfGF@liv> In-Reply-To: <2945607.tWFyTVdlCF@liv> References: <2945607.tWFyTVdlCF@liv> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: selinux-refpolicy-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux-refpolicy@vger.kernel.org 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/