[redhat-lspp] Re: CUPS audit record

[Matt Anderson]

Steve Grubb wrote:
> On Wednesday 30 August 2006 16:41, Matt Anderson 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.
> 
> 
> Ok, that is the sender's loginuid. That is "sauid".

That sounds good, I'll update the record to use that instead.

>>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.
> 
> 
> acct is used when you do not know the uid. Example - pre-authentication. uid 
> is always preferred since that means they've been authenticated.

I think CUPS is a case where acct would be preferable.  The auid is
known, and will be recorded, but acct will correspond with the user
field that shows up on paper.

>>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?
> 
> 
> Sure. Use "?" so as to not consume diskspace. The easiest way to create 
> uniformity is to create a function that takes all the parameters being logged 
> as an argument. Then call it instead.

'?' works for me.

>>>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.
> 
> 
> Everything should have a default value - even at startup. :)
>
>
>>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.
> 
> 
> Watching the file tells you the file changed, but not what changed.

Unfortunately Classification is only configurable by editing the config
file.  If the admin could use the lpadmin command to adjust the value
then I'd be right there with you on what should be captured.  In this
case its just a known unknown, so I'd like to avoid implying anything else.

>>classified is the leading banner page, none is the trailing banner.  I
>>could make that snippet look like this:
>>banners=classified,none range=SystemHigh
> 
> 
> You mean header & footer? If so, you can have that as the name for each one.
> 
> 
>>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.
> 
> 
> I'd try to avoid having the same field in a record twice.
> 
> 
>>The audit record has to capture what the user suggested, along with what the
>>server ended up using. 
> 
> 
> user-header, final-header?
> 
> 
>>Would the parser handle banner= showing up twice?
> 
> 
> Not very well.
> 
> 
>>If not does anyone have a suggestion as to how to differentiate the two?
> 
> 
> Give separate names.

Thats what I was trolling for ;)  How about we split the difference.
banner=none,none final-banner=mls,none  The alternative is a bit
lengthy: user-header=none user-footer=none final-header=mls
final-footer=none

-matt