[Fwd: Re: audit]

[Steve Grubb]

Hello,

I created the audit patch. I'll see if I can address some off these questions.

On Tuesday 06 September 2005 05:58, Peter Vrabec wrote:
> I'm look again and agin on auditing chages and I discover some IMO
> strange things in this changes. I'm just starting reading
> documetation for auditing support so please correct me if I'm wrong.
>
> [src]$ grep AUDIT_ *c | awk '{ print $3}' | sort | uniq -c
>      129 (AUDIT_USER_CHAUTHTOK,
>
> Hmm .. *all places* where logging auditing records are injected are
> reported as AUDIT_USER_CHAUTHTOK .. even from error handling (?!?). Is it
> realy correct ?

Yes. The audit system right now is trying to standardize the messages. Some 
may not be an exact fit and may change if needed. Because pam is so tightly 
tied to authentication of users and allowing the change of account 
attributes, the naming is pamish.

We are following CAPP guidelines which basically state that an audit event 
should show: who made the changes, to what account, when, what the operation 
was, and the outcome. So for the most part, nearly everything shadow utils 
does is changing the authentication tokens in pam terminology. The outcome of 
the operation is stated as failure in the event of error handling. But the 
admin needs to know what was attempted.

> First from edge .. chage.c:
>
>          if (!amroot && !lflg) {
>                  fprintf (stderr, _("%s: Permission denied.\n"), Prog);
> #ifdef WITH_AUDIT
>                  audit_logger (AUDIT_USER_CHAUTHTOK, Prog, "change age",
> NULL, getuid (), 0);
> #endif
>                  exit (E_NOPERM);
>          }
>
> In this place auditing comment is "change age" like on case changing user
> account age but it is *error* report *not* performing this chage.
> Many other places where was injected audit_logger() are very simillar.

What would be a better description of the operation? We cannot get too 
descriptive as the shadow utils patch has about 325 messages added for 
auditing. I also need the text to be short as each audit message consumes 
disk space. So we are trying to be sensitive to that as well.

> >From libadit.h:
>
> #define AUDIT_USER_AUTH         1100    /* User space authentication */
> #define AUDIT_USER_ACCT         1101    /* User space acct change */
> #define AUDIT_USER_MGMT         1102    /* User space acct management */
> #define AUDIT_CRED_ACQ          1103    /* User space credential acquired
> */ #define AUDIT_CRED_DISP         1104    /* User space credential
> disposed */ #define AUDIT_USER_START        1105    /* User space session
> start */ #define AUDIT_USER_END          1106    /* User space session end
> */ #define AUDIT_USER_AVC          1107    /* User space avc message */
> #define AUDIT_USER_CHAUTHTOK    1108    /* User space acct attr changed */
> #define AUDIT_USER_ERR          1109    /* User space acct state err */
> #define AUDIT_CRED_REFR         1110    /* User space credential refreshed
> */ #define AUDIT_USYS_CONFIG       1111    /* User space system config
> change */
>
> On first look on this list loging all auditing records as
> AUDIT_USER_CHAUTHTOK is incorrect.

Remember this is pamish. We may need a new message type for adding and 
deleting a user account or group. That make more sense to me.

> Probaly using "usedadd -D <other_options>" will be good report as
> AUDIT_USYS_CONFIG (?).

This is for changes to the system config like hwclock that are mandated by the  
CAPP specification.

> Succesfull changing account propertiees as 
> AUDIT_USER_ACCT (what about changing group properties ?).

I didn't see any properties other than adding a user to a group. This should 
be recorded from the user's perspective as changes to the account.

> Probaly start/stop su, login, newgrp session will be good mark as
> AUDIT_USER_START/AUDIT_USER_END (?).

Yes. I don't think newgrp has session start/end, but it probably should.

> Questions like above after spending more time will be probably much more.

Please cc me on these questions as I can help explain what was done. There is 
also an audit mail list just in case you are interested. 
www.redhat.com/mailman/listinfo/linux-audit. I'm cc'ing this to that mail 
list since it looks like I may have a few action items.

Hope this helps...

-Steve