Adding audit support to dpkg

[Richard Guy Briggs]

On 2020-08-04 00:50, Guillem Jover wrote:
> Hi!
> 
> We got a request to add audit support to dpkg [R], and as initially
> mentioned on the bug report it seems the AUDIT_SOFTWARE_UPDATE format
> does not appear to be documented, so while looking into all this, got
> several questions.
> 
>   [R] <https://bugs.debian.org/931748>
> 
> >From the rpm implementation and auparse/normalize.c I gather that it
> would contain the following fields, applied to dpkg:
> 
>   * primary field would be "sw" which would contain something like
>     «"nginx_1.18.0-5_amd64"», I assume that the format differing from
>     the one in rpm is fine as that would be keyed on the next field?
>   * secondary field would be "sw_type" which would be «dpkg».
>   * field "op", which would contain entries different to rpm, such as
>     «unpack», «configure», «install», «remove», «purge», not sure if
>     that might be a problem?
>   * field "key_enforce", I take to denote whether a cryptographic
>     verification has been performed on the .deb archive? With values
>     «0» or «1». (This would depend on whether debsig-verify(1) has
>     been configured to be executed or not.)
>   * field "gpg_res", to denote whether the aforementioned verification
>     succeeded or not? With values «0» or «1». And while dpkg can indeed
>     use GnuPG to verify signatures from archives, the name feels too
>     implementation specific, perhaps it could be renamed so that it
>     would not be very confusing, in case someone implements a check
>     based on say x509 certificates?
>   * field "root_dir", to denote the installation root directory, which
>     would map to dpkg --instdir value, with a value such as «"/"».
> 
> Anything else I might have missed or might be worth taking into
> account while adding the support?

I don't see any glaring issues with what you propose.  In particular,
the op field seems fine, sticking to single words with no spaces.

You might review these two documents to check for details:
	https://github.com/linux-audit/audit-documentation/wiki/SPEC-Writing-Good-Events

And check here to see if there are already fields that are set aside for
these uses and make sure there isn't a conflict of type or meaning for
an existing one:
	https://github.com/linux-audit/audit-documentation/blob/master/specs/fields/field-dictionary.csv

Other documents in this set might be helpful:
	https://github.com/linux-audit/audit-documentation/wiki

> Guillem

- RGB

--
Richard Guy Briggs <rgb at redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635