Q: investigate tighter restrictions in audit_field_valid(...)

[pcmoore]

From an email on the linux-audit mailing list from @pcmoore:

Looking at the original patch and audit_field_valid(), I think we should probably look into tightening up what constitutes "valid" fields.  For example, does it make sense to allow anything but equal/not-equal when comparing AUDIT_SUBJ_TYPE? (note well: this is just one example, there are many more)

[rgbriggs]

Since all AUDITSUBJ and AUDITOBJ fields are text fields, I would assume that equal/not-equal are the only two that make sense. Other text fields for which this applies would be:

• AUDIT_WATCH
• AUDIT_DIR
• AUDIT_FILTERKEY
• AUDIT_EXE

Exceptions are AUDIT{SUBJ{CLR,SEN},OBJLEV{LOW,HIGH} for which a range is implemented.

Others for which only equal/not-equal apply would be:

• AUDIT_LOGINUID_SET
• AUDIT_ARCH
• AUDIT_FSTYPE
• AUDIT_PERM
• AUDIT_FILETYPE
• AUDIT_FIELD_COMPARE

Bitwise ops should be valid for AUDIT_ARG*, and potentially AUDIT_PERS and AUDIT_DEVMINOR.

The remaining should be equal/not-equal and any greater or less than.

There is some coverage in userspace lib/libaudit.c:audit_rule_fieldpair_data(), but not comprehensive.

[rgbriggs]

2019-05-06: Posted v1: https://www.redhat.com/archives/linux-audit/2019-May/msg00002.html

[rgbriggs]

Posted v2: https://www.redhat.com/archives/linux-audit/2019-May/msg00006.html

[rgbriggs]

2019-05-22: Posted v3: https://www.redhat.com/archives/linux-audit/2019-May/msg00036.html

Staged in audit/next: ecc68904a3e5 ("audit: re-structure audit field valid checks")

[rgbriggs]

Merged for v5.3-rc1 in 61fc5771f5e729a2ce235af42f69c8506725e84a

[rgbriggs]

Please close. Upstream in Linux 5.3 4d856f72c10e