Bug 905179 - audit rules with -F "auid!=4294967295" return EINVAL
audit rules with -F "auid!=4294967295" return EINVAL
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
Unspecified Unspecified
urgent Severity high
: ---
: ---
Assigned To: Richard Guy Briggs
Fedora Extras Quality Assurance
Depends On:
Blocks: 853068
  Show dependency treegraph
Reported: 2013-01-28 13:58 EST by Steve Grubb
Modified: 2013-09-27 08:42 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 950615 (view as bug list)
Last Closed: 2013-09-27 08:42:49 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
audit: omit check for uid and gid validity in audit rules and data (2.38 KB, patch)
2013-03-05 21:36 EST, Richard Guy Briggs
rbriggs: review+
Details | Diff

  None (edit)
Description Steve Grubb 2013-01-28 13:58:40 EST
Description of problem:
The stig.rules file has a line like this:

-a always,exit -F arch=b32 -S creat -S open -S openat -S truncate -S ftruncate -F exit=-EACCES -F auid>=500 -F auid!=4294967295 -k access

When its run, it returns EINVAL:

# auditctl -a always,exit -F arch=b32 -S creat -S open -S openat -S truncate -S ftruncate -F exit=-EACCES -F "auid>=500" -F "auid!=4294967295" -k access
Error sending add rule data request (Invalid argument)

Version-Release number of selected component (if applicable):
Comment 1 Stephen Fromm 2013-02-01 15:19:48 EST
I bumped into the same problem on F17 with kernel-3.7.3-101.fc17.x86_64.  Rules fail to load and then auditd stops.
Comment 2 Steve Grubb 2013-03-04 13:04:13 EST
Ping? Any movement on this? This is still broke on 3.8.1 kernel even though we talked about fixing this on 3.7.6. Any ETA? Thanks.
Comment 3 Eric Paris 2013-03-05 13:11:23 EST

If you look in kernel/audit_filter.c::audit_rule_to_entry() you will see he added:

f->uid = make_kuid(current_user_ns(), f->val);
if (!uid_valid(f->uid))
        goto exit_free;

however UID_INVALID is actually perfectly valid...  We shouldn't do the check at all and should just leave f->uid == UID_INVALID.

The rest of the filter code should then be tested to make sure it can still match properly....
Comment 4 Richard Guy Briggs 2013-03-05 21:36:40 EST
Created attachment 705758 [details]
audit: omit check for uid and gid validity in audit rules and data

Remove the check for invalid uid and gid when parsing rules and data for logging.

Revert part of ca57ec0f00c3f139c41bf6b0a5b9bcc95bbb2ad7 (2012-09-11) to fix this.

Tested on f18 kernel 3.9-rc1 6dbe51c251a327e012439c4772097a13df43c5b8 with:
     auditctl -a always,exit -F arch=b32 -S creat -S open -S openat -S truncate -S ftruncate -F exit=-EACCES -F "auid>=500" -F "auid!=4294967295" -k access
Comment 5 Eric Paris 2013-03-06 10:34:44 EST
So you proved that rule loads.

Did it work?
does a auid==-1 work?
Comment 6 Richard Guy Briggs 2013-03-08 13:38:31 EST
Yes. I added a rule:

  auditctl -a exit,always -F path=/etc/cups/cupsd.conf -F "auid=4294967295" -k etc-cups-cupsd.conf


  systemctl start cups.service

which produced the expected:

  type=SYSCALL msg=audit(1362767586.796:671): arch=c000003e syscall=4 success=yes exit=0 a0=7fff7f8b5300 a1=7f2cfd213050 a2=7f2cfd213050 a3=a items=1 ppid=1 pid=6820 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="cupsd" exe="/usr/sbin/cupsd" subj=system_u:system_r:cupsd_t:s0-s0:c0.c1023 key="etc-cups-cupsd.conf"

while a simple

  cat /etc/cups/cupsd.conf

doesn't trigger that filter.
Comment 7 Steve Grubb 2013-03-19 13:56:31 EDT
Has this been posted to stable? Reminder...anyone trying to use the audit system cannot. Let's try to get this in 3.8.4 if we can. Thanks.
Comment 8 Josh Boyer 2013-03-19 14:09:45 EDT
As far as I know, Richard or Eric haven't posted this upstream anywhere.  It isn't going to make 3.8.4 because patches for stable kernels need to be in Linus' tree first.
Comment 9 Richard Guy Briggs 2013-03-20 16:00:29 EDT
I had posted a patch attachment here, hoping to get a quick ack from those Cc-ed to this bz and then forgot about it.

I've just posted it (yesterday's post didn't go through):

I'll post to stable when I get a nod.
Comment 10 Richard Guy Briggs 2013-04-17 14:08:04 EDT
April 9th, Eric Biederman posted a counter-patch:

April 16th I tested it works as expected.
Comment 11 Josh Boyer 2013-09-27 08:42:49 EDT
Eric's patch went into 3.10, so this has been fixed for quite some time.

Note You need to log in before you can comment on or make changes to this bug.