Description of problem: SELinux denied access requested by hpijs. It is not expected that this access is required by hpijs and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Version-Release number of selected component (if applicable): Source RPM Packages: hpijs-1.6.7-4.1.el5_2.4 Target RPM Packages: Policy RPM: selinux-policy-2.4.6-203.el5 Selinux Enabled: TruePolicy Type: targetedMLS Enabled: TrueEnforcing Mode: Enforcing Plugin Name: catchall Host Name: reclus2 Platform: Linux reclus2 2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008 x86_64 x86_64 Alert Count: 8 First Seen: Fri 23 Jan 2009 02:14:28 PM CET Last Seen: Sat 31 Jan 2009 02:43:52 PM CET How reproducible: Any print from cups to hpijs now raises an SELinux alert, but the print job is run: You can generate a local policy module to allow this access - see FAQ Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report against this package. This did not happen until the 5.3 updates if I remember correctly. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: Raw Audit Messages : host=reclus2 type=AVC msg=audit(1233409432.287:1672): avc: denied { read write } for pid=22160 comm="hpijs" path="socket:[539637]" dev=sockfs ino=539637 scontext=system_u:system_r:hplip_t:s0-s0:c0.c1023 tcontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tclass=unix_stream_socket host=reclus2 type=AVC msg=audit(1233409432.287:1672): avc: denied { read write } for pid=22160 comm="hpijs" path="socket:[539637]" dev=sockfs ino=539637 scontext=system_u:system_r:hplip_t:s0-s0:c0.c1023 tcontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tclass=unix_stream_socket host=reclus2 type=AVC msg=audit(1233409432.287:1672): avc: denied { read write } for pid=22160 comm="hpijs" path="socket:[539638]" dev=sockfs ino=539638 scontext=system_u:system_r:hplip_t:s0-s0:c0.c1023 tcontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tclass=unix_stream_socket host=reclus2 type=SYSCALL msg=audit(1233409432.287:1672): arch=c000003e syscall=59 success=yes exit=0 a0=11b5ebe0 a1=11b5e190 a2=11b5daa0 a3=8 items=0 ppid=22159 pid=22160 auid=4294967295 uid=4 gid=7 euid=4 suid=4 fsuid=4 egid=7 sgid=7 fsgid=7 tty=(none) ses=4294967295 comm="hpijs" exe="/usr/bin/hpijs" subj=system_u:system_r:hplip_t:s0-s0:c0.c1023 key=(null)
Most likely a leaked file descriptor in cups. Can be safely ignored. You can add policy to allow this via audit2allow -M
Resolved by running as root: cat /var/log/audit/audit.log | audit2allow -M local semodule -i local.pp with local.te: # more local.te module local 1.0; require { type hplip_t; type cupsd_t; class unix_stream_socket { read write }; } #============= hplip_t ============== allow hplip_t cupsd_t:unix_stream_socket { read write }; Printing no longer provokes alerts. Thanks.
I also am encountering an AVC violation accessing a file from hplip_t on Fedora 11 stable updated to today's version. It happens when I print to a locally attached HP inkjet printer using hpijs drivers. Who maintains the selinux stuff for these printer drivers???? Summary SELinux is preventing python (hplip_t) "open" security_t. ... Same type of fix worked for me, but in my case local.te has the following, slightly different stuff: ----------- module local 1.0; require { type hplip_t; type security_t; class file read; } #============= hplip_t ============== allow hplip_t security_t:file read;
My previous comment applied to a usb-connected HP printer. However, I have another HP printer (Officejet Pro L7780), and when I set that up I got additional AVC errors on file open, write, and doing execmem calls when printing the standard CUPS test page. To reproduce that bug, set up a socket://machineIP:9100 connection to an HP OfficeJet Pro L7780 using the CUPS interface. The driver to use is the one that comes with CUPS called HP OfficeJet Pro L7700 Foomatic/hpijs. After the printer is set up, print the standard CUPS test page. You will get an AVC violation and page will fail to print correctly, with errors in the printer log. After processing with audit2allow, etc. the local.te file I needed to make a policy module that will fix both the above problem and this one is as follows. I would appreciate it if the Fedora SELinux crew could add this to the hplip package. ----------------- module local 1.0; require { type unconfined_t; type security_t; type hplip_t; type user_home_t; type unconfined_execmem_t; class file { execmod open read }; class capability2 mac_admin; } #============= hplip_t ============== allow hplip_t security_t:file open; allow hplip_t security_t:file read; #============= unconfined_execmem_t ============== allow unconfined_execmem_t user_home_t:file execmod; #============= unconfined_t ============== allow unconfined_t self:capability2 mac_admin;
David: please see bug #507694 for the Fedora 11 bug from comment #3. I'll file a separate bug for your report in comment #4. Thanks for letting us know. (*This* bug is for Red Hat Enterprise Linux.)
I don't think this is file descriptor leakage. cupsd legitimately uses pipes to communicate with filters.
Tim, are you sure, since we do not see this with Fedora or Rawhide policy? Roger are you updated to the RHEL5.4 policy? Do you still see the AVC's there? David, I don't think you are reporting a bug about a RHEL5 type system. If this is a Fedora problem please open a separate bug.
Fixed in selinux-policy-2.4.6-260.el5
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0182.html