Description of problem: SELinux is preventing /usr/bin/grep from using the 'execmem' accesses on a process. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that grep should be allowed execmem access on processes labeled cupsd_t by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep grep /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:cupsd_t:s0-s0:c0.c1023 Target Context system_u:system_r:cupsd_t:s0-s0:c0.c1023 Target Objects [ process ] Source grep Source Path /usr/bin/grep Port <Unknown> Host (removed) Source RPM Packages grep-2.18-1.fc21.x86_64 Target RPM Packages Policy RPM selinux-policy-3.13.1-38.fc21.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 3.14.0-0.rc7.git0.1.fc21.x86_64 #1 SMP Mon Mar 17 13:48:26 UTC 2014 x86_64 x86_64 Alert Count 1 First Seen 2014-03-21 19:46:20 CET Last Seen 2014-03-21 19:46:20 CET Local ID f4fb849c-a7ba-4ee5-8e6a-0ec22d235738 Raw Audit Messages type=AVC msg=audit(1395427580.543:403): avc: denied { execmem } for pid=2848 comm="grep" scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tclass=process type=SYSCALL msg=audit(1395427580.543:403): arch=x86_64 syscall=mmap success=yes exit=139959619260416 a0=0 a1=10000 a2=7 a3=22 items=0 ppid=2819 pid=2848 auid=4294967295 uid=4 gid=7 euid=4 suid=4 fsuid=4 egid=7 sgid=7 fsgid=7 tty=(none) ses=4294967295 comm=grep exe=/usr/bin/grep subj=system_u:system_r:cupsd_t:s0-s0:c0.c1023 key=(null) Hash: grep,cupsd_t,cupsd_t,process,execmem Additional info: reporter: libreport-2.2.0 hashmarkername: setroubleshoot kernel: 3.14.0-0.rc7.git0.1.fc21.x86_64 type: libreport
This is very strange AVC. There is no reason for grep or cups to need execmem privilege.
*** Bug 1094077 has been marked as a duplicate of this bug. ***
Description of problem: Impression d'un document (cups) Additional info: reporter: libreport-2.2.2 hashmarkername: setroubleshoot kernel: 3.14.2-200.fc20.x86_64 type: libreport
I get this too. I Googled it because I was also surprised to see grep wanting to execmem. Christoph, Fred, what's your printer? Mine's an HP that has a binary plugin (that is installed by hp-toolbox). Does yours have a binary plugin too?
Also: in the duplicate (#1079534), the description says "Attempted to print to a remote CUPS server". This present bug does not state whether the CUPS server was remote. In my case, it is on localhost.
My printer is an Epson Stylus C84. It's not a remote printer.
Description of problem: Trying to print from Okular Additional info: reporter: libreport-2.2.2 hashmarkername: setroubleshoot kernel: 3.14.2-200.fc20.x86_64 type: libreport
This comes from pcre. Not sure if there's a way for grep to tell it not to do that. Several print filters use grep. Probably the best thing is for this to be allowed in the policy.
Description of problem: tried to make a printout to a remote printer Additional info: reporter: libreport-2.2.2 hashmarkername: setroubleshoot kernel: 3.14.2-200.fc20.x86_64 type: libreport
Description of problem: Nothing special just printed from Word using cross over office Additional info: reporter: libreport-2.2.2 hashmarkername: setroubleshoot kernel: 3.14.3-200.fc20.x86_64 type: libreport
Description of problem: This was the command that triggered the problem: ls some/path/*.inc | a2ps -P my_printer Additional info: reporter: libreport-2.2.2 hashmarkername: setroubleshoot kernel: 3.14.3-200.fc20.x86_64 type: libreport
Tim you are saying libpcre requies execmem privs now?
Description of problem: I have got this error message after installing HP-printer driver from hplipopensource.com/hplip-web/install/install/index.html , according their instruction. Additional info: reporter: libreport-2.2.2 hashmarkername: setroubleshoot kernel: 3.14.4-200.fc20.x86_64 type: libreport
Description of problem: hi! :-) when i want to use my hp deskjet 2540 serie by wifi, selinux block her. before i add fedora 20 , it was fedora 19 and it run very good. the log: Vous devriez rapporter ceci en tant qu'anomalie. Vous pouvez générer un module de stratégie local pour autoriser cet accès. Autoriser cet accès pour le moment en exécutant : # grep grep /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional info: reporter: libreport-2.2.2 hashmarkername: setroubleshoot kernel: 3.14.4-200.fc20.i686 type: libreport
(In reply to Daniel Walsh from comment #12) > Tim you are saying libpcre requies execmem privs now? Just observing that grep doesn't use PROT_EXEC in mmap(), but libpcre does. Looks similar to bug #923516?
PCRE library can use JIT for matching regular expression since version 8.21 (first in Fedora 17). By default not JIT is used. Application has to ask for it explicitly with pcre_study(, PCRE_STUDY_JIT_COMPILE, ) and then allocating the JIT stack by pcre_jit_stack_alloc() and registering it to the context by pcre_assign_jit_stack(). Please note the JIT is not used all the time a application request it. Some regular expressions are not implemented in JIT, thus PCRE library can decide to fall to the interpreter path back. See pcrejit(3) for more details. grep-2.18 as can be found in Fedora 21 does that (src/pcresearch.c). a2ps does use PCRE library directly. It executes grep(1). Decision whether a JIT will be used is a run-time matter. It's up to applications.
Does grep have a runtime switch for not using JIT?
grep does not PCRE by default. However if run with `-P' option, it will use PCRE and it will enable JIT. There is no switch to disable the JIT currently.
Could anyone experiencing this bug please try 'yum downgrade grep' and see if the problem still occurs? That would help to determine if it really is coming from the changes in the new version of grep.
*** Bug 1097300 has been marked as a duplicate of this bug. ***
(In reply to Tim Waugh from comment #19) > Could anyone experiencing this bug please try 'yum downgrade grep' and see > if the problem still occurs? > > That would help to determine if it really is coming from the changes in the > new version of grep. I just tried to downgrade grep. Problem persists. |<
SELinux says that grep is doing this. Does the maintainer have any idea why grep would need 'execmem' in any situation?
Description of problem: I just tried to send two pages to printer from Okular ... Additional info: reporter: libreport-2.2.2 hashmarkername: setroubleshoot kernel: 3.14.4-200.fc20.x86_64 type: libreport
(In reply to Tim Waugh from comment #22) > SELinux says that grep is doing this. Does the maintainer have any idea why > grep would need 'execmem' in any situation? This has nothing to do with libpcre or grep. This is a bug in SELinux policy. Just any process which executes "grep -P" can run into the JIT code. The code resides in libpcre and it does mmap(PROT_EXEC). The problem is SELinux policy binds permissions to process domains which are bound to executed programs. AFAIK SELinux cannot track shared libraries linked into the executed program. So there is no way to declare that any program linked to libpcre is allowed to do "execmem". Instead the policy needs to enumerate each programs which executes grep. Therefore the only workaround here is to create a new domain for /usr/bin/grep and allow "execmem" there. And then allow the transition from daemons domain there.
Well this is the only time we have ever seen an AVC about grep doing execmem. -P, --perl-regexp Interpret PATTERN as a Perl regular expression. This is highly experimental and grep -P may warn of unimplemented features. Does not seem like this is likely to happen often. Simplest thing is to allow cups to do execmem. Perhaps via boolean.
Description of problem: I just printed a few pages ... this one should end up as duplicate, sending just to update the version - still a problem with cups-1.7.2-1.fc20.x86_64 cups-filters-1.0.53-2.fc20.x86_64 foomatic-4.0.9-6.fc20.x86_64 Additional info: reporter: libreport-2.2.2 hashmarkername: setroubleshoot kernel: 3.14.4-200.fc20.x86_64 type: libreport
Description of problem: I was using a2ps -1 to print a small file on my HP 8700 printer. Additional info: reporter: libreport-2.2.2 hashmarkername: setroubleshoot kernel: 3.14.4-200.fc20.x86_64 type: libreport
Description of problem: Problem occurred using xsane in "copy"mode, copying from HP scanner to (separate) HP printer. Additional info: reporter: libreport-2.2.2 hashmarkername: setroubleshoot kernel: 3.14.3-200.fc20.x86_64 type: libreport
(In reply to Daniel Walsh from comment #25) > Simplest thing is to allow cups to do execmem. Perhaps via boolean. Moving back to SELinux policy component.
I see this only when I print from SoftMaker but not when printing a PDF.
commit a315fce1314d0fc74d7632d08430eb6bd01ce1a4 Author: Miroslav Grepl <mgrepl> Date: Fri Jun 6 14:10:44 2014 +0200 Add cups_execmem boolean
I think this is an incorrect "solution" to this problem. I don't understand why the "experimental" -p switch in grep is using execmem, when in fact Perl itself does not do so. It strikes me as an entirely insecure, even dangerous, usage. And I'm grateful that SELinux caught it. Why CUPS is using this experimental switch is also a mystery to me. It would be far better for the people working on CUPS and grep to explain what is going on, rather than offering a potentially disastrous security hole into SELinux. I can understand why WINE/Microsoft Windows requires execmem, but not CUPS or grep.
(In reply to John Freed from comment #32) > I don't understand why the "experimental" -p switch in grep is using > execmem, Because -P stands for "use PCRE semantics and PCRE library" and, in addition, grep enables JIT in the PCRE library. Thus PCRE library needs execmem permission. > when in fact Perl itself does not do so. Perl does not do JIT. > Why CUPS is using this experimental switch is also a mystery to me. > Because it's faster?
Would not the optimal solution be if grep was able to both a) use PCRE and b) not use JIT? Perhaps with a new switch, e.g. --no-pcre-jit ... and then to patch everywhere in CUPS that is calling grep to use that switch? From a usability point-of-view, having a cups_execmem boolean seems a bit like pushing the hard decision onto the ill-equipped user. From a security point-of-view, allowing a program that potentially receives remote user-controlled input (e.g. network office printing) to have the ability to execmem seems worrying, especially when (from this ticket so far), the exact vectors through which input gets passed through from cups to grep seem not to be known yet. Is the cups_execmem boolean at this point just a renamed "not_really_understood_lower_your_security_if_you_want_its_your_risk" boolean, or is this problem better understood than the comments in this ticket imply so far?
Thank you David Anderson for expressing this better than I could. Petr, "faster but insecure" is not a solution. If it is in fact several orders of magnitude faster, I might agree, but I have seen no groundswell of demand for such a change -- none at all in fact. I have never noticed a speed problem with CUPS. The horrendous potential security hole, on the other hand, is obvious (and trapped by SELinux).
(In reply to Miroslav Grepl from comment #31) > commit a315fce1314d0fc74d7632d08430eb6bd01ce1a4 > Author: Miroslav Grepl <mgrepl> > Date: Fri Jun 6 14:10:44 2014 +0200 > > Add cups_execmem boolean Please patch for Fedora 20 as well. Thanks.
I think I have have tracked down the culprit: /usr/lib/cups/filter/pstopdf, from the cups-filters package. I was never able to reproduce the AVC here. Would someone be able to verify whether this package fixes it?: http://koji.fedoraproject.org/koji/buildinfo?buildID=521544
Sorry, but the abrt report did not disappear. selinux-policy-3.13.1-55.fc20.noarch selinux-policy-targeted-3.13.1-55.fc20.noarch selinux-policy-devel-3.13.1-55.fc20.noarch I'll attach a new description file.
Created attachment 902970 [details] description with selinux 3.13.1-55 This happened with a koji scratch build from the fc21 source rpm. selinux-policy-3.13.1-55.fc20.noarch selinux-policy-targeted-3.13.1-55.fc20.noarch selinux-policy-devel-3.13.1-55.fc20.noarch
Sure, please see the "Fixed In Version" field. selinux-policy-3.13.1-56.fc21
(In reply to Miroslav Grepl from comment #40) > selinux-policy-3.13.1-56.fc21 Oh, sorry for this wasted noise. I did not notice that only the patch # has increased. I'll wait for an official new package.
(In reply to John Freed from comment #35) > Thank you David Anderson for expressing this better than I could. > > "faster but insecure" That says you. > speed problem with CUPS. The horrendous potential security hole, on the > other hand, is obvious (and trapped by SELinux). I proposed creating new domain specifically for grep. Not allowing whole cupsd to have executable heap as it was implemented by the update. Also please note that the thing which is executed is not a network input (the printed page), but a regular expression which is a static argument. And just for your information, there are numerous binaries with JIT: Javascript engines, Java, Haskell, or Prolog interpreters, OpenGL implementations etc. Even the modern Linux packet filter is JITted. Today's software is such a horrendously insecure.
I agree with David that we really need a way to tell grep not to use this. Writing a transition rule for something like grep is rather difficult policy writing and brings little benefit. Allowing JIT for user sessions is a fact of life, but allowing it for system services, so far has not been that big of a problem. I have seen few instances where services need this access.
Description of problem: The problem happens every time I try to print. Specifically from Okular. My files still printed, but this AVC denial persists. Additional info: reporter: libreport-2.2.2 hashmarkername: setroubleshoot kernel: 3.14.6-200.fc20.x86_64 type: libreport
cups-filters-1.0.53-4.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/cups-filters-1.0.53-4.fc20
Description of problem: Printing from browser Additional info: reporter: libreport-2.2.2 hashmarkername: setroubleshoot kernel: 3.14.5-200.fc20.i686+PAE type: libreport
Package cups-filters-1.0.53-4.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing cups-filters-1.0.53-4.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-7297/cups-filters-1.0.53-4.fc20 then log in and leave karma (feedback).
Still getting AVC. Unless I am making some sort of error, line 108 of pstopdf reads: if printf "%s" "$5" | grep -iPq '(\s|^)landscape(=(1|on|yes|true))?(\s|$)'; then and thus still uses grep -P
Thanks for spotting that. The patch hadn't been applied in the spec file. :-( cups-filters-1.0.53-5.fc20 should fix it.
Perfect! Thanks, Tim Waugh. Here's hoping the premature boolean introduced in Comment #31 can be reversed.
Petr, thanks for your explanation in comment #42 that it's just using the static argument and not the network input. That's reassuring.
Package cups-filters-1.0.53-5.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing cups-filters-1.0.53-5.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-7297/cups-filters-1.0.53-5.fc20 then log in and leave karma (feedback).
cups-filters-1.0.53-5.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.