Red Hat Bugzilla – Bug 231529
[LSPP] bogus audit records with cups printing
Last modified: 2007-11-30 17:07:42 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=9.8.234.172, 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 -bash-3.1$ 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 obj=testuser_u:user_r:user_lpr_t:SystemLow-SystemHigh label=SystemLow-SystemHigh: exe="/usr/sbin/cupsd" (hostname=zaphod.ltc.br.ibm.com, addr=9.8.234.172, 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 obj=testuser_u:user_r:user_lpr_t:SystemLow-SystemHigh label=SystemLow-SystemHigh: exe="/usr/sbin/cupsd" (hostname=zaphod.ltc.br.ibm.com, addr=9.8.234.172, terminal=? res=success)' Version-Release number of selected component (if applicable): cups-1.2.4-11.5.el5 How reproducible: always 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
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.
Closing (see comment #1). There is no utility in hiding the job numbers, since they can be deduced from further jobs.
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?
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.
[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?
Identifying the information being printed is a problem with cups. What if its stdin? # cat foo.ps | lpr
># 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.
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.
Adding Dan to this bz.
RedHat, any resolve about this?
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? Dan
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.
I think this is an unsolvable problem. Just like the user created a tmp file called cp secret.ps noneofyourbusiness.ps lpr noneofyourbusiness.ps rm noneofyourbusiness.ps I think trying to solve this is a waste of time.
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.
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.
Can this be closed or deferred?
Steve Grubb is still mulling this one over.
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.
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.