Bug 231529 - [LSPP] bogus audit records with cups printing
[LSPP] bogus audit records with cups printing
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: cups (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Tim Waugh
David Lawrence
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2007-03-08 15:57 EST by Klaus Heinrich Kiwi
Modified: 2007-11-30 17:07 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-05-03 10:44:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Klaus Heinrich Kiwi 2007-03-08 15:57:17 EST
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" (hostname=zaphod.ltc.br.ibm.com,
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 Audit_ok.ps SystemLow_ok.ps

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 title=Audit_ok.ps
label=SystemLow-SystemHigh: exe="/usr/sbin/cupsd"
(hostname=zaphod.ltc.br.ibm.com, 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 title=Audit_ok.ps
label=SystemLow-SystemHigh: exe="/usr/sbin/cupsd"
(hostname=zaphod.ltc.br.ibm.com, 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 18:38:25 EST
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" Audit_ok.ps SystemLow_ok.ps

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 04:14:18 EST
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 09:22:04 EST
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 11:16:12 EST
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 11:21:52 EST
[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 11:58:10 EST
Identifying the information being printed is a problem with cups.  What
if its stdin?  

# cat foo.ps | lpr 
Comment 7 Steve Grubb 2007-03-09 12:08:26 EST
># cat foo.ps | 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 12:17:16 EST
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 18:11:03 EDT
Adding Dan to this bz.
Comment 10 Klaus Heinrich Kiwi 2007-03-21 20:07:38 EDT
 any resolve about this?
Comment 11 Daniel Walsh 2007-03-22 16:01:23 EDT
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 secret.ps | lpr 

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

Comment 12 Steve Grubb 2007-03-22 16:07:20 EDT
Its not a question of what's printed on the job, its what is in the audit trail.
The problem is that "secrets.ps" 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 16:32:30 EDT
I think this is an unsolvable problem.  Just like the user created a tmp file

cp secret.ps noneofyourbusiness.ps
lpr noneofyourbusiness.ps 
rm noneofyourbusiness.ps

I think trying to solve this is a waste of time.
Comment 14 Klaus Heinrich Kiwi 2007-03-22 17:18:41 EDT
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 12:43:11 EDT
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 16:33:42 EDT
Can this be closed or deferred?
Comment 17 George C. Wilson 2007-04-02 16:19:41 EDT
Steve Grubb is still mulling this one over.
Comment 18 Steve Grubb 2007-04-10 10:37:02 EDT
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 10:44:58 EDT
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.