Bug 905179 - audit rules with -F "auid!=4294967295" return EINVAL
Summary: audit rules with -F "auid!=4294967295" return EINVAL
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 18
Hardware: Unspecified
OS: Unspecified
urgent
high
Target Milestone: ---
Assignee: Richard Guy Briggs
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 853068
TreeView+ depends on / blocked
 
Reported: 2013-01-28 18:58 UTC by Steve Grubb
Modified: 2013-09-27 12:42 UTC (History)
9 users (show)

Fixed In Version:
Clone Of:
: 950615 (view as bug list)
Environment:
Last Closed: 2013-09-27 12:42:49 UTC
Type: Bug
Embargoed:


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

Description Steve Grubb 2013-01-28 18:58:40 UTC
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):
kernel-3.7.4-204.fc18.x86_64

Comment 1 Stephen Fromm 2013-02-01 20:19:48 UTC
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 18:04:13 UTC
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 18:11:23 UTC
ca57ec0f00c3f139c41bf6b0a5b9bcc95bbb2ad7

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-06 02:36:40 UTC
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 15:34:44 UTC
So you proved that rule loads.

Did it work?
does a auid==-1 work?

Comment 6 Richard Guy Briggs 2013-03-08 18:38:31 UTC
Yes. I added a rule:

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

then

  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 17:56:31 UTC
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 18:09:45 UTC
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 20:00:29 UTC
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):
https://www.redhat.com/archives/linux-audit/2013-March/msg00039.html
https://lkml.org/lkml/2013/3/20/524

I'll post to stable when I get a nod.

Comment 10 Richard Guy Briggs 2013-04-17 18:08:04 UTC
April 9th, Eric Biederman posted a counter-patch:
  https://www.redhat.com/archives/linux-audit/2013-April/msg00010.html
  https://lkml.org/lkml/2013/4/9/264

April 16th I tested it works as expected.

Comment 11 Josh Boyer 2013-09-27 12:42:49 UTC
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.