[redhat-lspp] Re: CUPS audit record

[Matt Anderson]

Steve Grubb wrote:
> On Tuesday 29 August 2006 18:27, Loulwa Salem wrote:
> 
>>I wanted to let you know that the "auid" field is shown twice, is it going
>>to remain this way?
> 
> 
> The one inside the msg should go away. Userspace apps cannot be trusted to set 
> that correctly.

We talked about this before Steve, mainly on #audit.  The auid reported
in the audit record is the auid of cupsd which isn't relevant.  Your
suggestion at the time was to add auid=N to the text of the record in
order to capture the security relevant auid of the user who submitted
the job.  At your suggestion I used the same code that libaudit uses to
determine the auid, and that is being done by cupsd which is already
part of the TCB so there is no integrity issue here.


>>The other thing .. I am looking at parsing the following types:
>>USER_LABELED_EXPORT
>>LABEL_LEVEL_CHANGE
>>LABEL_OVERRIDE
>>
>>I see multiple variations of the LABEL_LEVEL_CHANGE (as below), is there a
>>way to make the format slightly more standardized so parsing won't be
>>complicated? Or maybe have two different types if the records look that
>>much different. Steve are you parsing those types in your auparse tool?
> 
> 
> If they have the same message type, they should be identical in format. That 
> is the rule for the audit system. I have not looked at the audit messages in 
> cups. Maybe I should do that in a day or two.

I was unaware of this rule.  Is this rule intended to be system wide or
application wide?  I'm pretty sure my USYS_CONFIG message doesn't match
any system wide format.

At enqueue time when I issue the record for a failed export based on the
user not being at the level of the printer -

type=USER_LABELED_EXPORT msg=audit(1155404776.500:188): user pid=4479
uid=0 auid=0 subj=system_u:system_r:cupsd_t:s0-s15:c0.c255 msg='job=133
auid=500 acct= obj=user_u:user_r:user_lpr_t:SystemLow refused, unable to
access printer=localp: exe="/usr/sbin/cupsd" (hostname=orbital,
addr=2.0.0.0, terminal=? res=failed)'

I do not yet have the job-sheet information needed to fill in all the
fields of a successful USER_LABELED_EXPORT message.

type=USER_LABELED_EXPORT msg=audit(1156183150.940:3882): user pid=19179
uid=0 auid=0 subj=root:system_r:cupsd_t:s0-s0:c0.c255 msg='job=405
auid=0 acct=root printer=foo title=cert2.ps
obj=root:system_r:unconfined_t:SystemLow-SystemHigh
label=SystemLow-SystemHigh: exe="/usr/sbin/cupsd" (hostname=orbital,
addr=2.0.0.0, terminal=? res=success)'

I could remove the information from the success case, but I think its
good to know what label a job was exported with.  Upon closer inspection
I now notice that acct= is also blank in the failure case.  The auid is
known, but not the username that the user was operating under.

To make matters worse this is the enqueue access check.  If the printer
was at the right level and the job made it into the queue but then by
the dequeue access check the printer was no longer at the correct level
then this information would be known.  If we remove the enqueue check
then users would not be able to get an error at lpr time and they would
not get any feedback from the system that their job will never print.

I can go through and make most of the messages have the same format.
For the enqueue failure case there would just be blank fields, would
that be parsable?

As for LABEL_LEVEL_CHANGE I cannot come up with any reasonable way to
make those two audits look the same.  I have heard from Eduardo Fleury
that the printer message is also generated when a printer is added.
Given that, the message should not start with the [Config] prefix, would
that be a good differentiator for parsing?

>>type=LABEL_LEVEL_CHANGE msg=audit(1156884529.511:827): user pid=14900 uid=0
>>auid=0 subj=root:staff_r:staff_t:s0-s15:c0.c255 msg='[Config] Security
>>level=mls: exe="/usr/sbin/cupsd" (hostname=localhost.localdomain,
>>addr=2.0.0.0, terminal=? res=success)'
> 
> 
> Shouldn't there be a: was, is kinda thing?  I think it should answer the basic 
> question of: who changed it, from where, what changed, what was it, what is 
> the new value, and was it successful.

All messages that start with [Config] should only be issued once on
server startup.  There is no way to record a previous value.  All the
information you are talking about could occur while the CUPS server is
offline.  If you wanted to capture that you would need a watch on the
/etc/cups/cupsd.conf file.

>>type=LABEL_LEVEL_CHANGE msg=audit(1156884529.515:828): user pid=14900 uid=0
>>auid=0 subj=root:staff_r:staff_t:s0-s15:c0.c255 msg='[Config] printer=LTC
>>uri=usb:/dev/usb/lp0 banners set to classified none has range SystemHigh:
>>exe="/usr/sbin/cupsd" (hostname=localhost.localdomain, addr=2.0.0.0,
>>terminal=? res=success)'
> 
> 
> This looks wrong. Anything that is meaningful should be in name=value format 
> so that parsers can find it.
> 
> Not knowing the context exactly, but something like this, perhaps:
> banners=classified none range=SystemHigh
> 
> I don't know what the none goes to.

classified is the leading banner page, none is the trailing banner.  I
could make that snippet look like this:
banners=classified,none range=SystemHigh

That shouldn't confuse the parser too much since there wouldn't be any
white space between the banners.  It looks like the LABEL_OVERRIDE
messages need to be changed to this format as well.  In those messages
however there are two banner= fields.  The audit record has to capture
what the user suggested, along with what the server ended up using.
Would the parser handle banner= showing up twice?  If not does anyone
have a suggestion as to how to differentiate the two?

-matt