[PATCH 4th revision] Add SELinux context support to AUDIT target

[Eric Paris]

On Mon, Jun 20, 2011 at 10:21 AM, Mr Dash Four
<mr.dash.four at googlemail.com> wrote:
>
>> Do you think this should be hardcoded to be obj? Would we ever log the
>> subj? Or should obj be part of the function name to make it clear which
>> piece is getting logged?
>>
>
> I thought of that, though I don't know what variety of option names would be
> there to be used with that function.
>
> If there is a need to use something other than "obj", like, "subj" or even
> "tcontext" or "scontext" for example, then I would favour passing the option
> name as function parameter - something like "void audit_log_secctx(struct
> audit_buffer *ab, char *secname, u32 secid)" or even "void
> audit_log_secctx(struct audit_buffer *ab, int secname, u32 secid)" (secname
> here being one of 0, 1, 2 ... corresponding to "obj", "subj" etc).
>
> Similar approach is already used in audit.c - in audit_log_config_change for
> example:
>
> static int audit_log_config_change(char *function_name, int new, int old,
> uid_t loginuid, u32 sessionid, u32 sid, int allow_changes)
> {
>   struct audit_buffer *ab;
>   int rc = 0;
>
>   ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_CONFIG_CHANGE);
>   audit_log_format(ab, "%s=%d old=%d auid=%u ses=%u", function_name, new,
> old, loginuid, sessionid);

Hard code for now.  %s in audit record building is the devil since
there is no enforcement of audit's rather 'special' string encoding
rules.  If we need another name later we'll cross that bridge when we
get there, possibly with another helper function and pushing the %s to
a static function inside audit.  I will not willing expose %s to code
outside of audit.c.

Acked-by: Eric Paris <eparis at redhat.com>