Bug 231529

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.