Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 231529 - [LSPP] bogus audit records with cups printing
Summary: [LSPP] bogus audit records with cups printing
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: cups
Version: 5.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Tim Waugh
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2007-03-08 20:57 UTC by Klaus Heinrich Kiwi
Modified: 2007-11-30 22:07 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-05-03 14:44:58 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Klaus Heinrich Kiwi 2007-03-08 20:57:17 UTC
Description of problem:
Some odd behavior related to how cups is auditing some operations:

If the printing failed, wouldn't be better to let the job=? afterwads?
I can't list 'failed' jobs in any way so I just thought this would be the
correct behavior:
type=USER_LABELED_EXPORT msg=audit(1173378615.266:5872): user pid=16552 uid=0
auid=505 subj=system_u:system_r:cupsd_t:s15:c0.c1023 msg='job=289 auid=504 acct=
obj=testuser_u:user_r:user_lpr_t:SystemLow-SystemHigh refused unable to access
printer=TestPrinter: exe="/usr/sbin/cupsd" (,
addr=, terminal=? res=failed)

If I try to print one or more files with the same command, the audit records
generated have all the same 'title', that's the first file title:

-bash-3.1$ lpr -P TestPrinter

type=USER_LABELED_EXPORT msg=audit(1173378789.893:5873): user pid=16552 uid=0
auid=505 subj=system_u:system_r:cupsd_t:s15:c0.c1023 msg='job=290 auid=504
acct=testuser printer=TestPrinter
label=SystemLow-SystemHigh: exe="/usr/sbin/cupsd"
(, addr=, terminal=? res=success)'
type=USER_LABELED_EXPORT msg=audit(1173378791.613:5874): user pid=16552 uid=0
auid=505 subj=system_u:system_r:cupsd_t:s15:c0.c1023 msg='job=290 auid=504
acct=testuser printer=TestPrinter
label=SystemLow-SystemHigh: exe="/usr/sbin/cupsd"
(, addr=, terminal=? res=success)'

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
in the test description
Actual results:

Expected results:
-job=? or no jop field at all when job is canceled due to selinux
-correct job title for each printed file for batch prints

Comment 1 Matt Anderson 2007-03-08 23:38:25 UTC
In your command line you are not listing a title for your job.  Since you are
not specifing CUPS defaults the title of the job to the first filename.  This is
existing CUPS behavior and is the expected result.

lpr -P TestPrinter -T "Super Secret Title"

would result in a similar set of audit messages.  If you look at the banner page
on your output you'll see that the title for your job is listed correctly. 
Recording the title was added as a feature request by customers and is not
required by the security target.

As for incrementing the job number on jobs that get canceled that is also
expected existing behavior.

Comment 2 Tim Waugh 2007-03-09 09:14:18 UTC
Closing (see comment #1).  There is no utility in hiding the job numbers, since
they can be deduced from further jobs.

Comment 3 Steve Grubb 2007-03-09 14:22:04 UTC
Matt, are you saying that the audit messages do not need to say what was
exported? It seems to me that the file being exported has to be identified and
title is optional. Also, is user_lpr_t the correct label for the file?

Comment 4 Matt Anderson 2007-03-09 16:16:12 UTC
The requirement is not that the audit must record the filename or the job title,
these were added to the record at the request of some customers on the
redhat-lspp list.

LSPP only ever talks about the least upper bound of the data.  Since there is no
secure way to get this information and store it in the audit record it was
decided that storing the user's context was the best way to go.  We can securely
determine the user's context and we know their level is able to read the data.

Comment 5 Steve Grubb 2007-03-09 16:21:52 UTC
[Audit1] Auditing procedures, including:
   1. Providing the capability to ensure that all audit records include enough
information to allow the ISSO to determine the date and time of action (e.g.,
common network time), the system locale of the action, the system entity that
initiated or completed the action, the resources involved, and the action involved.

How can you determine the resource involved from that audit message?

Comment 6 Linda Knippers 2007-03-09 16:58:10 UTC
Identifying the information being printed is a problem with cups.  What
if its stdin?  

# cat | lpr 

Comment 7 Steve Grubb 2007-03-09 17:08:26 UTC
># cat | lpr

I bet there could be a config option that disallows reading from stdin. Or even
identifies it as stdin if that mode is used. But the bottom line is that it
should tell what resources are involved in addition to its label.

Comment 8 Tim Waugh 2007-03-09 17:17:16 UTC
Steve: if there were a config option that disallowed reading from stdin, *and*
all the CUPS utilities honoured it, what about just sending an IPP request
(including a document) to the UNIX domain socket with cat?

Any restriction of this sort would need to be done at the SELinux level I think.
 cupsd cannot know for sure *what* file was used, or whether it came from stdin.

Comment 9 Steve Grubb 2007-03-12 22:11:03 UTC
Adding Dan to this bz.

Comment 10 Klaus Heinrich Kiwi 2007-03-22 00:07:38 UTC
 any resolve about this?

Comment 11 Daniel Walsh 2007-03-22 20:01:23 UTC
I am not sure I understand what the problem here is.  I thought the lpr was
reporting the level of the process that executed the print job not the context
of the file being printed,  So if I am at top secret and I 

cat | lpr 

It will print "Top Secret" on the job, correct?


Comment 12 Steve Grubb 2007-03-22 20:07:20 UTC
Its not a question of what's printed on the job, its what is in the audit trail.
The problem is that "" is not in the audit message. If you have the
file, you should be able to correctly identify the file's label.

Comment 13 Daniel Walsh 2007-03-22 20:32:30 UTC
I think this is an unsolvable problem.  Just like the user created a tmp file


I think trying to solve this is a waste of time.

Comment 14 Klaus Heinrich Kiwi 2007-03-22 21:18:41 UTC
Agree with dwalsh and linda. What can we do now this late in the game to audit
titles from stdin or filenames the user has control of.
This makes the title= field worthless. Better is to document it and maybe have
it done in another way in another major release.

Adding Klaus W. in cc as he may have a different opinion.

Comment 15 Klaus Weidner 2007-03-23 16:43:11 UTC
re comment #5, that's not a LSPP requirement, and we've been concentrating on
LSPP/RBAC for the evaluations. I can't comment on what other standards may
require in this case.

I agree with Dan, Linda, and Klaus K that there seems to be no way to reliably
associate print jobs with filesystem objects unless you completely track all
data copying (including in userspace) and rename operations in the audit trail,
and that goes far beyond what's possible in the current design.

Comment 16 George C. Wilson 2007-03-26 20:33:42 UTC
Can this be closed or deferred?

Comment 17 George C. Wilson 2007-04-02 20:19:41 UTC
Steve Grubb is still mulling this one over.

Comment 18 Steve Grubb 2007-04-10 14:37:02 UTC
I think that we want to fix this problem long term, but we can defer it for LSPP
this time. 

For the case where stdin is used, I suppose it could log stdin as the source and
let the site deal with it through operating proceedures. SE Linux can be used to
prevent non-cups utilities from writing to the socket - IOW, fixing this should
not be delayed because there are ways to write it via bash. We'll deal with that
issue separately.

Removing LSPP dependency trackers.

Comment 20 Tim Waugh 2007-05-03 14:44:58 UTC
Steve, cupsd does not know the file name.  It's not just that it can't rely on
it -- it does not know it in the first place.  It does not get told the file
name, and there is no provision in the IPP specification for doing this other
than in the job title.

I'm closing this as CANTFIX.

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