linux-audit / audit-kernel Goto Github PK

The AUDIT_MAC_POLICY_LOAD event is missing some information:

type=MAC_POLICY_LOAD msg=audit(1479299795.404:43): policy loaded auid=4294967295 ses=4294967295

There should be results even if its hard coded as success. Also, what policy version got loaded (ok if not available), which MAC framework (selinux/smack/apparmor), and uid might be useful in telling if the user had changed accounts.

The exclude filter was created a long time ago to filter out SELinux AVC's to meet the Common Criteria profile for CAPP. Currently the only field that can be used for filtering is the msgtype field. There are times when an admin may want to exclude events coming from user space or syscall events using uid, auid, session ID, or even SELinux types.

The lowest common denominator is the credentials that come from netlink during user space originating events. It might be possible to combine the filters for user and exclude which would give a little more flexibility in writing rules for the exclude filter. The only issue is the semantics are different between them. The user filter passes selected events where the exclude deletes selected events.

Currently audit tree rule removal is an unaccompanied record that has no subject attributes.

• kernel/audit_tree.c:audit_tree_log_remove_rule()
  compare with:
• kernel/audit_watch.c:audit_watch_log_rule_change()

Add "auid" and "ses".

Almost all AUDIT_NETFILTER_CFG events have a syscall and proctitle record. Every now and then we get an event like this:

type=NETFILTER_CFG msg=audit(1479622038.866:2): table=filter family=2 entries=0

and that is all there is. I have no idea what this event means or why it was emitted.

Hook the audit system into the Linux Kernel's device layer to capture and record device attach and detach events, also hook significant upper layers to capture notable metadata about the device, e.g. serial #, device and vendor IDs, etc.

• GH Feature Page

Currently the AUDIT_MAC_POLICY_LOAD record includes dangling keywords:

• security/selinux/selinuxfs.c:sel_write_load(): "policy loaded auid=%u ses=%u"

Switch "policy loaded" to "op=policy_load" or "op=load_policy".

Additionally, should auid= and ses= be dropped if this record is accompanied by a syscall record? If not, then should the context passed to audit_log() be NULL?

The lack of namespace identifiers in audit records can make interpreting audit records difficult in some configurations. Pay special attention to the fact that this issue is about namespace identifiers and not container identifiers; while this work will help track activities associated with containers, ultimately it is the container engine which will need to create/assign/manage the container identifier.

I'm concerned there may be a race issue with multiple threads calling into auditd_reset(), e.g. the kauditd_thread and various processes via audit_log_end() or similar. Investigate this and correct if necessary.

See #30 for more information.

When you run load_policy, you get this in the logs:

type=USER_AVC msg=audit(1485430158.330:324): pid=833 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: received policyload notice (seqno=2) exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'

There's a lot of dangling text (avc: received policyload notice (seqno=2)). Two possible solutions: 1) send user_mac_policy_load event with no additional text, or 2) change dangling text to op=cleared-cache.

Record the module name passed as an argument to init_module(2). A simple reproducer is shown below:

1. Add "-a always,exit -F arch=x86_64 -S init_module -F key=mod-load" to the audit rules
2. Reboot the system
3. Run 'ausearch --start today -k mod-load -i | less'

We keep a cache of audit buffers that is implemented as a simple list maintained by the audit subsystem, we really should look into leveraging the existing kernel mechanisms and not using our own caching mechanism.

Possible solutions include a straight removal of the cache and reliance on the SLUB cache as well as the creation of an audit buffer specific kmem_cache.

Log information about programs connecting and disconnecting to the audit netlink multicast socket. This is needed so that during investigations a security officer can tell who or what had access to the audit trail. This helps to meet the FAU_SAR.2 requirement for Common Criteria.

This issue will require the addition of a new test in the audit-testsuite as well as a new RFE page in the audit kernel wiki.

• https://github.com/linux-audit/audit-testsuite
• https://github.com/linux-audit/audit-kernel/wiki/Template-RFE

Currently, iptables, ip6tables and arptables registration is logged but ebtables registration is not.

This is done indirectly by xt_register_table() calling xt_replace_table(), but ebt_register_table() does not call its counterpart do_replace() or do_replace_finish().

Add auditing similar to ebtables' do_replace_finish() to ebt_register_table().

