* Adding audit support to dpkg
@ 2020-08-03 22:50 Guillem Jover
2020-08-04 12:22 ` Richard Guy Briggs
2020-08-04 13:20 ` Steve Grubb
0 siblings, 2 replies; 3+ messages in thread
From: Guillem Jover @ 2020-08-03 22:50 UTC (permalink / raw)
To: linux-audit
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?
Thanks,
Guillem
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Adding audit support to dpkg
2020-08-03 22:50 Adding audit support to dpkg Guillem Jover
@ 2020-08-04 12:22 ` Richard Guy Briggs
2020-08-04 13:20 ` Steve Grubb
1 sibling, 0 replies; 3+ messages in thread
From: Richard Guy Briggs @ 2020-08-04 12:22 UTC (permalink / raw)
To: Guillem Jover; +Cc: linux-audit
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@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
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Adding audit support to dpkg
2020-08-03 22:50 Adding audit support to dpkg Guillem Jover
2020-08-04 12:22 ` Richard Guy Briggs
@ 2020-08-04 13:20 ` Steve Grubb
1 sibling, 0 replies; 3+ messages in thread
From: Steve Grubb @ 2020-08-04 13:20 UTC (permalink / raw)
To: linux-audit; +Cc: Guillem Jover
Hello,
On Monday, August 3, 2020 6:50:49 PM EDT Guillem Jover wrote:
> 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?
sure
> * secondary field would be "sw_type" which would be «dpkg».
yes
> * field "op", which would contain entries different to rpm, such as
> «unpack», «configure», «install», «remove», «purge», not sure if
> that might be a problem?
>From compliance perspective, only install, update, and remove are relevant.
You want to know when something gets added or removed because they could add
setuid programs or daemons that autostart. Secondly, you may be tracking
current versions to resolve CVE's. So, for that purpose, you also want to
know when something gets updated. Nothing else matters.
How does unpack differ from install? How does purge differ from remove? There
is another event type, AUDIT_USYS_CONFIG, that tracks user space configuration
changes. However, this is rarely used. Instead, what is done is watches are
placed on important configuration files to see if anything opens the file for
modiciation. So, would there be any need to have a configuration option for
SOFTWARE_UPDATE?
> * 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.)
This denotes whether signature checks is being enforced. This is independent
from whether or not the signature is valid. IOW, if a signature (next field)
is invalid, will the package be allowed in anyway?
> * 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?
This field is whether or not the package passes its verification with a hash,
gpg signature, x509 certificate, or any other integrity scheme.
> * field "root_dir", to denote the installation root directory, which
> would map to dpkg --instdir value, with a value such as «"/"».
Yes. Rpms can be relocatable to anywhere. So, this is to document what part
of the system the package will affect.
> Anything else I might have missed or might be worth taking into
> account while adding the support?
I think that's pretty much it. If you wanted to see an example of the code,
it is here:
https://github.com/rpm-software-management/rpm/blob/master/plugins/
audit.c#L80
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-08-04 13:20 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-03 22:50 Adding audit support to dpkg Guillem Jover
2020-08-04 12:22 ` Richard Guy Briggs
2020-08-04 13:20 ` Steve Grubb
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).