[redhat-lspp] Initial CUPS auditing patch

Janak Desai janak at us.ibm.com
Mon Aug 22 18:15:32 UTC 2005


Matt Anderson wrote:
> Janak,
> 
> Thanks for the feedback.
> 
> Janak Desai wrote:
> 
>> Is it possible to make the message a little more explanatory? That is, 
>> what does it mean when the ClassifyOverride flas is set or unset?
> 
> 
> How about something like:
> 
> CUPS Config: ClassifyOverride is enabled, users can override print banners
> 
> CUPS Config: ClassifyOverride is disabled, users cannot override print 
> banners
> 

That works for me, however, as Steve pointed out, there are other issues
(std format, searchability) that may dictate what the text looks like so
lets punt on this for now.

> 
>>> +#ifdef WITH_AUDIT
>>> +    audit_log(AuditLog, AUDIT_USER, "CUPS Job #%d: being printed on 
>>> \"%s\" with label \"%s\"",
>>> +              id, printer->name, mls_label);
>>> +#endif /* WITH_AUDIT */
>>
>>
>>
>> This audit record is created when the job is submitted. Is it possible 
>> that
>> on the filter side, the CLASSIFICATION environment variable can be
>> changed/overridden/deleted in such a way that affects the actual labels
>> that come out on pages?
> 
> 
> That record is actually getting created in StartJob just before the exec 
> of the filter.  Theoretically the filter could ignore the environment 
> variable, but I don't believe it could get deleted or changed.  Putting 
> the audit record in the filter wouldn't help that anyway since the same 
> malicious filter that is ignoring the environment variable could just as 
> easily audit a fake label.
> 
> Unless a clear need arises I'd like to keep this record in cupsd since 
> the cups architecture is such that filters are supposed to be drop-ins. 
>  If we can avoid patching the filters it will make the patch that much 
> more maintainable.
> 

Ok, sounds good.

-Janak




More information about the Linux-audit mailing list