Bug 516078
| Summary: | setroubleshoot: SELinux is preventing python (hplip_t) "read" var_lib_t. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tom London <selinux> |
| Component: | selinux-policy | Assignee: | Miroslav Grepl <mgrepl> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 11 | CC: | dwalsh, fabian.kanngiesser, ingimar, jkubin, mgrepl, twaugh, west |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | setroubleshoot_trace_hash:cf3c4943363481d3dad61ee835f22d718a75b7ad444a5e014f8dbe41ad26cb1f | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-09-15 12:03:50 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 513911, 517000 | ||
|
Description
Tom London
2009-08-06 16:19:57 UTC
The fix is to use this in cups.fc: /var/lib/hp(/.*)? gen_context(system_u:object_r:hplip_etc_t,s0) This affects Fedora 11 as well as rawhide. Ok I am removing hplip_etc_t and type alias to hplip_var_lib_t /var/lib/hp(/.*)? gen_context(system_u:object_r:hplip_var_lib_t,s0) Currently no domain can write there. Miroslav can you make a similar change to F11. Tim does any domain need to be able to write to this label? Fixed in selinux-policy-3.6.26-7.fc12.noarch Only hplip_t needs to write to hplip_var_lib_t. (So will /etc/hp/* be labelled hplip_var_lib_t now as well?) Yes, But isn't /etc/hp/* going away, or do we need two different labeles? /etc/hp/* read/only by hplip_t and /var/lib/hp/* r/w by hplip_t No, /etc/hp/* (read-only) is staying where it is. /var/lib/hp/* is different, and is read-write. Two different labels would be best if that's not too fine-grained. Fixed in selinux-policy-3.6.26-9.fc12.src.rpm Miroslav, just add type hplip_var_lib_t; files_type(hplip_var_lib_t) manage_files_pattern(hplip_t, hplip_var_lib_t, hplip_var_lib_t) manage_lnk_files_pattern(hplip_t, hplip_var_lib_t, hplip_var_lib_t) /var/lib/hp(/.*)? gen_context(system_u:object_r:hplip_var_lib_t,s0) Fixed in selinux-policy-3.6.12-75.fc11 *** Bug 517729 has been marked as a duplicate of this bug. *** I'm running rawhide, so I can't test fc11. "Works for me" with the fc12 package. I'm running FC11 incorporating selinux-policy 3.6.12-81.fc11 - a related SELinux message appears, although the printer does in fact print on demand, even with SELinux policy currently enforcing. Here is the message:
**Summary:
SELinux is preventing python (hplip_t) "write" usr_t.
**Detailed Description
SELinux denied access requested by python. It is not expected that this access is required by python 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.
**Allowing Access
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.
**Additional Information
Source Context: system_u:system_r:hplip_t:s0
Target Context: unconfined_u:object_r:usr_t:s0
Target Objects: /usr/share/hplip/prnt [ dir ]
Source: python
Source Path: /usr/bin/python
Port: <Unknown>
Host: localhost.localdomain
Source RPM Packages: python-2.6-9.fc11
Target RPM Packages:
Policy RPM: selinux-policy-3.6.12-81.fc11
Selinux Enabled: True
Policy Type: targeted
MLS Enabled: True
Enforcing Mode: Enforcing
Plugin Name: catchall
Host Name: localhost.localdomain
Platform: Linux localhost.localdomain 2.6.30.5-43.fc11.x86_64 #1 SMP Thu Aug 27 21:39:52 EDT 2009 x86_64 x86_64
Alert Count: 108
First Seen: Tue 01 Sep 2009 07:08:06 AM PDT
Last Seen: Tue 08 Sep 2009 09:19:31 AM PDT
Local ID: 3b3261c6-7166-4a59-810d-199abffde082
Line Numbers:
Raw Audit Messages :
node=localhost.localdomain type=AVC msg=audit(1252426771.556:128): avc: denied { write } for pid=3209
comm="python" name="prnt" dev=dm-0 ino=4850285 scontext=system_u:system_r:hplip_t:s0
tcontext=unconfined_u:object_r:usr_t:s0 tclass=dir
node=localhost.localdomain type=SYSCALL msg=audit(1252426771.556:128): arch=c000003e syscall=2 success=no
exit=-13 a0=7fff12cefe10 a1=2c1 a2=81ed a3=280ad70 items=0 ppid=3191 pid=3209 auid=4294967295 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="python" exe="/usr/bin/python"
subj=system_u:system_r:hplip_t:s0 key=(null)
I'm running FC11 incorporating selinux-policy 3.6.12-81.fc11 - a related SELinux message appears, although the printer does in fact print on demand, even with SELinux policy currently enforcing. Here is the message:
**Summary:
SELinux is preventing python (hplip_t) "write" usr_t.
**Detailed Description
SELinux denied access requested by python. It is not expected that this access is required by python 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.
**Allowing Access
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.
**Additional Information
Source Context: system_u:system_r:hplip_t:s0
Target Context: unconfined_u:object_r:usr_t:s0
Target Objects: /usr/share/hplip/prnt [ dir ]
Source: python
Source Path: /usr/bin/python
Port: <Unknown>
Host: localhost.localdomain
Source RPM Packages: python-2.6-9.fc11
Target RPM Packages:
Policy RPM: selinux-policy-3.6.12-81.fc11
Selinux Enabled: True
Policy Type: targeted
MLS Enabled: True
Enforcing Mode: Enforcing
Plugin Name: catchall
Host Name: localhost.localdomain
Platform: Linux localhost.localdomain 2.6.30.5-43.fc11.x86_64 #1 SMP Thu Aug 27 21:39:52 EDT 2009 x86_64 x86_64
Alert Count: 108
First Seen: Tue 01 Sep 2009 07:08:06 AM PDT
Last Seen: Tue 08 Sep 2009 09:19:31 AM PDT
Local ID: 3b3261c6-7166-4a59-810d-199abffde082
Line Numbers:
Raw Audit Messages :
node=localhost.localdomain type=AVC msg=audit(1252426771.556:128): avc: denied { write } for pid=3209
comm="python" name="prnt" dev=dm-0 ino=4850285 scontext=system_u:system_r:hplip_t:s0
tcontext=unconfined_u:object_r:usr_t:s0 tclass=dir
node=localhost.localdomain type=SYSCALL msg=audit(1252426771.556:128): arch=c000003e syscall=2 success=no
exit=-13 a0=7fff12cefe10 a1=2c1 a2=81ed a3=280ad70 items=0 ppid=3191 pid=3209 auid=4294967295 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="python" exe="/usr/bin/python"
subj=system_u:system_r:hplip_t:s0 key=(null)
Could the write be caused by python compilation? I don't know, Daniel. My installation is vanilla Fedora 11. BTW, I apologize for the double-posting. Are there python scripts in /usr/share/hplip/prnt If you simply run #python /usr/share/hplib/prnt/*py It should generate all of the compiled python code and stop this AVC if this is the cause. Thanks, Daniel. I infer from your Comment #16 that .../prnt/*py should have been run (although 'hplip' is what I think you meant). I also infer from $yum info hplip that hplip-3.9.8-12.fc11 is "available" (meaning, I believe, not "yum installed") I also infer from "locate hplip | grep 3.9.8" that the hplip I am using is 3.9.8. These inferences lead me to conclude (tentatively) that my installation is not as "vanilla" as I thought. Having now run #python /usr/share/hplip/prnt/*py, the message SELinux is preventing python (hplip_t) "write" usr_t. still appears. However, having now run "yum install hplip", the AVC no longer appears. It appears that some other details needed attention - although I will not speculate about what they are. So thanks very much for your help. My problem is resolved. Not sure how, but who am I to argue. :^) I guess my main point was that had I been more rigorous in relying on the yellowdog updater (modified), I would not have had any difficulty to begin with. *** Bug 559945 has been marked as a duplicate of this bug. *** |