On 2019-07-12 14:02, Stephen Smalley wrote:
> On 7/12/19 1:50 PM, James Morris wrote:
> > On Fri, 12 Jul 2019, Nicholas Franck wrote:
> >
This aggressive trimming dropped a bit of helpful context:
+++ b/security/lsm_audit.c
@@ -229,9 +229,26 @@ static void dump_common_audit_data(struct
audit_buffer *ab,
case LSM_AUDIT_DATA_IPC:
audit_log_format(ab, " key=%d ", a->u.ipc_id);
break;
- case LSM_AUDIT_DATA_CAP:
- audit_log_format(ab, " capability=%d ", a->u.cap);
> > > + case LSM_AUDIT_DATA_CAP: {
> > > + const struct inode *inode;
> > > +
> > > + if (a->u.cap_struct.cad) {
> > > + switch (a->u.cap_struct.cad->type) {
> > > + case CAP_AUX_DATA_INODE: {
> > > + inode = a->u.cap_struct.cad->u.inode;
> > > +
> > > + audit_log_format(ab, " dev=");
> > > + audit_log_untrustedstring(ab,
> > > + inode->i_sb->s_id);
> > > + audit_log_format(ab, " ino=%lu",
> > > + inode->i_ino);
> > > + break;
> > > + }
> > > + }
> > > + }
> > > + audit_log_format(ab, " capability=%d ", a->u.cap_struct.cap);
> > > break;
+ }
case LSM_AUDIT_DATA_PATH: {
struct inode *inode;
> >
> > Will this break any existing userspace log parsers?
>
> I'm hoping not given that we are only adding auxiliary fields and those are
> already defined for other AVC audit messages. ausearch appeared to work
> fine. Added the linux-audit mailing list to the cc line to get their view.
Generally, additional or optional fields should only be added after
existing ones. Also, generally, fields should not be optional, but this
is tricky since it gobbles network and cpu bandwidth and disk space and
there are lots of precedents to contradict this.
- RGB
--
Richard Guy Briggs <rgb@xxxxxxxxxx>
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
