Bug 220080 - lpq is not honoring MLS restrictions
Summary: lpq is not honoring MLS restrictions
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy   
(Show other bugs)
Version: 5.0
Hardware: All Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Daniel Walsh
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-12-18 19:48 UTC by Matt Anderson
Modified: 2007-11-30 22:07 UTC (History)
6 users (show)

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


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

Description Matt Anderson 2006-12-18 19:48:49 UTC
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 19:53:54 UTC
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 18:29:53 UTC
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-20 00:40:07 UTC
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 18:27:43 UTC
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 18:44:46 UTC
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 18:51:22 UTC
Cups is not allowed to do this. It must log to the audit system.

Comment 8 Daniel Walsh 2006-12-20 18:58:32 UTC
Fixed in selinux-policy-2.4.6-16

Comment 10 RHEL Product and Program Management 2007-02-08 01:52:42 UTC
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.