The DISA STIG calls out for auditing both loading and unload kernel modules:

http://people.redhat.com/swells/scap-security-guide/RHEL/7/output/ssg-rhel7-guide-stig-rhel7-server-upstream.html#xccdf_org.ssgproject.content_group_auditing

We need the module name when delete_module is an auditable event.

Thanks

The adjtimex syscall takes a pointer to a structure as its argument. We have to be able to audit when someone or something changes the system clock because that affects correlation of events. Auditing this syscall floods the audit trail with status requests.

Add the ability to clear/reset the lost value from the output of 'auditctl -s':

# auditctl -s
enabled 1
failure 1
pid 1025
rate_limit 0
backlog_limit 8192
lost 66
backlog 0
backlog_wait_time 60000
loginuid_immutable 0 unlocked

There are some syscalls being emitted that have missing success and exit values. For example:

type=PROCTITLE msg=audit(11/16/2016 12:50:35.860:856) : proctitle=/lib/ld-linux.so.2 --verify /home/sgrubb/working/BUILDROOT/audit-2.7-1.fc24.x86_64/sbin/audisp-remote

type=SYSCALL msg=audit(11/16/2016 12:50:35.860:856) : arch=i386 syscall=exit_group a0=EXIT_FAILURE a1=0xffc738a4 a2=0x56621ca9 a3=0x0 items=0 ppid=20063 pid=20065 auid=sgrubb uid=sgrubb gid=sgrubb euid=sgrubb suid=sgrubb fsuid=sgrubb egid=sgrubb sgid=sgrubb fsgid=sgrubb tty=pts4 ses=5 comm=ld-linux.so.2 exe=/usr/lib/ld-2.23.so subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=32bit-abi

We really need to know if the syscall succeeded or not.

All we really want is the kernel module name. Reproducer is below:

1. Add "-a always,exit -F arch=x86_64 -S init_module -F key=mod-load" to the audit rules
2. Reboot the system
3. Run 'ausearch --start today -k mod-load -i | less'

Catch-all for any remaining audit queue backlog issues.
See:
https://bugzilla.redhat.com/show_bug.cgi?id=1129013
#23

• RFE: audit default backlog_wait_time setting
  Add audit_pid to the while loop conditions in audit_log_start()
  https://bugzilla.redhat.com/show_bug.cgi?id=1296189

• Ensure we don't have any special problems with systemd shutting down auditd, filling or blocking the queue. I don't like the idea of hard-coding a pid. Another method would be preferable.
  https://www.redhat.com/archives/linux-audit/2015-October/msg00071.html

• Potentially allow audit_cmd_mutex holders to bypass, override or jump to the head of the queue.
  https://www.redhat.com/archives/linux-audit/2015-October/msg00073.html

• Wake up waiting tasks when auditd goes away and put them on the hold queue
  audit: wake up audit_backlog_wait queue when auditd goes away
  https://www.redhat.com/archives/linux-audit/2015-October/msg00074.html
  https://www.redhat.com/archives/linux-audit/2015-November/msg00028.html

• audit: wake up kauditd_thread after auditd registers
  https://www.redhat.com/archives/linux-audit/2015-October/msg00075.html

On occasion SELinux AVC denials are dropped by the audit subsystem during early boot without any warnings about dropped audit records. This was reported as an issue with Android kernels but it is expected to be a problem with standard kernels as well.

In order to correlate an USER_AUTH event to a LOGIN event, we need to have the tty that's associated with the change in loginuid.

As described in the email thread below, it can sometimes be confusing when an admin attempts to set audit filters and syscall auditing has been disabled in the kernel. While we already return an error to the user, it seems like we could also emit a printk(...) message indicating that support has not been compiled into the kernel; other ideas are also welcome.

• https://www.redhat.com/archives/linux-audit/2016-October/msg00000.html

The auditd_reset() function, used to break the kernel/auditd connection, flushes the main backlog queue to the hold queue and in doing so bypasses the multicast send in kauditd_thread.

