Bug 220080 - lpq is not honoring MLS restrictions
lpq is not honoring MLS restrictions
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-18 14:48 EST by Matt Anderson
Modified: 2007-11-30 17:07 EST (History)
6 users (show)

See Also:
Fixed In Version: RC
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-02-07 20:52:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Proposed fix (74.52 KB, patch)
2006-12-18 14:53 EST, Matt Anderson
no flags Details | Diff

  None (edit)
Description Matt Anderson 2006-12-18 14:48:49 EST
Description of problem:
When CUPS is configured in LSPP mode it no longer enforces the MLS restrictions
while listing jobs

How reproducible:
Every time.

Steps to Reproduce:
1. newrole -l s1
2. lpr /etc/password
3. exit the s1 shell going back to s0
4. lpq  - seeing the pending job from a higher level
  
Actual results:
You can see jobs at all levels

Expected results:
You should only be able to see jobs at your level and below
Comment 1 Matt Anderson 2006-12-18 14:53:54 EST
Created attachment 143937 [details]
Proposed fix

This appears to be a side effect of adding the job->scon check to the if
statement in question.

- if (selinuxcheck && (strncmp(job->scon, UNKNOWN_SL, strlen(UNKNOWN_SL)) !=
0))
+ if ((selinuxcheck == 1) && (strncmp(job->scon, UNKNOWN_SL,
strlen(UNKNOWN_SL)) != 0))
Comment 3 Steve Grubb 2006-12-19 13:29:53 EST
We don't understand what this patch provides. The above 1 line change has no
effect on the program.
Comment 4 Matt Anderson 2006-12-19 19:40:07 EST
Sorry about that bogus patch, there was some confusion in various test
environments which seemed to make a previously solved problem reappear.

In the version of cups provided with RHEL5rcs3 cups-1.2.4-11.4.el5 there is not
a problem with lpq, or cups.

There is an selinux-policy issue that needs to be addressed still:
allow sysadm_lpr_t print_spool_t:file read;

Which will allow the sysadm role the ability to see other's jobs and therefore
manage the queue.
Comment 5 Daniel Walsh 2006-12-20 13:27:43 EST
My reading of current policy would allow this.

allow sysadm_lpr_t print_spool_t:file read;

Which version of policy and could you attach the AVC's.
Comment 6 Linda Knippers 2006-12-20 13:44:46 EST
I'm looking at the system where mra was doing his testing.
He was running selinux-policy-mls-2.4.6-12.el5.
He had a little policy module with the above in it and the functionality
was working but when I unloaded the module and tried an lpq from sysadm_r,
I get this in the /var/log/cups/errors_log file.  Cups logs its own AVCs 
so they don't end up in the audit log.

cups:  denied  { read } for 
scontext=staff_u:sysadm_r:sysadm_lpr_t:s0-s15:c0.c1023
tcontext=system_u:object_r:print_spool_t:s15:c0.c1023 tclass=file

As a staff_u/staff_r user I can see more jobs than I can as sysadm_r
after a newrole.
Comment 7 Steve Grubb 2006-12-20 13:51:22 EST
Cups is not allowed to do this. It must log to the audit system.
Comment 8 Daniel Walsh 2006-12-20 13:58:32 EST
Fixed in selinux-policy-2.4.6-16
Comment 10 RHEL Product and Program Management 2007-02-07 20:52:42 EST
A package has been built which should help the problem described in 
this bug report. This report is therefore being closed with a resolution 
of CURRENTRELEASE. You may reopen this bug report if the solution does 
not work for you.

Note You need to log in before you can comment on or make changes to this bug.