Skip to contentSkip to conversation

auditctl -l listing with correct operators

PATCH In review Michael C Thompson 3 participants 4 messages May 17, 2006 – May 18, 2006

lore
Share & tools
lore

Michael C Thompson

author
#0 lore raw

PATCH 1/1 auditctl -l listing with correct operators

With the current version of audit, auditctl -l only prints an equal, not equal operator when it displays rules, while the rules in the kernel are operating correctly, this is most an inconvenience, since is not possible to tell what rules are really in the kernel.

The problem lies in the audit_print_reply logic not detecting the type of the message (either AUDIT_LIST or AUDIT_LIST_RULE).

Below is a patch which adds this detection.

Thanks,
Mike

----

Signed-off-by Michael Thompson <[email protected]>
src/auditctl.c 2006-05-16 15:56:31.000000000 -0500 renamed from src/auditctl.c 2006-05-12 14:59:59.000000000 -0500 +8 -2
@@ -926,8 +926,14 @@ static int audit_print_reply(struct audi
             for (i = 0; i < rep->rule->field_count; i++) {
                 int field = rep->rule->fields[i] &
                     ~AUDIT_OPERATORS & ~AUDIT_NEGATE;
-                int op = rep->rule->fields[i] &
-                    (AUDIT_OPERATORS | AUDIT_NEGATE);
+                int op;
+                if (rep->type == AUDIT_LIST_RULES) {
+                    op = rep->ruledata->fieldflags[i] &
+                        (AUDIT_OPERATORS | AUDIT_NEGATE);
+                } else {
+                    op = rep->rule->fields[i] &
+                        (AUDIT_OPERATORS | AUDIT_NEGATE);
+                }
 
                 const char *name = audit_field_to_name(field);
                 if (name) {
author
#1 lore raw
Quoted 8 lines · Michael C Thompson

With the current version of audit, auditctl -l only prints an equal, not equal operator when it displays rules, while the rules in the kernel are operating correctly, this is most an inconvenience, since is not possible to tell what rules are really in the kernel.

The problem lies in the audit_print_reply logic not detecting the type of the message (either AUDIT_LIST or AUDIT_LIST_RULE).

Below is a patch which adds this detection.

Thanks,
Mike

This thread is technically a repost, because I realized that hiding a patch inside a big discussion thread is probably a no-no, and its just a dumb idea to begin with. Oh well, live and be dumb.

Below is some testing between the original code and the patched code.

# auditctl -a entry,always -S chmod -F 'uid=100'
# auditctl -a entry,always -S chmod -F 'uid>200'
# auditctl -a entry,always -S chmod -F 'uid>=300'
# auditctl -a entry,always -S chmod -F 'uid!=400'
# auditctl -a entry,always -S chmod -F 'uid<500'
# auditctl -a entry,always -S chmod -F 'uid<=600'
# auditctl -l    [ audit-1.2.2 auditctl pre-patch]
LIST_RULES: entry,always uid=100 (0x64) syscall=chmod
LIST_RULES: entry,always uid=200 (0xc8) syscall=chmod
LIST_RULES: entry,always uid=300 (0x12c) syscall=chmod
LIST_RULES: entry,always uid=400 (0x190) syscall=chmod
LIST_RULES: entry,always uid=500 (0x1f4) syscall=chmod
LIST_RULES: entry,always uid=600 (0x258) syscall=chmod
# auditctl -l   [ audit-1.2.2 auditctl post-patch ]
LIST_RULES: entry,always uid=100 (0x64) syscall=chmod
LIST_RULES: entry,always uid>200 (0xc8) syscall=chmod
LIST_RULES: entry,always uid>=300 (0x12c) syscall=chmod
LIST_RULES: entry,always uid!=400 (0x190) syscall=chmod
LIST_RULES: entry,always uid<500 (0x1f4) syscall=chmod
LIST_RULES: entry,always uid<=600 (0x258) syscall=chmod

Thanks,
Mike

#2 lore raw
Quoted 36 lines · Michael C Thompson
Quoted 5 lines · Michael C Thompson

With the current version of audit, auditctl -l only prints an equal, not equal operator when it displays rules, while the rules in the kernel are operating correctly, this is most an inconvenience, since is not possible to tell what rules are really in the kernel.

Quoted 7 lines

The problem lies in the audit_print_reply logic not detecting the type of the message (either AUDIT_LIST or AUDIT_LIST_RULE).

Below is a patch which adds this detection.

Thanks,
Mike

This thread is technically a repost, because I realized that hiding a patch inside a big discussion thread is probably a no-no, and its just a dumb idea to begin with. Oh well, live and be dumb.

Below is some testing between the original code and the patched code.

# auditctl -a entry,always -S chmod -F 'uid=100'
# auditctl -a entry,always -S chmod -F 'uid>200'
# auditctl -a entry,always -S chmod -F 'uid>=300'
# auditctl -a entry,always -S chmod -F 'uid!=400'
# auditctl -a entry,always -S chmod -F 'uid<500'
# auditctl -a entry,always -S chmod -F 'uid<=600'
# auditctl -l    [ audit-1.2.2 auditctl pre-patch]
LIST_RULES: entry,always uid=100 (0x64) syscall=chmod
LIST_RULES: entry,always uid=200 (0xc8) syscall=chmod
LIST_RULES: entry,always uid=300 (0x12c) syscall=chmod
LIST_RULES: entry,always uid=400 (0x190) syscall=chmod
LIST_RULES: entry,always uid=500 (0x1f4) syscall=chmod
LIST_RULES: entry,always uid=600 (0x258) syscall=chmod
Quoted 8 lines
# auditctl -l   [ audit-1.2.2 auditctl post-patch ]
LIST_RULES: entry,always uid=100 (0x64) syscall=chmod
LIST_RULES: entry,always uid>200 (0xc8) syscall=chmod
LIST_RULES: entry,always uid>=300 (0x12c) syscall=chmod
LIST_RULES: entry,always uid!=400 (0x190) syscall=chmod
LIST_RULES: entry,always uid<500 (0x1f4) syscall=chmod
LIST_RULES: entry,always uid<=600 (0x258) syscall=chmod

This looks good, Mike.

:-Dustin