The *setxattr syscalls take 5 arguments. One that is important is the fifth argument, flags. This denotes creation or replacement of the extended attribute. A similar situation occurred for mmap where an auxiliary record was created to capture a syscall argument. I think we should have an auxiliary record added for *setxattr syscalls just to state what the flags value is. It should be a 1 field record (like mmap's) simply stating the flag value numerically.

When experimenting with the ANOM_LINK event creation, it was found that the proctitle record seemed to have the exe of the ppid instead of the pid's.

This has been observed on Fedora kernel 4.1.6-200.fc22.x86_64.

Reproducer

As a non-root user:

# cd /tmp
# ln -s /bin/passwd my-passwd

As root:

# ausearch --start recent -m anom_link -i
<verify you have nothing>
# chown lp /tmp/my-passwd       <- but use tab completion after /tmp/m
<this will fail>
# ausearch --start recent -m anom_link -i | grep PROCTITLE
type=PROCTITLE msg=audit(08/27/2015 19:22:40.823:1246) : proctitle=-bash 
type=PROCTITLE msg=audit(08/27/2015 19:22:40.824:1247) : proctitle=su - root 
type=PROCTITLE msg=audit(08/27/2015 19:22:40.824:1248) : proctitle=su - root 
type=PROCTITLE msg=audit(08/27/2015 19:22:43.489:1249) : proctitle=chown lp /tmp/my-passwd 

Expected Results

I would not expect su to be involved.

See the mailing list thread below for information:

• https://www.redhat.com/archives/linux-audit/2016-June/msg00029.html

Taken from the original report:

In function audit_log_single_execve_arg(), the whole argument is fetched from user space twice via copy_from_user(). In the first loop, it is firstly fetched (line 1038) to verify, aka looking for non-ascii chars. While in the second loop, the whole argument is fetched again (line 1105) from user space and used at line 1121 and line 1123 respectively depends on the previous verification.

The audit subsystem is adding a BPRM_FCAPS record when auditing setuid application execution. This is not expected as it was supposed to be limited to when the file system actually had capabilities in an extended attribute.

This was observed on Fedora kernel 4.1.5-200.fc22.x86_64.

Reproducer:

# auditctl -a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -F key=setuid-exec
# su - root
# ausearch --start recent -k setuid-exec -i

Actual results:
It lists all capabilities making the event really ugly to parse what is happening.

Expected results:
No BPRM_FCAPS record. The PATH record correctly records the setuid bit and owner.

Currently there are two formats for AUDIT_MAC_STATUS records:

• security/selinux/selinuxfs.c:sel_write_enforce(): "enforcing=%d old_enforcing=%d auid=%u ses=%u"
• security/selinux/selinuxfs.c:sel_write_disable(): "selinux=0 auid=%u ses=%u"

I assume the latter should be brought in line with the former? Or both be augmented to include all fields?

Additionally, should auid= and ses= be dropped if this record is accompanied by a syscall record? If not, then should the context passed to audit_log() be NULL?

From commit 7f49294:

At the moment the audit watch code is a lot more complex.  That code only
creates one fsnotify watch per parent directory.  That 'audit_parent' in
turn has a list of 'audit_watches' which contain the name, ino, dev of
the specific object we care about.  This just creates one fsnotify watch
per object we care about.  So if you watch 100 inodes in /etc this code
will create 100 fsnotify watches on /etc.  The audit_watch code will
instead create 1 fsnotify watch on /etc (the audit_parent) and then 100
individual watches chained from that fsnotify mark.

We should be able to convert the audit_watch code to do one fsnotify
mark per watch and simplify things/remove a whole lot of code.  After
that conversion we should be able to convert the audit_fsnotify code to
support that hierarchy if the optimization is necessary.

The commit below, present in the v4.9-rcX kernels, causes a regression in the selinux-testsuite that appears to be triggered whenever audit_log() is called under write_lock_irq(). Thanks to @stephensmalley for identifying the problem and contacting the patch's author. We are currently awaiting a fix from the author.

commit bc51dddf98c907b598e645ae4b277ed1295b6d5f
Author: WANG Cong <[email protected]>
Date:   Thu Sep 1 21:53:45 2016 -0700

    netns: avoid disabling irq for netns id

    We never read or change netns id in hardirq context,
    the only place we read netns id in softirq context
    is in vxlan_xmit(). So, it should be enough to just
    disable BH.

    Cc: Nicolas Dichtel <[email protected]>
    Signed-off-by: Cong Wang <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

We currently queue the audit unicast sends to a separate thread while we send the multicast messages immediately. There doesn't appear to be a reason why we can't also do the multicast send from the separate thread as long as we are careful to only queue the skb once and move the netlink tweaks to the dedicated kauditd_thread.

The cap_* fields swing in and out of PATH records.
If no capabilities are set, the cap_* fields are completely missing and when one of the cap_fi or cap_fp values is empty, that field is omitted.
Normalize the PATH record by always printing all 4 cap_* fields.

There are times when admins need to restrict audit events based on the session information. The session ID is in the netlink credentials coming from user space. They just didn't get added to the user filter when they were added to netlink. It would be nice to add them to the user filter.

The audit source files in the kernel reference Steve's Red Hat people page as the audit userspace utilities home. Once @stevegrubb flips the switch and migrates the userspace repository to linux-audit/audit-userspace we should update/remote the references in the kernel.

See discussion upstream:

• https://lkml.org/lkml/2016/7/31/98

The nlmsghdr->nlmsg_pid represents the sending task's Netlink port ID, which in the case of the kernel is 0 (zero). Historically the kernel audit subsystem has used a variety of different values, depending on the call site. Thankfully the audit userspace does not appear to check the port ID set in the Netlink message header as @rgbriggs states:

Ok, after digging through audit_get_reply() and adjust_reply(), I see
that you are checking the sockaddr_nl member nl_pid which is set by
netlink, and not checking the struct nlmsghdr member nlmsg_pid at all,
that was set by kaudit, the latter of which I was asking about, so this
value is ignored and it doesn't matter. You are using the nlmsghdr
members nlmsg_type, nlmsg_len, nlmsg_seq, nlmsg_flags, but not nlmsg_pid.

@stevegrubb Are these worth normalizing the listed fields?

• security/selinux/ss/services.c:security_validtrans_handle_fail():
  • "op=security_validate_transition seresult=denied oldcontext=%s newcontext=%s taskcontext=%s tclass=%s"
• security/selinux/ss/services.c:security_bounded_transition()
  • "op=security_bounded_transition seresult=denied oldcontext=%s newcontext=%s"
• security/selinux/ss/services.c:compute_sid_handle_invalid_context()
  • "op=security_compute_sid invalid_context=%s scontext=%s tcontext=%s tclass=%s"
• security/selinux/ss/services.c:security_sid_mls_copy()
  • "op=security_sid_mls_copy invalid_context=%s"

Should "oldcontext" be switched to "old-scontext", "newcontext" to "scontext", "taskcontext" to "tcontext"?

See the linux-audit mail list thread for details:

• https://www.redhat.com/archives/linux-audit/2016-May/msg00010.html

From: https://www.redhat.com/archives/linux-audit/2017-January/msg00077.html

AUDIT_NETFILTER_CFG records currently list:
table,family,entries

What is missing is everything about who sent it:
pid,uid,auid,ses,subj,exe,res

To make it compatible with the majority of records, suggested format is:
pid,uid,auid,ses,subj,table,family,entries,exe,res

We should improve/fix the seccomp logging such that we can accomplish the following two things:

• Enable/disable logging based on the seccomp action. One idea is to set a sysctl variable to the minimum action to allow, e.g. 0x00030000 to only log TRAP and KILL.
• Ensure proper logging, following the filter above, to dmesg/syslog when auditing is disabled.

While we've discussed this previously in various threads, the most recent to bring this up is from Andi Kleen:

• https://lkml.org/lkml/2016/4/9/70

The AUDIT_NETFILTER_PKT audit events are not normalized. They swing fields in and out based on settings rather than changing the value of the event. Here's one example in ./net/netfilter/xt_AUDIT.c:

if (ntohs(ih->frag_off) & IP_OFFSET) {
    audit_log_format(ab, " frag=1");
    return;
}

frag should always be set like:

audit_log_format(ab, " frag=%d", ntohs(ih->frag_off) & IP_OFFSET);

The ANOM_PROMISCUOUS record is declared with context included, attaching itself to a SYSCALL record, but it already includes some subject attributes.

Should this be an autonomous record or should it be accompanying a SYSCALL record?

Recommend either removing the subject attributes from the ANOM_PROMISCUOUS, or (preferably) making them more complete and not adding a context reference to the audit_log... call.

type=SYSCALL msg=audit(05/12/2017 19:11:13.254:109) : arch=x86_64 syscall=ioctl success=yes exit=0 a0=0x17 a1=SIOCBRADDIF a2=0x7fdb72d74ad0 a3=0x2 items=0 ppid=1 pid=2284 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=libvirtd exe=/usr/sbin/libvirtd subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 key=(null)
type=ANOM_PROMISCUOUS msg=audit(05/12/2017 19:11:13.254:109) : dev=virbr0-nic prom=yes old_prom=no auid=unset uid=root gid=root ses=unset

note: net/core/dev.c:__dev_set_promiscuity()

A shutdown race of audit_sock appears to be causing a GPF when audit_replace tries to get sock_sndtimeo after audit_sock has been reset.

Reported-by: Dmitry Vyukov [email protected]
Post:
Reproducer: The following program triggers GPF in sock_sndtimeo:
Eric Dumazet: Looks a bug added in commit 32a1dba
("audit: try harder to send to auditd upon netlink failure")
or 133e1e5 ("audit: stop an old
auditd being starved out by a new auditd")
Cong Wang: It is racy on audit_sock, especially on the netns exit path.

Currently, iptables, ip6tables and arptables table registration is logged but their unregistration and that of ebtables is not.

Log when netfilter tables are unregistered.

In ebtables this would be done in ebt_unregister_table(), in x_tables (for ipv4, arp, ipv6) it would be done in xt_unregister_table().

The audit entry filter is deprecated and should be removed. There was a plan to remove it around the 2.6.31 time frame, but that was missed.

The ANOM_LINK record duplicates fields ppid to subj from the SYSCALL record. This causes a problem in that which one is authoritative? I would go with SYSCALL's as being authoritative and delete the fields from ANOM_LINK.

to replicate:
cd /tmp
ln -s /etc/passwd my-passwd
su root
ls ./my-passwd
ausearch --start recent

type=PROCTITLE msg=audit(1476388218.833:1329): proctitle=6C73002D2D636F6C6F723D6175746F002F746D702F6D792D706173737764
type=PATH msg=audit(1476388218.833:1329): item=0 name="/tmp/my-passwd" nametype=UNKNOWN
type=CWD msg=audit(1476388218.833:1329): cwd="/root"
type=SYSCALL msg=audit(1476388218.833:1329): arch=c000003e syscall=4 success=no exit=-13 a0=7ffc2e20f626 a1=55e8a06aeb90 a2=55e8a06aeb90 a3=55e8a06aeb80 items=1 ppid=2333 pid=20581 auid=4325 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=5 comm="ls" exe="/usr/bin/ls" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=PATH msg=audit(1476388218.833:1329): item=0 name="/tmp/my-passwd" inode=716142 dev=00:26 mode=0120777 ouid=4325 ogid=4325 rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0 nametype=NORMAL
type=ANOM_LINK msg=audit(1476388218.833:1329): op=follow_link ppid=2333 pid=20581 auid=4325 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=5 comm="ls" exe="/usr/bin/ls" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 res=0

Capabilities were augmented to include ambient capabilities in v4.3 <58319057b7847667f0c9585b9de0e8932b0fdb08>.

Add ambient capabilities to the BPRM_FCAPS and CAPSET records.

For the *at syscalls, can we get the path from the FD being passed as an argument to be able to reconstruct what is being accessed? (Readlink in /proc/<pid>/fds/# shows the path, why can't this go into the record?) We may need a new auxiliary record type since this is neither the cwd or path.

When booting with audit_backlog_limit=8192, as soon as I log in I run "auditctl -s" I can see I've lost 73 events. Then I run "aureport --start boot" and I see 644 total events. This is nowhere near the 8192 limit that I asked for. Meaning that events should not be lost when the total is far less than the limit where it would have overflowed the queue. There is also no message in syslog saying that events were lost and a reason.

This was noticed on a 4.9.x kernel.

Currently, the AUDIT_KERNEL avc initialization message is:

• security/selinux/avc.c:avc_init(): "AVC INITIALIZED\n"

Switch it to "state=avc_initialized" at minimum, but preferably bring it in line with commit 7c397d0
adding "audit_enabled" and "res" fields and if these don't make sense, consider creating a new message type.

This should be an unaccompanied record, so send a context of NULL.