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 -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
